● ХАРДКОДИНГ PRO

Гайд №13.
Тестирование проекта

Как доказать, что всё действительно работает: от быстрой проверки до полного пути пользователя и финальной приёмки. Без необходимости становиться программистом.

SmokeE2ERegressionОсновной успешный сценарийНепонятные слова6 промптов25 проверок

Гайд №13. Тестирование проекта

1. Проверяй результат, а не только слова «готово»

ИИ может написать «готово», когда он всего лишь изменил код. Это ещё не значит, что реальный пользователь сможет получить обещанный результат.

Не верь словам «готово» — нужны доказательства — Проверяй результат, а не только слова «готово» — нужны доказательства

Главное правило: готово — это когда критерии задачи проверены и есть доказательства.

Изменение→Проверка→Доказательство→Приёмка

Что требовать от ИИ: не «уверенность», а конкретные тесты, фактические результаты и PASS / FAIL.

2. Быстрая проверка (Smoke test): сервис вообще жив?

Smoke test — быстрая проверка самого главного. Мы не проверяем весь проект, а убеждаемся, что основа не умерла.

Для сайта

страница открывается;
главная кнопка работает;
сервер отвечает;
база доступна.

Для Telegram-бота

бот отвечает;
главная команда работает;
ИИ/API доступен;
нет критических ошибок.

Smoke не доказывает всё. Он доказывает, что самое важное вообще живо.

3. Сквозная проверка (E2E): путь пользователя целиком

E2E означает «от начала до конца». Мы повторяем реальный путь пользователя, а не проверяем отдельный кусок системы.

Открыл→Вошёл→Сделал действие→Получил результат

Главный вопрос: сможет ли обычный человек без нашей помощи пройти путь до обещанного результата?

После E2E полезно открыть логи: иногда интерфейс выглядит нормально, но внутри уже копятся ошибки.

4. Повторная проверка старых функций (Regression)

Ты добавил новую функцию. Она работает. Но рядом могла перестать работать старая кнопка, авторизация, оплата или другой сценарий.

До изменения

Главные старые сценарии работают.

После изменения

Проверяем новую функцию и повторяем критичные старые сценарии.

По-человечески: новое не должно ломать то, что уже приносило результат.

5. Основной успешный сценарий и сценарии ошибок

Если проверять только идеального пользователя, продукт быстро удивит тебя в реальной жизни.

Основной успешный сценарий

Правильные данные, хороший интернет, внешние сервисы отвечают. Идеальный путь.

Негативные сценарии

Пустое поле, неверный пароль, повторный клик, нет интернета, API упал, база временно недоступна.

Хороший продукт умеет не только работать, но и нормально переживать ошибки.

6. Где тестировать проект

Тест должен быть максимально близок к той среде, где будет настоящий пользователь.

Продукт	Где проверять
Сайт	Настоящий браузер, мобильный экран, разные размеры окна
Telegram-бот	Реальный Telegram-клиент
iPhone	iPhone или соответствующий эмулятор
Android	Android-устройство или эмулятор
Desktop	Та ОС, где реально будет пользователь

Один экран — не вся правда. То, что работает у тебя на Mac, ещё не доказывает работу у клиента на iPhone.

7. ИИ сам составляет тест-план

Тебе не нужно придумывать все проверки вручную. Дай ИИ цель продукта и попроси его сначала предложить систему проверки.

Функция→Сценарии→Проверки→Ожидаемый результат→PASS / FAIL

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

8. Приёмка: когда задача действительно закончена

Приёмка — финальная сверка результата с критериями задачи.

Пример

Плохо: «сделать авторизацию».

Хорошо: пользователь может зарегистрироваться, войти, выйти, восстановить доступ; пользователь A не видит данные пользователя B; все сценарии пройдены.

Критерий→Действие→Результат→Доказательство→PASS

9. Непонятные слова простыми словами 😄

Не нужно запоминать всё сразу. Используй эту таблицу как шпаргалку, когда ИИ пишет незнакомый термин.

Термин	Простыми словами
Smoke test	Быстрая проверка самого главного: сервис вообще запускается и выполняет основную функцию.
E2E	Проверка полного пути пользователя: от первого шага до конечного результата.
Regression	Проверка, что новое изменение не сломало то, что раньше уже работало.
Acceptance / приёмка	Финальная проверка по заранее понятным критериям: можно ли считать задачу готовой.
Основной успешный сценарий	Обычный успешный сценарий, когда пользователь всё делает правильно.
Negative scenario	Проверка того, что произойдёт при ошибке пользователя или сбое внешнего сервиса.
Edge case	Редкая или необычная ситуация, о которой легко забыть.
Bug / баг	Ошибка или неправильное поведение программы.
Test case	Один конкретный сценарий проверки.
Test plan	Список проверок: что проверяем, как проверяем и какой результат считаем правильным.
PASS	Проверка пройдена: фактический результат совпал с ожидаемым.
FAIL	Проверка не пройдена: фактический результат отличается от ожидаемого.
Staging	Тестовая версия проекта перед публикацией для реальных пользователей.
Рабочая версия (production / прод)	Рабочая версия проекта, которой пользуются реальные люди.
Mock	Искусственно созданный ответ внешнего сервиса для безопасного тестирования.
Assertion	Условие, которое должно быть выполнено, чтобы тест считался успешным.
Rollback / откат	Возврат к предыдущей рабочей версии проекта.
Environment / среда	Место, где реально работает проект: браузер, iPhone, Android, VPS и т.д.

10. Какие доказательства собирать

Хороший тест оставляет след, который можно проверить.

Что подходит

скрин результата;
фактический ответ API;
PASS / FAIL теста;
лог без ошибок;
видео короткого сценария;
совпадение ожидаемого и фактического результата.

Что не подходит

«кажется работает»;
«ИИ сказал готово»;
«код выглядит правильно»;
«один раз открылось».

11. Что проверять после каждого изменения

Изменение→Smoke→E2E→Regression→Логи→Приёмка

Для маленькой правки не всегда нужен огромный набор тестов. Но хотя бы быстрая проверка и связанный пользовательский сценарий должны стать привычкой.

Лучший момент тестировать — сразу после изменения. Чем позже нашёл проблему, тем сложнее понять, какое изменение её вызвало.

Тестирование — повторяемый цикл: изменение → smoke → E2E → regression → доказательство