Тест-анализ в условиях неопределённости: когда требований нет, а тестировать надо

На курсе по тест-анализу у нас было много практических задач, и вы уже знаете, как строить проверки, когда:
✅ требования чёткие,
✅ ограничения прописаны (длина поля = 50, email — без +, пароль — от 8 символов и т.д.),
✅ классы эквивалентности и граничные значения выделены 

А теперь реальная задача, с которой хоть раз сталкивался почти каждый тестировщик:

«Проверь новую форму обратной связи. Дизайн в Figma, ТЗ пока нет».
В макете — просто: Имя, Email, Сообщение, Кнопка.

И тут внутренний голос шепчет:
«Ну как я спроектирую тесты… если не знаю, что допустимо?»

Хорошая новость: вы уже умеете думать как тест-аналитик. Остаётся применить этот навык в условиях неопределённости.

И вот как это можно сделать. 

Шаг 1. Собери всё, что есть

Не жди ТЗ как решение всех проблем. Ищи информацию везде, где возможно сейчас:

• Макет (Figma/Sketch): есть ли плейсхолдер? подсказка? маска ввода?
• Чаты/комментарии в задаче: «аналитик упоминал, что email не обязателен» — это уже ограничение!
• Похожие формы в продукте: как ведёт себя поле «Имя» в регистрации? Там 255 символов — вероятно, и тут будет так же.
• стандарты / UX-гайды: общие требования к email адресам, паролям и другим специфичным поля ввода.

Даже фраза «как в прошлый раз» может быть источником. Просто найди «прошлый раз» и посмотри.

Шаг 2. Задай 1–2 точных вопроса аналитику (или заказчику)

Не нужно собирать целые совещания, часто может быть достаточно чётко и кратко задать всего несколько вопросов:
— Email обязателен?
— Есть ли ограничение на длину сообщения (например, 1000 символов)?

Ответы на такие вопросы не занимают много времени и дают ключевые ограничения для тест-дизайна.

Шаг 3. Включи здравый смысл + опирайся на чужой опыт

Когда ограничений нет — опирайся на:

• «Как обычно работает»:
  • Поле Имя — текст, без цифр
  • Email — поддерживает +, поддомены, кириллицу в домене 
  • Сообщение — 1 символ? 10 000? HTML-теги экранируются?
• Чужой опыт. Всегда можно найти чит-листы для типовых полей и использовать их для проверки:

Это не всё, что можно проверить, но это минимум, который покроет большинство критических ошибок.

Шаг 4. Зафиксируй, хотя бы кратко

Даже если ТЗ появится завтра, задокументируй проделанную работу сегодня:

«Проверено:
— Валидация email (формат, дубли не проверялись — уточнить),
— Длина сообщения: до 2000 символов (ограничение не задано — проверено по аналогии с формой поддержки),
— Поведение при offline: форма не отправляется, ошибка не показана — заведен баг #456»

Почему это важно:

• Чтобы не повторять одни и те же проверки,
• Чтобы коллега понял ваш подход,
• Чтобы через месяц вспомнить: «Ага, мы же уже смотрели спецсимволы».

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