Процес управління дефектами в тестуванні програмного забезпечення
Томас Гамільтон
Що таке процес управління дефектами?
Управління дефектами – це систематичний процес виявлення та виправлення помилок. Цикл управління дефектами містить такі етапи: 1) Виявлення дефекту, 2) Класифікація дефекту, 3) Виправлення дефекту розробниками 4) Перевірка тестувальниками, 5) Закриття дефекту, 6) Звіт про дефект наприкінці проекту
У цій темі ви дізнаєтесь, як застосувати процес керування дефектами на веб-сайті проекту Guru99 Bank. Щоб усунути дефекти, виконайте наведені нижче дії.
Крок 1) Відкриття
На етапі відкриття команди проекту мають виявити як багато дефекти як можливо, до того, як кінцевий клієнт зможе його виявити. Кажуть, що дефект виявлено та змінено на статус прийнятий коли це визнано та прийнято розробниками
У наведеному вище сценарії тестувальники виявили 84 дефекти на веб-сайті Guru99.
Давайте розглянемо наступний сценарій; ваша команда тестування виявила деякі проблеми на веб-сайті Guru99 Bank. Вони вважають їх дефектами і повідомляють команді розробників, але виникає конфлікт –
Що ви будете робити в такому випадку як керівник тестів?
B) Керівник тестування бере на себе роль судді, щоб вирішити, чи є проблема дефектом чи ні
C) Погодьтеся з командою розробників, що це не дефект
У такому випадку для вирішення конфлікту має бути застосований процес вирішення, ви берете на себе роль судді, щоб вирішити, чи є проблема веб-сайту дефектом чи ні.
Крок 2) Категоризація
Категоризація дефектів допомагає розробникам програмного забезпечення визначити пріоритети своїх завдань. Це означає, що такий пріоритет допомагає розробникам у першу чергу виправляти ті вади, які є дуже критичними.
Дефекти зазвичай класифікуються керівником випробувань –
Давайте виконаємо невелику вправу, як показано нижче
Перетягніть пріоритет дефектів нижче| 1) Веб-сайт працює надто повільно |
|
| 2) Функція входу на веб-сайт не працює належним чином |
|
| 3) Графічний інтерфейс веб-сайту не відображається належним чином Mobile Пристрої |
|
| 4) Веб-сайт не зміг запам’ятати сеанс входу користувача |
|
| 5) Деякі посилання не працюють |
|
Ось рекомендовані відповіді
| Ні. | Опис | Пріоритет | Пояснення |
|---|---|---|---|
|
1 |
Веб-сайт працює надто повільно |
Високий |
Помилка продуктивності може завдати величезних незручностей користувачеві. |
|
2 |
Функція входу на веб-сайт не працює належним чином |
Критичний |
Вхід є однією з основних функцій веб-сайту банку, якщо ця функція не працює, це серйозні помилки |
|
3 |
Графічний інтерфейс веб-сайту не відображається належним чином на мобільних пристроях |
Medium |
Дефект впливає на користувачів, які використовують смартфон для перегляду веб-сайту. |
|
4 |
Веб-сайт не зміг запам’ятати сеанс входу користувача |
Високий |
Це серйозна проблема, оскільки користувач зможе увійти, але не зможе виконувати подальші операції |
|
5 |
Деякі посилання не працюють |
низький |
Це легко виправити для хлопців-розробників, і користувач усе ще може отримати доступ до сайту без цих посилань |
Крок 3) Усунення дефекту
Усунення дефектів тестування програмного забезпечення - це покроковий процес усунення дефектів. Процес усунення дефектів починається з призначення дефектів розробникам, потім розробники планують виправлення дефекту відповідно до пріоритету, потім дефекти виправляються, і, нарешті, розробники надсилають звіт про усунення менеджеру тестування. Цей процес допомагає легко виправити та відстежити дефекти.
Ви можете виконати наступні дії, щоб усунути дефект.
- Призначення: призначено розробнику або іншому техніку для виправлення та змінено статус на Відповідаючи.
- Фіксація розкладу: сторона розробника бере на себе відповідальність на цьому етапі. Вони створять графік усунення цих дефектів залежно від пріоритету дефекту.
- Усуньте дефект: поки команда розробників виправляє дефекти, менеджер тестування відстежує процес виправлення дефектів у порівнянні з наведеним вище графіком.
- Повідомити про резолюцію: Отримайте звіт про вирішення проблеми від розробників після усунення дефектів.
Крок 4) Перевірка
Після команди розробників фіксованою та повідомляє дефект, команда тестування аудит що дефекти фактично усунені.
Наприклад, у наведеному вище сценарії, коли команда розробників повідомила, що вони вже виправили 61 дефект, ваша команда провела б повторне тестування, щоб перевірити, чи справді ці дефекти виправлено чи ні.
Крок 5) Закриття
Після усунення та перевірки дефекту статус дефекту змінюється на закрито. Якщо ні, ви повинні надіслати сповіщення розробці, щоб повторно перевірити дефект.
Крок 6) Звіт про дефект
Звіт про дефекти у тестуванні програмного забезпечення – це процес, у якому керівники тестування готують і надсилають звіт про дефекти команді керування для отримання зворотного зв’язку щодо процесу керування дефектами та статусу дефектів. Потім команда управління перевіряє звіт про дефект і надсилає відгук або надає додаткову підтримку, якщо потрібно. Звітування про дефекти допомагає краще спілкуватися, відстежувати та детально пояснювати дефекти.
Правління має право знати статус дефекту. Вони повинні розуміти процес управління дефектами, щоб підтримати вас у цьому проекті. Тому ви повинні повідомити їм про поточну ситуацію з дефектом, щоб отримати від них зворотній зв’язок.
Навіщо потрібен процес управління дефектами?
Ваша команда виявила помилки під час тестування проекту Guru99 Banking.
Через тиждень розробник відповідає –
Наступного тижня тестер відповідає
Як і в наведеному вище випадку, якщо дефектне спілкування відбувається усно, незабаром усе стає дуже складним. Для контролю та ефективного керування помилками вам потрібен життєвий цикл дефектів.
Важливі показники дефектів
Поверніть наведений вище сценарій. Команди розробників і тестувальників перевіряють повідомлені дефекти. Ось результат цієї дискусії
Як виміряти та оцінити якість виконання тесту?
Це питання, яке задає кожен Менеджер випробувань хоче знати. Є 2 параметри, які можна розглядати як наведені нижче
У наведеному вище сценарії ви можете обчислити коефіцієнт браку дефектів (DRR) є 20/84 = 0.238 (23.8 %).
Ще один приклад, припущення, що веб-сайт банку Guru99 має загальну суму 64 дефекти, але ваша команда тестування лише виявляє 44 дефекти, тобто вони пропущені 20 дефекти. Таким чином, ви можете обчислити коефіцієнт витоку дефектів (DLR) 20/64 = 0.312 (31.2%).
Висновок, якість виконання тесту оцінюється за двома параметрами
Чим менше значення DRR і DLR, тим краще якість виконання тесту. Який діапазон співвідношення прийнятний? Цей діапазон можна визначити та прийняти як основу в цільовому проекті або ви можете звернутися до показників подібних проектів.
У цьому проекті рекомендоване значення прийнятного співвідношення становить 5 ~ 10%. Це означає низьку якість виконання тесту. Ви повинні знайти контрзаходи, щоб зменшити ці співвідношення, наприклад
- Покращувати тестування навичок члена.
- Витрачайте більше часу для виконання тестування, особливо для перегляду результатів виконання тесту.
Питання і відповіді
Натисніть тут якщо відео недоступне
Ресурси:
Завантажте зразок шаблону звіту про дефекти
