Изучаем методы тест-дизайна

Какие бывают техники тест-дизайна

В каждом тестировании (QA, Quality Assurance) должен быть этап тест-дизайна. На нем QA-аналитик создает набор тестов для дальнейшей работы. Указанный набор должен быть оптимальным для проекта. Оптимальность здесь означает максимально возможное покрытие проверяемых тестовых условий.

Цель тест-дизайна – уменьшить количество тестов без существенного ущерба для тестового покрытия. С помощью этого можно сэкономить ресурсы (и при необходимости направить их на другое тестирование). 

В тест-дизайне есть 6 популярных методов (техник). Давайте их рассмотрим.

1. Метод классов эквивалентности (Equivalence partitioning)

Класс эквивалентности – это подмножество входных данных, значения которых программа должна обрабатывать одним и тем же способом. Например, если в Интернет-магазине есть скидка 5% для сумм от 50 000 рублей, то сценарии с покупками 60 000 и 70 000 рублей должны однообразно предусматривать уменьшение стоимости заказа на эту скидку.

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

2. Анализ граничных значений (Boundary value testing)

Граничное значение – то значение входных данных, когда ПО должно менять метод обработки данных. В нашем примере – это стоимость покупки 50 000 рублей. До этого значения скидка не применяется, при этом значении и выше – скидка должна всегда снижать сумму к оплате на 5%.

Поскольку программа меняет способ обработки, то здесь потенциально могут быть дефекты. Значит, нам нужно проверить работу ПО при значениях 49 999 руб. 00 коп. и 50 000 руб. 00 коп. Иногда рекомендуют также на всякий случай проверить значение сразу за границей – 50 000 руб. 01 коп. Более подробно о граничных условиях и классах эквивалентности – см. статью на нашем сайте.

3. Попарное тестирование (Pairwise testing)

Данный метод исходит из гипотезы, что наибольшее количество дефектов возникает при взаимодействии двух входных параметров. В нашем примере это может быть, если владелец магазина захочет ввести еще скидку за оплату наличными (3%) и дополнительный сбор за доставку в зависимости от адреса (допустим, 3 тарифа). 

Т.е. теперь получается 3 входных параметра, а именно: 

1. Сумма – 2 опции (до 50 тыс. руб., 50 тыс.руб. и выше.);
2. Оплата – 2 опции (наличные и безнал);
3. Доставка – 4 опций (без доставки и 3 тарифа для доставки).

Даже с классами эквивалентности нам пришлось бы сделать 2 х 2 х 5 = 20 тестов. Но в попарном тестировании нам достаточно взять вот такой набор кейсов:

№ теста	Сумма	Оплата	Тариф
	До 50 тыс.руб.	Наличные	Без доставки
	До 50 тыс.руб.	Безнал	Тариф 1
	До 50 тыс.руб.	Наличные	Тариф 2
	До 50 тыс.руб.	Безнал	Тариф 3
	50 тыс.руб. и выше	Безнал	Без доставки
	50 тыс.руб. и выше	Наличные	Тариф 1
	50 тыс.руб. и выше	Безнал	Тариф 2
	50 тыс.руб. и выше	Наличные	Тариф 3

Например, в комбинации пары «Сумма»&«Оплата» есть 4 варианта: До 50 тыс.руб. + Наличные, До 50 тыс.руб. + Безнал, 50 тыс.руб. и выше + Наличные, 50 тыс.руб. и выше + Безнал. И все они есть в этом наборе. Также присутствуют все варианты, которые возможны для пар «Сумма»&«Тариф» и «Оплата»&«Тариф». Получается, что нам нужно сделать 8 проверок вместо 20.

Более подробно про метод попарного тестирования можно почитать в статье на нашем сайте.

4. Метод состояний и переходов (State-Transition Testing)

Это графический метод, в котором все состояния данного объекта показаны фигурами (например, прямоугольники, внутри которых название состояния), а возможные переходы – стрелками. Получается схема, с помощью которой можно составить необходимые проверки.

5. Матрица принятия решений (Decision Table Testing)

Это метод тест-анализа, когда все возможные сценарии работы ПО отражены в виде таблицы. Используется для того, чтобы сложный текст требований переложить в более наглядный табличный вид. Это позволяет проверить полноту и непротиворечивость вариантов.

Например, в нашем примере будет таблица из 20 колонок – возможных вариантов.

6. Сценарий использования (Use Case)

Метод тест-анализа, в котором описывается взаимодействие двух и более участников (обычно — пользователя) и ПО в виде сценария:

• кто взаимодействует с ПО;
• что он хочет сделать;
• с какой целью;
• какие шаги делает;
• как на эти шаги реагируют другие участники.

Use Case не содержит подробностей, как именно должен быть реализован сценарий. Также обычно нет описания интерфейса или элементов дизайна. В сценарии использования важно не «как?», а «что делает ПО?».

Сценарии использования задействуются тестировщиками для разработки тест-кейсов и обнаружения недочетов в процессах взаимодействия участников.

Резюме

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