Перед выкладкой имеет смысл прогнать то, от чего зависят деньги и заявки: формы, оплату, вход в кабинет, расчёт в калькуляторе. Не «покликать наугад», а по понятному списку сценариев.
Одна маленькая правка может зацепить другое место. Клиент или менеджер узнаёт об этом первым — уже на боевом сайте.
Знакомо, если релизы «на авось»: вроде работало вчера, сегодня уже нет — а что именно сломалось, непонятно.
Не гарантия от всех багов навсегда — но критичный путь «заявка → оплата → письмо в CRM» перед выкладкой уже пройден.
В больших студиях тестирование иногда живёт отдельно: сначала сдают код, потом ищут «отдел качества». Если вы заказываете сайт или сервис у одного разработчика, такой схемы просто нет — и это плюс.
Я не отдаю проект с формулировкой «ну вроде кликнул — работает». Перед сдачей проходят сценарии, которые мы заранее согласуем: что нельзя сломать ни при каких обстоятельствах. Для форм, оплаты и кабинетов это обычно вход, отправка заявки, расчёт, статусы, письма и интеграции.
Если проект уже сделан другими — подключаюсь отдельно: разовая проверка перед запуском, регрессия после правок или набор автотестов, который можно гонять перед каждым релизом.
Сайт, калькулятор или кабинет сдаются уже с понятным чек-листом: что проверено, что автоматизировано, что смотреть руками перед следующей правкой.
Перед запуском, после редизайна, когда страшно трогать оплату или форму. Получаете отчёт: что прошло, что нашли, что критично исправить до релиза.
Стек — инструмент. На созвоне важнее другое: какие сценарии в вашем продукте нельзя сломать.
Не всё имеет смысл автоматизировать. Часть смотрит человек — особенно новый интерфейс и странные краевые случаи.
| Сценарий | Вручную | Авто |
|---|---|---|
| Форма и заявка | ||
| API и интеграции | ||
| Оплата | ||
| Роли и доступы | ||
| Вёрстка и адаптив | — | |
| Первое впечатление / UX | — | |
| Регрессия после правок |
Повторяется каждый релиз, результат можно сравнить однозначно.
Здесь важнее контекст и впечатление, чем «зелёная галочка в CI».
Не страница про «наш стек ради стека». Типовой маршрут: правка → прогон API и UI → отчёт → выкладка, когда критичные сценарии уже зелёные.
Не «мы провели QA» в одном абзаце отчёта, а материалы, с которыми можно работать дальше — своими силами или со мной на поддержке.
Даже если заказана только проверка — вы получаете не абстрактное «всё ок», а документы и сценарии, по которым можно повторить прогон или передать другому разработчику.
Сначала — что нельзя сломать. Потом сценарии, прогон, отчёт. Не «потестируем когда-нибудь».
Что нельзя сломать при релизе.
ScopeКритичные пути и edge cases.
Чек-листРучное + автоматизация где уместно.
pytestПеред релизом, не после жалобы клиента.
PassЧто проверено, что нашли, что исправили.
ReportЕсли коротко: тестирование — это не отдельная «услуга для галочки», а способ не узнавать о баге от клиента.
Нет. Менеджер по-прежнему может смотреть тексты и общую логику. Я проверяю технические сценарии: форма уходит, оплата проходит, письмо приходит, роли работают.
Зависит от частоты релизов. Раз в полгода — часто достаточно ручного прогона по списку. Раз в неделю — автотесты на критичные пути окупаются быстро.
Да — перед запуском, после редизайна, когда сменился подрядчик. Нужен доступ к staging или тестовой копии и короткий созвон про критичные сценарии.
Могу — если это мой проект или договорились на доработку. Если проверка стороннего кода — отдаю воспроизводимый отчёт, правки делает ваш разработчик или я отдельной задачей.
Цепочка, без которой бизнес теряет деньги или заявки. Например: калькулятор → заявка → письмо менеджеру → запись в CRM. Именно её прогоняем в первую очередь.
Опишите продукт — предложу формат: разовая проверка, регрессия или автотесты. Особенно если в проекте деньги, заявки или доступы клиентов.
