Курс Bug advocacy - часть 2 - Эффективная защита: Как заставить людей захотеть пофиксить баг

Предыдущая часть лекций показалась мне более структурированной, чем часть, которую мы рассмотрим сегодня. В этой части я обнаружил много светлых и хороших идей, но разбросанных безсистемно. Возможно дело во мне и я просто не смог увидеть структуру. В любом случае, думаю полезно будет обсудить основные тезисы второй части. Напоминаю, что все материалы курса BBST можно найти по ссылке http://www.testingeducation.org/BBST/bugadvocacy/.

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

• Баг - это что либо угрожающее ценности продукта для влиятельного стейкхолдера;
• Баг репорт - это утверждение о том, что продукт может быть лучше, чем он есть;
• Идея "быть лучше" сама по себе субъективна: что лучше для одного, может быть хуже для другого;
• Баг репорт обоснован, если он описывает проблему, которая действительно уменьшает ценность продукта для влиятельного стейкхолдера.

Очень часто серьезные баги остаются неисправленными потому, что люди, принимающие решения, не понимают, в чем смысл баг репорта.

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

Тут возникает компромиссы:

1. чем больше времени мы уделяем исследованию каждого бага, тем меньше нам остается времени на обнаружение новых багов;
2. если мы тратим много времени на сбор информации, необходимой программистам, то сколько времени мы таким образом сохраняем для них? (например, стоит ли тратить час на исследование бага, если этим мы сэкономим программисту 10 минут его времени?)

Мы постоянно должны решать эти компромиссы.

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

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

Защита багов - это продажа багов

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

“The best tester isn’t the one who finds the most bugs or embarrasses the most programmers.The best tester is the one who gets the most THE RIGHT bugs fixed.”

Защита багов состоит в:

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

Процесс продажи бага можно разделить на 2 части:

• мотивация программиста пофиксить баг;
• преодоление возражений, направленных на то, чтобы отклонить фикс бага.

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

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

Далее мы поговорим о так называемом follow-up тестировании, которое нужно проводить после обнаружения бага. Я буду переводить этот процесс как контрольное тестирование, так как  этот процесс очень похож на то, что мы обычно делаем перед завершением какой-то работы для проверки того, что мы все сделали правильно.

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

1. Попробовать изменить последовательности шагов, приведших к багу. Например, можно повторить шаги несколько раз. Возможно простая ошибка, повторенная несколько раз, приведет к крашу программы. Или можно тестировать эту ошибку в комбинации с другими фичами, на которые она может повлиять.
2. Попробовать воспроизвести баг с другими настройками программы.
3. Попробовать изменить файлы с данными, для которых наблюдается баг.
4. Попробовать проверить баг на другой платформе (на другой ОСи, на другом железе).

Есть хорошее правило при исследовании важности бага:

UNCORNER YOUR CORNER CASES

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

Чем шире диапазон данных и настроек, на которых наблюдается баг, тем он серьезнее.

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

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

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

Одна деталь, на которую обращает внимание Канер: после того, как мы нашли серьезный баг на одной машине, нужно оставить эту машину (создать снапшот) и попробовать воспроизвести баг на другой машине. Очень важно не потерять трудновоспроизводимый баг. Даже если он не воспроизведется на другой машине, мы может предоставить для исследования бага первую машину.

Summary

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

Хорошие баг репорты требуют дополнительного контрольного тестирования для представления бага в наиболее сильном свете:

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