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

1. Пинг-понг (малоэффективный способ, вызывает претензии руководства)

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

2. Недофикс

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

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

3. Девелоперский баг

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

В этом случае полезным может быть комментарий типа «Дайте информацию, как верифаить, или поверифайте, пожалуйста, сами». Такая фраза, в сочетании с назначением бага на разработчика, работает лучше, чем просто «Дайте информацию, как верифаить».

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

4. Это не баг, а фича (мнение разработчика)

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

5. Это не баг, а фича (мнение тестировщика)

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

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

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

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

Но лучше, конечно, починить блокер в текущей версии.