Анализ пропущенных дефектов

Всем известно, что QA не может гарантировать отсутствия дефектов (багов) в выпущенном программном продукте, не зависимо от количества человеко-дней потраченных на тестирование. Именно поэтому, игра сводится к оптимизации процесса тестирования. Немного фактов:

1. Поиск и решение проблемы после релиза в 100 раз дороже, чем на стадии проектирования
   
2. 90% простоев (downtime) происходит из-за 10% дефектов
   
3. 80% проблем связано с 20% модулей
   

Итак, как найти наиболее проблематичные области? Основная идея метода - изменить критерий группировки дефектов по проблеме на группировку по решению.

Речь пойдет об анализе дефектов полученных от пользователей через обращения в службу технической поддержки. Именно эти дефекты чинятся в авральном порядке, зачастую, прямо у клиента. Обычно, проблема, найденная пользователем, проходит через несколько уровней (tiers) тех. поддержки. Tier I – первая линия, основная задача получение информации от пользователя для лучшего понимания проблемы. Этот уровень призван решать 70-80% пользовательских проблем, как правило, связанных с неправильным использованием продукта. Не решенные проблемы передаются (escalate) на следующий уровень - Tier II. На этом уровне работают люди, хорошо знающие продукт, особенности его имплементации, интеграции с другими продуктами, способные читать логии и изолировать проблему. Во многих организациях в этой работе принимает участие отдел QA. Тут, как правило, проблема превращается в дефект и передается на следующий уровень. Tier III и Тier IV – это обычно девелоперы, чинящие дефект. Система или системы, используемая различными уровнями поддержки, может быть применена для выявления наиболее проблематичных мест. Эта процедура стандартна и проводится практически во всех фирмах, заботящихся о качестве выпускаемого продукта. Основная проблема заключается в том, что первичное категорирование дефектов, необходимое для автоматического присваивания дефекта разработчику/отделу, не позволяет эффективно находить причину, по которой, этот дефект был пропущен QA. Иными словами, просто найти виновного, и практически невозможно определить направление совершенствования процесса тестирования.

Суть предложения провести brainstorm для разделения пропущенных дефектов на группы, обладающие сходными признаками. Необходимо изменить вопрос «как мы могли это пропустить?» на «как мы можем увеличить вероятность того, что подобный дефект будет обнаружен в будущем?». Далее будет вольный перевод статьи замечательной Elisabeth Hendrickson с небольшими добавлениями, после имплементации сего действа у себя на работе .

Что необходимо приготовить заранее:

• Небольшая группа людей (3-5 человек) с разными ролями в организации.
  
• Маркеры и карточки из плотной бумаги или стикеры.
  
• Комната с большим столом или стенами, куда можно клеить стикеры, заказанная на пару часов.
  
• Список из «пользовательских» проблем, дошедших до Tier III. Из этого списка следует исключить проблемы, связанные с неправильным использованием продукта. Список должен включать не более 30-40 дефектов на одну встречу. Человек, готовящий список, должен быть готов представить проблемы остальным участникам.
  

Во время встречи:

• Рассмотреть каждый дефект с участниками, пытаясь ответить на вопрос: «Что мы должны сделать по-другому в следующий раз, чтобы увеличить вероятность того, что дефект, подобный этому, будет найден в процессе тестирования»
  
• Каждый из участников должен записать свое предложение на отдельной карточке в виде законченного предложения: «В следующем релизе/итерации мы должны ______». Предложение должно быть как можно более подробным. Например, вместо «Добавить тесты» написать «Добавить тесты для специальных символов в конце строки». Так же следует избегать показываний пальцами – «Это Вася пропустил» и т.п.
  
• Продолжайте до конца списка или окончания первого часа. Второй час мы потратим на построение групп.
  
• Разложите все карточки с предложениями перед всеми участниками встречи.
  
• Группируйте карточки по схожести предложенного решения. Все участники должны приложить руку к сортировке.
  
• Теперь предложите участникам дать подходящие по смыслу названия для групп решений.
  

В результате будет приготовлен список направлений для улучшения стратегии тестирования. Теперь можно сосчитать количество решений в каждой группе и построить диаграмму Парето для выявления тех самых 20% областей, приносящих 80% проблем.

В качестве примера приведу слайд из презентации результатов на работе:

Немного о себе или зачем мне блог

Здравствуйте, меня зовут Дима. Мне 34 года. Я родился на юге России, а теперь живу и работаю в Израиле. Я больше 10 лет работаю в сфере высоких технологий. Знакомство с компьютерами, вернее с вычислительными устройствами, началось с Б3-34 и публикаций в Науке и Жизни. Потом были фортран на ЕС-1040, паскаль на Искрах (модель не нашел, что-то до 226), бейсик на собраном своими ручками Специалисте. А потом Правец-16, купленный к отцу в институт ознаменовал начало эры PC. Где-то между Искрами и Правецом я начал работу в "отрасли". От лаборанта кафедры ВТ (тогда это звучало намного круче), программиста в куче мест, сисадмина UNIX и до QA Engineer. Временами я отвлекался на бизнес, банковское дело и гулянки, но всегда возвращался к компьютерам. Последние 5 лет я занимаюсь тестированием. Я стараюсь постоянно совершенствоваться и развиваться. Как мне кажется, у меня уже есть что рассказать другим. С другой стороны, было бы интересно услышать мнения людей из цеха.
Теперь я работаю в HP Software, бывшем Mercury, колыбели таких продуктов как LoadRunner, Performance Center, Quick Test Professional, Quality Center и так далее.
Последний проект, которым я руковожу, принес кучу новых решений и вопросов. Тут и тестирование SDK (продукт выходит без GUI), работа с удаленной коммандой тестеров и упаковка конечного продукта как Virtual Appliance для VMware. Немного в стороне, но тоже безусловно интересующая тема Continuous Integration и его сопряжения с системными тестами, Quality Dashboard и многое, многое другое.