Открих грешка - това е технически документ и във връзка с това, ние искаме да се отбележи, че описанието език на проблема да е технически. Правилно терминология трябва да се използва, когато се използва имената на елементи на потребителския интерфейс (полето за редактиране, падащ списък, ComboBox, линк, текст площ, бутон, меню, изскачащо меню, заглавна лента, системната лента и т.н.), потребителското действие (кликнете върху връзката, натиснете бутона , т изберете меню и т.н.) и на резултатите, получени (се отваря прозорец, се показва съобщение за грешка, системата се разби и т.н.).
към задължителните изисквания на докладите за полета бъг
Имайте предвид, че задължителните полета на доклад за грешка са кратко описание (Bug Обобщение), тежест (тежест), стъпки за възпроизводството (стъпки за възпроизвеждане), резултатът (действителният резултат), очакван резултат (Очакван резултат). По-долу са дадени примери за изискванията и да попълните тези полета.
кратко описание
Името говори за себе си. В едно изречение, което трябва да се поберат по смисъла на всички доклади за грешки, а именно: кратки и ясни, като се използва правилната терминология да се каже какво и къде не работят. Например:
- от приложенията възникне срив на, когато се опитате да запишете в текстов файл по-голям от 50 МБ.
- Данните за формата на "Профил", не се съхраняват, когато кликнете върху "Save".
Освен това, ние ви предлагаме да изследва принципа на "Къде? Кога?". описано в "QA гнездо" страниците на блога:
"Това, което е на този принцип?
Направи предложение, в което фактите дефекта, посочени в следната последователност:
сериозност
С две думи, може да се отбележи, че ако възникне проблем в основната функционалност на приложението и след настъпването на заявлението става напълно недостъпни, както и работа с тях не е възможно, тогава той е блокиран. Обикновено всички блокиращи проблеми са открити по време на първоначалната проверка за нови версии на продукта (Build Тест за проверка. Smoke Test), като тяхното присъствие не позволява пълно тестване. Ако тестът може да бъде продължена, сериозността на дефекта ще бъде от решаващо значение. За сметка на значителни. незначителни и тривиални грешки въпроса съвсем ясно, и по наше мнение това не се нуждаят от допълнително обяснение.
Стъпки за възпроизвеждане / резултат / Очакван резултат
Важно е да се ясно описание на всички стъпки, с посочване на всички входни данни (потребителско име, данни за попълване на формата) и междинните резултати.
Основни грешки при писане на доклад за грешка
Липсата на данни, предоставени
Тя не винаги е един и същ проблем може да възникне, когато всички входни стойности и по всяко влезлия потребител, така че това е силно препоръчително да се направи цялата необходима информация в доклад за грешка
Определяне на степента на
Много често се случва, или преувеличение или подценяване на сериозността на дефекта, което може да доведе до грешен приоритет при решаване на проблемите.
Езикови описания
Често се използва при описанието на проблема с грешна терминология или комплекс говорни модели, които биха могли да подведат лицето, отговорно за решаване на проблема.
Липсата на очаквания резултат
В случаите, когато не посочват какво следва да се изисква от поведението на системата, да отделите време и разработчик, за да намерите тази информация, като по този начин забавя корекция на дефекта. Трябва да посочите точка в изискванията, напиши случай тест или личното Ви мнение, ако тази ситуация не е документирано.
Попълване полета съобщения за бъгове
Както е описано по-долу таблица показва основните доклади поле за грешки, както и ролята на служителя, отговарящ за попълване на полето. Червен цвят показва задължителни полета:
Отговорен за попълването на полето
Свързани статии