В този процес, разработчиците да коригират грешки и прилагат нови функции. Различни бъгове имат различни функции и значение на проекта, различен приоритет (тоест, от порядъка на изпълнение).
Но различни хора - различни виждания за това, което е по-важно, и че - най-малко. Фактът, че тестера или разработчик смята за маловажно, може да бъде важно за клиента. И обратното.
Е, ситуация, в която тестер твърди, че грешката е задължително трябва да бъдат поправени, а разработчикът с него не е съгласен, познато на всеки един от нас. На практика, поради това често има спорове и недоразумения.
В допълнение. При липса на регулаторен документ за определяне на важността и приоритетът ни остава да се разчита на собственото си разбиране на продукта. Като се има предвид мащаба и дълга история на продукти, няма гаранция, че тя
а) ще бъде
б) съвпадат в различните хора.
Поради тези причини, правилата, създадени от определението на критичност и приоритетни дефекти. Пример за такива правила е както следва.
1 Цел на документа
"Правилата определят критичност и приоритетни дефекти" се въвежда за поръчване на задачи и грешки, уеднаквяване и опростяване на задачи, като например определяне на приоритети, в която задачата трябва да бъдат извършени, prostanovka критичност тестери предотвратяват спорове за значението и приоритета на дефекти и проблеми.
2 Съгласно правилата за определяне на критичност
Тежест. грешка критичност. Когато грешка се определя от регистрацията на тестер. Той посочва сериозността на неговите последици за системата, удовлетвореността на потребителя, финансовите резултати.
Грешки в гръб получават по-нисък приоритет от грешки в фронтенд. Дефекти, за които има не води до грешка пътека изпълнение байпас, получават по-нисък приоритет, отколкото тези без такъв път.
За да се определи тежестта, използвайте следния списък с функционалността на системата:
За дефекти "сериозността" е задължително поле за задачи - по избор. По подразбиране всички нови сметки е настроен да "Мала».
Критично. Критични дефекти, които не позволяват да се работи при тест функционалност или да нарушат нормалната работа на критични функции бизнес модел. Признати критични стабилно възпроизвеждане на дефекти, които правят невъзможно използването на основните функции.
Майор. Основни дефекти, без които не могат да бъдат считани за планираната функционалност реализирани и работещ. Основните недостатъци са признати, е трудно да се използват основните функции или да го направи невъзможно използването на допълнителни функции.
Мала. Малки дефекти, които засягат функционалността на системата, в малка степен или имат явни заобиколни. Признат малки дефекти, които усложняват използването на допълнителни функции.
Trivial. Trivilnye дефекти, които не засягат функционалността на системата, но се влошават потребителя за външния си вид. Тривиални признати дефекти в потребителския интерфейс, като например печатни грешки, граматични, правописни, пунктуационни грешки в текстовете, едва доловими грешки в показването на страници в зависимост от настройките на браузъра и потребителски, и т.н.
3 Правила за определяне на приоритет
Приоритет. грешки или приоритетни задачи, определени от ръководителя на проекта в развитието на предаването. Той показва реда, по който трябва да се направи, това, което трябва да се направи първо, и които по-късно задачи.
Невярно «приоритет» е задължително, както за дефектите, както и за изпълнение на задачите. По подразбиране всички нови сметки е настроен на «Нормално». Регистриране на запис тестер тази стойност не се променя. Ако е необходимо, да увеличите или намалите приоритета на ръководителя на проекта се променя стойността преди предаването им за развитието.
Най-високо. Най-висок приоритет. Присвоени грешки, които трябва да бъдат коригирани незабавно. Този приоритет може да бъде назначен само една грешка, но не и задачи. Проектиран за извънредни ситуации, се отразява отрицателно на бизнеса на компанията и изискват незабавно корекция. Корекция и публикуването на подобни грешки се извършва на първо място, преди въвеждането на каквито и да било нови проблеми.
Обикновено, най-висок приоритет се определя на критични функционални дефекти, но може да има изключения. Така например, ситуацията, когато поради тривиална грешка в файлови пътища на главния портал страницата никога няма да се зареди на лого и бутон за менюто, и трябва да се коригира незабавно.
Висока. Висок приоритет. Присвоени грешките и проблемите, които трябва да бъдат фиксирани на първо място. Във всеки проект във всеки един момент може да бъде не повече от 10 отворени бъгове или висок приоритет задачи. Ако има повече от един приоритет, ръководителят на проекта да зададете приоритет на "високо", само след като по-нисък приоритет на други задачи.
Нормално. Нормално приоритет. Присвоени грешки и проблеми, които трябва да бъдат коригирани на второ място, в работно състояние. Този приоритет е избрана по подразбиране. Повечето от грешките и проблемите трябва да получи точно такъв приоритет.
Ниска. Нисък приоритет. Поставени задачи и грешки, корекция на която не е задължително и се извършва в най-малко време позволява.