Глубокая проверка качества каждой функции

functional-regression-matrix отвечает на вопрос «работает ли функция вообще» и даёт snapshot статусов pass/fail/partial. Этот промт задаёт другой вопрос: насколько хорошо работает каждая функция — под реальной нагрузкой, с плохими данными, при потере сети, при нетипичном поведении пользователя. Это не планирование покрытия, а сам процесс тестирования с вынесением качественного вердикта по каждой функции.

Без этого аудита продукт выглядит рабочим на smoke и matrix, но ломается у пяти процентов пользователей в граничных ситуациях — а именно там доверие к продукту рушится быстрее всего.

Product: {{product_url}} Critical functions: {{critical_functions}}

1. Что проверяется в «глубокой» проверке

Для каждой функции исследуются четыре измерения:

1.1 Базовая работоспособность

• Выполняет ли функция свою задачу при нормальных условиях?
• Каков ожидаемый outcome и как убедиться что он достигнут?

1.2 Robustness (устойчивость к стрессу)

1.3 Поведение на граничных данных

• Минимальное валидное значение (1 символ, 0, пустой список)
• Максимальное валидное значение (лимит поля, 9999 элементов, дата из прошлого)
• Граничные типы: только пробелы, только спецсимволы, очень длинное слово без пробелов

1.4 Воспринимаемое качество

• Latency: есть ли feedback в ≤100ms после действия? (loader, disabled state, optimistic-update)
• Jank: есть ли прыжки layout, дёргания при загрузке?
• Optimistic UI: если применён — корректно ли откатывается при ошибке сервера?
• Layout shift (CLS): не прыгает ли страница при загрузке данных?
• Recovery: если что-то сломалось — предлагает ли интерфейс выход или пользователь в тупике?

2. Рубрика Robustness Score (0-3)

Балл 0 или 1 = blocker. Балл 2 = polish backlog. Балл 3 = готово.

3. Рецепты стресс-теста по типу взаимодействия

Форма / ввод данных

• ✓ Submit с каждым полем пустым по отдельности
• ✓ Вставить 10 000 символов в текстовое поле
• ✓ Tab через все поля — порядок и focus-визуал
• ✓ Submit → немедленно navigate away → данные сохранились?
• ✓ Submit → Offline → retry → данные не дублировались?
• ✓ Submit → двойной Enter → один запрос или два?

Список / грид

• ✓ Пустое состояние: что показывается при 0 элементах?
• ✓ 1 элемент, 2 элемента (граничные визуально)
• ✓ >1000 элементов: pagination / virtual scroll работает?
• ✓ Delete последнего элемента → пустое состояние появляется?
• ✓ Filter → нет результатов → снять filter → список восстанавливается?
• ✓ Sort → navigate away → back → sort сохранился?

Поиск

• ✓ Пустой запрос → Submit
• ✓ Спецсимволы: <script>, %20, --, "
• ✓ Очень длинный запрос (300+ символов)
• ✓ Быстрый ввод (debounce работает?) → нет дублирующих запросов
• ✓ Запрос → navigate → back → запрос в поле сохранился?
• ✓ Offline → попробовать поиск → понятная ошибка

Асинхронное действие (delete, publish, send)

• ✓ Кликнуть дважды быстро → одно действие или два?
• ✓ Slow 3G → кнопка disabled во время запроса?
• ✓ Offline mid-request → UI откатывается к предыдущему состоянию?
• ✓ 500 от сервера → retry доступен? Данные не повреждены?
• ✓ Timeout (30s) → что показывает интерфейс?

Навигация между страницами

• ✓ Back на шаге 3 из 3 multi-step flow → шаг 2 или начало?
• ✓ Refresh на шаге 2 → потеря прогресса или восстановление?
• ✓ Открыть в двух вкладках → конфликт состояния?
• ✓ Navigate away во время upload → предупреждение?
• ✓ Глубокая ссылка (direct URL) → корректный контент?

Реальное время (websocket, polling, live updates)

• ✓ Отключить сеть → переподключиться → данные синхронизировались?
• ✓ Долгое бездействие (15 мин) → reconnect без потери данных?
• ✓ Два пользователя меняют одну запись → merge conflict / last-write-wins?
• ✓ Очень быстрые обновления → UI не «мелькает»?

4. Где инвестировать глубину проверки

Критические функции из {{critical_functions}} → Deep по умолчанию.

5. Как проводить сессию

1. Подготовка (30 мин): Перечисли все функции. Отметь каждой уровень Deep/Middle/Surface. Создай таблицу для scores.
2. Deep-pass (основное время): По каждой Deep-функции — пройти все стресс-сценарии, зафиксировать поведение, выставить балл 0-3.
3. Middle-pass: Сокращённый набор проверок, balл 0-3.
4. Surface-pass: Только базовая работоспособность.
5. Заполнение output: Таблица + blockers + polish-backlog.

Anti-patterns

• ❌ Остановиться на «работает при happy path» — это smoke, не deep verification
• ❌ Тестировать только на хорошем соединении — 20% пользователей на медленной сети
• ❌ Игнорировать double-submit — самый частый способ задублировать данные в БД
• ❌ «Offline не поддерживаем» без явного UI — пользователь видит бесконечный loader и уходит
• ❌ Пропустить back/refresh для multi-step flow — здесь теряются данные незаметно
• ❌ Не проверять optimistic UI rollback — оптимистичный UI без rollback хуже чем pessimistic UI
• ❌ Считать latency feedback «косметикой» — >100ms без отклика меняет восприятие надёжности
• ❌ Тестировать под одним аккаунтом — некоторые баги видны только при первом использовании функции
• ❌ Начинать без списка функций — без инвентаря Deep-проверка становится случайной

Output

1. Quality score table — каждая функция: Robustness Score (0-3) + одна строка описания состояния
2. Blockers (score 0-1) — каждый: repro-шаги (numbered), условие воспроизведения, ссылка на видео/скриншот, severity (data-loss / silent-fail / crash / bad-ux)
3. Polish backlog (score 2) — каждый: описание проблемы, effort (S / M / L), ожидаемый impact на восприятие
4. Severity-ranked issue list — все находки отсортированы: data-loss → silent-fail → crash → bad-ux → cosmetic