У нас есть масштабный проект, который нужно тестировать.

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

В статье расскажем и покажем на примерах,

• как mind maps помогают лучше тестировать,
• как писать тест-кейсы для масштабного проекта,
• как оценить, хороши тест-кейсы или нет.

Вот что умеет наш проект:

• продавать авиабилеты, обменивать и возвращать,
• продавать дополнительные услуги пассажирам (этих услуг сейчас 15, включая продажу, возврат и отчетность),
• оформлять билеты и услуги как на собственные рейсы заказчика, так и на рейсы авиакомпаний-партнёров, что даёт определенную вариативность,
• различает типы пассажиров (тургруппы, корпоративные клиенты, льготники и т.д.), и для каждого типа есть свои особенности в оформлении билетов и услуг.

В этой системе работают пользователи с двумя базовыми ролями: для простоты назовём их «Агент» и «Кассир». Агент может продавать и билеты, и услуги. Кассир же продаёт только услуги. Функциональность ролей частично пересекается, что добавляет пикантности тестированию.

У пользователя помимо основной роли есть ограничения со стороны системы бронирования (например, принадлежность к тому или иному сообществу). В итоге для услуги «оформление багажа» в получается около 30-ти конечных веток функциональности.

Проблема: нужна методология, как вести тестовую документацию на проектах подобного масштаба.

Наш подход:

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

Mind map

В составлении карты приложения хорошо себя показал метод исследовательского тестирования.

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

Что ж, посмотрим, как этот метод нам поможет.

В первую очередь выделяем области, которые могут нас заинтересовать при тестировании (исследовательский подход). Это конечно же, функциональность приложения, интеграция с другими сервисами, а также способы мониторинга и надёжность. Не слишком-то и много, но нам хватит.

Раскручиваем. С какими внешними сервисами мы интегрируемся? На что это влияет в нашей системе? Какую функциональность мы предоставляем пользователю? Давайте разбивать функциональность на части.

Давайте возьмем одну функцию нашей системы — продажа багажа. Что нужно сделать, чтобы её оформить?

• Нужен клиент, которому мы продаём.
• Ещё нам надо понять тип: со скидкой или без мы продадим этот багаж.
• Вспоминаем про то, что в системе две роли, и услуга должна быть доступна для обеих.

Самое главное — отдавать себе отчет в том, какую часть функциональности мы сейчас описываем.

Плохой пример: описать определение типа услуги для обеих пользовательских ролей.

Хороший пример: отдельно описать определение типа услуги, отдельно — что услуга выписывается под обеими ролями, когда мы уже уверены, то её тип определяется правильно.

Получается примерно так:



Для интереса можно также рассмотреть интеграционные ветки:



Что ещё хорошо: в процессе составления наглядно видно, как мы будем группировать тест-кейсы по сьютам. И если какая-то группировка окажется неудачной, то можно оперативно перегруппировать.

Какие ограничения

К сожалению, mind map недостаточно по трем причинам:

• это описание доступной функциональности, а не сценарии тестирования,
• над ними неудобно работать командой,
• неудобно собирать статистику по пройденным сценариям.

Все эти проблемы решаются написанием тест-кейсов.

Тестовый случай (Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. (Источник)

Если в mind map упор был на описание, а в тест-кейсе упор уже будет на проверку.

Тест-кейсы на практике

Чего мы хотим от тест-кейсов?

1. Чтобы из названия было понятно, что именно мы проверяем. Мы составляем отчет о тестировании в формате Excel. В отчете по названию тест-кейса должно быть понятно, что работает, а что нет.
2. Чтобы они были атомарными, то есть одно действие пользователя/системы равнялось одному тест-кейсу.
3. Чтобы оставалось место для человеческого фактора и творчества. Этим мы автоматически обезопасим себя от «парадокса пестицида».
4. Чтобы тестировщик понимал, что он проверяет и почему должно работать именно так (воспитание критического взгляда).

Как написать хороший тест-кейс. Первый пример

Давайте посмотрим на тест-кейсы более пристально. Начнём с первого и главного — авторизации в систему. Внимательно смотрим на эту картинку:



Что с ней не так? А вот что.

• Если в итоге тестирования этот тест-кейс упадёт, то что это будет означать? Что для вас значит фраза «Авторизация в систему не работает»? Страница авторизации не открылась? Ошибка «Пользователь не найден»? Сервис авторизации «прилег» и на все запросы отвечает кодом 500? Пользователь авторизовался, но элементы на UI не прорисованы? Пользователь авторизовался, но видит «не свой» интерфейс? Получается, мы увидели проблему, но не поняли причину и при каких условиях она возникает.
• Сценарий не атомарен. Всё смешано всё в кучу: и определение роли, и проверка на наличие доступа, и кнопка логаута.
• Допустим, что тестировщик авторизовался всеми указанными пользователями и увидел, что открылся один и тот же UI. Это потому, что наша система сломалась, или потому, что такие данные пришли извне? Неясно.

Давайте посмотрим на него ещё раз, имея в голове карту приложения и ветку про интеграцию в частности. Рассмотрим первые два шага этого тест-кейса — какой UI мы показываем в зависимости от роли.

Мы узнаём о роли пользователя из тех данных, что приходят извне. Соответственно, напрашивается уже другое название тест-кейса: «Определение роли пользователя при авторизации». Переименовываем его.

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

Исправим всё это и получим вот что:



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

Аналогично создаем следующий сценарии: «У пользователя нет роли в системе», «Логаут из приложения». Да, сценариев станет больше, зато проверки будут более осмысленными.

Второй пример

Давайте посмотрим, как описывать тест-кейсы для функциональных проверок на примере продажи багажа. В теории mind map выглядел просто, а на практике только на определение типа услуги построено вот сколько веток:



Задаемся вопросом, под кем надо авторизоваться, чтобы это проверить. Можно честно авторизоваться под агентом и пройти все проверки, а потом повторить то же самое с кассиром.

А можно подумать и задать себе вопрос:«Что именно мы сейчас проверяем-то?» Правильность определения типа услуги. В нашем случае этот сценарий одинаков для обеих ролей. Значит, не так уж важно, под какой ролью мы его проверим. Одним вопросом мы сэкономили время на тестирование.

Третий пример

Вот сценарий оформления услуги на рейс «Туда-Обратно», написанный до mindmap и вопросов о смысле наших действий. Давайте посмотрим на него свежим взглядом.



Итак, мы оценили первый шаг и задали наводящие вопросы менеджеру проекта: «Автоматически выбран ближайший рейс, а почему? Какие варианты выбора у нас есть ещё?» Узнали, что нюансы дефолтного выбора рейса для оформления услуги довольно обширны, и рейс «туда-обратно» — это только частность.

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

Подведем итоги

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

В процессе осознания подхода к написанию тест-кейсов незаметно родились такие вещи как:

• методология составления тест-кейсов: всем понятно, откуда брать сценарии, как их писать и как их ревьюить,
• база знаний, где есть не только логины, но и «как поменять курс валют в БД», «как внести изменения в файл настроек», «какие классы эквивалентности используются в проекте» и т.д.,
• максимальная локализация потенциального бага.

И самое главное. Мы перешли к тестированию самого механизма, а не результата. Потому что результат может быть разным, но мы должны понимать, проблема в механизме или в чем-то другом.