Техника тест-дизайна «Таблица решений» - одна из самых сложных для применения, но одна из самых удобных для тестирования сложных бизнес-фич, когда есть более одного условия и одно/несколько действий системы как результат выполнения или не выполнения этих условий. Также при формировании таблицы часто используются техники «Классы эквивалентности» и «Граничные значения».
О том, что это за техника и как правильно с ней работать, написана не одна статья (например, Decision Table — что это и как применять), поэтому саму технику здесь я описывать не буду. Эта и последующие статьи скорее для тех, кто уже имеет представление об этой технике и хотел бы расширить границы ее использования на своих проектах.
В своей работе я часто использую эту технику для тестирования различных бизнес-фич:
фильтрации с зависимыми фильтрами
форм с зависимыми полями
данных в ответах на запросы API в зависимости от данных в запросе
алгоритмов с большим количеством входных условий/параметров и итоговых действий системы
и др.
Как показывает практика, такие таблицы удобно использовать не только для тестирования готовых фич, но также отдавать эти таблицы с тестами аналитикам и разработчикам до начала разработки или в процессе. Это помогает разработчику сразу более подробно разобраться в том, как должна быть реализована фича и какие могут быть кейсы, что очень экономит время тестировщиков в будущем.
В этой статье речь пойдет о составлении таблицы решений для фильтрации с зависимыми фильтрами. Для примера я взяла одну из фич со своего позапрошлого проекта, но названия полей и логика изменены, так как это закрытый проект.
Представим, что на веб-портале есть раздел с реестром данных по сущности, для которой существует статусная модель:
НЕ проведен осмотр
Проведен осмотр
Сформирован документ (на основе осмотра)
Подписан документ (сформированный на основе осмотра)
Для каждого из трех статусов «Проведен осмотр», «Сформирован документ», «Подписан документ» в разделе есть фильтр, в котором можно выбрать значения: «Не выбрано», «Да», «Нет». Все фильтры доступны для выбора, не зависимо от того, что было выбрано в другом фильтре из трех.
Для фильтрации по «Сформирован документ» и «Подписан документ» существует зависимость:
если документ сформирован, значит осмотр точно был пройден
если документ подписан, значит осмотр точно был пройден и документ на основании этого осмотра был сформирован
Для каждого сочетания выбранных значений в этих трех фильтрах должна отрабатывать своя логика фильтрации сущностей. В качестве условий для таблицы решений были выбраны три фильтра «Проведен осмотр», «Сформирован документ», «Подписан документ», а в качестве действия – результат фильтрации сущностей в разделе.
Итоговая таблица с тестами представлена ниже.
Времени на составление такой таблицы было потрачено намного меньше, чем если бы этот тест-дизайн был представлен в качестве отдельных тест-кейсов.
Наглядность таких тестов – это также большой плюс как для определения полноты покрытия фичи тестами и проверки правильности результата в тестах аналитиком проекта, так и для разработчика/тестировщика при отладке/тестировании самой фичи.
