У меня до сих пор, на лице возникает возмущение, когда "менеджер" или "директор" начинает совещание о качестве продукта. А на нем не звучит ничего принципиально нового и глубокого.

Слайды, структурированный спич о том, как команда "существенно усилила качество продукта" за некий период. Именно в этот момент происходит подмена понятий.

Количество имеющихся у команды тестов - предстает эквивалентом качества. Процент покрытия - доказывает зрелость проекта.

При этом само понятие качества не является чем-то размытым. Мы интуитивно понимаем разницу между тем, что работает стабильно, и тем, что держится на удаче и терпении пользователей. А с ПО внезапно начинается другая логика. Удобно измеряемые показатели объявляются главным доказательством прогресса, хотя они описывают лишь объём проделанной работы, но не её реальное влияние на устойчивость продукта.

Сами цифры не лгут, но легко вводят в заблуждение. Когда качество сводится к количеству, оно становится удобным для отчётности и безопасным для обсуждения. Но при этом теряет содержание.

Какие секреты качества существуют?

1. Качество не имеет отношения к цифрам

Проблема в том, что рост показателей сам по себе не описывает качество. Он описывает активность.

Качество трудно измерить напрямую, и именно поэтому так велик соблазн заменить его удобными метриками, которые можно посчитать, сравнить и вставить в отчёт. Добавили сто тестов - «улучшили качество», подняли покрытие выше 80% - «стали зрелее», сократили число дефектов - «движемся в правильном направлении».

Это логично звучит, но логика здесь подменена.

Достаточно одного серьёзного бага, чтобы обрушить доверие пользователей и нанести финансовый ущерб. Достаточно одного недовольного клиента, чтобы публично поставить под сомнение вашу репутацию, и достаточно одного критически важного пропущенного сценария, чтобы запустить цепочку последствий.

У качества нет универсального числа.

2. Качество субъективно для каждого. Это неудобный факт.

Самая распространённая иллюзия о качестве - вера в то, что существует универсальная формула, где достаточно подставить количество тестов, процент покрытия и число дефектов, чтобы получить объективный результат. Такая модель выглядит управляемой и понятной, но она игнорирует главное: качество не существует вне системы ценностей.

Качество - это ценность для кого-то.  Это автоматически переводит разговор из плоскости арифметики в плоскость приоритетов, ожиданий и контекста.

Разница хорошо видна на бытовых примерах.

Один человек убеждён, что лучшие смартфоны - iPhone, другой - что Samsung или любой другой android, и ни таблицы характеристик, ни примеры, ни комплектация не способны окончить спор.

3. Вы не обеспечиваете качество

Когда я попал в IT, тестировщики (или QA), казалось, верят, что они эдакие волшебные пчелки, поедающие ПО и гадящие качеством. Спустя 6 лет мы все еще верим в это. Некоторые из нас даже оскорбляются, если назвать их тестировщиками. Но "вы" странные ребята, честно.

Со временем и при помощи моих наставников я выяснил, что качество нельзя насильно "втестировать" в продукт. В реальности тестирование и качество никак явно не коррелируют.

Да, конечно, мы знаем, что успешные компании тестируют свое ПО, но в мире тысячи компаний с успешными продуктами и ужасными процессами – настолько, что задумываешся, как им удается не потерять свой бизнес. Даже технические гиганты начинали в гараже с пятью разработчиками на коленке – у них не было "директора по качеству", "ангелов" или еще кого. Тестирование не обеспечивает качество так же, как тест на Covid не гарантирует, что вам станет лучше – он просто дает вам информацию о вашем текущем состоянии. Иными словами, тестирование – это диагностика, дающая важную информацию, которая может повлиять на ваши решения о качестве.

Итак, подитожить – не существует действия или его отсутствия, приводящего к "обеспечению качества", если бы оно существовало – почему же мы все этим не заняты? Тестирование занимает время и силы, если бы существовал простой способ им заниматься – его бы уже создали.