Голяма част от софтуерното тестване включва писане на тестови случаи (test cases) и докладване на грешки (bug reporting).
Добрият bug report трябва да улесни всеки друг, да разбере грешката и да предприеме действия по нея, без да се налага да говори с човека, който го е написал. С други думи, добрият bug report трябва бързо да покаже бъга в резюме и този, който чете да знае как да го репликира.
Всеки екип има свои собствени работни процеси и инструменти, но общото е, че едно добро описание на бъг трябва да има:
Ето и отделните компоненти:
Заглавието на доклада за грешка е първото нещо, което читателят вижда. Трябва да е кратко и да дава кратко резюме на грешката. Писането на кратки заглавия изисква практика. Започнете, като захвърлите ненужните думи и избягвайте използването на общи заглавия като „____ не работи“. Вместо да казвате какво не се случва, кажете какво се случва.
Добър пример: „Бутонът за влизане води до грешка 404.“
Лош пример: „Бутонът за влизане не работи.“
Силното заглавие не само помага да се разбере за какво се отнася грешката. То помага да се намали възможността за дублиране, като се знае, че грешката вече съществува в системата за проследяване на грешки.
Основният текст на доклада за грешка трябва да предоставя по-подробна информация и винаги трябва да включва стъпките за възпроизвеждане на грешката. Подобно на заглавието, дръжте този раздел кратък, но включете всички необходими подробности. Изброяването на стъпките в номерирана последователност го прави лесно за четене и разбиране.
Не забравяйте, че всяка грешка отнема време за писане и обработка – колкото по-просто и синтезирано е oписанието на бъга, толкова по-бързо можете да работите по него. Предисловията също могат да намалят броя на стъпките. Например, вместо да записвате всяка стъпка за влизане, започнете стъпките с „Предпоставка: потребителят е влязъл“. Този раздел трябва да включва и друга полезна информация като тип браузър, устройство и т.н.
Колко важен е проблемът? Колко често се случва? Посочването на приоритета на грешката помага да се определи спешността на проблема.
Какво е въздействието на проблема? Определянето на сериозността на грешката в доклада за нея, отразява тежестта на този конкретен проблем върху софтуера, който се тества, както и въздействието, която проблемът оказва върху способността на потребителя да взаимодейства с приложението и неговите функции.
Бъдете ясни по отношение на мотивите защо е наложително или защо не е важно. Приоритетът /priority/ и тежестта /severity/ са полезни за целите на планирането и проследяването и са важна част от добрия доклад.
Този раздел помага за затвърждаване на основния проблем и дава ясно разбиране защо класифицирате проблема като „бъг“. Подобно на заглавието, когато описвате очакваните резултати, обяснете какво трябва да се случи, а не какво не трябва да се случи. По същия начин, когато описвате действителни резултати, опишете какво се е случило, а не какво не се е случило.
Включете само файлове, които добавят стойност. Не включвайте пет различни екранни снимки, ако е необходима само една от тях – това само ще накара читателя да загуби повече време за дешифриране на грешката.
Маркирайте проблемните области в екранните снимки и добавете текстови пояснения, ако е необходимо. Винаги включвайте URL низа, показан в браузъра – това може да включва важна и полезна информация.
Понякога обаче едно изображение не е достатъчно. Видеоклипът е допълнителната стъпка и предоставя много повече информация за грешката. Например, екранна снимка на бъга е страхотно, но видеозаснемане на екрана на това, което е довело до съобщението за грешка, е по-доброто решение. Ако правите видеоклип, изрежете го, за да покажете само грешката. Отново, това намалява времето, необходимо за дешифриране на проблема. И накрая, винаги включвайте лог файлове, когато е възможно.
Добрите доклади са от полза за всички и позволяват на екипът да функционира като добре смазана машина. Прекарайте малко допълнително време предварително, за да създадете качествени описания и ще спестите много време по пътя, докато работите с тях. Всичко се свежда до комуникация – регистрирането на грешка е съобщаване на проблем. Комуникирайте добре и жизненият цикъл на дефекта ще бъде ефективен и приятен.