Процес управління дефектами в тестуванні програмного забезпечення
Томас Гамільтон
⚡ Розумний підсумок
Процес управління дефектами в тестуванні програмного забезпечення – це структурована структура для виявлення, категоризації, вирішення, перевірки, закриття та звітування про помилки. Вона забезпечує передбачувану комунікацію між тестувальниками та розробниками, покращує якість релізу та зменшує кількість виходів на рівень виробництва протягом життєвого циклу проекту.
Що таке процес управління дефектами?
Команда Процес управління дефектами – це систематичний підхід, що використовується в тестуванні програмного забезпечення для виявлення, класифікації, виправлення та перевірки помилок перед випуском програмного забезпечення. Життєвий цикл включає шість основних етапів: 1) Виявлення дефекту, 2) Категоризація, 3) Вирішення розробниками, 4) Перевірка тестувальниками, 5) Закриття та 6) Звітування про дефекти в кінці проекту.
У цій статті пояснюється, як застосовувати процес управління дефектами за допомогою GuruПриклад веб-сайту банку 99, щоб початківці та тестувальники середнього рівня могли зрозуміти кожен крок у реальному контексті проекту.
Навіщо потрібен процес управління дефектами?
Уявіть, що ваша команда виявила кілька помилок під час тестування Guru99 Банківський проект. Без структурованого процесу спілкування між тестувальниками та розробниками відбувається усно або через розрізнені повідомлення.
Через тиждень розробник відповідає з іншим розумінням проблеми.
Наступного тижня тестер відповідає знову, що створює ще більше плутанини.
Коли повідомлення про дефекти здійснюється усно або неформально, все дуже швидко ускладнюється. Щоб контролювати та ефективно керувати помилками, потрібен визначений життєвий цикл дефектів, який стандартизує спосіб звітності команд, track, і закрити питання.
Крок 1) Відкриття
Перейдіть на вкладку Відкриття На цьому етапі команда проекту повинна виявити якомога більше дефектів, перш ніж кінцевий клієнт зіткнеться з ними. Дефект вважається «виявленим», як тільки його визнає та приймає команда розробників, після чого його статус змінюється на Прийняті.
У наведеному прикладі тестувальники виявили 84 дефекти на GuruВебсайт банку 99.
Однак, тестувальники та розробники не завжди погоджуються. Розглянемо наступний випадок, у якому команда тестувальників виявляє проблеми на Guru99 веб-сайт банку та повідомляє про них, але команда розробників заперечує, чи є вони дефектами:
У такому випадку, як менеджер тестування, що вам слід робити?
A) Погодьтеся з командою тестування, що це дефект.
Б) Візьміть на себе роль судді та вирішіть, чи є проблема дефектом чи ні.
C) Погодьтеся з командою розробників, що це не є дефектом.
Правильний підхід – варіант B. Для вирішення конфлікту слід застосувати процес вирішення, а менеджер тестування повинен неупереджено оцінити проблему, перш ніж вирішити, чи кваліфікується вона як дефект.
Крок 2) Категоризація
Категоризація дефектів допомагає розробникам розставляти пріоритети у своїй роботі, щоб першими виправляти найважливіші для бізнесу проблеми. Категоризацію зазвичай виконує менеджер з тестування та вона базується на серйозності та впливі на бізнес.
Дефекти зазвичай групуються за чотирма рівнями пріоритетності: Критичний, високий, середній та низькийСпробуйте призначити правильний пріоритет кожному з наступних дефектів:
- Продуктивність веб-сайту занадто повільна.
- Функція входу на веб-сайт працює неправильно.
- Графічний інтерфейс веб-сайту відображається неправильно на мобільний пристроїв.
- Вебсайт не може запам'ятати сеанс входу користувача.
- Деякі посилання не працюють.
Ось рекомендовані відповіді:
| Ні. | Опис | Пріоритет | Пояснення |
|---|---|---|---|
| 1 | Веб-сайт працює надто повільно | Високий | Проблеми з продуктивністю завдають значних незручностей кінцевим користувачам. |
| 2 | Функція входу працює неправильно | Критичний | Вхід – це основна функція банківського веб-сайту. Якщо він не вдається, весь шлях користувача блокується. |
| 3 | Графічний інтерфейс користувача відображається неправильно на мобільних пристроях | Medium | Дефект впливає на користувачів, які переглядають веб-сайт на смартфонах. |
| 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%Поточне виконання виходить за межі цього діапазону, що сигналізує про необхідність покращення якості тестування за допомогою таких заходів:
- Покращувати навички тестування членів команди.
- Витрачайте більше часу на виконання тестів, особливо під час перегляду результатів виконання.
Найкращі практики для ефективного управління дефектами
Дотримання структурованих найкращих практик відрізняє зрілий процес управління дефектами від хаотичного. Мета полягає не лише у виправленні помилок, а й у створенні системи, яка запобігає їхньому потраплянню у продакшн та мінімізує збої у зв'язку між тестувальниками та розробниками.
Ось найкращі практики, які варто негайно застосувати тестувальникам-початківцям і середньому рівні:
- Стандартизуйте шаблон дефекту: Використовуйте шаблон звіту про фіксовані дефекти, що містить такі поля, як ID дефекту, Descriptіон, кроки для відтворення, серйозність, пріоритет, середовище та вкладення. Узгодженість зменшує обмін даними між тестувальниками та розробниками.
- Розставте пріоритети перед призначенням: Завжди класифікуйте дефекти за серйозністю та пріоритетом, перш ніж надсилати їх розробникам. Це гарантує, що критичні проблеми не застрягнуть за косметичними.
- Відтворити перед звітуванням: Відтворіть дефект щонайменше двічі на чистому середовищі, перш ніж піднімати його. Відтворювані дефекти швидше закриваються та зменшують коефіцієнт браку.
- Прийняти дефект tracкоролівський інструмент: Використовуйте такі інструменти, як ДЖИРА, Bugzillaабо Богомол централізувати tracкороль, історія та репортаж.
- Проводити зустрічі з сортування: Проводьте короткі, цілеспрямовані зустрічі з питань сортування дефектів, щоб узгодити пріоритети між командами контролю якості, розробки та розробки продукту.
- Вимірювання витоку та відхилення: Track DLR та DRR кожного спринту або циклу. Зростання коефіцієнта витоку є раннім попередженням про те, що охоплення тестуванням неповне.
- Виконайте аналіз першопричин: Для повторюваних або серйозних дефектів виконайте аналіз першопричини, щоб той самий клас помилок не повертався в майбутніх випусках.
- Замкніть цикл звітуванням: Діліться щотижневими інформаційними панелями дефектів із зацікавленими сторонами, щоб проблеми залишалися видимими та вирішуваними.
Застосовані послідовно, ці практики стабілізують життєвий цикл дефектів і підвищують загальну якість кожного релізу.
Ресурси:
Завантажте зразок шаблону звіту про дефекти
