[Из песочницы] Бюрократия баг-трекера
Я работаю тестировщиком уже не первый год и хочу написать о некоторых бюрократических способах взаимодействия тестировщиков с разработчиками через баг-трекер.1. Пинг-понг (малоэффективный способ, вызывает претензии руководства)Тестировщик пишет баг, а разработчик закрывает его без всяких комментариев и ставит обидный статус «Инвалид». Тестер переоткрывает баг с комментарием «Сам ты инвалид». Разработчик вынужден написать комментарий. Не факт, что по делу.2. Недофикс Недофикс — это не полностью пофикшенный баг. Например, отсутствовала нужная кнопка в двух местах. После фикса кнопка появилась, но только в одном месте. При верификации такого бага лучше всего, на мой взгляд, заводить новый баг о том, что кнопка отсутствует во втором месте. А оригинальный баг оставлять неповерифаенным и вставлять коммент «верификация заблокирована новым багом».Если поверифаить оригинальный баг, возможна ситуация, когда в результате фикса второго бага кнопка пропадет в первом месте, а мы это пропустим.
3. Девелоперский баг Девелоперский баг — это баг, написанный разработчиком. Зачастую разработчики не пишут в баге сценарий воспроизведения или даже хотя бы желаемое поведение продукта. Поэтому без бутылки или без дополнительной информации от автора поверифаить такой баг очень непросто.В этом случае полезным может быть комментарий типа «Дайте информацию, как верифаить, или поверифайте, пожалуйста, сами». Такая фраза, в сочетании с назначением бага на разработчика, работает лучше, чем просто «Дайте информацию, как верифаить».
В последнем случае мы не даем разработчику альтернативы выбора и он может начать выдумывать его себе сам. Например, отказаться давать информацию, утверждая, что некомпетентный тестировщик не умеет читать между строк. Но как только альтернатива верифаить баг самостоятельно встает перед разработчиком в полный рост, он, как правило, пишет подробную инструкцию.
4. Это не баг, а фича (мнение разработчика) Баг, закрытый с таким комментарием, нуждается в пристальном изучении. Не только тестировщиком, но и, возможно, его руководителем и руководителем разработки. Фича, выходит, настолько неочевидна и интуитивно непонятна, что больше напоминает баг. Если стороны все-таки сходятся во мнении, что в продукте ничего исправлять нецелесообразно, следует написать баг на документацию, чтобы неочевидное поведение было явно описано.5. Это не баг, а фича (мнение тестировщика) Если тестировщик увидел баг вида «Мы должны поддерживать три новые версии Линукса», это не баг, а фича, так как процесс верификации будет содержать, вероятно, полное прохождение регрессионных тестов. Три раза. Не говоря о тестировании возможности перехода со старой версии Линукс на новую. Соответственно, затраты времени на верификацию такого «бага» будут сильно больше среднего. Поэтому того, кто завел такой баг, нужно принуждать к его оформлению как полноценной фичи.6. Верификация бага на текущую версию заблокирована багом, запланированным к фиксу в следующей версии Нонсенс. Фикс-версию у обоих багов нужно поставить или текущую, или следующую. Это нужно потребовать в обоих багах.Возможно, я напишу очевидную вещь, но мне приходилось уже однажды ее писать.Если первый баг был признан столь вредным, что его стали фиксить в текущей версии, а сейчас все ломается в том же самом сценарии, следовательно, блокирующий баг так же вреден, как и заблокированный. Значит, нет никакого смысла держать их в разных фикс-версиях, кроме того, что сейчас никто не может починить блокер. А следовательно, можно абсолютно безопасно для качества продукта сдвинуть заблокированный баг в следующую фикс-версию, т. к. сценарий все равно сломан.
Но лучше, конечно, починить блокер в текущей версии.
