В последней части хотелось поговорить о тест-кейсах.

Существует несколько типичных сценариев, с которыми приходится сталкиваться на проекте:

1. Тест-кейсы отсутствуют полностью

2. Присутствуют чек-листы

3. Тест-кейсы не содержат достаточного объема информации

4. Тест-кейсы перегружены информацией

Тест-кейсы отсутствуют полностью.

Это самый простой и наименее трудоемкий вариант. Процесс здесь весьма предсказуем:

• Изучаем продукт.

• При наличии – разбираемся в требованиях.

• Определяем критичность функционала.

• Пишем тесты.

И, по сути, добавить здесь больше нечего.

Приведу пример из личного опыта.

Я пришел на проект, в котором:

• Отсутствуют тест-кейсы.

• Есть немного устаревшей документации

Мои действия:

1. Читаю документацию и забираю оттуда список ключевых частей продукта

2. Иду к аналитику и верифицирую свой список критически важного функционала

3. Создаю группы/папки в TMS по этому списку

4. Открываю тестовый стенд и собирают по каждой группе некоторое кол-во тестов, при этом еще и занимаюсь исследовательским тестированием

5. Документирую тест-кейсы и выставляю каждому из них критичность

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

Присутствуют чек-листы.

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

• Продолжать работу, опираясь непосредственно на содержимое чек-листов.

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

Пример:

Проект в котором есть текстовый документ со списком проверок. Вот в таком формате:

Приемка отправлений по накладной:

• Накладная с 5 простыми посылками

• Накладная с 1й коробкой, в которой посылки

• Накладная в которой 2 простые посылки и 1 коробка с 5ю вложенными посылками внутри

• Посылка отсутствует в накладной

Мои действия:

1. Иду в документацию и выясняю что такое "накладная", "простое отправление", "коробка с вложениями"

2. Если п.1 не увенчался успехом(а такое бывало), то иду к аналитику или разработчику, который это знает(ну или на крайний случай к лиду разработки, если это "ничейный" код)

3. Узнаю от аналитика или разработчика/лида как создавать накладные с нужными посылками(это можно сделать вместе с п1 или п2)

4. Создаю нужную мне накладную

5. Ищу функционал приемки накладной

6. Иду по флоу обработки накладной, параллельно сохраняя и описывая каждый шаг в заметки

В результате есть понимание:

• Как создавать накладные с нужной структурой посылок в ней(а в этом примере это самая сложная часть)

• Как работает механизм приемки посылок по накладной

• Есть на руках логика ветвления функционала обработки накладной(заметки из п.6)

В итоге написание тест-кейсов не составляет труда, так как мы имеем исчерпывающую информацию и подготовке данных и самом сценарии.

Тест-кейсы не содержат достаточного объема информации.

Самый простой способ решения подобной ситуации – это, пожалуй, устроить им символическое сожжение после ознакомления. И этому есть весомые причины:

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

• Формат. Далеко не все тестировщики придерживаются единого стиля написания тест-кейсов. Часто тест-кейсы создаются «под себя» и под собственный уровень понимания продукта.

• Актуальность. На одном из проектов действовало правило: «Если тест-кейс/автотест не выполняется более месяца, вероятнее всего, это уже мусор». Это утверждение особенно верно в условиях активной разработки и доработки определенных частей продукта.

• Время (снова). Решил выделить этот аспект отдельно, поскольку временные ограничения – это практически всегда данность. Если мы будем расходовать драгоценные часы на вычитку устаревших тест-кейсов, то неизбежно сократим время, которое могли бы уделить непосредственной работе с продуктом.

Пример:

На проекте есть механизм подписки.

Тест-кейс выглядит примерно так:

1. Пользователь выбирает годовую подписку

2. Создаем пользователю в системе "А" инвойс

3. Ожидаем чтобы "джоба" отработала и пользователю выставился счет

4. Пользователь оплатил подписку

Первое что мне бросается в глаза:

• Что за подписка там должна быть и какие подписки у нас вообще бывают

• Какие данные нам надо заполнить в системе "А" и где оно там вообще лежит

• Что за "джоба" в пункте номер 3

• А сколько времени нужно чтобы "джоба" отработала и как убедиться что оно отработала "мои данные"(не первый раз с джобами сталкиваюсь)

• где пользователь увидит что ему выставили счет, чтобы его оплатить

После выяснения всех моментов, сценарий оказался таким:

1. Пользователь с ролью "админ" открывает страницу оформления подписки в системе

2. Выбирает подписку "Professional" и тип платежа "ежемесячно"(да, данные в тесте оказались устаревшими)

3. Указывает данные банковской карты(необязательная опция на текущий момент, но как оказалось проверка была нужна.)

4. В систему "А" мы входим под пользователем с ролью "ADM"

5. В списке новый инвойсов находим аккаунт пользователя из п.1

6. Открываем инвойс и сравниваем тип подписки которая выставилась автоматически, с тем что отображается в специальном поле "ожидаемая подписка"

7. Нажимаем на "Выставить счет"

8. Здесь нужно подождать от 5 до 15 минут, чтобы сервис обновления подписок, обработал по расписанию. Или сделать "Force push" в сервисе обновления подписок. Он лежит тут "<ссылка на сервис>"

9. На странице сервиса, открываем вкладку "Logs" и выбираем интервал времени "последние 30 минут"

10. В строке поиска вводим accountId нужного нам аккаунта и видим сообщение "Invoice generated - done"

11. Заходим в наш продукт под пользователем из п.1

12. Открываем страницу подписки

Ожидаемый результат: У пользователя отображается тип подписки "Professional(Trial)", потому что на 7 дней с момента оформления подписки он должен выдаваться. Отображается кнопка "Оплатить" с данными по карте, которую мы привязали в п.3

Как можно заметить, сценарий значительно отличается в его детализации.

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

Тест-кейсы перегружены информацией.

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

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

Еще больше времени на прочтение. Придеться посидеть/поседеть и вычистить с каждого кейса мусор. Вот пример подобного тест-кейса:

Успешный вход администратора:

1. Вводим логин «админ» в поле «Логин».

2. Вводим пароль «1234567» в поле «Пароль».

3. Нажимаем кнопку «Войти».

4. Открылась главная страница административной панели.

5. В верхнем левом углу отображается логотип.

6. В верхнем правом углу отображается имя администратора.

7. По центру страницы отображается форма поиска.

Это далеко не полный перечень UI-элементов, упомянутых в реальном кейсе (их было около 16). Для меня ответ тут очевиден: все, что идет после четвертого пункта, является «мусором» для функционального теста (а четвертый пункт – это, по сути, ожидаемый результат). Почему старший QA-специалист с десятилетним опытом создал именно так, осталось для меня загадкой. Эти проверки не имеют никакого отношения к описанию функциональности.

Итог

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