Зачем нужен хороший баг репорт?
Если вы правильно описали баг, шансы на то, что его профиксят взлетают
до немереных высот. Поэтому существует зависимость от описания бага с исходным результатом (пофиксят или отложат до лучших времен). Чтобы правильно описать баг нужны определенные навыки и знания. Я постараюсь поведать вам это таинство.
"Цель описания бага в том, чтобы его профиксили" - Сэм Канер.
Если тестировщик некорректно опишет баг, то программист с большой вероятностью влепит ему статус "не воспроизводим" и пока-пока. Баг возвращается тестировщику и он опять должен его описывать - но уже более подробно. Цепочка может быть бесконечной, пока программист не даст щелбан тестировщику. А баг пойдет в релиз.
Где же критерии идеального баг репорта???
Каждый может описать баг. Но далеко не каждый может его описать эффективно. Вы должно тонко чувствовать разницу между обычным сереньким баг репортом и действительно хорошим баг репортом.
А как же это почувствовать? Седьмым чувством? Не обязательно, есть критерии, которым должен соответствовать хороший баг репорт.
1) Каждому багу - личный номерок
У каждого бага должен быть свой уникальный номер. Это поможет его отыскать и идентифицировать. Если вы используете какой-то инструмент для автоматизированного репорта багов - этот номер должен генерится автоматически, когда вы заносите баг.
Erlang. Аналог InArray. Как проверить вхождения элемента в список
-
Как проверить вхождение элемента в список? Документация List =
[1,2,3,4,5,6], lists:member(1,List) => true lists:member(8,List) => false