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