Исследование дефекта

Итак, мы обнаружили проблему. Что дальше?

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

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

1. Выдвигаем теорию.
2. Проверяем на практике.
3. Если практика не соответствует теории, теорию приводим в соответствие.

В случае исследования дефекта в программе это выглядит так:

1. Выдвигаем гипотезу.
2. Выясняем последовательность шагов, точно приводящих к дефекту.
3. Удаляем лишние шаги.
4. В оставшихся шагах уточняем каждое утверждение.

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

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

1. Пишем гипотезу

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

 "Иногда во время гуляния по настройкам графика приложение зависает". 

Но даже этого будет достаточно, чтобы перейти к следующему этапу.

2. Выясняем последовательность шагов, приводящих к дефекту

Очевидно, что воспроизвести дефект по описанию  "Иногда во время гуляния по настройкам ..." довольно сложно.  Иногда - это всегда или дефект нерегулярен? По каким именно настройкам? Что нажимать и в какой последовательности?

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

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

Теперь наша гипотеза уже не смутная мысль, а четко определенный список шагов, например:

1. Запустить приложение.
2. Создать отчет по форме №4.
3. Задать границы формирования отчета 19.05.2011 - 20.06.2011.
4. Выполнить отчет.
5. В мастере диаграмм выбрать тип «гистограмма»
6. В мастере диаграмм в настройках графика нажать кнопку «раздельная»
7. Перейти на вкладку «Данные»
8. В мастере диаграмм в настройках графика нажать на кнопку «совмещенная»
9. Перейти на вкладку «Данные»
10. В мастере диаграмм выбрать тип «линейная»
11. Перейти на вкладку «Данные»
12. В мастере диаграмм в настройках графика нажать кнопку «раздельная»
13. Перейти на вкладку «Данные»
14. В мастере диаграмм в настройках графика нажать на кнопку «совмещенная»
15. В мастере диаграмм выбрать тип «круговая»
16. Результат:  приложение не реагирует на запросы, приходится останавливать его, убивая его процесс – НЕ ОК 

Данный этап в исследовании дефекта самый сложный и самый важный.  Дальше - легче.

3. Удаляем лишние шаги

На предыдущем этапе гипотеза может стать довольно длинной. На прошлой неделе я терзала дефект, который первоначально вылился в список из 40 (сорока) шагов. Это много.  Чем меньше шагов нужно, чтобы повторить дефект, тем лучше. Если дефект длинный, программисту будет подсознательно казаться, что это большая и страшная проблема. Чем больше текста в описании дефекта, тем выше шансы, что программист этот дефект отложит, а исправлять в первую очередь возьмет что-нибудь, что выглядит не так устрашающе :) .

Поэтому этом этапе мы займемся удалением лишнего. 

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

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

В конце данного этапа наша гипотеза уже может выглядеть так:

1. Запустить приложение.
2. Создать отчет по форме №4.
3. Задать границы формирования отчета 19.05.2011 - 20.06.2011.
4. Выполнить отчет.
5. В мастере диаграмм выбрать тип «гистограмма»
6. В мастере диаграмм в настройках графика нажать на кнопку «совмещенная»
7. В мастере диаграмм выбрать тип «круговая»
8. Результат:  приложение не реагирует на запросы, приходится останавливать его, убивая его процесс – НЕ ОК 

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


4. В оставшихся шагах уточняем каждое утверждение

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

Например, в моей системе есть не только форма отчета №4, но также с десяток других форм. И границы формирования отчета я могу задать разные. Также, кроме гистограммы и круговой диаграммы, есть еще и другие виды диаграмм. Это явные переменные - они явно прописаны в шагах нашей гипотезы.

Но обратите внимание, что существуют и неявные переменные. Это, в первую очередь, последовательность действий. Например, повторится ли дефект, если сначала выбрать круговую диаграмму, а потом гистограмму, а не наоборот?

К неявным переменным относится и окружение. Внутрисистемное окружение: это параметры/ процессы внутри тестируемой системы, которые предположительно могут повлиять на работу функциональности, в которой обнаружен дефект. Например, выполняются ли в приложении фоновые операции? Не проводилась после старта клиента смена конфигурации на сервере? И т.д.  Операционное окружение: это ОС и установленные в ней программы (например, jre, Oracle и т.п.).

Цель данного этапа – уточнить каждую переменную в нашем сценарии. Делаем мы это затем, чтобы точнее обрисовать границы проблемы и, соответственно, облегчить программисту поимку этого бага.

Дефект имеет место только с формой №4 или с другими тоже? Зависит ли он от времени формирования отчета? Зависит ли только от типов графиков  «гистограмма» и «круговая диаграмма»? Зависит ли от окружения?

Процесс уточнения следующий. Мы меняем одну из переменных и выполняем все шаги снова. В зависимости от результатов дополняем наш сценарий. Затем цикл повторяем для следующей переменной, влияние которой мы считаем важным. И так далее.

В конце-концов, мы получим уточненную гипотезу. Например, такую:

1. Запустить приложение.
2. Создать отчет (любой).
3. Выполнить отчет атк, чтобы получить данные.
4. В мастере диаграмм выбрать тип графика, содержащий семь видов.
5. В мастере диаграмм в настройках выбтьа седьмой вид графика
6. В мастере диаграмм выбрать тип «круговая»
7. Результат:  приложение не реагирует на запросы, приходится останавливать, его убивая его процесс – НЕ ОК 

Теперь, если нужно, прикладываем скриншоты и логи и подписываем этот достойно исследованный дефект в баг-трекер. :)

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