Тест-кейс: что это и как его написать

Какая тестовая документация бывает

Тестировщик пишет специальную документацию, в которой подробно отражает, что и как должно работать. Это и есть тест-кейсы. Их пишут в процессе разработки, до старта тестирования, иногда во время и даже после тестов.

Есть два основных вида тестовой документации: тест-кейсы и чек-листы. Одностраничному веб-сайту или команде, в которой один или два тестировщика, хватит и чек-листов. Большим командам лучше использовать тест-кейсы, чтобы информация не терялась.

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

1. Оформление подписки.

2. Просмотр витрины фильмов.

3. Запуск продолженного просмотра.

А тест-кейс — детализированный план того, как проверить определённое требование к программе. Например, когда проверяем оформление подписки, шаги тест-кейса могут выглядеть так:

1. Авторизоваться в приложении Кинопоиска как пользователь без подписки.

2. Нажать на кнопку «Оформить подписку».

3. Ввести данные карты и код из смс.

4. Подтвердить оформление подписки.

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

Тест-кейсы бывают:

• Позитивные — показывают, что при корректных данных и ожидаемых сценариях система выполняет то, что должна. Например, если поле пароля позволяет вписать цифры и символы, позитивный тест-кейс — проверка на ввод пароля, состоящего из цифр и символов.

• Негативные — показывают, что при некорректных входных данных система отреагирует правильно. Например, выведет окно с подсказкой или предупреждением.

Зачем описывать тесты

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

• Проверяемую функциональность будут тестировать ещё много раз. И это могут делать другие люди. Новые сотрудники должны легко разбираться в проекте и не тратить время на проверку документов.

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

• Это облегчает оценку тестового покрытия. Позволяет точнее определить время, требуемое для тестирования.

Из чего состоит тест-кейс

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

• Заголовок — наименование тест-кейса. Описывает то, что должно быть проверено.

• Предусловия, или входные данные, — действия, которые надо выполнить до начала проверки, и/или инструменты, которые надо использовать.

• Шаги — описание последовательных действий, которые необходимо выполнить для проведения теста.

• Ожидаемый результат — описание того, как система должна реагировать на шаги теста.

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

Когда тестовая документация не нужна

• Когда на проекте работают только опытные тестировщики, которые смогут качественно протестировать и по чек-листам.

• Когда проект небольшой, например одностраничный лендинг. Его по чек-листу сможет протестировать даже новичок.

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

Вот несколько советов, следуя которым вы повысите качество своих тест-кейсов:
— Сразу после написания кейса дайте пройти его незнакомому с программой человеку. Фидбэка не бывает много — и чем его больше, тем быстрее можно научиться писать кейсы качественно.
— При написании тест-кейсов нужно помнить о конечном пользователе и об интересах бизнеса. Проходите собственные тест-кейсы с точки зрения их практической пользы для пользователя.
— Внедряйте методы тест-дизайна. Например, проводите анализ граничных значений.
Даниил Скляров, инженер по тестированию в Яндексе