Как писать тест-кейсы
Тест-кейс может выглядеть заполненным и всё равно подвести следующего читателя. Шаги есть, но данные неясны, ожидаемый результат обозначен словом «успешно», а команда не понимает, какое решение должна поддержать проверка.
Разбираясь, как писать тест-кейсы, важно не заполнять каждое поле. Нужно создать небольшой воспроизводимый договор между тем, кто выполняет проверку, и тем, кому предстоит понять её результат.
Как писать тест-кейсы вокруг решения
Начните с поведения, которое имеет значение. Спросите, что может изменить решение о релизе или дефекте, если проверка пройдёт или провалится. Кейс для восстановления пароля защищает восстановление доступа, а не просто наличие зелёного сообщения.
Коротко назовите назначение. Так через месяц будет понятно, зачем сценарий ещё находится в наборе. Заголовок с условием и результатом полезнее безличного номера.
Сделайте предусловия и данные понятными другому человеку
Опишите только состояние, с которого нужно начинать: статус учётной записи, права, флаг, браузер или связь между записями. Если читатель должен угадывать, как получить такое состояние, кейс ещё не воспроизводим.
Данные должны быть явными и безопасными. Используйте фикстуры и заполнители вместо реальных персональных данных, а важные для наблюдения значения назовите отдельно.
Пишите шаги так, чтобы у результата было наблюдение
В каждом шаге оставляйте одно осмысленное действие. Не объединяйте переход, ввод данных и проверку в абзац, где теряется место сбоя. Хороший шаг говорит, что сделать и какое состояние должно быть перед следующим действием.
Ожидаемый результат должен быть видимым или измеримым: запись создана, сообщение валидации показано, запрос отклонён или связанное значение изменилось. Слова «работает» и «правильно» заменяйте конкретным наблюдением.
Покройте соседний риск, не раздувая набор
Начните с основного пути, а затем выберите близкие варианты, способные изменить вывод: пустое значение, граница диапазона, истёкший сеанс или повторная попытка. Не копируйте кейс для каждого возможного ввода. Если значения должны вести себя одинаково, используйте решение о классе эквивалентности.
Поддерживайте кейсы в актуальном состоянии
После изменения спросите, защищает ли сценарий то же поведение и можно ли подготовить его состояние. Уберите шаги, которые больше ничего не доказывают, обновите формулировки и привязывайте падение к минимальному полезному контексту.
Сильный кейс не самый длинный. Это сценарий, который коллега может выполнить, понять и использовать в решении без устного перевода.
Как писать тест-кейсы: превратите риск в воспроизводимую проверку
Выберите одно поведение небольшой формы или API-метода. Запишите риск, нужное начальное состояние, минимальные данные и три действия. Остановитесь, прежде чем добавлять детали, которые не меняют решение.
Сформулируйте ожидаемый результат через наблюдение. Попросите другого человека выполнить кейс по вашим записям и отметьте все места, где ему пришлось спрашивать о скрытом допущении.
Добавьте один близкий вариант и объясните, зачем он нужен. Если нельзя назвать покрываемый риск, пока оставьте его за пределами сценария.
Вопросы перед следующим шагом
- Какое решение поддерживает этот кейс?
- Какое начальное состояние нужно описать явно?
- Что именно увидит исполнитель?
- Какая вариация меняет риск, а не только значение?
Закрепляйте принципы тест-дизайна и выполнения тестов с помощью тематических вопросов и объяснений.
Подробнее об ISTQB Quiz →