Качественный субъективизм

Один из серьёзных нюансов с качеством ПО с точки зрения разработки: уровень этого самого качества в изрядной степени субъективен.

При желании каждый участник процесса разработки легко найдёт оправдания и объяснит, почему налажал не он. Бизнес-аналитик честно подумал, но не смог учесть все нюансы многолетней архитектуры. Разработчик честно реализовал требования, а тестировщик честно их проверил. Оба - как поняли. Ну а что, если требования не полны - вопросы к аналитику. Он ещё и менял их постоянно, чего удивляться. Техлид недоучёл энтузиазм джуниора, а джуниор не в курсе, чем отзывается взмах крылом в этом конкретном компоненте системы.

В общем, все молодцы, а на выходе какашка. Нормальный процесс переработки сырого продукта.

И да, отмечу, фраза "каждый легко найдёт оправдания и объяснит, почему налажал не он" не должна вводить в заблуждение. Злобные мудаки встречаются всё же не очень часто (ну или я избалован работой в продуктовой компании). Никто не стремится саботировать. Просто каждый работает так, как видит возможным. Через голову не перепрыгнешь. Если есть из критериев качества только и прежде всего соответствие требованиям, то от них и будет каждый отталкиваться. В меру своего формализма, бодрости, семейных радостей и физического здоровья.




Я как аналитик сделал всё возможное: проанализировал ожидания и возможности, проконсультировался с инженерами. Несколько раз скорректировал требования по мере проявления нюансов.

Я как разработчик реализовал требования в архитектуре и коде насколько позволили уже существующие архитектура и код, а также время и личная смелость.
Я как тестировщик, проверил фичу, пришёл в ужас, зарепортил баги, бился за них, но треть багов умерли вонтфиксами. Часть потом переоткроется, как показывает опыт, но это потом. Ответственные лица решили, что баги не фатальные. С формальной точки зрения блокирующих проблем нет, тестирование - done.

Я как... Ой, а всё, никого ж не осталось. Релиз.

Я как руководитель RnD недоволен, что мне на совете директоров рассказывают про баги в продукте. Каждый из инженеров видел проблему, и никто её не починил (а то и не заметил).
В этой войне авторитетов "рядовой тестировщик" равно как и "рядовой разработчик" с формальной точки зрения не всегда может показать что продукт - ну не готов к использованию. Есть те, кто более равны и есть формальные требования.

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

Полагаю, привносить эту субъективность можно по-разному, и разным командам/компаниям подойдут разные способы. Если тестировщик поставил фиче оценку 2 из 5, вероятно с фичей что-то не так. Возможны и другие способы, но "техническая" реализация не суть важна. Важно дополнить формальные показатели живым ощущением сотрудника - тогда чуть больше шансов узнать реальное состояние продукта.

Всяко это лучше и полезней, чем пытаться понять, что таск-трекер может сказать о качестве продукта (QA квартирник Codefest'а, привет). Таки таск-трекер для задач, а качество для людей. Давайте у людей и спрашивать о качестве.