Стратегии тестирования качества для аналитических панелей
Моя команда строит аналитическую панель для SaaS/ мультитенантного приложения с использованием Cognos. Проблема, с которой я сталкиваюсь, - это правильная стратегия тестирования.
Прямо сейчас тестирование одного отчета с фильтрами начальной и конечной даты (в формате месяц / год), одномерным фильтром и двумя элементами управления для выбора меры (есть 7 показателей, которые могут быть представлены в виде сумм или отдельных подсчетов).
Кроме того, пользователи могут детализировать точки в итоговом отчете до подробных данных транзакций.
Также подразумевается, что в отчетах по одному арендатору не отображаются данные по другому арендатору.
Итак, вот проблема. Тестирование этого простого отчета занимает две недели, включая сотни тестов для огромного набора комбинаций фильтров и мер. Мне кажется, это излишнее излишество.
Существует ли "стратегия", которую можно использовать для надежного сокращения пространства поиска и предотвращения чрезмерно повторяющегося тестирования?
3 ответа
Хороший вопрос! Когда мы обычно публикуем (или хотим) новые отчеты, основанные на Таблице, которые попадают в наш куб SSAS, мы обычно просим определенную группу людей выступать в качестве группы суперпользователей, чтобы использовать отчет, как если бы он был в производстве. Хотя это может и не занять определенного периода времени, скажем, у вас есть только 2 дня, чтобы протестировать его, но это будет продолжаться в течение нескольких недель. Тем временем исправления ошибок или изменения могут быть внесены и распространены в этой же группе без необходимости останавливать тестировщиков, заставлять их ждать исправления, а затем продолжать.
Не поймите меня неправильно, хотя крайняя дата запуска по-прежнему идеальна, но фактическое представление отчета в небольшой группе часто помогает продвинуться вперед быстрее, чем прохождение каждого теста параметров.
Похоже, они пытаются проверить "каждую возможную комбинацию", в которой может использоваться отчет. Возможно, было бы целесообразно сделать это для нескольких избранных отчетов, которые лучше всего представляют типичные или критические отчеты. Это поможет устранить серьезные недостатки в дизайне, архитектуре или реализации.
Но попытка проверить каждую возможную комбинацию для каждого отчета в надежде найти каждую ошибку невозможна. Предложение Ajdams имеет смысл и типично для требуемых "компромиссов". Все дело во времени, ресурсах и в том, что имеет наибольшее значение для ситуации.
Поэтому я бы предложил гибрид из двух (выберите небольшую горстку отчетов, для которых необходимо провести обширное тестирование, но убедитесь, что они сфокусированы на поиске ошибок, которые могут быть распространены в других отчетах). Затем протестируйте каждый отдельный отчет, используя такую технику, как айдамы.
Что действительно поможет вашему тестированию наверстать упущенное в скорости и надежности, так это подготовить сценарии тестов, которые включают в себя необходимые функции отчетов. Как предлагалось ранее, бета-группа пользователей поможет вам выявить ошибки и недостатки дизайна во время бета-тестирования.