Цели и критерии успеха

Обычный опыт. Цель — «чтобы работало» и «чтобы понять, как писать автотесты». Успех — тест прошёл, баг найден, код написан. Часто нет метрик: покрытие считают приблизительно, стабильность тестов не отслеживают.

Коммерческий опыт. Цель — минимизировать риски при выпуске, держать стабильность релизов и стоимость поддержки тестов на приемлемом уровне. Успех измеряют: покрытие по критическим сценариям, доля flaky‑тестов, время прогона, процент ложных срабатываний, стоимость одного прогона. В коммерции часто считают не «сколько тестов», а «сколько рисков закрыто» — это как раз стыкуется с математикой тест‑дизайна (классы эквивалентности, граничные значения, комбинаторика).

Окружение и воспроизводимость

Обычный. Локальная машина, фиксированные данные, «просто запустилось у меня». Проблемы с окружением считаются нормальными: «у меня работает».

Коммерческий. Окружение должно быть детерминированным: контейнеры, CI/CD, тестовые среды, моки/заглушки, версионирование данных. Если тест падает из‑за нестабильного окружения — это баг процесса, а не «особенность». Здесь критично уметь описывать и воспроизводить условия: версии браузеров, ОС, базы данных, сетевые задержки

Качество и поддержка тестов

Обычный. Тесты пишут быстро, рефакторинг откладывают, дублирование кода допустимо, если «работает». Падающий тест можно просто закомментировать.

Коммерческий. Тест — это код продукта: код-ревью, стандарты именования, структура, изоляция, понятные сообщения об ошибках. Падающий тест требует расследования: это баг в продукте, в тесте или в инфраструктуре? Есть SLA на исправление: сколько дней допустимо держать тест в «красном» состоянии.

Стабильность и flaky‑тесты

Обычный. Flaky (нестабильные) тесты — неприятность, но не катастрофа. Можно запускать несколько раз и брать «лучший результат».

Коммерческий. Flaky‑тесты — это прямые издержки: ложные алерты, потеря доверия к автотестам, задержки релизов. Их считают, классифицируют и либо исправляют, либо изолируют. Вводят метрики: процент нестабильных тестов, среднее число перезапусков, доля падений по причинам.

Интеграция в процесс разработки

Обычный. Автотесты запускают вручную, когда «есть время». Нет связи с задачами в трекере, нет отчётности.

Коммерческий. Тесты — часть пайплайна: запуск по коммиту, по релизу, по расписанию. Результаты связаны с задачами (Jira/YouTrack), есть отчётность для команды и менеджмента. Есть правила: какие тесты запускать на PR, какие — на релиз, какие можно пропускать.

Экономика и сроки

Обычный. Стоимость тестов не считают. Пишут, пока интересно.

Коммерческий. Считают TCO (total cost of ownership) автотестов: время написания, прогона, поддержки, исправления. Есть правило: тест должен окупаться. Если он падает чаще, чем находит баги, или требует слишком много времени на поддержку — его убирают или переписывают.