Для поля промокода система различает действующий, просроченный, уже использованный и неизвестный код. Как построить классы эквивалентности для ручной проверки?
Нужно разделить входные данные на классы, внутри которых система должна вести себя одинаково, и выбрать как минимум по одному представителю каждого класса: действующий код, просроченный код, уже использованный код и неизвестный код. Дополнительно следует выделить пустое или некорректно оформленное значение, если для него ожидается отдельное поведение.
Главный принцип: класс определяется не внешним видом значения, а одинаковым ожидаемым результатом обработки. Если два промокода приводят к разным сообщениям, статусам или изменениям заказа, они относятся к разным классам.
Разбиение на классы эквивалентности появилось как практический способ сократить объём проверок. Полный перебор всех возможных значений обычно невозможен, поэтому тестировщик группирует значения с предположительно одинаковым поведением системы.
Подход не утверждает, что одного примера достаточно для доказательства корректности класса. Он снижает количество проверок за счёт обоснованного предположения: если система корректно обрабатывает представителя класса, вероятность одинаковой обработки других его представителей выше.
У промокода могут быть миллионы возможных строк, но бизнес-логика обычно обрабатывает их по ограниченному числу правил. Если проверять только один успешный и один неуспешный код, можно пропустить различия между просроченным, использованным и неизвестным промокодом.
Неверное разбиение приводит к двум противоположным рискам. Слишком крупный класс скрывает разные реакции системы, а слишком мелкое разбиение превращает тестирование в почти полный перебор без существенного роста покрытия.
Сначала нужно зафиксировать ожидаемое поведение для каждой категории:
Для каждого класса выбирается представитель, который действительно обладает нужным свойством. Нельзя считать строку просроченного кода представителем неизвестного кода только потому, что оба приводят к отказу: различие причин может влиять на текст ошибки, аудит, аналитику или дальнейшее поведение заказа.
Классы должны быть взаимоисключающими в рамках одной проверки и по возможности покрывать все предусмотренные требованиями варианты. Если один код одновременно просрочен и уже использован, нужно определить приоритет правила; иначе классы пересекаются, а ожидаемый результат остаётся неоднозначным.
Разбиение не заменяет проверки границ. Для срока действия могут потребоваться отдельные значения непосредственно до истечения, в момент истечения и сразу после него. Это уже анализ границы временного условия, а не новый класс по бизнес-статусу.
Ограничение метода в том, что он опирается на корректное понимание правил. Если классы определены неверно, тестировщик систематически пропустит дефект. Поэтому спорные категории нужно сверять с требованиями, аналитикой или владельцем продукта, а не выводить только из интерфейса.
В интернет-магазине промокод отображал одинаковую ошибку для просроченного и неизвестного значения. Рассматривались два варианта: объединить оба случая в один класс и сократить проверки либо оставить их раздельными. Объединение было быстрее, но скрывало риск ошибки в отчётности и неверной блокировки повторного применения кода.
Выбрали раздельные классы, потому что бизнес-правила различали причины отказа, даже если пользовательский текст временно совпадал. В набор добавили действующий, просроченный, использованный и неизвестный коды, а также проверку срока непосредственно на границе. В результате обнаружили, что просроченный код отклонялся правильно, но использованный код повторно уменьшал сумму заказа после обновления страницы.
1. Достаточно ли выбрать по одному значению из каждого класса?
Нет, это минимальное покрытие классов, а не полное тестирование функции. Дополнительные проверки нужны там, где есть границы, разные форматы, чувствительность к регистру, пробелам, длине строки или сочетанию промокода с другими условиями заказа.
При этом дополнительные значения должны быть обоснованы риском. Случайный перебор строк не заменяет анализа правил и может дать большой объём проверок без понимания, какие ошибки он покрывает.
2. Можно ли объединить просроченный и неизвестный промокод, если пользователь видит одно сообщение?
Можно только при подтверждённом требовании, что для системы эти случаи полностью эквивалентны. Нужно учитывать не только текст на экране, но и HTTP-результат, запись в журнале, аналитику, начисление скидки, ограничения повторной попытки и другие наблюдаемые последствия.
Если хотя бы одно из этих проявлений различается, классы следует разделить. Одинаковое сообщение само по себе не доказывает одинаковую обработку.
3. Что делать, если один промокод одновременно просрочен и уже использован?
Такой пример выявляет пересечение классов и необходимость определить порядок применения бизнес-правил. Следует уточнить, какая причина должна считаться основной и какой результат ожидается при одновременном выполнении условий.
После уточнения это становится отдельной проверкой сочетания условий, а не обычным представителем одного класса. Если приоритет не определён, это не только пробел тестов, но и неоднозначность требования, которую нужно зафиксировать до принятия результатов тестирования.