Що таке помилка?
Помилка - це наслідок / результат помилки кодування.
Дефект при тестуванні програмного забезпечення
Дефект тестування програмного забезпечення є зміна або відхилення додатки від вимог кінцевого користувача або оригінальних бізнес - вимог. Дефект програмного забезпечення - це помилка в кодуванні, яка спричиняє неправильні або несподівані результати програмного забезпечення, яке не відповідає фактичним вимогам. Тестери можуть зіткнутися з такими дефектами під час виконання тестів.
Ці два терміни мають дуже тонку межу різниці. У промисловості обидва - це несправності, які потрібно виправити, і тому їх взаємозалежність використовується деякими групами випробувачів.
Коли тестери виконують тестові кейси, вони можуть натрапити на такі результати тесту, які суперечать очікуваним результатам. Ця варіація результатів тестування називається дефектом програмного забезпечення. Ці дефекти або варіації позначаються різними назвами в різних організаціях, наприклад проблеми, проблеми, помилки чи інциденти.
У цьому підручнику ви дізнаєтесь-
- Повідомлення про помилку
- Процес управління дефектами
- Відкриття
- Категоризація
- Дозвіл
- Перевірка
- Закриття
- Звітність
- Важливі показники дефектів
Звіт про помилку при тестуванні програмного забезпечення
Повідомлення про помилку в тестуванні програмного забезпечення являє собою детальний документ про помилки , виявлені в програмному забезпеченні. Звіт про помилки містить кожну деталь про помилки, як-от опис, дату знаходження помилки, ім'я тестувальника, який її знайшов, ім'я розробника, який її виправив тощо. Звіт про помилки допомагає виявити подібні помилки в майбутньому, щоб її можна було уникнути.
Повідомляючи про помилку розробнику, ваш звіт про помилку повинен містити наступну інформацію
- Defect_ID - унікальний ідентифікаційний номер дефекту.
- Опис дефекту - Детальний опис дефекту, включаючи інформацію про модуль, в якому виявлено дефект.
- Версія - версія програми, в якій виявлено дефект.
- Кроки - Детальні кроки разом із скріншотами, за допомогою яких розробник може відтворити дефекти.
- Дата підвищення - дата, коли дефект піднімається
- Довідка - де ви надаєте посилання на такі документи, як. вимоги, дизайн, архітектура або, можливо, навіть скріншоти помилки, щоб допомогти зрозуміти дефект
- Виявлено за - Ім'я / ідентифікатор випробувача, який порушив дефект
- Статус - статус дефекту, про це пізніше
- Виправлено - Ім'я / ідентифікатор розробника, який це виправив
- Дата закриття - дата закриття дефекту
- Серйозність, яка описує вплив дефекту на заявку
- Пріоритет, який пов'язаний з терміновістю виправлення дефектів. Пріоритет серйозності може бути високим / середнім / низьким залежно від терміновості удару, при якій дефект повинен бути виправлений відповідно
Клацніть тут, якщо відео недоступне
Ресурси
Завантажте зразок шаблону звітування про дефекти
Розгляньте наступне як менеджера тестів
Ваша команда знайшла помилки під час тестування проекту Guru99 Banking.
Через тиждень розробник відповідає -
Наступного тижня тестер відповідає
Як і у наведеному вище випадку, якщо спілкування з дефектами здійснюється усно, незабаром все стає дуже складним. Для контролю та ефективного управління помилками вам потрібен життєвий цикл дефектів.
Що таке процес управління дефектами?
Управління дефектами - це систематичний процес виявлення та виправлення помилок. Цикл управління дефектами містить наступні етапи 1) Виявлення дефекту, 2) Категоризація дефектів 3) Виправлення дефектів розробниками 4) Перевірка тестерами, 5) Закриття дефектів 6) Звіти про дефекти в кінці проекту
Ця тема допоможе вам застосувати процес управління дефектами до веб-сайту проекту Guru99 Bank. Ви можете виконати наведені нижче дії для управління дефектами.
Відкриття
На фазі виявлення команди проекту повинні виявити якомога більше дефектів , перш ніж кінцевий замовник зможе їх виявити. Дефект , як кажуть , щоб бути виявленими і зміна статусу прийнятим , коли він визнаний і прийнятий розробниками
У вищезазначеному сценарії тестувальники виявили 84 дефекти на веб-сайті Guru99.
Давайте подивимось на наступний сценарій; Ваша команда тестування виявила деякі проблеми на веб-сайті банку Guru99. Вони вважають їх дефектами і повідомляють команді розробників, але є конфлікт -
У такому випадку, як менеджер тестів, що ти будеш робити?
А) Погодьтесь з тестовою групою про її дефект
Б) Керівник тесту виконує роль судді, який вирішує, чи є проблема дефектом чи ні
В) Погодьтеся з командою розробників, яка не є дефектом. Виправте InCorrect
У такому випадку для вирішення конфлікту слід застосувати процес вирішення проблеми. Ви берете на себе роль судді, який вирішує, є проблема веб-сайту дефектом чи ні.
Категоризація
Категоризація дефектів допомагає розробникам програм визначати пріоритети своїх завдань. Це означає, що такий пріоритет допомагає розробникам у першу чергу виправити ті дефекти, які є надзвичайно важливими.
Дефекти зазвичай класифікуються менеджером випробувань -
Давайте зробимо невеличку вправу, як слідуючи перетягуванню пріоритету дефекту нижче
- Критичний
- Високий
- Середній
- Низький
| 1) Ефективність веб-сайту занадто повільна |
|
| 2) Функція входу на веб-сайт не працює належним чином |
|
| 3) Графічний інтерфейс веб-сайту відображається неправильно на мобільних пристроях |
|
| 4) Веб-сайт не пам’ятає сеанс входу користувача |
|
| 5) Деякі посилання не працюють |
|
Ось рекомендовані відповіді
| Ні. | Опис | Пріоритет | Пояснення |
|---|---|---|---|
| 1 | Продуктивність веб-сайту занадто повільна | Високий | Помилка продуктивності може спричинити величезні незручності для користувача. |
| 2 | Функція входу на веб-сайт не працює належним чином | Критичний | Вхід в систему є однією з основних функцій банківського веб-сайту, якщо ця функція не працює, це серйозні помилки |
| 3 | Графічний інтерфейс веб-сайту відображається неправильно на мобільних пристроях | Середній | Дефект впливає на користувача, який використовує смартфон для перегляду веб-сайту. |
| 4 | Веб-сайт не зміг згадати сеанс входу користувача | Високий | Це серйозна проблема, оскільки користувач зможе увійти в систему, але не зможе виконувати будь-які подальші транзакції |
| 5 | Деякі посилання не працюють | Низький | Це просте виправлення для хлопців-розробників, і користувач все одно може отримати доступ до сайту без цих посилань |
Вирішення дефектів
Усунення дефектів при тестуванні програмного забезпечення - це поетапний процес виправлення дефектів. Процес усунення дефектів починається з присвоєння дефектів розробникам, потім розробники планують виправлення дефекту відповідно до пріоритету, потім дефекти виправляються, і нарешті розробники надсилають звіт про вирішення проблеми менеджеру тесту. Цей процес допомагає легко виправити та відстежити дефекти.
Ви можете виконати такі дії, щоб виправити дефект.
- Призначення : Призначено розробнику чи іншому технічному персоналу для виправлення та змінено статус на Відповідає .
- Виправлення розкладу : Розробник бере на себе відповідальність на цьому етапі. Вони створять графік виправлення цих дефектів залежно від пріоритету дефекту.
- Виправлення дефекту : Поки команда розробників виправляє дефекти, Диспетчер випробувань відстежує процес виправлення дефектів у порівнянні з наведеним вище графіком.
- Повідомте про розв’язання : Отримайте звіт про роздільну здатність від розробників, коли усунені дефекти.
Перевірка
Після того, як команда розробників виправила та повідомила про дефект, команда тестування перевіряє, що дефекти дійсно усунені.
Наприклад, у наведеному вище сценарії, коли команда розробників повідомила, що вже виправила 61 дефект, ваша команда повторно перевірить, чи справді ці дефекти були виправлені чи ні.
Закриття
Після усунення та підтвердження дефекту статус дефекту змінюється як закритий . Якщо ні, ви надішлете повідомлення розробнику, щоб перевірити дефект ще раз.
Звітування про дефекти
Звітування про дефекти при тестуванні програмного забезпечення - це процес, в рамках якого керівники тестів готують і надсилають звіт про дефекти керівній групі для зворотного зв'язку щодо процесу управління дефектами та стану дефектів. Потім керівна команда перевіряє звіт про дефект і надсилає відгук або надає подальшу підтримку, якщо це необхідно. Повідомлення про дефекти допомагає краще спілкуватися, детально відстежувати та пояснювати дефекти.
Правління має право знати стан дефекту. Вони повинні розуміти процес управління дефектами, щоб підтримати вас у цьому проекті. Тому ви повинні повідомити їм про поточну ситуацію з дефектами, щоб отримати від них відгук.
Важливі показники дефектів
Поверніться до вищевказаного сценарію. Розробники та тестові групи мають огляди повідомлених дефектів. Ось результат цієї дискусії
Як виміряти та оцінити якість виконання тесту?
Це питання, яке хоче знати кожен менеджер випробувань. Є 2 параметри, які ви можете розглянути як такі
У наведеному вище сценарії ви можете розрахувати коефіцієнт відхилення дефекту (DRR) 20/84 = 0,238 (23,8%).
Ще один приклад: передбачається, що на веб-сайті банку Guru99 є 64 дефекти, але ваша команда тестування виявляє лише 44 дефекти, тобто вони пропустили 20 дефектів. Таким чином, можна обчислити коефіцієнт витоку дефекту (DLR) є 20/64 = 0,312 (31,2%).
Висновок, якість виконання тесту оцінюється за двома параметрами
Чим менше значення DRR та DLR, тим краща якість виконання тесту. Який діапазон коефіцієнтів є прийнятним ? Цей діапазон можна визначити та прийняти за основу в цілі проекту, або ви можете використати показники подібних проектів.
У цьому проекті рекомендоване значення допустимого співвідношення становить 5 ~ 10%. Це означає, що якість виконання тесту низька. Ви повинні знайти контрзаходи для зменшення цих коефіцієнтів, таких як
- Удосконалити навички тестування члена.
- Витратьте більше часу на тестування, особливо на перегляд результатів тестування.