Таблица принятия решений

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

В таких "спартанских" условиях умелое использование методологий разработки тестов выходит на передний план, т.к. необходимо сократить до минимума затраты на создание и поддержку тестовых сценариев. При этом важно поддерживать приемлемое качество последних, чтобы они не оседали мертвым грузом потраченного впустую времени, а приносили реальную пользу команде тестирования.

В этой статье я расскажу о своем опыте применения методологии "Таблицы принятия решений" (Decision Table, далее я буду использовать сокращение DT). Вся необходимая теория изложена в замечательной книге "A Practitioner's Guide to Software Test Design" by Lee Copeland.

Немного теории

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

В общем случае метод DT заключается в построении таблицы, содержащей следующие сущности:

Conditions (условия) - четко сформулированное описание входных условий (данных) для функционала. Формулировка условия должна быть выполнена в виде вопроса, на который можно дать однозначный ответ "да" или "нет" (или указать "не важно", но об этом чуть позже). Например, обязательное поле заполнено?
Rules (правила) - различные комбинации входных данных.
Actions (действия) - четко сформулированное описание ожидаемого результата, действия системы. Формулировка действия должна быть выполнена в форме утвердительного предложения. Обязательным является условие - одно предложение описывает только одно действие. Например, отображается сообщение об ошибке.
Area (область) - используется при составлении тестов для множества однотипных и имеющих небольшие различия модулей.

Разберем составление таблицы на примере тестирования формы авторизации.

 

Сценарий использования стандартный: пользователь указывает атрибуты учетной записи и щелкает по кнопке Login. 

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

Если пользователь не заполнил поля или заполнил неверными значениями, выводится соответствующее сообщение об ошибке.

В общем виде таблица принятия решений имеет следующий вид (я использую в работе MS Excel, но подойдет и любой другой редактор электронных таблиц):

Во всех проектах, в которых мне довелось работать действует единое соглашение относительно нумерации наборов данных - используются числа от 001 до 999. Поэтому, в дальнейшем я буду использовать данный формат, вместо Rule 1...N.

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

Затем выписываем возможные ожидаемые результаты в секцию Actions. На данном этапе обычно корректируется секция Conditions, т.к. в процессе сопоставления ожидаемых результатов и путей их достижения обнаруживаются пропущенные условия.

Затем полученная матрица заполняется возможными комбинациями входных условий. При этом каждая ячейка может иметь одно из трех значений: да, нет, неважно (обозначено текстурной заливкой). Использование значения "неважно" помогает сократить количество описываемых случаев, при этом обеспечить тот же уровень покрытия, что и при описании всех допустимых комбинаций условий. 

Рассмотрим на примере набора 001. Проверяем случай, когда пользователь не указал username и указал password. При этом третье условие становится заблокированным - значение не указано, соответственно о регистре символов речь идти не может. Так же заблокированы пятое и шестое условия. А вот регистр пароля в данном случае может как соответствовать, так и не соответствовать указанному в базе данных значению. В разрезе данного теста это неважно, т.к. по ожидаемому алгоритму исполнение не должно дойти до проверки пароля. Если вследствие какого-либо дефекта исполнение продолжится, то это будет обнаружено независимо от того какой регистр пароля будет использован. Исходя из вышесказанного тестовое покрытие не пострадает, можно оставлять выбор значения данного условия тестировщику, тем самым сокращая количество комбинаций с двух до одной.

Для каждой из комбинаций входных условий указывается ожидаемый результат. При этом необходимый action помечается словом "да", все остальные ячейки помечаются заливкой "неважно" для большей читаемости таблицы.

 

И "на десерт" - повторное применение DT. Предположим, тестируемая система состоит из нескольких модулей. Проверки формы авторизации для внешних потребителей мы описали, теперь нужно описать проверки той же формы для внутренних потребителей. Формы идентичны и имеют различие только в поведении кнопки Login (для внутренних потребителей она становится доступна только тогда, когда указаны username и password). Таким образом случаи 001 и 002 недоступны для второй формы.

Заполняем секцию Area, указываем оба портала. Затем помечаем любым удобным символом какие проверки необходимо выполнять для того или иного функционала. 

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

 

Текста теории получилось несколько больше, чем я ожидала. Поэтому реальные примеры использования в проектах (удачные и не очень) приведу в следующий раз. To be continued...