Тест-дизайн
Проверить все возможные входы нельзя — их бесконечно много. Тест-дизайн отвечает на вопрос «какие немногие проверки поймают большинство дефектов». Это набор техник чёрного ящика, которые превращают расплывчатое «протестируй форму» в конечный, обоснованный список кейсов, где каждый закрывает свой риск.
Фундамент — сам тест-кейс как единица (однозначный, воспроизводимый, независимый) и две базовые техники: классы эквивалентности сжимают однородные входы до одного представителя, а граничные значения добивают края, где кучкуются дефекты. Дальше — таблицы решений для взаимодействующих условий, чек-листы для быстрого обхода экрана и привычка сначала оспорить требование, а уже потом проектировать. Замыкают тему разобранные задачи-«классика собеседований»: калькулятор, поиск, email, негативные API-кейсы. Полная карта — в слоях ниже.
Карта темы
- Структура тест-кейса — обязательные поля и три свойства: однозначность, воспроизводимость, независимость.
- Классы эквивалентности — разбить входы на группы и тестировать по одному представителю каждой.
- Анализ граничных значений — проверять края диапазонов, где скапливаются off-by-one дефекты.
- Таблицы решений — покрыть комбинации взаимодействующих условий, столбец на правило.
- Дизайн чек-листа — сгруппированный обход экрана от позитива к негативу и краевым случаям.
- Пробелы в требованиях — сначала оспорить спецификацию, найти дыры и пересечения, потом тестировать.
- Тест-дизайн калькулятора — классическая задача на границы, классы и лимиты полей.
- Проверка валидности email — почему regex необходим, но недостаточен, и что доказывает подтверждение.
- Тест-кейсы строки поиска — позитив, негатив и безопасность в правильном порядке.
- Негативные API-сценарии — уровни невалидности запроса и верный код 4xx для каждого.
- Тест-дизайн по HTTP-ответу — правило сервера, неожиданный код и нагрузка против стресса.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Опускать явный ожидаемый результат в кейсе | Прогон не воспроизводим — «прошло/не прошло» решает угадывание |
| Тестировать только саму границу, а не значения чуть внутри/снаружи | Off-by-one дефекты на краю остаются незамеченными |
| Определять только валидные классы, забывая невалидные | Половина покрытия — обработка ошибок — выпадает |
| Применять таблицу решений к одному независимому входу | Лишняя сложность там, где хватает классов эквивалентности |
| Начинать с негатива или крайних значений вместо позитива | Не доказано, что базовая функция вообще работает |
| Начать проектировать до разрешения пробелов спеки | Тесты закрепляют неоднозначное или противоречивое требование |
| Считать, что regex доказывает валидность email | Синтаксически верный, но недоставляемый адрес принят за валидный |
| Ожидать 500 вместо точного 4xx на невалидный ввод | Дефект обработки ошибок маскируется под «ожидаемое» падение |
Значение для собеседований
Тест-дизайн — сердцевина собеседования тестировщика. Почти всегда дают практику: «спроектируйте кейсы для поля возраста / калькулятора / строки поиска». Проверяют не заученные определения, а системность — начали ли вы с уточнения требований, применили ли классы и границы, не забыли ли негатив и безопасность, указали ли ожидаемый результат в каждом кейсе.
Что обычно проверяют:
- Классы эквивалентности и граничные значения на конкретной задаче, а не в теории.
- Порядок работы — уточнить требования, позитив, негатив, границы, безопасность.
- Когда нужна таблица решений, а когда хватает независимых классов.
- Умение заметить пробел или противоречие в спецификации до написания тестов.
Типичный неверный ответ: «протестирую все возможные значения, чтобы наверняка». Полный перебор невозможен и не нужен — сила тест-дизайна в том, чтобы горсткой представителей и границ покрыть тот же риск, что и бесконечный перебор, и при этом явно назвать ожидаемый результат каждой проверки.