Как тестировщику писать понятные и структурированные тест-кейсы с помощью DoQA
Созданием тест-кейсов часто пренебрегают даже на больших проектах — быстрее пройтись по функционалу с помощью чек-листов. Экономия времени на написании кейсов может не повлиять на работу в моменте, но в будущем такой подход чреват проблемами. Облегчить и ускорить этот рутинный процесс поможет система управления тестированием — узнайте, как с помощью TMS DoQA оформлять тест-кейсы так, чтобы избежать сложностей на проекте.
Невнимательное отношение к тест-кейсам влечет за собой ряд неприятных последствий. Самый часто встречающийся фактор риска — бас-фактор. Если тестировщик, держащий в голове знания о том, как именно что-то должно работать, уволится или заболеет, то другим тестировщикам придется восстанавливать информацию, разыскивая требования в системах хранения документации или у других членов команды. Это отнимает гораздо больше времени, чем написание тест-кейсов, поэтому лучше сразу обстоятельно их оформлять, если масштаб проекта того требует.
Система управления тестированием помогает избежать проблем, если тщательно придерживаться установленной структуры документации. Кроме того, TMS превращает набор документов в структурированную систему, благодаря которой можно собирать метрики, а это уже совершенно иной уровень подхода к тестированию.
Из чего состоит тест-кейс в TMS DoQA
У тест-кейсов есть атрибуты — некоторые действия, которые должен совершить тестировщик. Какие атрибуты заполнять в TMS, а какие нет, зависит от команды. Определяют это менеджеры, лиды тестирования — то есть те, кто занимаются тест-аналитикой и решают, достаточны ли написанные тест-кейсы для достижения уверенности в качестве системы.
Главное преимущество ведения тестовой документации в TMS — система сама подсказывает, что нужно делать, за счет наличия определенных атрибутов в самой структуре тест-кейса. Помимо этого, в DoQA тест-кейсы устроены так, чтобы хранить и отслеживать в одном месте всю необходимую информацию вплоть до истории изменений и комментариев.
Вот из каких атрибутов будет состоять тест-кейс в DoQA.
Название
Как пишется название тест-кейса, зависит от правил команды. Оно должно указывать, что именно им проверяют, и может содержать в себе требования, название раздела, описание функции и теги.
Описание
Здесь удобно указывать данные, которые понадобятся при работе с тест-кейсом: дату создания, автора, ссылки на стенд и требования, креды для авторизации и так далее.
Предусловия и постусловия
Отдельные строки выделены для предусловий и постусловий — забыть о них не получится. Эти поля способны значительно облегчить работу с кейсами.
Конечно, не заполнив какую-то из строк, тестировщик все равно сможет выполнить шаги проверки, но здесь стоит подумать о себе в будущем и коллегах, которые потом будут работать с этой документацией. Если в каждом поле есть нужная информация, то это делает кейс однозначным и упрощает его прохождение.
Приоритеты
Низкий, средний, высокий — приоритеты помогают тестировщикам определять порядок прохождения кейсов и грамотно распределять ресурсы. Когда тест-кейсы не отсортированы по степени важности, вся работа выстраивается наугад, особенно если проверок тысячи, и нет понимания, какие из них точно должны быть выполнены до конца тестирования, а какие можно убрать из прогона и отложить на следующий раз.
Статус тест-кейса
Статус показывает тестировщику актуальное состояние тест-кейса.
«Готов» — тест-кейсом можно пользоваться, он полностью актуален.
«Ревью» — тест-кейс находится на проверке и еще не готов к использованию.
«Черновик» — тест-кейс в работе.
«В архиве» — тест-кейс уже не актуален, но оставлен для истории, чтобы можно было вернуться к нему за информацией.
«Сломан» — тест-кейс не воспроизводится, или что-то пошло не так, и его нужно доработать.
Ключи и теги
Ключи и теги помогают объединять тест-кейсы в группы по ключевым словам — создавать их можно по своему усмотрению и логике проекта.
Например, если мы установим в качестве ключа вид тестирования, то логично будет присвоить ему теги «смоук», «регресс», «негативное», «позитивное» и так далее. Если ключом будет раздел сайта, например, административная панель, то тегами могут стать фичи, которые будут там проверяться: «форма авторизации», «добавление контента», «редактирование товара».
Это помогает держать в порядке документацию, кастомизировать ее и быстро находить нужные тест-кейсы с помощью фильтров.
Шаги
Здесь прописываются шаги, которые тестировщик выполняет, и ожидаемые результаты, которые нужно получить.
Чек-бокс рядом с шагами позволяет копировать или удалять отдельные шаги, помимо этого их можно перетаскивать и менять местами при необходимости.
Нумерация шагов динамическая, и это очень удобно. В неприспособленных для тест-кейсов инструментах, например, популярных у небольших команд Google-таблицах, такого функционала нет — если там в середину тест-кейса добавляется новый шаг, то всю нумерацию приходится переписывать.
История редактирования и история запуска
История позволяет просматривать, кто, когда и какие изменения внес в тест-кейс, в каких прогонах он участвовал, и какие были результаты. Этот функционал избавляет от хаоса в команде, помогает отслеживать актуальное состояние тест-кейса и без проблем передавать работу коллегам — они всегда будут знать, к кому обратиться с вопросами, потому что автор изменений указан прямо в системе.
Выявленные баги
Если в результате прохождения кейса будут выявлены баги, то информация об этом появится в окне конкретного тест-кейса — ничего не потеряется.
Комментарии
Удобная вкладка для информирования коллег об изменениях. Например, если тестировщик проходил тест-кейс, нашел в нем ошибку и исправил ее, то он может оставить комментарий для других о том, что в тест-кейсе изменилась определенная часть, и теперь все работает правильно.
Главные признаки хорошего тест-кейса
Система управления тестированием — инструмент, который помогает придерживаться грамотной структуры тест-кейса и не забывать вносить важные данные. Но насколько грамотной документация будет по своей сути, зависит только от тестировщика.
Вот каких принципов стоит придерживаться при составлении тест-кейсов, чтобы TMS стала надежным помощником команды QA
Понятность. Придерживайтесь однозначности и полноты в описании проверок и их результатов. Хороший тест-кейс легко читается и понятен не только тестировщику, который уже десять лет в проекте, но и новичку, который обучается проекту на основе этого самого тест-кейса.
Атомарность. Соблюдайте правило «один тест — одна проверка». Бывает, что тестировщик прописывает один шаг, видит, что система после этого должна совершить еще много действий, и начинает формировать шаги дальше с миллионом запросов между микросервисами.
В итоге получается гигантский нечитаемый тест-кейс, который не может пройти никто, кроме его автора. Впрочем, автор тоже через какое-то время забудет, как его проходить.
Чтобы этого избежать, необходимо дробить кейсы на минимально необходимое число шагов для выполнения одной проверки и недвусмысленно формулировать ожидаемые итоги действий в каждом.
Непротиворечивость. Следите за тем, чтобы выполняемые действия в тест-кейсе и их результаты друг другу не противоречили. Часто противоречия — это следствие изменений, которые применили не ко всем элементам.
Попробуйте TMS DoQA, чтобы увидеть, как наша система увеличивает эффективность процессов тестирования. Мы предоставим бесплатный доступ к сервису без ограничений на один месяц: полный функционал и любое количество тестировщиков на проекте.
Авторы материала: PM DoQA Евгения Федорова, QA Lead IT Test Андрей Бракоренко.
How to
Неделя рекламы 
Новости 
Кейсы 
Интервью и дискуссии 
Маркетинговые исследования 
Просто о сложном 
Проверено ADPASS 
Рекламные кампании 
