"...the goal shouldn’t be more tests. It should be less risk. Quality isn’t about measuring lines of code, it’s about understanding where things can go wrong and ensuring we catch critical issues early."
"Risk thinking aligns quality with business impact, not just technical metrics."
"Хорошие тесты лучше, чем много тестов" (Don’t aim for more tests; aim for the right tests) - этот дзен не всем понятен и в целом, в автоматизации тестирования количество не всегда переходит в качество. Это происходит достаточно часто, потому что многие находятся в вечном "достижении количества" в условиях "постоянно уходящего поезда из новых фичей".
Вот вроде все хорошо с этим risk based подходом, за исключением нюанса -
Про риски тут в канале уже было бубубу:
Со словом "риски" у меня с недавних пор сложные отношения, но в целом действительно, если отталкиваться от них, действительно можно получать более предсказуемые результаты проекта. Но работать с ними никто не умеет (я таких не встречал)...
В статье есть подсказки:
• Какие риски для бизнеса являются наиболее критическими?
• Какие сбои нам было бы стыдно объяснять руководству?
И следующие за ними:
• Есть ли у нас тесты, которые позволяют снизить эти риски на ранних этапах жизненного цикла разработки?
• Если нет, как мы можем повысить уверенность в этой области?
—
Очень логичным кажется пойти к бизнесу и спросить про эти риски. Но часто ответ будет "нужно, чтобы все работало и лучше вчера, на крайняк - сегодня" и вообще "за качество отвечает разработка".
А если ответ будет не таким, то будет что-то вида "репутационные риски" и "финансовые претензии" от "несоответствия ожиданий заказчика реальности". А, еще, "нужно писать фичи, а то продаж не будет" - вот где настоящий риск.
И мой опыт показывает, что история настолько комплексная и многоаспектная, что в 90% случаев "прилетает" по вопросам/проблемам всем давно известным, но которые намеренно или не намеренно "упустили" в момент заключения сделки, если до нее все же дошло.
А давайте подумаем, как мог бы выглядеть анализ того, обычно скрыто за магией слова "риск" без походов к бизнесу.
Продолжение следует.
Пока я думаю и пытаюсь выгрузить это хоть в какой-то понятной форме, расскажите, что у вас обстоят дела с "risk based testing approach". Выходит ли за пределы регламентов и правил? Как определяете что и сколько тестировать или автоматизировать?
#quality