Представьте поле «возраст», которое принимает числа от 18 до 60. Сколько значений проверить? Все подряд — 18, 19, 20… 60 — это 43 проверки, и большинство из них бессмысленны. Тест-дизайн — это набор приёмов, которые помогают проверить то же самое несколькими умными кейсами вместо десятков наугад.

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

Классы эквивалентности

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

Для поля «возраст от 18 до 60» групп три:

  • Меньше 18 (например, 15) — должно не пройти.
  • От 18 до 60 (например, 30) — должно пройти.
  • Больше 60 (например, 70) — должно не пройти.

Проверять и 15, и 16, и 17 незачем: все они попадают в группу «меньше 18» и программа обработает их одинаково. Хватит одного представителя. Так 43 проверки превращаются в 3.

Группы бывают не только числовые. Для поля «страна» из выпадающего списка каждая страна — своя ситуация или нет? Обычно нет: программе всё равно, Франция там или Германия. А вот «страна выбрана» и «страна не выбрана» — разные классы.

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

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

Для «возраст от 18 до 60» границы — 18 и 60. Проверяем вокруг них:

  • 17 — на единицу меньше нижней границы, должно не пройти.
  • 18 — сама нижняя граница, должно пройти.
  • 60 — сама верхняя граница, должно пройти.
  • 61 — на единицу больше, должно не пройти.

Именно здесь ловятся классические баги: «принимает 17, хотя не должно» или «не принимает 60, хотя должно». Значения 19 или 59 в середине проверять не нужно — их закрывает класс эквивалентности.

Вместе: мало кейсов, много смысла

Обе техники используют в паре. Сначала классами эквивалентности намечаем группы (по представителю на каждую), потом граничными значениями усиливаем проверку на стыках. Для нашего поля «возраст» итог — примерно шесть точек: 17, 18, 30, 60, 61 плюс что-нибудь совсем невалидное (буквы, пусто).

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

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

Где это применяется

Эти две техники вы будете применять буквально к каждому полю ввода и каждому условию: сумма заказа, количество товара, длина имени, дата, диапазон дат. Как только видите «принимает значения от и до» или «не длиннее N символов» — сразу думайте: какие классы, где границы. Это превращает расплывчатое «надо проверить поле» в конкретный короткий список кейсов.

Где спотыкаются начинающие:

  • Проверяют кучу значений из одной группы (18, 19, 20, 21…) и ни одного с границы. Много работы, мало смысла.
  • Забывают про границы — а это самое багоопасное место. Всегда проверяйте значение на границе и по обе стороны от неё.
  • Пропускают невалидный ввод. Пустое поле, буквы вместо цифр, спецсимволы — отдельный класс, где живёт масса багов.

Что учить дальше. Классы и границы хороши для одного поля. А когда результат зависит от комбинации нескольких условий, помогают таблицы решений и попарное тестирование.