Техника тест-дизайна «Таблица решений» - одна из самых сложных для применения, но одна из самых удобных для тестирования сложных бизнес-фич, когда есть более одного условия и одно/несколько действий системы как результат выполнения или не выполнения этих условий. Также при формировании таблицы часто используются техники «Классы эквивалентности» и «Граничные значения».
О том, что это за техника и как правильно с ней работать, написана не одна статья (например, https://habr.com/ru/post/546432/), поэтому саму технику здесь я описывать не буду. Эта и последующие статьи скорее для тех, кто уже имеет представление об этой технике и хотел бы расширить границы ее использования на своих проектах.
В своей работе я часто использую эту технику для тестирования различных бизнес-фич:
фильтрации с зависимыми фильтрами
форм с зависимыми полями
данных в ответах на запросы API в зависимости от данных в запросе
алгоритмов с большим количеством входных условий/параметров и итоговых действий системы
и др.
Как показывает практика, такие таблицы удобно использовать не только для тестирования готовых фич, но также отдавать эти таблицы с тестами аналитикам и разработчикам до начала разработки или в процессе. Это помогает разработчику сразу более подробно разобраться в том, как должна быть реализована фича и какие могут быть кейсы, что очень экономит время тестировщиков в будущем.
В этой статье речь пойдет о составлении таблицы решений для фильтрации с зависимыми фильтрами. Для примера я взяла одну из фич со своего позапрошлого проекта, но названия полей и логика изменены, так как это закрытый проект.
Представим, что на веб-портале есть раздел с реестром данных по сущности, для которой существует статусная модель:
НЕ проведен осмотр
Проведен осмотр
Сформирован документ (на основе осмотра)
Подписан документ (сформированный на основе осмотра)
Для каждого из трех статусов «Проведен осмотр», «Сформирован документ», «Подписан документ» в разделе есть фильтр, в котором можно выбрать значения: «Не выбрано», «Да», «Нет». Все фильтры доступны для выбора, не зависимо от того, что было выбрано в другом фильтре из трех.
Для фильтрации по «Сформирован документ» и «Подписан документ» существует зависимость:
если документ сформирован, значит осмотр точно был пройден
если документ подписан, значит осмотр точно был пройден и документ на основании этого осмотра был сформирован
Для каждого сочетания выбранных значений в этих трех фильтрах должна отрабатывать своя логика фильтрации сущностей. В качестве условий для таблицы решений были выбраны три фильтра «Проведен осмотр», «Сформирован документ», «Подписан документ», а в качестве действия – результат фильтрации сущностей в разделе.
Итоговая таблица с тестами представлена ниже.
Времени на составление такой таблицы было потрачено намного меньше, чем если бы этот тест-дизайн был представлен в качестве отдельных тест-кейсов.
Наглядность таких тестов – это также большой плюс как для определения полноты покрытия фичи тестами и проверки правильности результата в тестах аналитиком проекта, так и для разработчика/тестировщика при отладке/тестировании самой фичи.
gleb_l
Карты Карно?
MalcKaterina Автор
Карты Карно все же больше подходят тогда, когда итоговый результат представлен булевым значением или "Да"/"Нет". А результат при применении таблиц решений обычно представлен более сложным поведением системы, чаще это несколько результатов для разных переменных или сущностей.
gleb_l
Как формально доказать, что Ваша таблица верна? Вывод формируется комбинацией нескольких признаков - когда входных переменных 2-3, и выходных комбинаций примерно столько же - ещё можно умозрительно валидировать тестовую карту. Если их уже 4 на 4 - появляется существенная вероятность допустить ошибку.
MalcKaterina Автор
Да, вероятность ошибки всегда есть, но у меня на практике ни разу не было такого. Чаще всего я делаю такие таблицы на алгоритмы или формы, для которых может быть по 5-10 условий и 2-10 результатов, и таких тестов может быть 100+ и больше. Поэтому сначала я составляю и все внимательно отсматриваю по результатам, а потом иногда отдаю аналитикам на проверку и согласование правильности. Но если бы это было 100+ тест-кейсов отдельных для фичи, то врядли бы это было наглядно и просто использовать для тестирования, я уже не говорю про использования таких тест-кейсов разработчиками для предварительной отладки.
Поэтому уже не на одном проекте я использую эту технику и это успешно заходит для всех участников проекта. Кроме того это достаточно быстро (даже на самые сложные фичи уходит 1-2 дня всего на весь тест-дизайн), если уже есть опыт составления таких таблиц.
gleb_l
Неудивительно, что описания тест-кейзов менее наглядны, чем этот чарт - так как они по сути одномерны, а чарт - двумерен ;). Чтобы воспринимать модель по набору сечений - нужен навык достраивания ее в голове - это вам скажет любой конструктор.
Да, этот формат более нагляден и доступен широкой публике - но формальный пруф его корректности затруднён - скорее всего, в той же мере, в какой его восприятие легче.
Пытаться представить большее количество информации меньшим - самообман. Если для 99 из 100 моделей это эмпирически удаётся, значит условная 100-я модель будет в этой схеме совершенно непредставима.
MalcKaterina Автор
Никто не мешает по таблице написать тест-кейсы, если есть проблемы с их пониманием у кого-то в команде... Но задача тест-дизайна как раз в том и состоит, чтобы сокращать время на тестовую документацию и тестирование. А учиться нужно всему, хотя в agile-командах проблем с достраиванием в голове модели работы фич не должно быть, поскольку это повседневная активность, учитывая, что не на всех проектах есть хоть какая-то даже поверхностная документация и достаточно времени на написание подробных тест-кейсов на все-все фичи...
Но тут скорее, на вкус и цвет - на всех проектах выбирают то, что им больше подходит под их реальность и скорость разработки/выпусков. Поэтому это всего лишь вариант, как можно сократить время и написать быстро тесты, покрыв фичи достаточным количеством проверок.