Ответ
Ответственность за качество продукта лежит на всей команде разработки (Whole Team Responsibility). Это ключевой принцип современных методологий, таких как Agile и DevOps.
Роли и их вклад в качество:
- Разработчики (Dev): Пишут чистый, тестируемый код, проводят модульное и интеграционное тестирование, практикуют парное программирование и ревью кода.
- QA-инженеры: Специализируются на обеспечении качества. Они проектируют тестовые стратегии, выполняют исследовательское и нефункциональное тестирование, выступают как адвокаты пользователя и эксперты по тестируемости системы.
- Менеджер продукта (PO): Формулирует четкие, тестируемые требования и критерии приемки (Acceptance Criteria), которые являются основой для тестов.
- Дизайнеры (UX/UI): Обеспечивают качество пользовательского опыта и соответствие макетам.
Пример на практике (процесс «триады»): Перед началом разработки новой функции проводятся встречи по уточнению требований с участием PO, Dev и QA. На них:
- PO объясняет бизнес-цель.
- Dev обсуждает техническую реализацию.
- QA задает вопросы с позиции пользователя и тестирования, помогая сформулировать четкие критерии приемки.
# Пример критерия приемки (Given-When-Then), сформулированного совместно
Feature: Добавление товара в корзину
Scenario: Успешное добавление товара в наличии
Given пользователь находится на странице товара
And товар есть в наличии
When пользователь нажимает кнопку "В корзину"
Then товар появляется в мини-корзине в шапке сайта
And отображается сообщение "Товар добавлен в корзину"
And счетчик товаров в корзине увеличивается на 1Таким образом, QA — это не «последний барьер», а интегральная часть команды, которая встраивает качество в процесс на всех этапах.
Ответ 18+ 🔞
Да ты посмотри, какая хуйня! Все эти умные книжки про «эджайл» и «девопс» кричат одно и то же: «Качество — это дело всей команды, блядь!». Ага, щас. Как будто раньше мы не знали, что если один мудак накосячит, то всем потом расхлёбывать.
Ну ладно, по пунктам, как у этих теоретиков.
Кто за что в ответе, или «Разделяй и не властвуй, а то заебёшься»:
- Разработчики (Эти, Dev): Им, конечно, главное — не нагородить такого кода, чтобы потом самим же в нём и утонуть. Чистый код, тесты свои написали, друг другу в ревью посмотрели — вот и хорошо. А то бывает, сдадут фичу, а там такой пиздец, что хоть святых выноси.
- Тестировщики (QA): А это, блядь, самые главные циники и пессимисты в команде. Их работа — не верить на слово. Никому. Ни продакту, ни разработчикам, ни даже самим себе. Они должны думать, как пользователь, у которого руки из жопы и который специально будет жать не на те кнопки. Адвокаты пользователя, ёпта! Эксперты по тому, как всё сломать, пока не поздно.
- Менеджер продукта (PO): А этот товарищ должен требования писать не как бог на душу положит, а так, чтобы их можно было проверить. Не «сделайте красиво», а «при нажатии на эту хуйню должно происходить вот это». Критерии приемки — это его епархия. Если их нет, вся команда потом будет в жопе.
- Дизайнеры: Ну, эти следят, чтобы кнопки были на своих местах, а не как у меня в гараже — где попало. Качество опыта, все дела.
А на практике как? А вот как, блядь!
Перед тем как начать пилить фичу, нормальные люди собираются втроём (PO, Dev, QA) и начинают её обсуждать. Это называется «триада», звучит умно, а по сути — чтобы потом не было мучительно больно.
- PO выдает: «Нам надо, чтобы пользователь мог купить этот шлакоблок».
- Dev начинает чесать репу: «Ну, мы можем прикрутить кнопку к апишке корзины, но там легаси-код, может всё ебнуться».
- А тут вступает QA, хитро так прищурившись: «А стоп, ребята. А если товара нет? Что покажем? А если пользователь уже добавил его? А если интернет отвалится в момент клика? А если он робот? А если он нажмёт кнопку десять раз подряд?».
И вот в этой драке и рождаются те самые критерии приемки — список условий, когда фича считается сделанной, а не просто «о, вроде работает».
# И вот эта простыня — результат той самой драки. Все согласны.
Feature: Добавление товара в корзину
Scenario: Успешное добавление товара в наличии
Given пользователь находится на странице товара
And товар есть в наличии
When пользователь нажимает кнопку "В корзину"
Then товар появляется в мини-корзине в шапке сайта
And отображается сообщение "Товар добавлен в корзину"
And счетчик товаров в корзине увеличивается на 1Так что нет, QA — это не тот чел, который в конце приходит и говорит: «Всё хуёво, переделывайте». Это тот, кто сидит с самого начала и не даёт команде наделать таких косяков, которые потом и исправить-то будет овердохуища работы. Качество встраивается в процесс, а не прикручивается скотчем в конце. Всем, блядь, плевать на качество, пока не припрет. А вот чтобы не приперло — для этого QA и нужен.