Test Documentation: тест кейс и чек-лист
Test Documentation
Test Documentation (или тестовая документация) – артефакты, которые тестировщик использует в своей работе.
Основная цель тестовой документации – сделать процесс работы и ее результат максимально эффективным, прозрачным и измеряемым!
Типичные ошибки при работе с документацией:
- Время потраченное на работу с артефактами более 20% от общего рабочего времени тестировщика;
- Излишний перфекционизм и ненужные детали ;
- Лишние или не полезные пункты или поля;
- Неправильный инструмент для работы;
- Неправильный подход к созданию;
- Отсутствие конкретики;
- Хаотическая структура;
- Понятны только создателю;
Test cases
Test Case (или тестовый случай) – это профессиональная документация тестировщика, последовательность действий направленная на проверку какого-либо функционала, описывающая как придти к фактическому результату.
Для чего нам нужны тест кейсы?
Тест-кейсы должны помочь нам провести проверку продукта без ознакомления с всей документацией. Написанный один раз, удобный в поддержке тест-кейс сэкономит много времени и сил тестировщикам.
Тест кейсы бывают позитивные и негативные.
Позитивные
Используют только корректные данные и проверяет то, что приложение правильно выполняет вызываемую функцию.
Негативные
Имеет минимум 1 некорректный параметр и ставит целью проверку исключительных ситуаций, и так же проверяет, что вызываемая приложением функция не выполняется при вводе некорректных данных.
Основные атрибуты тест кейсов:
- Уникальный идентификатор тест-кейса (ID) – необходим для удобной организации хранения и навигации по нашим тест-наборам;
- Название (Title) — основная тема, или идея тест-кейса. Краткое описание его сути;
- Предусловия (Preconditions) — описание условий, которые не имеют прямого отношения к проверяемому функционалу, но должны быть выполнены.Например, оставить комментарий на вашем портале может только зарегистрированный пользователь. Значит для тест-кейса «Создание комментария» будет необходимо выполнение предусловия «пользователь зарегистрирован», и «пользователь авторизован»;
- Шаги (Steps) — описание последовательности действий, которая должна привести нас к ожидаемому результату;
- Ожидаемый результат(Expected Result) — результат: что мы ожидаем увидеть после выполнения шагов;
Название (Title) должно быть:
- Краткое
- Емкое
- Уникальное
Неправильно:
- Тест 1
- Тест 2
- Улучшенная версия теста 78
- Проверить регистрацию
Предусловия (Preconditions):
- Не может содержать шаги и ожидаемый результат;
- Не должны быть ссылки на среду тестирования;
- может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса;
- может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…);
Шаги (Steps):
- Начинать с очевидного;
- Заканчивать ожидаемым;
- Каждый шаг с новой строки;
- Все шаги нумеруються;
- Начинается с безличного глагола;
Неправильно:
- Включить компьютер, открыть браузер и тд…
- “Перейдите на домашнюю страницу…”
- “To put the correct email…”
- Если пользователь не зарегистрирован, то …
Ожидаемый результат (Expected Result):
- Писать для каждого шага
- Однозначное описание
- Можно использовать скриншоты
Неправильно:
- Приложение работает правильно
- Если получили код 200, то..
- Если пользователь не зарегистрирован, то …
Общие рекомендации:
- язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц;
- тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще);
- тест-кейсы группируются в функциональные блоки по их назначению;
Checklist
Checklist (или чек-лист) – упрощенный вариант набора test case-ов, где проверки не расписываются подробно, а имеют только summary и два варианта результата.
Когда чек-лист хорошо?
- Простые проверки с ответом да/нет;
- Смоук или Регрешен тесты;
- Минимизация временных затрат;
- Наборы проверок для подтверждения или опровержения чего-либо;
- Когда вы один QA на проекте и точно будете один до конца;
- Когда проект очень короткий ( до 3-х месяцев) или очень простой;
- Простые Функциональные и GUI тесты;
Когда чек-лист плохо?
- Сложные тесты с большим количеством шагов;
- Не функциональные тесты – Security, Load/Performance, Usability;
- Сложный для понимания продукт;
- Большая команда тестировщиков, где возможны изменения;
- Длительный, огромный с функциональной точки зрения, проект;
Правила составления чек-листов:
- Один пункт = одна проверка;
- Пункты чек-листа – это минимальные полные операции;
- Давайте пунктам чек-листа названия по форме, общей для всех членов команды;
- Пункты пишутся в утвердительной форме;
- Оптимальное количество пунктов – до 20;
