Alex_Wilson
New member
У нас в команде почти год не было отдельного QA. Сначала это казалось экономией, потом — лотереей на проде. Я перепробовал кучу автотестов и понял простую вещь: спасают релизы не те, что дают красивое покрытие, а те, что проверяют рискованные и дорогие сценарии. Если тест не способен предотвратить звонок клиента или откат деплоя, он скорее ритуал, чем защита.
Первым делом мы попробовали тяжёлые E2E через интерфейс. Это было больно: тесты падали из-за таймингов, селекторов и тестовых данных, шли по часу и всё равно пропускали баги в API. Тогда я собрал дымовой набор на уровне API: авторизация, создание заказа, оплата, вебхук от платёжки, чтение статуса. Он бежит пару минут после деплоя и ловит большинство катастроф. Совет: сделайте такой smoke обязательным, даже если больше ничего не успеваете.
Второе, что реально спасало, — контрактные тесты между сервисами. Без QA никто не проверяет вручную, что бэкенд не поменял тип поля, что фронт не отправил лишний параметр, что событие в очередь уходит в старом формате. Мы зафиксировали схемы публичных API и событий, добавили проверки совместимости. Однажды такое тестирование поймало изменение, которое иначе уронило бы интеграцию с партнёром в пятницу вечером.
E2E всё же нужны, но их должно быть мало. У нас пять-семь сценариев на критический путь: регистрация, вход, основная покупка, отмена, возврат, сброс пароля. Запускаем не на каждый коммит, а перед релизом и на стейдже. Если тест флакует, я не терплю: либо чиню, либо удаляю. Флаки-тест хуже отсутствия теста, потому что команда перестаёт верить красному CI.
Юнит-тесты я считаю обязательными там, где есть деньги и данные: расчёт скидок, налоги, лимиты, даты, идемпотентность. Интеграционные тесты с реальной базой и очередями тоже окупаются. Именно они у нас поймали двойное списание из-за ретрая. Правило простое: чем дороже ошибка, тем ближе к коду должен быть тест. Не гонитесь за процентами покрытия — гонитесь за риском.
Что я почти не автоматизирую: пиксельную вёрстку, одноразовые админки и исследовательское тестирование. Но перед крупным релизом у нас есть короткий ручной чек-лист и наблюдение за метриками после выката. Автотесты не заменяют мониторинг, алерты, фича-флаги и канареечный деплой. Лучший тест — тот, который не только находит баг до релиза, но и помогает быстро откатиться после.
Из процесса: быстрый набор на pull request до десяти минут, релизный набор до получаса, запрет на merge при красном CI, тестовые данные как код и один ответственный за здоровье тестов. И главное — без QA качество принадлежит разработчикам. Как только мы это признали, автотесты перестали быть театром и стали страховкой.
В итоге за год без отдельного QA мы не стали идеальными, но перестали бояться каждого релиза. Меня больше всего спасали дымовые API-тесты, контракты и несколько честных E2E на деньги. А какие автотесты реально выручали ваши релизы? Расскажите свою историю — уверен, у форумчан найдётся пара приёмов, которые стоит забрать в копилку.
Первым делом мы попробовали тяжёлые E2E через интерфейс. Это было больно: тесты падали из-за таймингов, селекторов и тестовых данных, шли по часу и всё равно пропускали баги в API. Тогда я собрал дымовой набор на уровне API: авторизация, создание заказа, оплата, вебхук от платёжки, чтение статуса. Он бежит пару минут после деплоя и ловит большинство катастроф. Совет: сделайте такой smoke обязательным, даже если больше ничего не успеваете.
Второе, что реально спасало, — контрактные тесты между сервисами. Без QA никто не проверяет вручную, что бэкенд не поменял тип поля, что фронт не отправил лишний параметр, что событие в очередь уходит в старом формате. Мы зафиксировали схемы публичных API и событий, добавили проверки совместимости. Однажды такое тестирование поймало изменение, которое иначе уронило бы интеграцию с партнёром в пятницу вечером.
E2E всё же нужны, но их должно быть мало. У нас пять-семь сценариев на критический путь: регистрация, вход, основная покупка, отмена, возврат, сброс пароля. Запускаем не на каждый коммит, а перед релизом и на стейдже. Если тест флакует, я не терплю: либо чиню, либо удаляю. Флаки-тест хуже отсутствия теста, потому что команда перестаёт верить красному CI.
Юнит-тесты я считаю обязательными там, где есть деньги и данные: расчёт скидок, налоги, лимиты, даты, идемпотентность. Интеграционные тесты с реальной базой и очередями тоже окупаются. Именно они у нас поймали двойное списание из-за ретрая. Правило простое: чем дороже ошибка, тем ближе к коду должен быть тест. Не гонитесь за процентами покрытия — гонитесь за риском.
Что я почти не автоматизирую: пиксельную вёрстку, одноразовые админки и исследовательское тестирование. Но перед крупным релизом у нас есть короткий ручной чек-лист и наблюдение за метриками после выката. Автотесты не заменяют мониторинг, алерты, фича-флаги и канареечный деплой. Лучший тест — тот, который не только находит баг до релиза, но и помогает быстро откатиться после.
Из процесса: быстрый набор на pull request до десяти минут, релизный набор до получаса, запрет на merge при красном CI, тестовые данные как код и один ответственный за здоровье тестов. И главное — без QA качество принадлежит разработчикам. Как только мы это признали, автотесты перестали быть театром и стали страховкой.
В итоге за год без отдельного QA мы не стали идеальными, но перестали бояться каждого релиза. Меня больше всего спасали дымовые API-тесты, контракты и несколько честных E2E на деньги. А какие автотесты реально выручали ваши релизы? Расскажите свою историю — уверен, у форумчан найдётся пара приёмов, которые стоит забрать в копилку.