Ответ
На последнем проекте QA-команда была встроена в кросс-функциональную продуктовую команду (Squad) по модели Agile/Scrum.
Структура и распределение ролей:
| Роль | Количество | Основные обязанности в контексте QA |
|---|---|---|
| Manual QA Engineer | 2 | • Разработка и выполнение тест-кейсов. • Exploratory и регрессионное тестирование. • Верификация багов. • Тестирование на мобильных устройствах. |
| QA Automation Engineer (я) | 1 | • Разработка и поддержка фреймворка автотестов (UI/API). • Интеграция тестов в CI/CD (Jenkins/GitLab CI). • Анализ падающих тестов и флакки-тестов. • Консультирование разработчиков по написанию unit- и интеграционных тестов. |
| Разработчики (Backend/Frontend) | 4 | • Написание unit- и интеграционных тестов. • Участие в сессиях pair-testing с QA. |
| Прочие (PO, SM, Designer) | 3 | • Формирование требований (Acceptance Criteria). • Планирование тестовых активностей в спринте. |
Ключевые принципы работы:
- Shift-Left: QA участвовали в планировании и обсуждении требований с самого начала спринта.
- Коллективная ответственность: Качество — задача всей команды, а не только QA. Разработчики также писали тесты и участвовали в тестировании.
- Прозрачность: Результаты автоматических прогонов (Allure отчеты, метрики) были доступны всем через CI/CD дашборд.
Такая модель позволяла быстро получать обратную связь и обеспечивала высокое качество на каждом этапе разработки.
Ответ 18+ 🔞
А, ну это ж классика, блядь! Сейчас расскажу, как мы там в последнем проекте в этой вашей Agile-шараге крутились. Представь себе, сидим мы, как три мушкетёра, только вместо шпаг — багрепорты, а вместо плащей — джиры забитые под завязку.
Кто чем занимался, или "Разделяй и не еби мозг":
| Кто в этой цирковой труппе | Сколько душ | Чем мозги выносили (в контексте QA) |
|---|---|---|
| Ручные тестировщики (Manual QA) | 2 чувака | • Писали эти ваши тест-кейсы, будто романы в стол. • Бегали по продукту, как угорелые, в поисках, где бы ещё что-нибудь сломать (Exploratory тестирование, ёпта). • Проверяли, починили ли баги, или разработчики опять лажанулись. • Тыкали в телефоны до посинения пальцев. |
| Я, Автоматизатор (QA Automation) | 1 я, блядь | • Писал фреймворк для автотестов, который потом все ругали, но без которого жить не могли. • Настраивал эту магию, чтобы тесты сами бегали в CI/CD (Jenkins, GitLab CI — ну ты понял). • Разбирался, почему тесты падают: то ли баг, то ли я кривой, то ли просто тесты — флакки ебаные. • Объяснял разработчикам, как свои unit-тесты писать, чтобы не позорились. |
| Разработчики (Backend/Frontend) | 4 технаря | • В теории — писали unit-тесты. На практике — иногда приходилось им напоминать, что это вообще такое. • Иногда снисходили до pair-testing с нами, простыми смертными QA. |
| Остальная обслуга (PO, SM, Designer) | 3 человека | • Рождали требования (Acceptance Criteria), которые потом все по-разному понимали. • Решали, сколько времени в спринте мы будем тратить на тестирование, а сколько — на пофиксить то, что сломали во время тестирования. |
А теперь, сука, главные фишки, как мы выживали:
- Shift-Left, блядь: Нас, QA, не выгоняли в конец спринта, как обычно. Нет! Мы с самого начала влезали в обсуждение требований и орали: "А как это тестировать-то, ёпта? Это ж не протестируешь!" Экономили всем нервы, короче.
- Качество — общая забота: Это не наш, QA, крест такой — качество тащить. Нет, блядь. Разработчики тоже должны были тесты писать и иногда даже руками потыкать. Коллективная ответственность, ебать её в сраку. Работало, надо сказать.
- Всё на виду: Все отчёты от автотестов, эти ваши графики и метрики — висели на дашборде, как на всеобщем позоре. Упал тест — все видят. Прозрачность, блядь, total.
В общем, такая модель, если все не мудаки, а адекваты, позволяла не доводить до пиздеца, а ловить косяки почти сразу. Как-то так, блядь.