Мне нравится 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).

Вы можете вообще никакие инструменты не использовать: если у вас хорошая предсказуемость и вы выполняете все обязательства перед бизнесом - никаких вопросов к вам не будет.

Предсказуемость. Как это работает на практике:

0. Команды, которые совместно разрабатывают группу продуктов, собираются в Поезд (ART).

1. Раз в квартал весь поезд собирается на Планирование (PI Planning). Команда (вся команда, и тестировщики тоже, привет Shift Left Testing) забирает работы из беклога, оценивает, объединяются в цели (PI Objectives). Очень подробно об этом написали в РТЛабс (ГосУслуги).
   

   

   В конце планирования приходят Владельцы бизнеса (Business Owners) и определяют, что важно сделать в первую очередь. Они проставляют каждой цели оценку от 1 до 10. Эта оценка называется Business Value (BV). Вы можете добавить в список целей даже устранение тех. долга, если там накопилось.

   

2. В конце квартала бизнес берет каждую цель и оценивает степень ее достижения (Actual Value, AV).
   
   Итого:
   BV — что было важно для бизнеса в начале квартала.
   AV — насколько хорошо цель была выполнена в конце.
   ? Получается Предсказуемость (Predictability) - очень важная метрика понятная команде и бизнесу - : Выполняем ли мы свои обещания перед бизнесом

3. Команды собираются на мега-ретро (Inspect & Adapt) и всем поездом обсуждают почему им не удалось достичь целей и что с этим делать.

   

Внутренние баги — это часть процесса, а не его результат. Они не должны мешать команде достигать высокого AV. Мешает только то, что утекло в прод и испортило опыт пользователя.

? Какие метрики еще сомнительны.

Если ваши метрики попадают под один из этих пунктов, задумайтесь:

• Метрика вызывает споры в команде.

• Её можно подтасовать.

• Она никак не влияет на итоговый командный результат и ценность.

✅ На что смотреть помимо предсказуемости?

• ❤️ Лояльность пользователей и другие feedback-метрики.

• ? Количество критичных дефектов в проде

Если концепция интересна, можем вживую обсудить в телеге: https://t.me/sharkov_qa/15 или на вашем канале, подкасте