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

О том, что это за техника и как правильно с ней работать, написана не одна статья (например, https://habr.com/ru/post/546432/), поэтому саму технику здесь я описывать не буду. Эта и последующие статьи скорее для тех, кто уже имеет представление об этой технике и хотел бы расширить границы ее использования на своих проектах.

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

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

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

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

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

  • и др.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии (6)


  1. gleb_l
    09.05.2022 20:37

    Карты Карно?


    1. MalcKaterina Автор
      09.05.2022 21:30

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


      1. gleb_l
        09.05.2022 21:43

        Как формально доказать, что Ваша таблица верна? Вывод формируется комбинацией нескольких признаков - когда входных переменных 2-3, и выходных комбинаций примерно столько же - ещё можно умозрительно валидировать тестовую карту. Если их уже 4 на 4 - появляется существенная вероятность допустить ошибку.


        1. MalcKaterina Автор
          09.05.2022 22:08

          Да, вероятность ошибки всегда есть, но у меня на практике ни разу не было такого. Чаще всего я делаю такие таблицы на алгоритмы или формы, для которых может быть по 5-10 условий и 2-10 результатов, и таких тестов может быть 100+ и больше. Поэтому сначала я составляю и все внимательно отсматриваю по результатам, а потом иногда отдаю аналитикам на проверку и согласование правильности. Но если бы это было 100+ тест-кейсов отдельных для фичи, то врядли бы это было наглядно и просто использовать для тестирования, я уже не говорю про использования таких тест-кейсов разработчиками для предварительной отладки.

          Поэтому уже не на одном проекте я использую эту технику и это успешно заходит для всех участников проекта. Кроме того это достаточно быстро (даже на самые сложные фичи уходит 1-2 дня всего на весь тест-дизайн), если уже есть опыт составления таких таблиц.


          1. gleb_l
            09.05.2022 23:36

            Неудивительно, что описания тест-кейзов менее наглядны, чем этот чарт - так как они по сути одномерны, а чарт - двумерен ;). Чтобы воспринимать модель по набору сечений - нужен навык достраивания ее в голове - это вам скажет любой конструктор.

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

            Пытаться представить большее количество информации меньшим - самообман. Если для 99 из 100 моделей это эмпирически удаётся, значит условная 100-я модель будет в этой схеме совершенно непредставима.


            1. MalcKaterina Автор
              10.05.2022 15:30

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

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