Комментарии 6
Карты Карно?
Карты Карно все же больше подходят тогда, когда итоговый результат представлен булевым значением или "Да"/"Нет". А результат при применении таблиц решений обычно представлен более сложным поведением системы, чаще это несколько результатов для разных переменных или сущностей.
Как формально доказать, что Ваша таблица верна? Вывод формируется комбинацией нескольких признаков - когда входных переменных 2-3, и выходных комбинаций примерно столько же - ещё можно умозрительно валидировать тестовую карту. Если их уже 4 на 4 - появляется существенная вероятность допустить ошибку.
Да, вероятность ошибки всегда есть, но у меня на практике ни разу не было такого. Чаще всего я делаю такие таблицы на алгоритмы или формы, для которых может быть по 5-10 условий и 2-10 результатов, и таких тестов может быть 100+ и больше. Поэтому сначала я составляю и все внимательно отсматриваю по результатам, а потом иногда отдаю аналитикам на проверку и согласование правильности. Но если бы это было 100+ тест-кейсов отдельных для фичи, то врядли бы это было наглядно и просто использовать для тестирования, я уже не говорю про использования таких тест-кейсов разработчиками для предварительной отладки.
Поэтому уже не на одном проекте я использую эту технику и это успешно заходит для всех участников проекта. Кроме того это достаточно быстро (даже на самые сложные фичи уходит 1-2 дня всего на весь тест-дизайн), если уже есть опыт составления таких таблиц.
Неудивительно, что описания тест-кейзов менее наглядны, чем этот чарт - так как они по сути одномерны, а чарт - двумерен ;). Чтобы воспринимать модель по набору сечений - нужен навык достраивания ее в голове - это вам скажет любой конструктор.
Да, этот формат более нагляден и доступен широкой публике - но формальный пруф его корректности затруднён - скорее всего, в той же мере, в какой его восприятие легче.
Пытаться представить большее количество информации меньшим - самообман. Если для 99 из 100 моделей это эмпирически удаётся, значит условная 100-я модель будет в этой схеме совершенно непредставима.
Никто не мешает по таблице написать тест-кейсы, если есть проблемы с их пониманием у кого-то в команде... Но задача тест-дизайна как раз в том и состоит, чтобы сокращать время на тестовую документацию и тестирование. А учиться нужно всему, хотя в agile-командах проблем с достраиванием в голове модели работы фич не должно быть, поскольку это повседневная активность, учитывая, что не на всех проектах есть хоть какая-то даже поверхностная документация и достаточно времени на написание подробных тест-кейсов на все-все фичи...
Но тут скорее, на вкус и цвет - на всех проектах выбирают то, что им больше подходит под их реальность и скорость разработки/выпусков. Поэтому это всего лишь вариант, как можно сократить время и написать быстро тесты, покрыв фичи достаточным количеством проверок.
Таблица решений для тестирования фильтрации с зависимыми фильтрами