Курс Bug advocacy - часть 1 - Основные понятия

В первой части рассматриваются основные понятия:

• зачем нужны качественные баг-репорты;
• что такое error, failure, bug;
• что такое качество.

Зачем нужны эффективные баг репорты?

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

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


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

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

“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 bugs fixed.” (TCS 2 0)

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

Что такое баг?

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

Давайте рассмотрим некоторые из определений:

1. Баг - это несоответствие между спецификацией и поведением продукта. Если спецификация есть и продукт ведет себя иначе - это конечно, правильное определение. Но не все продукты имеют полные спецификации. Среди таких продуктов без детальных спецификаций - лидеры рынка, лучшие в своем классе. Поэтому мы не будем ограничиваться таким определением бага.
2. Баг - это ошибка в коде. Но это не всегда так. Продукт ведет себя так, как его задумали и запрограммировали. Но иногда это нам не нравится. Если фича слишком сложна - люди не будут ее использовать. Поэтому ошибки кодирования - это только часть проблемы.
3. Баг - это неспособность оправдать обоснованные ожидания пользователя (классическое определение Глена Майерса). Но какой пользователь имеется в виду? Один пользователь может ожидать одно, а другой - другое. Причем их ожидания могут быть противоположными,  ведь все используют продукт по-разному. Так как же нам решить, какой пользователь для нас важнее? Еще одна проблема в этом определении - то, что оно ограничено на пользователе. Давайте лучше подумаем о stakeholders. Это люди, наиболее заинтересованные в успехе продукта. Влиятельный стейкхолдер - тот, к чьему мнению будет прислушиваться команда разработки. Например, если вицепрезидент по продажам скажет, что нам не нужна эта фича, то кто будет заботиться о том, что он - не пользователь? Так что давайте расширим определение. 
4. Баг - это неспособность оправдать обоснованные ожидания стейкхолдера.
5. Баг -  это любое ненужное или необоснованное снижение качества продукта. Это определение наиболее подходит к нашему размышлению о том, для чего нужен баг репорт. Мы создаем баг репорт потому, что мы думаем, что если этот баг будет исправлен - программа будет лучше. В независимости от того, где эта ошибка - в продукте или в спецификации.

Когда мы говорим о баге, в нашей голове всплывают другие понятия - error, failire, fault, defect, critical condition. В чем же разница?

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

• Error (или fault, ошибка) - это что-то неправильное в продукте, например ошибка дизайна, ошибка кодирования.
• Failure (неисправность) - это неправильное поведение программы, или отсутствие нужного поведения.
• Critical condition (критические условия) - это данные, либо определенный шаг, который рождает failure, то есть неправильное поведение программы. Ошибка не всегда рождает неправильное поведение. Она рождает неправильное поведение при выполнении некоторых критических условий. 

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

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

Мы можем остановиться на следующем определении бага.

Баг (или ошибка программы) - это любое ненужное или необоснованное снижение качества продукта.

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

Что такое качество?

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

1. Качество - это согласованность с требованиями (Филипп Кросби). Имеются в виду не только письменные требования, но и просто ожидаемое поведение, неписаные правила. Но качество - это не согласованность с документами, это согласованность с потребностями. Даже если продукт будет полностью соответствовать документации, он может иметь плохое качество с точки зрения пользователя.
2. Качество - это пригодность для использования (Джозеф Юран). Джозеф разделял всех пользователей на Довольных и Недовольных. Идеальный продукт должен иметь много Довольных и почти не иметь Недовольных.

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

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

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

Качество - это ценность для определенного человека (Weinberg).

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

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

Еще одно хорошее определение бага:

Баг - это нечто в продукте, что угрожает его ценности (Болтон, Бах).

 Итоги

Баг репорт - это утверждение, что продукт может быть лучше, чем он есть.

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

Фича или атрибут продукта могут быть более важными для одного человека, чем для другого. Поэтому и баги в этой фиче/атрибуте более важны для первого человека, чем для другого.

Баг оправдан, если он обнаруживает проблему, которая уменьшает ценность для влиятельного стейкхолдера.