От требований к тестированию: тест-кейсы и приёмка

Тест-кейсы обычно пишут тестировщики, но исходный материал для них даём мы: требования, критерии приёмки, примеры значений. Чем точнее требование, тем меньше вопросов появляется при написании проверок и тем меньше споров на приёмке.

Кейс: поле причины отмены

В «Узелке» покупатель отменяет заказ, пока он не передан курьеру (требование ФТ-12), и указывает причину отмены длиной от 3 до 200 знаков (требование ФТ-13). Тестировщик читает эти строки и задаёт три вопроса. Что считать успешной отменой? Что должно произойти, если заказ уже у курьера? Какие значения причины проверять? (Номера требований и ограничение по длине условные: мы взяли их для иллюстрации.)

Если ответы на эти вопросы записаны в требованиях, проверки пишутся сразу. Если нет, вопросы возвращаются к нам, и это хороший сигнал: требование было неполным.

Что такое тест-кейс

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

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

Ссылка на требование нужна, чтобы видеть, что именно проверяется. Именно она связывает проверку с трассировкой, которую мы разбирали в статье 02-22.

Позитивные и негативные проверки

Позитивная проверка показывает, что система работает на допустимых данных и в разрешённом состоянии. Негативная проверка показывает, что система правильно ведёт себя на неверных данных или в запрещённом состоянии.

Для требования ФТ-12 набор получается такой (все номера условные):

• ТК-31, позитивная: заказ в статусе «Оформлен», причина допустимой длины. Ожидаем статус «Отменён» и подтверждение покупателю.
• ТК-32, негативная: заказ в статусе «Передан курьеру». Ожидаем сообщение об отказе и неизменный статус.
• ТК-33, негативная: причина не заполнена. Ожидаем ошибку у поля и отсутствие отмены.

Негативные проверки нужны не меньше позитивных: именно в них часто всплывают вопросы к требованиям, потому что в тексте обычно описано, что должно получиться, а не то, что должно происходить при отказе.

Граничные значения

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

Пример: допустимый логин содержит от 6 до 15 знаков. Проверяют длины 0, 5, 6, 15 и 16. Для нашей причины отмены от 3 до 200 знаков получаем такой же набор: 0, 2, 3, 200 и 201. Значения 3 и 200 должны пройти, значения 0, 2 и 201 должны быть отклонены с понятной ошибкой.

При написании требования это тоже полезно: если границы не записаны, тестировщик не знает, какое поведение ожидать на значениях 2 и 201.

Как из требования получить проверки

Порядок один и тот же для любого требования:

• найти в формулировке условия и значения: статус заказа, длина причины, роль пользователя;
• для каждого условия записать допустимый случай и недопустимый случай;
• для числовых и длинных полей добавить границы;
• записать ожидаемый результат для каждой проверки;
• связать проверки с требованием по номеру.

Если ожидаемый результат записать не получается, значит, требование недостаточно точное. Критерии качества требований мы разбирали в статье 02-19, и этот признак из них самый простой для проверки на практике.

Как проходит приёмка

Приёмка подтверждает, что система отвечает потребностям бизнеса и готова к запуску. Её описывают как проверку требований с точки зрения пользователя. Критерии приёмки мы пишем в статье 02-09, а здесь из них и из требований выводим проверки.

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

Где это встречается в работе

• Подготовка критериев приёмки вместе с владельцем продукта (статья 02-09).
• Согласование тест-кейсов с тестировщиками: мы проверяем, что они покрывают требования.
• Разбор дефекта: что записано в требовании и что проверял тест.
• Приёмка релиза: прогон сценариев по критериям и фиксация решения.
• Проверка полноты требований: нельзя записать ожидаемый результат, значит, нужны уточнения.

Итог

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

Что дальше

Дальше соберём чек-лист постановки задачи разработке (статья 02-26), где проверки и критерии приёмки входят в состав того, что передают исполнителю.