Home

Автор: Аугусто Евангелисти (Augusto Evangelisti)

Оригинал статьи: https://mysoftwarequality.wordpress.com/2016/10/17/ultimate-guide-to-reducing-the-amount-of-defects-and-other-waste-in-your-product/

Перевод: Ольга Алифанова

Что такое дефект? Лично мне нравится вот это определение:

"Дефект – это что угодно, угрожающее ценности продукта".

Прежде чем начать, давайте договоримся, что:

1. Мы не хотим сталкиваться с дефектами, угрожающими ценности нашего продукта.

2. Мы хотим, чтобы наши пользователи получали максимально возможную ценность от нашего продукта.

Если вы не согласны с утверждениями выше, дальше можно не читать.

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

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

Дефекты – это мусор

Надеюсь, все согласны: дефекты – это мусор. Это трата времени на разработку дефективных продуктов, создание дефективного кода, поиск дефектов, исправление дефектов, ретест дефектов. Даже на то, чтобы написать это предложение, я потратил некоторое время – представьте, сколько времени уходит на то, чтобы создать, найти, исправить, и проверить исправление бага.

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

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

Если все согласны, что дефекты – это мусор, зачем мы тратим время на их отслеживание, а уж рисовать графики – это вообще нонсенс! Не проще ли предотвращать их появление?

О, если бы мы только могли делать все как следует изначально, снижая количество дефектов в нашем творении! Однако я считаю, что эта цель вполне достижима. Хотите узнать больше? Читайте далее.

Команды, разрабатывающие ПО, придумали множество креативных способов управляться с дефектами. Вот несколько примеров.

Пример 1. Вознаграждение за мусор

Несколько лет назад я работал в одной из 5 Scrum-команд над критически важным для бизнеса проектом. Уточняю – внедрение Scrum было проведено из рук вон плохо, мы не релизились после каждого спринта, и наши критерии готовности были довольно сомнительными.

Близился важный релиз, и мы обнаружили, что нам нужно исправить множество дефектов перед выпуском продукта в прод. У нас было две недели на то, чтобы справиться с сотней дефектов. Наш технический директор поддерживал идею устранения багов и хотел выпустить продукт, в котором все дефекты устранены. Он разработал план, согласно которому нас бесплатно кормили днем и ночью, а разработчикам, которые бросили все силы на исправление багов, полагались дополнительные плюшки. Затем он решил выдать приз той команде, которая исправит максимальное количество багов.

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

Пример 2. Измерение дефектов

Раньше я работал по "водопаду" и хорошо помню, как менеджмент ввел новую метрику производительности, напрямую связанную с дефектами. Тестировщиков судили на основании Индекса Обнаружения Дефекта (рассчитанного как (количество багов, найденных в тестировании / общее количество багов, найденное в процессе производства ПО)*100. Индекс ниже 90 означал, что вся команда сидит без бонусов. Разработчиков индивидуально оценивали по количеству найденных тестировщиками в их коде дефектов, а бизнес-аналитиков судили по количество найденных тестировщиками проблем в требованиях.

Вооружайтесь – это настоящая бойня!

Встречи по приоритезации багов были полем битвы менеджеров, доказывающих, что это не баг, а упущенное требование, продакт-менеджеров, доказывающих, что все баги – ошибки кода или недопонимание тестировщика, а на тест-лида (меня) просто все орали, критиковали за разрешение тестировщикам нечетко следовать требованиям и пользоваться мозгом помимо заскриптованных рутин.

На эту встречу мы шли как на каторгу – люди и думать забыли о пользователях и уперлись исключительно в метрики. Мы тратили столько времени на споры и защиту наших бонусов, что это просто уму непостижимо! Наши пользователи, конечно, были несчастны – вместо того, чтобы тратить время на развитие и улучшение продукта, мы занимались игрищами с дефектами, как последние придурки.

Конечно, наши пользователи – бедные зайчики.

Пример 3. Дефект как несоответствие требованиям

Да начнутся придирки!

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

Тестировщикам было ровным счетом наплевать, в требованиях ли дело, в дефектах кода или в улучшениях – перед их глазами стоял уплывающий бонус, поэтому они ставили такие баги. Улучшения заводились как баги, потому что несоответствовали требованиям. В большинстве случаев у них была низкая серьезность и приоритет, и они радостно заводились, приоритезировались и использовались в построении трендов, метрик и других бессмысленных расчетов.

Эта продуктивная деятельность занимала примерно 30% времени тестировщика. Эти дефекты не просто жрали его время, но еще и поедали время разработчиков, продакт-менеджеров, бизнес-аналитиков, да и просто засоряли систему управления дефектами.

Мусор создает мусор по экспоненте.

Пример 4. Дефект-чарты, тренды и прочая ересь

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

В процессе определения требований для поражения ума старшего менеджмента менеджер ввела несколько новых бесполезных чартов и консолидировала их на аггрегированной дашборде. Она назвала это дашбордой здоровья продукта. Лично я назвал это (про себя) мусорным ведром.

Всем было ровным счетом наплевать на эту дашборду, никто не пользовался ее цифрами, всем было все равно, что ее можно конфигурировать, но мой босс гордился ей, как собственным ребенком. Легенда гласит, что эта штуковина помогла ей получить повышение. Играете с мусором – непременно начнете измерять мусор и закончите анализом мусора и консолидированным представлением мусора, хранящегося в вашем коде.

Как же этого избежать?

1. Концентрируйтесь на предотвращении дефектов.

Многие команды разработки сфокусированы на как можно более быструю доставку фич пользователю и мало задумываются о предотвращении дефектов. В теории, тестировщики (которые куда дешевле разработчиков) найдут эти дефекты, и их исправят. Этот подход – ложная экономия: переработка уже созданного нарушает рабочие потоки разработчиков и ухудшает ценность создаваемого продукта. Разработке доступно множество подходов, позволяющих уделять внимание предотвращению дефектов.

Хотите предотвратить появление дефектов – попробуйте комбинацию из чего-нибудь эдакого:

1. BDD/ATDD/Спецификация на основании примера или любой другой способ, где тестирование идет во главе угла, команды разработки тестируют предположения продакт-оунеров во время переговоров и с большей долей вероятности изначально сделают фичу правильно.
2. Способность получать быструю обратную связь тоже позволяет ловить дефекты довольно рано: автоматизированные юнит и интеграционные тесты могут помочь быстро определить потенциальные проблемные области и избавиться от них до того, как они станут неотъемлемой частью новой фичи.
3. Тесное сотрудничество между бизнесом и командой разработки помогает четко представлять себе бизнес-задачу и сокращать число никому не нужных фич. А это значит – меньше кода, а это, в свою очередь, значит, что и дефектов меньше. Лучший ваш код – это тот, который не надо писать.
4. Сокращение сложности процессов очень помогает предотвращать дефекты. Если сложную проблему можно разбить на несколько простых, мы, скорее всего, наплодим куда меньше багов. Простые проблемы имеют простые решения, а простые решения менее забагованы, чем сложные.
5. Хорошие стандарты кода – к примеру, ограничение длины метода небольшим количеством строк, установка ограничений на цикломатическую сложность, хорошие стандарты именования, чтобы код легко читался, тоже вносит свою лепту в снижение количества дефектов.
6. Код-ревью и парное программирование – ваши лучшие друзья.
7. В перспективе рефакторинг снижает количество дефектов в вашем продукте.

Мораль сей басни такова: если вы не пишете баги, вам не приходится от них избавляться.

2. Сразу же исправляйте все баги, вынесите системы управления дефектами на помойку

Если вы, как и я несколько лет тому назад, подустали от заведения, категоризирования, обсуждения, упорядочивания дефектов, то у меня есть для вас простое решение. Нашли баг? Тут же исправляем.

Для разработчика нормально исправлять дефекты кода сразу же, как только он их находит, ничего никуда не оформляя, но как только баг находит кто-нибудь другой (скажем, тестировщик), тут же начинаются длительные процессы логирования. Почему? Понятия не имею. Люди зачастую говорят "А как же мы будем анализировать глубинные причины того, что происходит? Надо следить за дефектами продукта!". На самом деле никто не мешает вам ничего анализировать, если вы действительно хотите этим заниматься. Мое предложение заключается в следующем: нашедший баг идет к разработчику, который за этот баг в ответе, и беседует с ним. По результатам этого разговора (который может включать и продакт-оунера) должно быть принято решение, фиксим ли мы его прямо сейчас или же забываем о нем навсегда. Исправление прямо сейчас в норме означает, что разработчик все еще помнит, о чем речь – а не спустя четыре недели, когда он понятия не имеет, что вообще писал этот код. Баг исправляется, мы про него забываем, пользователь счастлив.

Забыть о баге навсегда означает, что баг недостоин исправления (возможно, он не угрожает ценности продукта и пользователю все равно, исправим мы его или нет). Забыть навсегда также означает, что мы не тащим, фигурально выражаясь, проститутку на себе, перенеся ее через реку. Мы не тратим время на повторное обсуждение этого дохлого бага, и наши пользователи рады, что мы не тратим время на ерунду, а заняты делом. Если вы решили исправить баг, рекомендую написать под него автотест – если баг всплывет еще раз, вы узнаете о нем первым.

Я сталкивался со скептицизмом, предлагая выкинуть системы управления дефектами на помойку и исправлять баги по мере их поступления. На самом деле все мои команды уже шесть лет работают именно так, и никто пока не сказал "О, как я скучаю по Джире и этим красивым графикам и табличкам!"

Естественно, этот подход больше годится для команд, работающих в одном помещении. Я не пробовал применять его в распределенных командах, но если вы пробовали – сообщите мне, как оно прошло.

Индекс игрищ с дефектами

Эпидемия: 90% - единственные места в мире, где не занимаются оформлением и управлением дефектами – это места, где работал я и сделал все по-своему. За последние годы я слышал о паре других мест, где происходит нечто подобное, но этим все и ограничивается. Весь мир тратит кучу времени на оформление, категоризирование, отслеживание мусора.

Угроза: 100% - дефекты используются для оценки работы людей, и это одна из худших практик, с которой я когда-либо сталкивался за свою долгую карьеру. Урон, который она может нанести, огромен. Про пользователя все мгновенно забывают и начинают играть в игры с системой, чтобы обыграть ее в свою пользу. Заведение и управление дефектами занимает кучу времени, сил, и ставит под угрозу отношения между тестировщиками и разработчиками. Отслеживание дефектов и вывод релизной даты на основании плотности дефектов – это полнейший идиотизм. Немного внимания к предотвращению дефектов – и эти тренды вам никогда не понадобятся.

Устойчивость: 90% - мне пришлось покинуть одну компанию, потому что я посмел усомниться в заслугах управления дефектами, и меня, как ведьму, буквально сожгли на костре. В другой компании я попробовал избавиться от системы управления дефектами, и спустя пару лет мне это удалось. В третьей компании люди любили экспериментировать, и как только они осознали, от какого количества мусора мы избавимся, это тут же стало любимой практикой. Я много раз обсуждал этот вопрос с разными людьми, и основная их масса все равно убеждена, что управление дефектами должно быть жестким процессом, осуществляемым при помощи специального инструмента.

Потому что "Все же так делают!"

Список литературы:

Lean Software development – An Agile Toolkit (Mary and Tom Poppendieck)

https://mysoftwarequality.wordpress.com/2015/05/06/little-tim-and-the-messy-house/

https://mysoftwarequality.wordpress.com/2013/09/10/how-i-stopped-logging-bugs-and-started-living-happy/

Обсудить в форуме