Методологии в тестировании: Scrum, Agile или "хуяк-хуяк и в продакшен"?

Часто спрашивают: "А по какой методологии работает тестировщик?" Ответ простой – по той, которая есть в компании.

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

🔹 1. Agile / Scrum / Kanban
Самая популярная история в IT. По факту, QA в таких командах работает в режиме постоянных итераций:
✅ Пишем тест-кейсы до разработки (иногда).
✅ Тестируем во время спринта.
✅ Проводим ретро, обсуждаем проблемы.
✅ Чаще всего релизы раз в 2-4 недели.

Звучит идеально, но на практике:
📌 Вечно горящие дедлайны.
📌 В тестирование часто закладывают минимальное время.
📌 После релиза баги все равно вылазят, потому что "не успели покрыть все кейсы".

🔹 2. "Хуяк-хуяк и в продакшен"
Неофициальная, но встречающаяся модель. Обычно это стартапы, маленькие проекты или просто хаос в разработке.

Как выглядит процесс:
⚡️ Разработчик что-то закоммитил.
⚡️ QA бегло посмотрел, сказал "вроде норм".
⚡️ В тот же день фича уже в проде.

В итоге:
🚨 Баги летят пользователям.
🚨 QA всегда крайний.
🚨 "А почему вы это не проверили?" – "А когда я должен был это проверить, если код вышел через 10 минут после коммита?"

🔹 3. Waterfall (да, он еще жив)
Классическая модель, где сначала пишутся требования, потом долгий этап разработки, потом тестирование. QA тут подключается ближе к концу проекта.

Минусы:
📌 Если в требованиях ошибка – она вылезет только в самом конце.
📌 Фиксы делать долго и дорого.
📌 Гибкость минимальная.

Плюсы:
✅ Если процессы налажены, можно работать без хаоса и стресса.
✅ Хорошо подходит для серьезных систем (банки, госзаказы, медтехника).


Scrum, Agile, Kanban – это хорошо, но реальность часто выглядит иначе. Главное – не методология, а то, насколько процесс тестирования встроен в разработку.

А у вас какая методология на проектах?

#scrum #agile #методологии