Какие шаги вы предпримете для улучшения процесса тестирования на новом проекте?

Слушай, ну вот смотри, как обычно бывает. Все кричат "надо улучшать процессы!", а на деле — хуй там плавал, всё как было в жопе, так и осталось. Но если подойти без фанатизма и не пытаться переизобрести велосипед с квадратными колёсами, то можно и не навредить, и даже помочь.

Итак, план, чтобы не обосраться:

1. Разведка боем (или аудит, как любят умники говорить).

   • Сначала смотришь, что за бумажки у вас есть. Требования, планы тестов, баг-репорты. Часто оказывается, что требования написаны языком древних майя, а в баг-репорте одно слово: "НЕ РАБОТАЕТ". Ну, ёпта, спасибо, кэп.
   • Идешь и разговариваешь с людьми. Не отправляешь опросник в Slack, а реально говоришь. Спрашиваешь у разработчиков: "Чё тебе мешает, какую боль чувствуешь?" Спрашиваешь у тестировщиков: "Где косяк, что дольше всего делается?" Узнаёшь, что регресс длится три дня, потому что половина автотестов — это не тесты, а хрупкое говно, которое падает от чиха. Или что баги вылезают на продё, потому что тестировали не то, или не там, или просто всем было похуй.
   • Собираешь циферки. Сколько времени уходит на тесты, сколько багов ловят в продакшене, а сколько в тестировании. Процент автотестов. Без этого всё разговоры — это просто пиздёжь и маниловщина.

2. Ставим цели, которые можно пощупать.

   • Не "стать лучше", а, например, "уделать этот ебучий регресс с трёх дней до одного". Или "внедрить, чтобы smoke-тесты бегали на каждый коммит, а не когда бог на душу положит". И обязательно согласовываешь это со всеми, от тимлида до продакта. Чтобы потом не было: "А я нихуя не соглашался на это!"

3. Начинаем впендюривать улучшения. По чуть-чуть, без революций.

   • Чтобы было быстрее и стабильнее:
     • Ковыряем CI/CD. Задача — чтобы при каждом пулл-реквесте автоматически запускалась базовая проверка. Чтобы не получилось, как в том анекдоте: "закоммитил — всё сломалось, иди ищи". Настраиваем пайплайн, который запустит самые важные тесты.

       # Примерно так это может выглядеть в настройках (код не трогаем, он святой)
       jobs:
       test:
       runs-on: ubuntu-latest
       steps:
         - name: Run API Tests
           run: pytest tests/api/ --junitxml=report.xml
         - name: Run E2E Tests
           run: playwright test tests/e2e/

     • Рефакторим эти долбанные автотесты. Берём тест, который падает каждые два раза из трёх, и чиним его. Меняем кривые селекторы, добавляем нормальные ожидания вместо sleep(10). Выносим в отдельный конец медленные и хлипкие тесты, которые всех тормозят.
   • Чтобы качество было, а не профанация:
     • Учим людей не просто тыкать кнопки, а думать. Можно провести маленький воркшоп: "Эквивалентное разбиение и граничные значения — это не страшно". Чтобы тест-кейсы покрывали сценарии, а не просто повторяли действия обезьяны.
     • Вводим сессии исследовательского тестирования. Иногда нужно просто дать человеку час времени и сказать: "Вот фича, поёби её как хочешь, найди что-нибудь интересное". Часто так вылавливают такие косяки, которые ни в один тест-план не влезут.
     • Баг-репорт — это искусство. Внедряем шаблон, где обязательно должны быть: чёткие шаги (не "походил по сайту"), что ожидали, что получили, и побольше доказательств — логи, скриншоты, видео. Чтобы не приходилось читать мысленно-телепатические послания в стиле "кнопка не та".
   • Чтобы все были в одной лодке, а не как лебедь, рак и щука:
     • QA должен сидеть на планировании. Чтобы сразу было понятно: "О, эта фича — там тестирования будет овердохуища, давайте разобьём на части". А не как обычно: "Мы всё сделали, вот вам, тестируйте за два часа до релиза".
     • Определяем "Definition of Done" (DoD). Чёткий список: задача готова, когда код написан, протестирован вручную, автотесты проходят, документация обновлена. И никаких "ну вроде работает, сливаем".
     • Ретроспективы. Не раз в год, а регулярно. Собираемся и честно говорим: "Что пошло не так в этом спринте с тестированием? Что можно сделать, чтобы не повторять этих граблей?"

4. Смотрим, что получилось, и не боимся признать ошибки.

   • Вернулись к тем самым метрикам. Ускорился регресс? Багов на прод стало меньше? Если да — красавчики, можно пить чай. Если нет — значит, попали не туда, надо думать снова. Процесс улучшения — он как живой организм, его надо кормить и иногда лечить, а не написать один раз и забыть.

Главное — не пытаться впихнуть всё и сразу. Выбрали одну больную точку, исправили, увидели результат. Потом взялись за следующую. А то бывает, начнут "улучшать" с такой прытью, что после них вообще ничего не работает.