Авторский канал Антона Ватуцкого
Мнение о тестировании ПО
Вакансии для начинающих
Немного ссылок на туда - куда смотреть для обучения QA.
@antonvatuckii
Post #139
1.42K
Методологии в тестировании: Scrum, Agile или "хуяк-хуяк и в продакшен"?
Часто спрашивают: "А по какой методологии работает тестировщик?" Ответ простой – по той, которая есть в компании.
Но если копнуть глубже, то можно выделить несколько вариантов, которые встречаются чаще всего.
🔹 1. Agile / Scrum / Kanban
Самая популярная история в IT. По факту, QA в таких командах работает в режиме постоянных итераций:
✅ Пишем тест-кейсы до разработки (иногда).
✅ Тестируем во время спринта.
✅ Проводим ретро, обсуждаем проблемы.
✅ Чаще всего релизы раз в 2-4 недели.
Звучит идеально, но на практике:
📌 Вечно горящие дедлайны.
📌 В тестирование часто закладывают минимальное время.
📌 После релиза баги все равно вылазят, потому что "не успели покрыть все кейсы".
🔹 2. "Хуяк-хуяк и в продакшен"
Неофициальная, но встречающаяся модель. Обычно это стартапы, маленькие проекты или просто хаос в разработке.
Как выглядит процесс:
⚡️ Разработчик что-то закоммитил.
⚡️ QA бегло посмотрел, сказал "вроде норм".
⚡️ В тот же день фича уже в проде.
В итоге:
🚨 Баги летят пользователям.
🚨 QA всегда крайний.
🚨 "А почему вы это не проверили?" – "А когда я должен был это проверить, если код вышел через 10 минут после коммита?"
🔹 3. Waterfall (да, он еще жив)
Классическая модель, где сначала пишутся требования, потом долгий этап разработки, потом тестирование. QA тут подключается ближе к концу проекта.
Минусы:
📌 Если в требованиях ошибка – она вылезет только в самом конце.
📌 Фиксы делать долго и дорого.
📌 Гибкость минимальная.
Плюсы:
✅ Если процессы налажены, можно работать без хаоса и стресса.
✅ Хорошо подходит для серьезных систем (банки, госзаказы, медтехника).
Scrum, Agile, Kanban – это хорошо, но реальность часто выглядит иначе. Главное – не методология, а то, насколько процесс тестирования встроен в разработку.
А у вас какая методология на проектах?
#scrum #agile #методологии
Часто спрашивают: "А по какой методологии работает тестировщик?" Ответ простой – по той, которая есть в компании.
Но если копнуть глубже, то можно выделить несколько вариантов, которые встречаются чаще всего.
🔹 1. Agile / Scrum / Kanban
Самая популярная история в IT. По факту, QA в таких командах работает в режиме постоянных итераций:
✅ Пишем тест-кейсы до разработки (иногда).
✅ Тестируем во время спринта.
✅ Проводим ретро, обсуждаем проблемы.
✅ Чаще всего релизы раз в 2-4 недели.
Звучит идеально, но на практике:
📌 Вечно горящие дедлайны.
📌 В тестирование часто закладывают минимальное время.
📌 После релиза баги все равно вылазят, потому что "не успели покрыть все кейсы".
🔹 2. "Хуяк-хуяк и в продакшен"
Неофициальная, но встречающаяся модель. Обычно это стартапы, маленькие проекты или просто хаос в разработке.
Как выглядит процесс:
⚡️ Разработчик что-то закоммитил.
⚡️ QA бегло посмотрел, сказал "вроде норм".
⚡️ В тот же день фича уже в проде.
В итоге:
🚨 Баги летят пользователям.
🚨 QA всегда крайний.
🚨 "А почему вы это не проверили?" – "А когда я должен был это проверить, если код вышел через 10 минут после коммита?"
🔹 3. Waterfall (да, он еще жив)
Классическая модель, где сначала пишутся требования, потом долгий этап разработки, потом тестирование. QA тут подключается ближе к концу проекта.
Минусы:
📌 Если в требованиях ошибка – она вылезет только в самом конце.
📌 Фиксы делать долго и дорого.
📌 Гибкость минимальная.
Плюсы:
✅ Если процессы налажены, можно работать без хаоса и стресса.
✅ Хорошо подходит для серьезных систем (банки, госзаказы, медтехника).
Scrum, Agile, Kanban – это хорошо, но реальность часто выглядит иначе. Главное – не методология, а то, насколько процесс тестирования встроен в разработку.
А у вас какая методология на проектах?
#scrum #agile #методологии
- 👍 10
- 🔥 3
