В последней части хотелось поговорить о тест-кейсах.
Существует несколько типичных сценариев, с которыми приходится сталкиваться на проекте:
Тест-кейсы отсутствуют полностью
Присутствуют чек-листы
Тест-кейсы не содержат достаточного объема информации
Тест-кейсы перегружены информацией
Тест-кейсы отсутствуют полностью.
Это самый простой и наименее трудоемкий вариант. Процесс здесь весьма предсказуем:
Изучаем продукт.
При наличии – разбираемся в требованиях.
Определяем критичность функционала.
Пишем тесты.
И, по сути, добавить здесь больше нечего.
Приведу пример из личного опыта.
Я пришел на проект, в котором:
Отсутствуют тест-кейсы.
Есть немного устаревшей документации
Мои действия:
Читаю документацию и забираю оттуда список ключевых частей продукта
Иду к аналитику и верифицирую свой список критически важного функционала
Создаю группы/папки в TMS по этому списку
Открываю тестовый стенд и собирают по каждой группе некоторое кол-во тестов, при этом еще и занимаюсь исследовательским тестированием
Документирую тест-кейсы и выставляю каждому из них критичность
Вот и базовый каркас для тестового покрытия. Далее можно уже посмотреть в сторону менее приоритетных частей продукта.(если время позволяет)
Присутствуют чек-листы.
Если вы оказались в незнакомой предметной области, для начала лучше отложить его. Погрузившись в продукт, можно приступить к сортировке содержимого чек-листов по фичам или другим удобным вам категориям. После этого открываются два наиболее очевидных пути:
Продолжать работу, опираясь непосредственно на содержимое чек-листов.
Для каждого пункта чек-листа написать полноценный тест-кейс. В этом случае чек-лист по сути выполняет роль своеобразной дорожной карты покрытия.
Пример:
Проект в котором есть текстовый документ со списком проверок. Вот в таком формате:
Приемка отправлений по накладной:
Накладная с 5 простыми посылками
Накладная с 1й коробкой, в которой посылки
Накладная в которой 2 простые посылки и 1 коробка с 5ю вложенными посылками внутри
Посылка отсутствует в накладной
Мои действия:
Иду в документацию и выясняю что такое "накладная", "простое отправление", "коробка с вложениями"
Если п.1 не увенчался успехом(а такое бывало), то иду к аналитику или разработчику, который это знает(ну или на крайний случай к лиду разработки, если это "ничейный" код)
Узнаю от аналитика или разработчика/лида как создавать накладные с нужными посылками(это можно сделать вместе с п1 или п2)
Создаю нужную мне накладную
Ищу функционал приемки накладной
Иду по флоу обработки накладной, параллельно сохраняя и описывая каждый шаг в заметки
В результате есть понимание:
Как создавать накладные с нужной структурой посылок в ней(а в этом примере это самая сложная часть)
Как работает механизм приемки посылок по накладной
Есть на руках логика ветвления функционала обработки накладной(заметки из п.6)
В итоге написание тест-кейсов не составляет труда, так как мы имеем исчерпывающую информацию и подготовке данных и самом сценарии.
Тест-кейсы не содержат достаточного объема информации.
Самый простой способ решения подобной ситуации – это, пожалуй, устроить им символическое сожжение после ознакомления. И этому есть весомые причины:
Время. Вы рискуете потратить колоссальное количество времени на чтение и осмысление этих кейсов. Погружение в каждый из них потребует значительных усилий.
Формат. Далеко не все тестировщики придерживаются единого стиля написания тест-кейсов. Часто тест-кейсы создаются «под себя» и под собственный уровень понимания продукта.
Актуальность. На одном из проектов действовало правило: «Если тест-кейс/автотест не выполняется более месяца, вероятнее всего, это уже мусор». Это утверждение особенно верно в условиях активной разработки и доработки определенных частей продукта.
Время (снова). Решил выделить этот аспект отдельно, поскольку временные ограничения – это практически всегда данность. Если мы будем расходовать драгоценные часы на вычитку устаревших тест-кейсов, то неизбежно сократим время, которое могли бы уделить непосредственной работе с продуктом.
Пример:
На проекте есть механизм подписки.
Тест-кейс выглядит примерно так:
Пользователь выбирает годовую подписку
Создаем пользователю в системе "А" инвойс
Ожидаем чтобы "джоба" отработала и пользователю выставился счет
Пользователь оплатил подписку
Первое что мне бросается в глаза:
Что за подписка там должна быть и какие подписки у нас вообще бывают
Какие данные нам надо заполнить в системе "А" и где оно там вообще лежит
Что за "джоба" в пункте номер 3
А сколько времени нужно чтобы "джоба" отработала и как убедиться что оно отработала "мои данные"(не первый раз с джобами сталкиваюсь)
где пользователь увидит что ему выставили счет, чтобы его оплатить
После выяснения всех моментов, сценарий оказался таким:
Пользователь с ролью "админ" открывает страницу оформления подписки в системе
Выбирает подписку "Professional" и тип платежа "ежемесячно"(да, данные в тесте оказались устаревшими)
Указывает данные банковской карты(необязательная опция на текущий момент, но как оказалось проверка была нужна.)
В систему "А" мы входим под пользователем с ролью "ADM"
В списке новый инвойсов находим аккаунт пользователя из п.1
Открываем инвойс и сравниваем тип подписки которая выставилась автоматически, с тем что отображается в специальном поле "ожидаемая подписка"
Нажимаем на "Выставить счет"
Здесь нужно подождать от 5 до 15 минут, чтобы сервис обновления подписок, обработал по расписанию. Или сделать "Force push" в сервисе обновления подписок. Он лежит тут "<ссылка на сервис>"
На странице сервиса, открываем вкладку "Logs" и выбираем интервал времени "последние 30 минут"
В строке поиска вводим accountId нужного нам аккаунта и видим сообщение "Invoice generated - done"
Заходим в наш продукт под пользователем из п.1
Открываем страницу подписки
Ожидаемый результат: У пользователя отображается тип подписки "Professional(Trial)", потому что на 7 дней с момента оформления подписки он должен выдаваться. Отображается кнопка "Оплатить" с данными по карте, которую мы привязали в п.3
Как можно заметить, сценарий значительно отличается в его детализации.
Вывод вполне очевидный: сценарий написан исключительно "для себя", человеком который эту часть продукта знает очень давно. Если бы я владел подобным уровнем знаний, то да, ничего переписывать не надо. Но если предположить, что нам надо будет еще кому-то его дать - быть беде и надо переписывать.
Тест-кейсы перегружены информацией.
Важно сразу оговориться: речь идет исключительно о функциональных тестах. В принципе, все, что было сказано в предыдущем пункте, применимо и здесь, но с некоторыми уточнениями.
В целом, все причины из предыдущего пункта отлично подходят, но с небольшим дополнением:
Еще больше времени на прочтение. Придеться посидеть/поседеть и вычистить с каждого кейса мусор. Вот пример подобного тест-кейса:
Успешный вход администратора:
Вводим логин «админ» в поле «Логин».
Вводим пароль «1234567» в поле «Пароль».
Нажимаем кнопку «Войти».
Открылась главная страница административной панели.
В верхнем левом углу отображается логотип.
В верхнем правом углу отображается имя администратора.
По центру страницы отображается форма поиска.
Это далеко не полный перечень UI-элементов, упомянутых в реальном кейсе (их было около 16). Для меня ответ тут очевиден: все, что идет после четвертого пункта, является «мусором» для функционального теста (а четвертый пункт – это, по сути, ожидаемый результат). Почему старший QA-специалист с десятилетним опытом создал именно так, осталось для меня загадкой. Эти проверки не имеют никакого отношения к описанию функциональности.
Итог
Если масштаб проблемы позволяет начать с чистого листа – это, несомненно, лучший вариант. В противном случае – искренне сочувствую и желаю вам удачи, чтобы не стать жертвой подобных тест-кейсов.