Открих грешка (доклад за грешка) или институция бъг тестване на

Да приемем ситуация, в която сте открили грешка в някакъв софтуер и веднага скакателната въпрос Че общо с това. Разбира се можете да отидете на разработчика и кажи на грешката и да се опишат на пръсти как да го играят, но това е лоша практика, тъй като разработчик на софтуер може да седи в другата стая, офиса или дори в друга страна, а броят на грешки може да бъде толкова голяма, че те не могат да си спомня и след това да ги пропуснете. И ако да отвлече вниманието на разработчика за всяка дребна грешка и ако те спаси нещо, което не е кошер идва от загубата на време и пропастта между разработчик на проблеми - не най-доброто решение. Следователно, не е въпрос на адекватно решение - документиране на грешки, намерени с възможност за споделянето им. Обикновено ИТ компании бъгове документирани в бъг-трекинг системи.

Има различен набор от бъг-система за проследяване, което ни позволява не само да се създаде задачи, промените състоянието им, но също така да се създаде доклади за грешки. Най-често далеч е Redmine, Bugzilla, Mantis, JIRA

Примерът изглежда списък на докладите за грешки в JIRA:

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

Същността на нашата грешка е нещо, което ние не можем да влезете в администраторския панел на ползвателя на администратор, който току-що е създаден, така че всички нови администратори не мога да вляза, когато въведете валиден потребител и парола в текстовите полета. По-долу е едно обяснение и описание на всяка област.

Основните направления в докладите за грешки

Това е уникален идентификатор на бъг намерен

Кратко и кратко описание на грешката, за да се отговори на въпроса какво се е случило и при какви условия.
Например, както «новосъздадените Admin потребител не може да влезете в администраторския панел»
Това е описанието на грешката да е програмист, за да го дори не можеше да се отвори веднага и за това, което е грешката изглежда. Но по-често през всички грешки, които са трудни и изискват допълнителни действия в рамките на описания и обяснения как да го възпроизвеждат, а в действителност трябва да бъде, така че само обобщение на трудно да се опише. Поради това, че има следните, полетата по-долу:

Предпоставки

Там обикновено е написано това, което трябва да направите, преди да изпълните стъпките на нашата игра. Може би искате да се създаде специална структура или потребители с различни роли и шаблони, необходими за възпроизвеждане на този бъг.
Например, ако бъг сме, че администраторът не можете да влезете в администраторския панел с правилните данни, но не мога да вляза само новосъздадената, т.е. старите администраторите вървят както обикновено и всичко е ОК.






В това поле трябва да напишете, че искате да създадете нов потребител администратор
От стъпките на създаването на този администратор не е същността на този бъг е, че могат да бъдат предприети в тази област.

Стъпки за възпроизвеждане

Полето се използва за описание на стъпките vosproizvideniya, в която ни бъг възпроизвеждат.
Например,
1) Отворете страницата за вход на администраторския панел
2) Въведете валиден пълномощията в «име» и «Парола» текстови полета
3) Натиснете бутона Enter
Е. В тази област се описва подробно описание на стъпките до момента, когато виждаме бъг
След последния етап, ние трябва да се види резултатът от което е бъг в тази ситуация

Действително Резултати

Тук ние се опише това, което имаме към последната стъпка за преминаване през стъпки
Например, тя може да бъде описан, както следва:
«Въвели сте неправилно потребител или парола» се появява съобщение до страницата за вход

Очакван резултат

В тази област, пише какво трябва да бъде, как трябва да се държат на софтуер на последната стъпка от възпроизвеждане на стъпки.
От първия момент на тя изглежда да е добре, защо на полето и така всички са очевидни, но има и много сложни бъгове, в който всичко изглежда да се работи, но чието поведение не съответства на поведение, което се посочва в изискванията или през устата с ovnera думите продукт. Ето защо, областта е важно и необходимо да се запълни

Тя drobdaun лист Наименование на проекта
Ако сте в компанията на повече от 1 проект просто да изберете вашия проект, в който е намерен бъг

номер на версията

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

Това поле се използва за определяне на приоритет грешката обикновено показват Ръководител на проекта или спорна топка майстор, с което определят приоритетните корекции на грешки срещу други грешки, намерени по този начин извършват приоритетно корекции на грешки
Разграничаване следните приоритети:
Висока: Най-високата, първичната
Средно: Средна приоритет
Ниска: Най-новата значение

Това поле показва сериозността на грешката. Има няколко нива на сериозност на грешки, като например:
Blocker: поставя ако грешката е блокиране допълнително приложение или блокове по-нататъшно изпитване, като грешка, която ако създадете потребител с името на вече съществуващ, а след това на всеки потребител сме, за да излезете на цялата система не може, защото показва SQL грешка на началната страница и вече не може да ходи никъде
Критични стане значително влияние върху поведението на софтуера и неправилно поведение програма, но не блокира работата на приложението, като бъг, така че потребителят може да влезе без парола
Специалност: става незначителен ефект върху поведението на софтуера, и не-решаващо значение за нашия проект, например за грешка, че ако броят на вписванията в списъка на записите се изчислява неправилно
Мала: поставя ако въздействието върху функционалността и поведението не прави грешката на софтуер, например тя може да бъде граматически грешки, в която художникът или

Тук можете да изберете програмист, който ще оправи грешката, и може да бъде на полето не е на разположение, както ръководителя на проекта решава кой от разработчиците, за да го изпратите на базата на обема на работата на разработчиците и тежестта на грешката

Обикновено попълва автоматично името на този, който създава доклад за грешка

Полето за състояние се попълва автоматично на открито, а след това може да се промени разработчик, тестер или на ръководителя на проекта в зависимост от на какъв етап е нашата грешка. Данните показват възможни състояния:

В допълнение,

тези области обикновено имат възможност да attachem трупи или снимки на екрани за лесно възпроизвеждане и да установи къде в бъг програмист