Без фиксации процессов тестирования проверка превращается в хаотичный набор действий, а результаты сложно воспроизвести. Вести отчетность можно разными способами: составлять чек-лист, прописывать опорные пункты или принципы исследовательского тестирования. Однако в современных системах управления тестами процессы фиксируются в тест-кейсах.
Тест-кейсы нужны при верификации программного обеспечения, при тестировании оборудования и проверке электроники. Станислав Кулагин, ведущий инженер отдела сертификационного тестирования, расскажет, что важно знать о тест-кейсе, чтобы успешно его составить и использовать в работе.
- что такое тест-кейс и из каких элементов он состоит;
- чем тест-кейс отличается от чек-листа, тест-сценария и баг-репорта;
- какие ошибки допускают инженеры, когда составляют тест-кейс, и как их избежать.
Что такое тест-кейс и зачем он нужен
Тест-кейс — это описание конкретной проверки. В нем зафиксированы шаги, входные данные, условия выполнения и ожидаемый результат. Когда инженер открывает тест-кейс, он сразу понимает, что делать и какой ответ системы считать правильным.
Этот документ нужен не только тестировщику. Разработчик может свериться с тест-кейсом перед коммитом. Аналитик увидит, как его требования воплощаются на практике. А руководитель проекта получает наглядную картину покрытия функциональности проверками, если из тест-кейсов или чек-листов собрать матрицу трассирования.
Хорошо написанный тест-кейс помогает повторять проверку одинаково, даже если ее проводит другой инженер или если с момента первой проверки прошло много времени. Это особенно важно при регрессионном тестировании, чтобы убедиться, что доработки ничего не сломали.
Когда система ведет себя не так, как описано в ожидаемом результате, тест-кейс можно использовать как готовые шаги для воспроизведения дефекта. В результате падения собираются артефакты, которые подтверждают и демонстрируют сбой: логи, скриншоты, видео. А тест-кейс показывает, какое требование нарушено, если есть жесткая связь с ним, и при каких условиях проявляется ошибка. Это ускоряет диагностику и отладку программного кода.
Из чего состоит тест-кейс
Единого стандарта оформления не существует, но есть элементы, которые встречаются в большинстве тест-кейсов. Каждый их них решает свою задачу.
- Идентификация тест-кейса. Идентификатор или номер нужен для быстрого поиска и ссылок. Название кратко описывает суть проверки. Цель объясняет, зачем этот тест-кейс вообще нужен.
- Подготовка к проверке. Предусловия описывают состояние системы перед началом проверки. Тестовые данные — конкретные значения, которые нужно ввести. Шаги выполнения перечисляют действия инженера.
- Результаты проверки. Ожидаемый результат — главный элемент, который можно представить как для каждого шага отдельно, так и для последовательности шагов. Фактический результат фиксируется при выполнении. Статус показывает, прошел тест или упал.
- Управление тест-кейсом. Приоритет помогает решить, какие проверки выполнять первыми при нехватке времени. Связь с требованием обеспечивает трассируемость — возможность проследить, откуда взялась проверка.
Вот как может выглядеть простой тест-кейс для проверки аутентификации:
В аппаратном тестировании структура остается похожей, но меняется содержание. Вместо кликов по интерфейсу инженер описывает подключения, команды, параметры сигналов и реакции устройства. Подробнее о специфике hardware-тестирования можно прочитать в этой статье.
Чем тест-кейс отличается от чек-листа, тест-сценария и баг-репорта
Эти документы часто путают, но, на мой взгляд, они решают разные задачи и не заменяют друг друга. Как мы разделяем понятия, опишу ниже.
Тест-кейс — подробное описание одной конкретной проверки. Он содержит шаги, данные и ожидаемый результат. По тест-кейсу проверку может выполнить инженер, который никогда раньше не работал с этой функциональностью.
Чек-лист — краткий список пунктов, которые нужно проверить. Он не содержит детальных шагов. Чек-лист подходит опытному специалисту, который сам знает, как выполнить каждую проверку.
Тест-сценарий — более широкое понятие, путь пользователя через систему, который может включать несколько проверок. Один тест-сценарий часто раскрывается через набор тест-кейсов.
Баг-репорт — описание уже найденной ошибки. Он фиксирует, что пошло не так, при каких условиях и как воспроизвести проблему. QA-инженер составляет баг-репорт появляется после выполнения тест-кейса, если результат не совпал с ожидаемым.
Какими бывают тест-кейсы
Классификация зависит от цели проверки и способа ее выполнения:
- Позитивные тест-кейсы проверяют, что система работает корректно при правильных входных данных.
- Негативные тест-кейсы исследуют поведение при некорректных данных, ошибках пользователя или сбоях внешних компонентов.
- Функциональные тест-кейсы проверяют, что система делает то, что должна.
- Нефункциональные тест-кейсы оценивают производительность, надежность, безопасность и другие характеристики качества.
- Регрессионные тест-кейсы нужны для проверки, что изменения в коде не сломали существующую функциональность.
- Smoke-тесты — быстрый набор проверок, подтверждающий, что основные функции вообще работают после сборки.
- Тест-кейсы для ручного тестирования рассчитаны на выполнение человеком: инженер сам выполняет шаги и оценивает результат проверки.
- Тест-кейсы для автоматизации пишутся так, чтобы их мог выполнить скрипт. Автоматизация тестирования накладывает еще более строгие требования к точности формулировок.
Тест-кейсы нужны не только для проверки пользовательских функций в приложениях. В инженерных проектах они помогают описывать ожидаемое поведение сложных систем — от ПО до оборудования. Чем сложнее система, тем важнее точно зафиксировать условия проверки и ожидаемый результат.
Где применяются тест-кейсы и где их хранить
Тест-кейсы используются везде, где нужна системная проверка продукта: в тестировании сетей связи, электроники, ПО, аппаратном тестировании, отладке программного кода и верификации.
Выбор места хранения зависит от размера команды, сложности продукта и частоты релизов. Тест-менеджмент системы TestRail или плагины к Jira вроде Zephyr созданы специально для управления тестовой документацией. Они поддерживают статусы, приоритеты, связи с требованиями и аналитику покрытия.
Таск-трекеры позволяют хранить тест-кейсы рядом с задачами разработки. Это удобно, когда команда небольшая и не использует специализированные инструменты. Wiki и базы знаний подходят для документации, которая редко меняется. Но обновлять тест-кейсы там неудобно, и сложно отслеживать историю изменений. Таблицы в Google Sheets или Excel хороши для старта. Но когда тест-кейсов становится много, таблицы превращаются в неуправляемую массу.
Репозиторий рядом с автотестами — правильный выбор, если команда активно развивает автоматизацию. Тест-кейсы хранятся как код рядом с тестами, и обновления идут через pull request. Главное правило: тест-кейсы должны храниться в одном месте, и вся команда должна знать, где искать актуальную версию.
Как писать тест-кейсы, чтобы ими пользовалась команда
Хороший тест-кейс пишется для других людей, а не для галочки. Через полгода его будет читать коллега, который никогда не видел эту проверку.
Пишите понятно и однозначно. Если шаг можно понять по-разному, при этом такой необходимости не было, его нужно переписать.
Не смешивайте несколько разных проверок в один тест-кейс, иначе набор раздувается, его становится тяжело поддерживать. Когда проверок несколько, это упрощает отслеживание результатов и поиск проблем, но увеличивает количество кейсов и превращает тестовые наборы в подробные чек-листы. Так что важно знать меру.
Всегда фиксируйте предусловия, если они нужны. Без них другой инженер потратит время на подготовку окружения. То же касается тестовых данных — указывайте конкретные значения, если хотите проверить на них.
Ожидаемый результат должен быть конкретным. Фраза «система работает правильно» бесполезна. Нужно указать, что именно должно произойти, какое сообщение появится, какой статус изменится.
Связывайте тест-кейс с требованием или задачей. Это помогает понять, зачем проверка нужна, и обеспечивает трассируемость. При изменениях в требованиях легко найти связанные тест-кейсы.
Обновляйте тест-кейсы после изменений в продукте. Устаревший тест-кейс хуже отсутствия тест-кейса, потому что создает ложное чувство уверенности.
Типичные ошибки и чек-лист хорошего тест-кейса
Даже опытные инженеры допускают ошибки при написании тест-кейсов. Знание типичных ошибок помогает их избегать.
Слишком общее название не позволяет быстро понять суть проверки. Отсутствие ожидаемого результата делает тест-кейс бесполезным. Неоднозначные шаги приводят к разным результатам у разных исполнителей. Хранение тест-кейсов в разных местах означает, что команда никогда не знает, какая версия актуальна. Излишняя детализация там, где достаточно чек-листа, замедляет работу.
Перед публикацией тест-кейса проверьте его по этим пунктам:
- Понятно ли, что именно проверяется?
- Есть ли предусловия?
- Шаги можно повторить без уточнений?
- Ожидаемый результат описан конкретно?
- Тест-кейс связан с требованием или задачей?
- Не смешались ли разные проверки в одном тест-кейсе?
- Понятно ли, где хранится актуальная версия?
- Можно ли использовать тест-кейс для повторной проверки?
Что делать дальше
Тест-кейс помогает формализовать проверку и сделать ее воспроизводимой: он содержит условия, шаги и ожидаемый результат. Этот инструмент нужен в разработке софта, в тестировании оборудования, электроники и сетевых устройств. Удобнее всего работать с тест-кейсами в системе управления тестами, например, в TestY TMS. Но если такой способ вам не подходит, можете использовать базы знаний, Excel-таблицы или таск-трекеры.
Если вы только начинаете разбираться в тестировании, полезно изучить смежные темы: чек-листы, баг-репорты, регрессионное тестирование, автоматизацию и верификацию. Это поможет лучше понимать, как устроена работа инженера по тестированию в программных и инженерных продуктах. А узнать больше о том, как устроено «железное» тестирование, можно в нашем материале.
