Как стать автором
Обновить

Таблица решений для тестирования фильтрации с зависимыми фильтрами

Время на прочтение 2 мин
Количество просмотров 12K

Техника тест-дизайна «Таблица решений» - одна из самых сложных для применения, но одна из самых удобных для тестирования сложных бизнес-фич, когда есть более одного условия и одно/несколько действий системы как результат выполнения или не выполнения этих условий. Также при формировании таблицы часто используются техники «Классы эквивалентности» и «Граничные значения».

О том, что это за техника и как правильно с ней работать, написана не одна статья (например, Decision Table — что это и как применять), поэтому саму технику здесь я описывать не буду. Эта и последующие статьи скорее для тех, кто уже имеет представление об этой технике и хотел бы расширить границы ее использования на своих проектах.

В своей работе я часто использую эту технику для тестирования различных бизнес-фич:

  • фильтрации с зависимыми фильтрами

  • форм с зависимыми полями

  • данных в ответах на запросы API в зависимости от данных в запросе

  • алгоритмов с большим количеством входных условий/параметров и итоговых действий системы

  • и др.

Как показывает практика, такие таблицы удобно использовать не только для тестирования готовых фич, но также отдавать эти таблицы с тестами аналитикам и разработчикам до начала разработки или в процессе. Это помогает разработчику сразу более подробно разобраться в том, как должна быть реализована фича и какие могут быть кейсы, что очень экономит время тестировщиков в будущем.

В этой статье речь пойдет о составлении таблицы решений для фильтрации с зависимыми фильтрами. Для примера я взяла одну из фич со своего позапрошлого проекта, но названия полей и логика изменены, так как это закрытый проект.

Представим, что на веб-портале есть раздел с реестром данных по сущности, для которой существует статусная модель:

  • НЕ проведен осмотр

  • Проведен осмотр

  • Сформирован документ (на основе осмотра)

  • Подписан документ (сформированный на основе осмотра)

Для каждого из трех статусов «Проведен осмотр», «Сформирован документ», «Подписан документ» в разделе есть фильтр, в котором можно выбрать значения: «Не выбрано», «Да», «Нет». Все фильтры доступны для выбора, не зависимо от того, что было выбрано в другом фильтре из трех.

Для фильтрации по «Сформирован документ» и «Подписан документ» существует зависимость:

  • если документ сформирован, значит осмотр точно был пройден

  • если документ подписан, значит осмотр точно был пройден и документ на основании этого осмотра был сформирован

Для каждого сочетания выбранных значений в этих трех фильтрах должна отрабатывать своя логика фильтрации сущностей. В качестве условий для таблицы решений были выбраны три фильтра «Проведен осмотр», «Сформирован документ», «Подписан документ», а в качестве действия – результат фильтрации сущностей в разделе.

Итоговая таблица с тестами представлена ниже.

Времени на составление такой таблицы было потрачено намного меньше, чем если бы этот тест-дизайн был представлен в качестве отдельных тест-кейсов.

Наглядность таких тестов – это также большой плюс как для определения полноты покрытия фичи тестами и проверки правильности результата в тестах аналитиком проекта, так и для разработчика/тестировщика при отладке/тестировании самой фичи.

Теги:
Хабы:
+2
Комментарии 6
Комментарии Комментарии 6

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн