Техники тест-дизайна: теория и примеры

Тест-дизайн — это процесс разработки техник и методов тестирования. Главная задача тест-дизайна — подготовить рабочую документацию, то есть разработать сценарии, которые позволят протестировать максимальное количество функций за минимальное время. Тестовая документация уникальна для каждого продукта. Разрабатывая её, тестировщик опирается на общие принципы и логику тестирования с поправкой на особенности продукта. Суть всех техник тест-дизайна — оптимизировать процесс тестирования.

Научиться анализировать требования к продукту и освоить техники тест-дизайна можно на курсе «Инженер по тестированию: от новичка до автоматизатора». Обучение длится 9 месяцев, обычно студенты могут брать первые рабочие проекты уже на 4―5 месяце обучения. Пройти первые уроки можно бесплатно.

Глобально все типы тестирования разделяют на функциональное и нефункциональное.

Реже встречается разделение на статическое и динамическое тестирование.

Выделяют три этапа тестирования:

1. Подготовка к тестированию. Тестировщик собирает информацию о продукте, изучая документацию и задавая вопросы. Цель этапа — максимально полно выяснить, каким областям и функциям программного продукта нужно уделить больше внимания.
На этапе подготовки важно понять, в каких окружениях будет проводиться тестирование, — это поможет корректнее оценить необходимое время. Условно на проверку продукта в одном окружении понадобится Х часов, а в пяти — Х*5 часов.

2. Собственно тестирование. Тест-дизайн начинается, когда тестировщик уже собрал все требования к продукту и понимает, как он должен работать. Иными словами, есть ожидаемое поведение и представление о работе продукта. Специалист последовательно проверяет продукт по составленным на первом этапе чек-листам и тест-кейсам и выясняет, корректно ли работает продукт при тех или иных условиях.

3. Анализ результатов тестирования. Тестировщику нужно выделить количество критичных багов, как результат можно представить детальную статистику о количестве и характере найденных ошибок. Удобно собирать такие метрики, разбивая функциональность на большие логические блоки: вёрстка, расчёты. Так можно составить карту и выделить конкретные области, на которые приходится большая часть ошибок. Это поможет в будущем при тестировании сразу акцентировать внимание на проблемных областях.

Если же тестировщик составил 100 тест-кейсов и нашёл 10 багов, а ещё 10 багов обнаружил за пределом кейсов, к составлению тестовой документации есть вопросы. Специалист что-то упустил при подготовке, не составил нужные кейсы и только чисто эмпирически нашёл эти 10 багов.

Обычно результат тестирования оформляют текстовым документом — это самый доступный и удобный формат. Реже их визуализируют в виде диаграмм и графиков.

Результаты выполнения тест-кейсов, оформленные в виде круговой диаграммы. Источник: performance-lab

Рассмотрим на примерах основные техники тест-дизайна. Часто они применяются комплексно, дополняя друг друга.

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

1. Не выдавать людям до 18 лет — первая граница.
2. Выдавать людям с 18 до 65 лет — вторая граница.
3. Не выдавать пенсионерам с 65 до 100 лет — третья граница.

Если тестировщик будет проверять все 100 значений от 0 до 99, ему придётся поработать со 100 кейсами — это займёт много времени. Оптимальнее будет разделить весь массив на группы, которые будут давать один и тот же результат, и протестировать всего три значения вместо 100. При любом значении от 0 до 18 лет система должна однозначно выдавать отказ в кредите, а при значении от 18 до 65 — согласие, а при значении от 65 до 100 — снова отказ. Значит, достаточно взять по одному значению в каждой группе, чтобы протестировать функцию.

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

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

Вернёмся к нашему примеру с кредитным калькулятором. Банк не даёт кредиты людям до 18 лет. Возникает вопрос: до 18 лет включительно? Разработчики и аналитики могли упустить этот момент в разработке требований, соответственно, на границе между 17 и 19 будут скапливаться ошибки.

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

Суть техники граничных значений ― найти ошибки в работе продукта на границах классов. В нашем примере тестировщик знает границу и проверяет приграничную область, делая шаг в глубь и за пределы диапазона, то есть тестирует систему на правильный ответ при вводе значений 17, 18 и 19 лет.

Суть техники граничных значений — в тщательной проверке границ каждого из классов

Эта техника тест-дизайна применяется, когда нужно проверить корректность работы системы по нескольким параметрам. Суть метода заключается в том, чтобы каждое значение хотя бы раз побывало в одной точке с другим значением. Техника попарного тестирования позволяет избежать избыточных проверок и сократить количество генерируемых тест-кейсов. Главный смысл техники попарного тестирования — оптимизировать время, которое тестировщик затратит на проверку.

Например, тестировщику нужно проверить работу браузерного приложения:
● в трёх операционных системах — Windows, MacOS, Linux;
● в трёх браузерах — Google Chrome, Яндекс Браузер, Mozilla Firefox;
● на двух языках — английском и русском.

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

Максимальное количество тест-кейсов в этой ситуации — 18: три операционные системы в трёх браузерах и на двух языках. Проверять 18 тест-кейсов долго и трудозатратно. По количеству пар можно сократить количество кейсов — в итоге нужно будет протестировать не 18, а только 9 кейсов.

Техника попарного тестирования позволяет избежать лишних проверок и сократить количество тест-кейсов

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

На примере кредитного калькулятора выделим параметры, при соблюдении которых банк выдаст кредит:
● возраст от 18 до 65 лет;
● работающий;
● с понятной целью — например, автокредит, потребительский или ипотечный.

Различные комбинации трёх параметров приводят к разному, заранее заложенному поведению системы.

Тестировщик составляет таблицу подобных нетипичных сочетаний, чтобы проверить все узкие места системы и найти ошибки в логике

Существенный минус техники принятия решений — её объёмность и трудозатратность. С другой стороны, метод позволяет выявить те ошибки, которые пропустят методы эквивалентного разделения и граничных значений. Его трёхмерность позволяет найти такие уникальные сочетания и ошибки, которые тестировщик обычно не предполагает увидеть.

Метод основан на интуиции тестировщика. Он хорошо работает только в том случае, если у специалиста достаточно опыта, в том числе пользовательского, и он отлично знает тестируемый продукт. Специалист на собственном опыте знает, в какой части системы накапливаются ошибки, какая область менее проработанная и сложная. Условно, тестировщик работает с продуктом не первый год и заранее понимает, в какой области функционала чаще случаются ошибки. В ходе тестирования он будет внимательнее именно к этим зонам и найдёт ошибки быстрее тестировщика, который впервые работает с этой системой.

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

Предугадывание ошибок — эмпирическая техника, которая доступна только опытным тестировщикам.