Мне нравится Scaled Agile Framework (SAFe), и я вброшу вам несколько идей по тестированию с точки зрения этого фреймворка.
Часто вижу, что во многих компаниях одной из ключевых метрик является количество найденных тестировщиком дефектов. Хочу донести мысль: от этой метрики можно смело отказаться и жить в прекрасном мире Agile-разработки! 🚀
🤯 Когда вы начинаете считать баги, найденные тестировщиком, происходит вот что:
⏳ Вы заменяете диалог бюрократией. Время на оформление и администрирование багов, можно спокойно потратить на создание фичи, улучшение автотестов или просто на кофе-брейк, где рождается неформальное взаимопонимание.
⚔️ Вы подогреваете конфликт «Тестировщики vs Разработчики». Метрика бессознательно противопоставляет друг другу две роли. Разработчики могут начать воспринимать баги как личную атаку, а тестировщики — как охотники за головами. Вместо «мы одна команда» возникает «мы и они». Исчезает психологическая безопасность, а с ней — и желание помогать друг другу.
📉 Вы теряете фокус на главном — на пользователе. Ценность — это то, что получает пользователь. Дефект, найденный и исправленный внутри спринта, для него не существует. Он никак не влияет на его опыт. Но ваша метрика заставляет команду концентрироваться на этом внутреннем шуме, а не на том, что будет после релиза.
🎯 Немного оффтопа. Откуда это взялось?
Я не знаю, большинство компаний уже перешли на командную работу.
В SAFe нет отдельной роли «Тестировщик» в традиционном смысле, поскольку фокус смещается на встраивание качества в процесс и ответственность за него у всей команды.
У меня две бомбящих версии:
1. Мидлы гордились своими найденными багами, стали лидами и теперь распространяют на всех метрики, которые считают хорошими
2. Владельцами продуктов стали выходцы из разработки и по старинке просят какую-то техническую информацию от сотрудников, вместо показателей команд в целом
🎯 На чем тогда фокусироваться команде?
Статья синьерская, пишу кратко.
В SAFe мы думаем о ценности, а не о процессе. Важны не баги на пути, а то, доехали ли вы до цели, которую перед собой поставили.
Все это называется большой фразой Build-in-quality (тут большая статья), в ней весь перечислен почти арсенал обеспечения качества. Я перечислю основные, вы про них отдельно уже много раз читали: Shift Left, DoD, DoR, NFR, SLA, TDD, BDD, IaC, CI, CD, автоматизация, нормальный Scrum (а не мемные созвоны).
📊 Команда использует те инструменты, которые ей подходят. Но единая метрика у всех команд одна - эта метрика называется Предсказуемость (Predictability).
Вы можете вообще никакие инструменты не использовать: если у вас хорошая предсказуемость и вы выполняете все обязательства перед бизнесом - никаких вопросов к вам не будет.
Предсказуемость. Как это работает на практике:
Команды, которые совместно разрабатывают группу продуктов, собираются в Поезд (ART).
Раз в квартал весь поезд собирается на Планирование (PI Planning). Команда (вся команда, и тестировщики тоже, привет Shift Left Testing) забирает работы из беклога, оценивает, объединяются в цели (PI Objectives). Очень подробно об этом написали в РТЛабс (ГосУслуги).
В конце планирования приходят Владельцы бизнеса (Business Owners) и определяют, что важно сделать в первую очередь. Они проставляют каждой цели оценку от 1 до 10. Эта оценка называется Business Value (BV). Вы можете добавить в список целей даже устранение тех. долга, если там накопилось.
В конце квартала бизнес берет каждую цель и оценивает степень ее достижения (Actual Value, AV).
Итого:
BV — что было важно для бизнеса в начале квартала.
AV — насколько хорошо цель была выполнена в конце.
📊 Получается Предсказуемость (Predictability) - очень важная метрика понятная команде и бизнесу - : Выполняем ли мы свои обещания перед бизнесомКоманды собираются на мега-ретро (Inspect & Adapt) и всем поездом обсуждают почему им не удалось достичь целей и что с этим делать.
Внутренние баги — это часть процесса, а не его результат. Они не должны мешать команде достигать высокого AV. Мешает только то, что утекло в прод и испортило опыт пользователя.
👃 Какие метрики еще сомнительны.
Если ваши метрики попадают под один из этих пунктов, задумайтесь:
Метрика вызывает споры в команде.
Её можно подтасовать.
Она никак не влияет на итоговый командный результат и ценность.
✅ На что смотреть помимо предсказуемости?
❤️ Лояльность пользователей и другие feedback-метрики.
🔥 Количество критичных дефектов в проде
Если концепция интересна, можем вживую обсудить в телеге: https://t.me/sharkov_qa/15 или на вашем канале, подкасте