Какво е бъг?
Грешка е последица / резултат от грешка в кодирането.
Дефект в софтуерното тестване
А Дефект в тестване на софтуер е вариант или отклонение от прилагането на софтуер от изискванията на крайния потребител или оригинални бизнес изисквания. Софтуерен дефект е грешка в кодирането, която причинява неправилни или неочаквани резултати от софтуерна програма, която не отговаря на действителните изисквания. Тестерите могат да се натъкнат на такива дефекти, докато изпълняват тестовите случаи.
Тези два термина имат много тънка граница на разлика, В индустрията и двете са грешки, които трябва да бъдат отстранени и така взаимно използвани от някои от екипите за тестване.
Когато тестерите изпълняват тестовите случаи, те могат да срещнат такива резултати от теста, които са в противоречие с очакваните резултати. Тази промяна в резултатите от теста се нарича дефект на софтуера. Тези дефекти или вариации са посочени с различни имена в различни организации, като проблеми, проблеми, грешки или инциденти.
В този урок ще научите -
- Доклад за грешка
- Процес на управление на дефекти
- Откритие
- Категоризация
- Резолюция
- Проверка
- Закриване
- Отчитане
- Важни показатели за дефекти
Отчет за грешки при тестване на софтуер
A Bug Report в тестване на софтуер е подробен документ за грешки, намерени в софтуерното приложение. Отчетът за грешки съдържа всяка подробност за грешки като описание, дата, когато е открита грешка, име на тестера, който я е намерил, име на разработчика, който я е поправил и др. Отчетът за грешки помага да се идентифицират подобни грешки в бъдеще, за да може да се избегне.
Докато докладвате за грешката на разработчика, вашият доклад за грешка трябва да съдържа следната информация
- Defect_ID - Уникален идентификационен номер за дефекта.
- Описание на дефекта - Подробно описание на дефекта, включително информация за модула, в който е открит дефект.
- Версия - Версия на приложението, в което е открит дефект.
- Стъпки - подробни стъпки заедно със скрийншотове, с които разработчикът може да възпроизведе дефектите.
- Дата на издигане - Дата на повдигане на дефекта
- Справка - къде в вас Предоставете препратка към документите като. изисквания, дизайн, архитектура или може би дори скрийншотове на грешката, за да се разбере дефекта
- Открито по - Име / идентификационен номер на изпитателя, повдигнал дефекта
- Състояние - Състояние на дефекта, повече за това по-късно
- Фиксирано от - Име / идентификатор на разработчика, който го е поправил
- Date Closed - Дата, когато дефектът е затворен
- Тежест, която описва въздействието на дефекта върху приложението
- Приоритет, който е свързан с спешността при отстраняване на дефекти. Приоритетът на сериозността може да бъде висок / среден / нисък въз основа на спешността на удара, при която дефектът трябва да бъде отстранен съответно
Щракнете тук, ако видеоклипът не е достъпен
Ресурси
Изтеглете примерен шаблон за докладване на дефекти
Помислете за следното като мениджър на тестове
Вашият екип откри грешки, докато тества проекта за банкиране Guru99.
След седмица разработчикът отговаря -
През следващата седмица тестерът отговаря
Както в горния случай, ако дефектната комуникация се извършва устно, скоро нещата стават много сложни. За да контролирате и ефективно да управлявате грешки, ви е необходим жизнен цикъл на дефекти.
Какво представлява процесът за управление на дефекти?
Управлението на дефекти е систематичен процес за идентифициране и отстраняване на грешки. Цикълът за управление на дефекти съдържа следните етапи 1) Откриване на дефекти, 2) Категоризиране на дефекти 3) Поправяне на дефекта от разработчици 4) Проверка от тестери, 5) Затваряне на дефекти 6) Отчети за дефекти в края на проекта
Тази тема ще ви насочи как да приложите процеса за управление на дефекти към уебсайта на проекта Guru99 Bank. Можете да следвате стъпките по-долу за управление на дефекти.
Откритие
Във фазата на откриване екипите по проекта трябва да открият колкото се може повече дефекти , преди крайният клиент да може да го открие. Казва се, че дефектът е открит и промяната в статуса е приета, когато бъде призната и приета от разработчиците
В горния сценарий тестерите са открили 84 дефекта в уебсайта Guru99.
Нека да разгледаме следния сценарий; вашият екип за тестване откри някои проблеми в уебсайта на Guru99 Bank. Те ги считат за дефекти и са докладвани на екипа за разработки, но има конфликт -
В такъв случай, като мениджър на тестове, какво ще правите?
А) Съгласете се с тестовия екип, че това е дефект
Б) Тест мениджърът изпълнява ролята на съдия, за да реши дали проблемът е дефектен или не
В) Съгласете се с екипа на разработчика, който не е дефект Коригирайте InCorrect
В такъв случай за разрешаване на конфликта трябва да се приложи процес за разрешаване, вие играете ролята на съдия, който решава дали проблемът с уебсайта е дефект или не.
Категоризация
Категоризацията на дефекти помага на разработчиците на софтуер да определят приоритетите си. Това означава, че този вид приоритет помага на разработчиците да отстранят първо тези дефекти, които са изключително важни.
Дефектите обикновено се категоризират от мениджъра на тестовете -
Нека направим малко упражнение, както следвате Drag & Drop the Defect Priority долу
- Критично
- Високо
- Среден
- Ниска
| 1) Ефективността на уебсайта е твърде бавна |
|
| 2) Функцията за вход на уебсайта не работи правилно |
|
| 3) GUI на уебсайта не се показва правилно на мобилни устройства |
|
| 4) Уебсайтът не може да запомни сесията за вход на потребителя |
|
| 5) Някои връзки не работят |
|
Ето препоръчителните отговори
| Не. | Описание | Приоритет | Обяснение |
|---|---|---|---|
| 1 | Ефективността на уебсайта е твърде бавна | Високо | Грешката в производителността може да причини огромни неудобства на потребителя. |
| 2 | Функцията за вход на уебсайта не работи правилно | Критично | Входът е една от основните функции на уебсайта за банкиране, ако тази функция не работи, това са сериозни грешки |
| 3 | GUI на уебсайта не се показва правилно на мобилни устройства | Среден | Дефектът засяга потребителя, който използва смартфон за преглед на уебсайта. |
| 4 | Уебсайтът не можа да запомни сесията за вход на потребителя | Високо | Това е сериозен проблем, тъй като потребителят ще може да влезе, но няма да може да извършва допълнителни транзакции |
| 5 | Някои връзки не работят | Ниска | Това е лесна корекция за разработчици и потребителят все още може да влезе в сайта без тези връзки |
Разрешаване на дефекти
Разрешаването на дефекти при тестване на софтуер е стъпка по стъпка процес на отстраняване на дефектите. Процесът за разрешаване на дефекти започва с присвояване на дефекти на разработчиците, след което разработчиците планират дефекта да бъде поправен според приоритета, след това дефектите се отстраняват и накрая разработчиците изпращат доклад за разрешаване на мениджъра на теста. Този процес помага за лесното отстраняване и проследяване на дефекти.
Можете да изпълните следните стъпки, за да отстраните дефекта.
- Задание : Възложено на разработчик или друг техник за поправяне и промени състоянието на Отговаряне .
- Фиксиране на графика : От тази страна на разработчика се поема отговорността. Те ще създадат график за отстраняване на тези дефекти, в зависимост от приоритета на дефекта.
- Отстраняване на дефекта : Докато екипът за разработки отстранява дефектите, Test Manager проследява процеса на отстраняване на дефекти в сравнение с горния график.
- Отчетете разделителната способност : Получете отчет за разделителната способност от разработчиците, когато дефектите бъдат отстранени.
Проверка
След разработването на отбора фиксирана и се съобщава на дефекта, за тестване на екипа проверява , че дефектите са всъщност решени.
Например, в горния сценарий, когато екипът за разработка съобщи, че вече е отстранил 61 дефекта, вашият екип ще тества отново, за да провери дали тези дефекти са реално отстранени или не.
Закриване
След като дефектът бъде разрешен и проверен, дефектът се променя като състояние на затворен . Ако не, изпратите известие до разработката, за да проверите отново дефекта.
Отчитане на дефекти
Отчитането на дефекти при тестване на софтуер е процес, при който мениджърите на тестове подготвят и изпращат отчета за дефектите на мениджърския екип за обратна връзка относно процеса на управление на дефекти и състоянието на дефектите. След това управленският екип проверява отчета за дефекта и изпраща обратна връзка или предоставя допълнителна поддръжка, ако е необходимо. Отчитането на дефекти помага за по-добра комуникация, проследяване и обяснение на дефекти в детайли.
Управителният съвет има право да знае състоянието на дефекта. Те трябва да разберат процеса за управление на дефекти, за да ви подкрепят в този проект. Следователно трябва да им докладвате текущата ситуация на дефекти, за да получите обратна връзка от тях.
Важни показатели за дефекти
Върнете горния сценарий. Разработчиците и тестовите екипи имат прегледи на докладваните дефекти. Ето резултата от тази дискусия
Как да се измери и оцени качеството на изпълнението на теста?
Това е въпрос, който всеки мениджър на теста иска да знае. Има 2 параметъра, които можете да разгледате като следните
В горния сценарий можете да изчислите коефициента на отхвърляне на дефекта (DRR) е 20/84 = 0,238 (23,8%).
Друг пример, предполага се, че уебсайтът на Guru99 Bank има общо 64 дефекта, но вашият екип за тестване открива само 44 дефекта, т.е. те са пропуснали 20 дефекта. Следователно можете да изчислите коефициента на изтичане на дефекти (DLR) е 20/64 = 0,312 (31,2%).
Заключение, качеството на изпълнението на теста се оценява чрез следните два параметъра
Колкото по-малка е стойността на DRR и DLR, толкова по-добро е качеството на изпълнението на теста. Какъв е приемливият диапазон на съотношението ? Този диапазон може да бъде дефиниран и приет като основа в целта на проекта или може да препратите показателите на подобни проекти.
В този проект препоръчителната стойност на приемливото съотношение е 5 ~ 10%. Това означава, че качеството на изпълнението на теста е ниско. Трябва да намерите противодействие за намаляване на тези съотношения, като например
- Подобрете уменията за тестване на член.
- Прекарайте повече време за изпълнение на теста, особено за преглед на резултатите от теста.