how write good bug report
Защо добър доклад за грешки?
Ако вашият доклад за грешки е ефективен, тогава шансовете му да бъде поправен са по-високи. Така че отстраняването на грешка зависи от това колко ефективно да я докладвате. Докладването на грешка не е нищо друго освен умение и ще обясня как да постигна това умение.
„Смисълът на писането на доклад за проблем (доклад за грешка) е да се поправят грешки“ - От Cem Kaner. Ако тестер не съобщава грешка правилно, програмистът най-вероятно ще отхвърли тази грешка, като я посочи като невъзпроизводима.
Това може да навреди на изпитателите морално, а понякога и на егото. (Предлагам да не се запазва какъвто и да е тип его. Его е като „Правилно съм докладвал грешката“, „Мога да я възпроизведа“, „Защо той / тя е отхвърлил грешката?“, „Вината не е моя“ и т.н. ,).
Какво ще научите:
- Какви са качествата на добрия доклад за грешки в софтуера?
- Ефективно докладване на грешки
- Как да докладвам за грешка?
- Важни функции във вашия доклад за грешки
- Някои бонус съвети за писане на добър доклад за грешки
- Заключение
- Препоръчително четене
Какви са качествата на добрия доклад за грешки в софтуера?
Всеки може да напише доклад за грешка. Но не всеки може да напише ефективен доклад за грешки.
Трябва да можете да правите разлика между среден доклад за грешка и добър доклад за грешка. Как да различаваме добър и лош доклад за грешки? Много е просто, прилагайте следните характеристики и техники, за да докладвате за грешка.
Характеристиките и техниките включват
# 1) Наличие на ясно определен номер на грешка: Винаги присвоявайте уникален номер на всеки доклад за грешка. Това от своя страна ще ви помогне да идентифицирате грешката. Ако използвате автоматизиран инструмент за докладване на грешки, този уникален номер ще се генерира автоматично всеки път, докато докладвате за грешката.
безплатен преглед на YouTube към mp3 конвертор
Обърнете внимание на номера и кратко описание на всяка грешка, за която сте докладвали.
# 2) Възпроизводимо: Ако грешката ви не е възпроизводима, тя никога няма да бъде отстранена.
Трябва ясно да споменете стъпките за възпроизвеждане на грешката. Не приемайте и не пропускайте нито една стъпка на възпроизвеждане. Грешка, която е описана стъпка по стъпка, е лесна за възпроизвеждане и отстраняване.
# 3) Бъдете конкретни: Не пишете есе за проблема.
Бъдете конкретни и точни. Опитайте се да обобщите проблема с минимални думи, но по ефективен начин. Не комбинирайте множество проблеми, дори ако изглеждат подобни. Напишете различни отчети за всеки проблем.
Ефективно докладване на грешки
Отчитането на грешки е важен аспект на софтуерното тестване. Ефективният доклад за грешки комуникира добре с екипа на разработчика и избягва объркване или неправилна комуникация.
Трябва да бъде добър доклад за грешка ясна и кратка без липсващи ключови точки. Всяка липса на яснота води до неразбиране и забавя процеса на развитие. Писането и докладването на дефекти е една от най-важните, но пренебрегвани области в жизнения цикъл на тестването.
Доброто писане е много важно за подаване на грешка. Най-важният момент, който тестващият трябва да има предвид, е да не използва команден тон в доклада. Това нарушава морала и създава нездравословна работна връзка. Използвайте внушителен тон.
Не предполагайте че разработчикът е сгрешил и следователно можете да използвате груби думи. Преди да докладвате, е също толкова важно да проверите дали същата грешка е била докладвана или не.
Дублирана грешка е тежест в цикъла на тестване. Проверете целия списък с известни грешки. Понякога разработчиците може да са знаели проблема и да са игнорирани за бъдеща версия. Могат да се използват и инструменти като Bugzilla, която автоматично търси дублирани грешки. Най-добре е обаче ръчно да търсите всяка дублирана грешка.
Информацията за импортиране, която докладът за грешка трябва да съобщава, е „Как?“ и къде?' Отчетът трябва ясно да отговори как е извършен тестът и къде точно е възникнал дефектът. Читателят трябва лесно да възпроизведе грешката и да намери къде е грешката.
Имайте предвид, че цел на написването на доклада за грешки е да се даде възможност на разработчика да визуализира проблема. Той / тя трябва ясно да разбере дефекта от доклада за грешки. Не забравяйте да дадете цялата подходяща информация, която разработчикът търси.
Също така имайте предвид, че докладът за грешка ще бъде запазен за бъдеща употреба и трябва да бъде добре написан с необходимата информация. Използвайте смислени изречения и прости думи за да опишете вашите грешки. Не използвайте объркващи твърдения, които губят времето на рецензента.
Докладвайте всяка грешка като отделен проблем. В случай на множество проблеми в един отчет за грешки, не можете да го затворите, освен ако не бъдат разрешени всички проблеми.
Следователно е най-добре да разделете проблемите на отделни грешки . Това гарантира, че всяка грешка може да бъде обработвана поотделно. Добре написаният доклад за грешка помага на разработчика да възпроизведе грешката в своя терминал. Това им помага да диагностицират проблема също.
Как да докладвам за грешка?
Използвайте следния прост шаблон за доклад за грешка:
Това е прост формат на доклад за грешки. Тя може да варира в зависимост от инструмента за докладване на грешки, който използвате. Ако пишете отчет за грешка ръчно, някои полета трябва да бъдат посочени специално като номера на грешката, който трябва да бъде зададен ръчно.
Репортер: Вашето име и имейл адрес.
Продукт: В кой продукт сте намерили тази грешка.
Версия: Версията на продукта, ако има такава.
Съставна част: Това са основните подмодули на продукта.
Платформа: Споменете хардуерната платформа, където сте намерили тази грешка. Различните платформи като „PC“, „MAC“, „HP“, „Sun“ и т.н.
Операционна система: Споменете всички операционни системи, в които сте открили грешката. Операционни системи като Windows, Linux, Unix, SunOS, Mac OS. Споменете различните версии на ОС също като Windows NT, Windows 2000, Windows XP и др., Ако е приложимо.
Приоритет: Кога трябва да се поправи грешка? Приоритетът обикновено се задава от P1 до P5. P1 като „поправете грешката с най-висок приоритет“, а P5 като „Поправете, когато времето позволява“.
Тежест: Това описва въздействието на грешката.
Видове тежест:
най-добрият компютър за почистване за Windows 7 безплатно изтегляне
- Блокиране: Не могат да се извършват допълнителни тестови работи.
- Критично: Срив на приложението, загуба на данни.
- Специалност: Голяма загуба на функция.
- Незначителен: Незначителна загуба на функция.
- Тривиално: Някои подобрения на потребителския интерфейс.
- Подобрение: Заявка за нова функция или подобрение в съществуващата.
Състояние: Когато регистрирате грешката във всяка система за проследяване на грешки, тогава по подразбиране състоянието на грешката ще бъде „Ново“.
По-късно грешката преминава през различни етапи като Fixed, Verified, Reopen, Won’t Fix и т.н.
=> Натисни тук за да прочетете повече за подробния жизнен цикъл на бъгове.
Възлага на: Ако знаете кой разработчик е отговорен за конкретния модул, в който е възникнала грешката, тогава можете да посочите имейл адреса на този разработчик. В противен случай оставете празно, тъй като това ще присвои грешката на собственика на модула, ако не Мениджърът ще присвои грешката на разработчика. Възможно е да добавите имейл адреса на мениджъра в списъка на CC.
URL: URL адресът на страницата, на който е възникнала грешката.
Резюме: Кратко резюме на грешката най-вече с 60 думи или по-долу. Уверете се, че вашето резюме отразява какъв е проблемът и къде е той.
Описание: Подробно описание на грешката.
Използвайте следните полета за полето за описание:
- Възпроизвеждане на стъпки: Ясно е да споменете стъпките за възпроизвеждане на грешката.
- Очакван резултат: Как трябва да се държи приложението при гореспоменатите стъпки.
- Действителен резултат: Какъв е действителният резултат от изпълнението на горните стъпки, т.е.поведението на грешката.
Това са важните стъпки в отчета за грешки. Можете също да добавите „Тип отчет“ като още едно поле, което ще опише вида на грешката.
Типовете отчети включват:
1) Грешка в кодирането
2) Грешка при проектирането
3) Ново предложение
4) Издаване на документация
5) Хардуерен проблем
Важни функции във вашия доклад за грешки
По-долу са дадени важните характеристики в доклада за грешки:
# 1) Номер на грешка / идентификационен номер
Номер на грешка или идентификационен номер (като swb001) улеснява докладването на грешки и препращането към грешка. Разработчикът може лесно да провери дали дадена грешка е отстранена или не. Това прави целия процес на тестване и повторно тестване по-плавен и лесен.
# 2) Заглавие на грешка
Заглавие на грешка се чете по-често от която и да е друга част от отчета за грешка. Тя трябва да казва всичко за това, което идва в грешката.
Заглавието на грешката трябва да е достатъчно внушително, за да може читателят да го разбере. Ясното заглавие на грешката улеснява разбирането и читателят може да разбере дали грешката е била докладвана по-рано или е коригирана.
# 3) Приоритет
Въз основа на сериозността на грешката може да се зададе приоритет за нея. Грешка може да бъде блокираща, критична, основна, незначителна, тривиална или предложение. Приоритет на грешки от P1 до P5 може да бъде даден, така че важните да се видят първо.
# 4) Платформа / Околна среда
Конфигурацията на операционната система и браузъра е необходима за ясен отчет за грешка. Това е най-добрият начин да се съобщи как бъгът може да бъде възпроизведен.
Без точната платформа или среда приложението може да се държи по различен начин и грешката в края на тестера може да не се репликира в края на разработчика. Затова е най-добре да споменем ясно средата, в която е открита грешката.
# 5) Описание
Описанието на грешки помага на разработчика да разбере грешката. Той описва възникналия проблем. Лошото описание ще създаде объркване и ще загуби времето и на разработчиците, и на тестерите.
Необходимо е да се комуникира ясно за ефекта от описанието. Винаги е полезно да използвате пълни изречения. Добра практика е всеки проблем да се описва поотделно, вместо да се руши изобщо. Не използвайте термини като „мисля“ или „вярвам“.
# 6) Стъпки за възпроизвеждане
Добрият доклад за грешки трябва ясно да споменава стъпките за възпроизвеждане. Стъпките трябва да включват действия, които причиняват грешката. Не правете общи изявления. Бъдете конкретни в стъпките, които да следвате.
Добър пример за добре написана процедура е даден по-долу
Стъпки:
- Изберете продукт Abc01.
- Кликнете върху Добавяне в количката.
- Щракнете върху Премахване, за да премахнете продукта от количката.
# 7) Очакван и действителен резултат
Описанието на грешката е непълно без очакваните и действителните резултати. Необходимо е да се очертае какъв е резултатът от теста и какво трябва да очаква потребителят. Читателят трябва да знае какъв е правилният резултат от теста. Ясно е да споменете какво се е случило по време на теста и какъв е резултатът.
# 8) Екранна снимка
Картината струва хиляда думи. Направете снимка на екрана на случая на повреда с правилни надписи, за да подчертаете дефекта. Маркирайте неочаквани съобщения за грешка със светлочервен цвят. Това насочва вниманието към необходимата площ.
Някои бонус съвети за писане на добър доклад за грешки
Дадени по-долу са някои допълнителни съвети за писане на добър доклад за грешки:
въпроси и отговори за интервю за jenkins
# 1) Незабавно докладвайте за проблема
Ако откриете някаква грешка по време на тестването, не е необходимо да чакате, за да напишете подробен доклад за грешка по-късно. Вместо това незабавно напишете доклада за грешка. Това ще осигури добър и възпроизводим доклад за грешки. Ако решите да напишете доклад за грешка по-късно, тогава има големи шансове да пропуснете важните стъпки в доклада си.
# 2) Възпроизведете грешката три пъти, преди да напишете доклад за грешка
Вашата грешка трябва да бъде възпроизводима. Уверете се, че стъпките ви са достатъчно стабилни, за да възпроизведат грешката без никакви неясноти. Ако грешката ви не може да се възпроизвежда всеки път, все още можете да подадете грешка, споменавайки периодичния характер на грешката.
# 3) Тествайте същата грешка на други подобни модули
Понякога разработчикът използва един и същ код за различни подобни модули. Така че има по-големи шансове грешката в един модул да се появи и в други подобни модули. Можете дори да опитате да намерите по-тежката версия на грешката, която сте открили.
# 4) Напишете добро обобщение на грешките
Резюмето на грешките ще помогне на разработчиците бързо да анализират природата на грешките. Докладът с лошо качество ненужно ще увеличи времето за разработка и тестване. Комуникирайте добре с резюмето на вашия доклад за грешки. Имайте предвид, че обобщението на грешките се използва като справка за търсене на грешката в инвентара на грешки.
# 5) Прочетете отчета за грешките, преди да натиснете бутона Submit
Прочетете всички изречения, формулировки и стъпки, използвани в отчета за грешки. Вижте дали някое изречение създава неяснота, която може да доведе до погрешно тълкуване. Трябва да се избягват подвеждащи думи или изречения, за да има ясен доклад за грешка.
# 6) Не използвайте груб език
Хубаво е, че сте свършили добра работа и сте открили грешка, но не използвайте този кредит, за да критикувате разработчика или да атакувате някое лице.
Заключение
Няма съмнение, че докладът ви за грешки трябва да бъде висококачествен документ.
Съсредоточете се върху писането на добри доклади за грешки и отделете малко време за тази задача, защото това е основната комуникационна точка между тестера, разработчика и мениджъра. Мениджърите трябва да създадат информираност на своя екип, че писането на добър доклад за грешки е основната отговорност на всеки тестер.
Усилията ви за написване на добър доклад за грешки не само ще спестят ресурсите на компанията, но и ще създадат добри отношения между вас и разработчиците.
За по-добра производителност напишете по-добър доклад за грешки.
Експерт ли сте в писането на доклад за грешка? Чувствайте се свободни да споделите вашите мисли в раздела за коментари по-долу.
Препоръчително четене
- Примерен доклад за грешка
- Как да намерите грешка в приложението? Съвети и трикове
- Как да напиша седмичен отчет за тестване на софтуер
- Какво представлява жизнения цикъл на дефекти / грешки при тестване на софтуер? Урок за жизнения цикъл на дефекти
- Как да разрешите всички грешки без етикет „Невалидна грешка“?
- Примерни отчети за грешки за уеб и продуктови приложения
- Как да напиша ефективен обобщен отчет на теста [Пример за изтегляне на доклад]
- Защо докладването на грешки е изкуство, което трябва да се научи от всеки тестер?