Процес на управление на дефекти при тестване на софтуер

Какво е процес на управление на дефекти?

- Процес на управление на дефекти е систематичен подход, използван в софтуерното тестване за идентифициране, класифициране, отстраняване и проверка на грешки преди пускането на софтуера. Жизненият цикъл включва шест основни етапа: 1) Откриване на дефекта, 2) Категоризиране, 3) Разрешаване от разработчиците, 4) Проверка от тестерите, 5) Приключване и 6) Докладване на дефекти в края на проекта.

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

Защо ви е необходим процес за управление на дефекти?

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

Седмица по-късно разработчикът отговаря с различно разбиране на проблема.

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

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

Стъпка 1) Откриване

в Откритие На тази фаза екипът на проекта трябва да идентифицира колкото се може повече дефекти, преди крайният клиент да се сблъска с тях. Дефектът се счита за „открит“, след като бъде признат и приет от екипа за разработка, като в този момент статусът му се променя на Приемани.

В примерния сценарий, тестерите откриха 84 дефекта на GuruУебсайт на банка 99.

Тестерите и разработчиците обаче не винаги са съгласни. Вижте следния случай, в който екипът по тестване идентифицира проблеми на Guru99 Bank уебсайт и ги докладва, но екипът за разработка оспорва дали са дефекти:

В такъв случай, като мениджър на тестове, какво трябва да направите?

A) Съгласен съм с екипа по тестване, че това е дефект.
Б) Вземете ролята на съдия и решете дали проблемът е дефект или не.
В) Съгласен съм с екипа за разработка, че това не е дефект.

Правилният подход е вариант Б. За разрешаване на конфликта трябва да се приложи процес на разрешаване, а мениджърът на тестването трябва да оцени проблема безпристрастно, преди да реши дали той се квалифицира като дефект.

Стъпка 2) Категоризация

Категоризирането на дефектите помага на разработчиците да приоритизират работата си, така че най-критичните за бизнеса проблеми да бъдат отстранени първо. Категоризирането обикновено се извършва от мениджъра на тестовете и се основава на тежестта и въздействието върху бизнеса.

Дефектите обикновено се групират в четири нива на приоритет: Критично, Високо, Средно и НискоОпитайте да зададете правилния приоритет на всеки от следните дефекти:

1. Производителността на уебсайта е твърде бавна.
2. Функцията за вход в уебсайта не работи правилно.
3. Графичният потребителски интерфейс на уебсайта не се показва правилно на Подвижен устройства.
4. Уебсайтът не може да запомни сесията за вход на потребителя.
5. Някои връзки не работят.

Ето препоръчителните отговори:

Не.	Descriptйон	Приоритет	Обяснение
1	Производителността на уебсайта е твърде бавна	Високо	Проблемите с производителността причиняват големи неудобства на крайните потребители.
2	Функцията за вход не работи правилно	критичен	Входът е основна функция на банковия уебсайт. Ако не успее, целият потребителски път се блокира.
3	Графичният потребителски интерфейс не се показва правилно на мобилни устройства	Среден	Дефектът засяга потребителите, които преглеждат уебсайта на смартфони.
4	Уебсайтът не може да запомни сесията за вход на потребителя	Високо	Потребителите могат да влизат в системата, но не могат да извършват никакви допълнителни транзакции.
5	Някои връзки не работят	ниско	Лесно решение за разработчиците, а потребителите все още могат да имат достъп до останалата част от сайта.

Стъпка 3) Решаване на дефекти

Разрешаване на дефекти В софтуерното тестване е стъпка по стъпка процес на отстраняване на дефекти. Процесът на разрешаване започва с възлагане на дефекти на разработчиците, които след това планират корекциите въз основа на приоритет, внедряват корекциите и накрая изпращат отчет за разрешаването обратно на мениджъра на тестването. Тази последователност прави дефекта... tracкрал прозрачен и отговорен.

Можете да следвате тези стъпки, за да отстраните дефект:

• Задание: Дефектът се присвоява на разработчик или техник и статусът му се променя на В отговор.
• Фиксиране на графика: Екипът за разработка поема контрола и създава график за отстраняване на дефекти въз основа на приоритета на дефекта.
• Поправете дефекта: Докато разработчиците поправят дефектите, мениджърът на тестовете tracks напредва спрямо планирания график.
• Докладвайте резолюцията: Разработчиците изпращат отчет, потвърждаващ кои дефекти са били отстранени и как.

Стъпка 4) Проверка

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

Например, когато екипът за разработка съобщи, че са отстранени 61 дефекта, екипът за тестване тества отново всеки един от тях, за да потвърди дали поправките работят правилно при същите условия, които са причинили първоначалния неуспех.

Стъпка 5) Затваряне

След като дефектът бъде отстранен и потвърден, неговият статус се променя на ЗатворенАко дефектът не бъде правилно отстранен по време на проверката, трябва да изпратите известие обратно до екипа за разработка, за да го разследват отново. Затварянето показва, че дефектът вече не е активен в системата.

Стъпка 6) Докладване на дефекти

Докладване на дефекти В софтуерното тестване е процесът, чрез който мениджърите по тестване подготвят и споделят състоянието на дефектите с управленския екип. Управленският екип преглежда доклада и предоставя обратна връзка или допълнителна подкрепа, ако е необходимо. Докладването на дефекти подобрява комуникацията, tracкрал и видимост около дефектите.

Ръководството има право да разбира състоянието на дефектите, за да може ефективно да подкрепи проекта. Следователно, трябва редовно да докладвате за текущата ситуация с дефектите, за да могат да предоставят насоки и ресурси.

Важни показатели за дефекти

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

Как можете да измерите и оцените качеството на изпълнение на тестовете?

Това е критичен въпрос всеки Тест мениджър иска да отговори. Обикновено се използват два ключови параметъра:

В горния сценарий, Коефициент на отхвърляне на дефекти (DRR) се изчислява като 20/84 = 0.238 (23.8%).

Като друг пример, да предположим, че GuruУебсайтът на банката 99 има общо 64 дефекти, но екипът за тестване открива само 44 — значение 20 дефектите бяха пропуснати. Коефициент на изтичане на дефекти (DLR) се изчислява като 20/64 = 0.312 (31.2%).

В обобщение, качеството на изпълнение на тестовете се оценява с помощта на двата параметъра по-долу:

Колкото по-малки са стойностите на DRR и DLR, толкова по-добро е качеството на изпълнение на теста. Приемливият диапазон обикновено се определя от целите на проекта или се сравнява с подобни проекти. В този пример препоръчителният приемлив диапазон е 5% до 10%Текущото изпълнение е извън този диапазон, което сигнализира, че качеството на тестовете трябва да се подобри чрез следните мерки:

• Подобряване на уменията за тестване на членовете на екипа.
• Прекарвайте повече време върху изпълнението на теста, особено при преглед на резултатите от изпълнението.

Най-добри практики за ефективно управление на дефекти

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

Ето най-добрите практики, които начинаещите и средно напредналите тестери трябва да възприемат веднага:

1. Стандартизирайте шаблона за дефекти: Използвайте шаблон за отчет за фиксирани дефекти, съдържащ полета като „Идентификатор на дефекта“, Descriptион, стъпки за възпроизвеждане, тежест, приоритет, среда и прикачени файлове. Последователността намалява обмена на информация между тестери и разработчици.
2. Приоритизирайте преди да възложите: Винаги категоризирайте дефектите по тежест и приоритет, преди да ги изпратите на разработчиците. Това гарантира, че критичните проблеми няма да останат зад козметичните.
3. Възпроизведете преди докладване: Възпроизведете дефекта поне два пъти в чиста среда, преди да го повдигнете. Възпроизводимите дефекти се затварят по-бързо и намаляват коефициента на отхвърляне.
4. Приемете дефект tracкралски инструмент: Използвайте инструменти като ДЖИРА, Bugzilla или богомолка да централизирам tracкрал, история и репортаж.
5. Провеждане на триажни срещи: Провеждайте кратки, фокусирани срещи за сортиране на дефекти, за да съгласувате приоритетите между екипите за контрол на качеството, разработка и продукти.
6. Измерване на изтичане и отхвърляне: Track DLR и DRR всеки спринт или цикъл. Нарастващата честота на изтичане е ранно предупреждение, че тестовото покритие е непълно.
7. Извършете анализ на първопричините: За повтарящи се или силно сериозни дефекти, изпълнете анализ на първопричината, така че същият клас грешки да не се повтаря в бъдещи издания.
8. Затворете цикъла с отчитане: Споделяйте седмични табла за управление на дефектите със заинтересованите страни, така че проблемите да останат видими и да могат да бъдат предприети действия.

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

Ресурси:

Изтеглете примерен шаблон за докладване на дефекти

Въпроси и Отговори