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

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

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

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

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

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