Меню

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

  • Головна
  • Інший
  • Процес управління дефектами: як ефективно управляти дефектом

defect management process

Спробуйте Наш Інструмент Для Усунення Проблем

Вступ до процесу управління дефектами:

Більш цілеспрямований процес та тестування дозволять на ринку отримувати менше програмного забезпечення, що глючить.

Запобігання дефектам набагато ефективніше і ефективніше зменшує кількість дефектів, а також дуже економічно виправляє дефекти, виявлені на ранній стадії програмного процесу. Більшість організацій проводять Виявлення дефектів , Видалення дефектів і потім Поліпшення процесу який в сукупності відомий як Процес управління дефектами .

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

найкраще шпигунське програмне забезпечення для мобільних телефонів Android

Що ви дізнаєтесь:

Цілі процесу управління дефектами (DMP)

Нижче наведено різні цілі цього процесу:

  • Запобігання дефекту
  • Раннє виявлення
  • Мінімізуйте вплив
  • Дозвіл дефекту
  • Поліпшення процесу

Перш ніж вивчати процес управління дефектами, давайте спочатку розберемося що насправді є дефектом чи помилкою?

Життєвий цикл управління дефектами

Коли система дає інший результат, відмінний від фактичної вимоги бізнесу, тобто коли є відхилення від фактичної або початкової вимоги бізнесу, тоді можна сказати, що в системі / програмному забезпеченні є дефект.

Коли команда тестування виконує тестові кейси, вони стикаються з ситуацією, коли фактичний результат тесту відрізняється від очікуваного. Ця варіація називається a Дефект .

В основному, дефект програмного забезпечення - це умова, яка не відповідає вимогам програмного забезпечення. Дефект - це помилка або недолік, що спричиняє несподівану або неправильну поведінку в системі.

Щоб адекватно обробляти проекти, потрібно знати, як боротися з розробкою та випуском, але поряд з цим потрібно знати, як обробляти дефекти.

Тільки уявіть, що буде, якщо команда тестування повідомить про дефекти усно, а команда розробників також оновить статус дефекту усно? Процес буде більш складним, оскільки ці дефекти включають усі дефекти, такі як фактично виправлені та працюють, як очікувалось, виправлені, але все ще не працюють, відхилені, відкладені, і процес триває.

У наведеному вище випадку, оскільки кількість дефектів збільшується, а спілкування здійснюється усно, ситуація найближчим часом буде найгіршою. Для ефективного контролю та усунення дефекту вам потрібен належний життєвий цикл дефектів.

Життєвий цикл дефектів забезпечує рівномірність та стандартизацію процесу. Дефект досягає різних станів у життєвому циклі. Після виявлення дефекту протягом свого життя він проходить різні стадії, і його зазвичай називають Життєвий цикл дефектів .

Як правило, життєвий цикл дефекту починається з того етапу, коли дефект виявляється або піднімається командою тестування, і закінчується, коли дефект закривається, гарантуючи, що він не відтворюється або відхилений командою розробників. Кількість станів, через які проходить дефект, залежить від проекту.

Подальше читання:

Що таке життєвий цикл дефектів / помилок при тестуванні програмного забезпечення? Підручник з життєвого циклу дефектів

Примітка: Нижче цикл трохи відрізняється від організації до організації.

Наведений нижче життєвий цикл дефекту охоплює всі можливі стани:

Блок-схема життєвого циклу дефектів

  • Коли команда тестування виявляє дефект у заявці, вона піднімає дефект із статусом ' НОВЕ '.
  • Коли новий дефект перевіряється проводом контролю якості та, якщо дефект дійсний, статус дефекту буде ' відчинено »І воно готове до передачі команді розробників.
  • Коли провідник якості присвоює дефект відповідному розробнику, статус дефекту буде позначений як “ Призначений '. На цьому етапі розробник повинен почати аналіз та виправлення дефекту.
  • Коли розробник відчуває, що дефект не є справжнім або дійсним, тоді розробник відхиляє дефект. Статус дефекту позначений як “ Відхилено ”І призначений назад до групи тестувань.
  • Якщо зареєстрований дефект повторюється двічі або обидва дефекти, про які повідомляється, мають однакові результати та етапи відтворення, тоді один дефект змінюється на “ Дублікат '.
  • Якщо в поточному випуску є деякі проблеми або перешкоди для виправлення певного дефекту, тоді дефект буде взятий у майбутніх випусках замість поточного випуску, а потім він позначений як “ Відкладено ”Або“ Відкладено '.
  • Коли розробник не може відтворити дефект за допомогою кроків, зазначених командою тестування в розділі «Кроки до відтворення», тоді розробник може позначити дефект як « Не відтворюється ” . На цьому етапі команда тестування повинна надати розробнику детальні кроки відтворення.
  • Якщо розробнику невідомо про етапи відтворення, передбачені QA для відтворення дефекту, він / вона може позначити його як “ Потрібна додаткова інформація '. У цьому випадку команда тестування повинна надати необхідну інформацію команді розробників.
  • Якщо дефект вже відомий і в даний час присутній у виробничому середовищі, то дефект позначається як “ Відомий дефект '.
  • Коли розробник вносить необхідні зміни, тоді дефект позначається як « Виправлено '.
  • Тепер розробник передає дефект команді тестувальників для перевірки, тому розробник змінює статус як “ Готовий до повторного тестування '.
  • Якщо дефект не має подальших проблем, і він був належним чином перевірений, тоді тестер позначає дефект як “ зачинено '.
  • Під час повторного тестування дефекту, якщо випробувач виявив, що дефект все ще відтворюється або частково виправлений, тоді дефект буде позначений як « Відкрито знову '. Тепер розробник повинен ще раз розглянути цей дефект.

Добре спланований та контрольований життєвий цикл дефектів дає загальну кількість дефектів, виявлених у випуску або у всіх випусках. Цей стандартизований процес дає чітке уявлення про те, як був написаний код, наскільки правильно було проведено тестування, як було випущено дефект або програмне забезпечення тощо. Це зменшить кількість дефектів у виробництві, виявивши дефекти під час тестування сама фаза.

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

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

Процес управління дефектами детально пояснюється нижче.

# 1) Запобігання дефектам:

Запобігання дефектам є найкращим методом усунення дефектів на ранній стадії тестування, а не виявлення дефектів на пізнішому етапі, а потім їх усунення. Цей метод також економічно вигідний, оскільки витрати, необхідні для усунення дефектів, виявлених на ранніх стадіях випробувань, дуже низькі.

Однак неможливо усунути всі дефекти, але принаймні ви можете мінімізувати вплив дефекту та витрати на їх усунення.

Основними етапами запобігання дефектам є наступні:

  • Визначте критичний ризик : Визначте критичні ризики в системі, які матимуть більший вплив, якщо це відбудеться під час тестування або на пізній стадії.
  • Оцініть очікуваний вплив : Для кожного критичного ризику підрахуйте, яким буде фінансовий вплив, якщо ризик насправді зіткнеться.
  • Мінімізуйте очікуваний вплив : Визначивши всі критичні ризики, візьміть на себе найвищі ризики, які можуть нашкодити системі у разі виникнення, і спробуйте мінімізувати або усунути ризик. Для ризиків, які неможливо усунути, це зменшує ймовірність виникнення та їх фінансовий вплив.

# 2) Результат базового рівня:

Коли результат (система, продукт або документ) досягає заздалегідь визначеного етапу, тоді можна сказати, що результат - це базовий рівень У цьому процесі продукт або результат переходить з однієї стадії на іншу, і в міру того, як поставляється з однієї стадії на іншу, наявні дефекти в системі також переносяться на наступний етап або етап.

Наприклад, розглянемо сценарій кодування, модульного тестування, а потім системного тестування. Якщо розробник виконує кодування та модульне тестування, тоді тестування системи проводить команда тестування. Тут кодування та модульне тестування є однією віхою, а тестування системи - іншою віхою.

Отже, під час модульного тестування, якщо розробник виявляє деякі проблеми, це не називається дефектом, оскільки ці проблеми визначаються до закінчення граничного терміну. Після завершення кодування та модульного тестування розробник передає код для тестування системи, і тоді ви можете сказати, що код “Базовий” і готовий до наступного етапу, тут, у цьому випадку, це “тестування системи”.

Тепер, якщо проблеми виявлені під час тестування, це називається дефектом, оскільки він виявляється після завершення попереднього етапу, тобто кодування та модульного тестування.

В основному результати є базовими, коли зміни в результатах завершуються, а всі можливі дефекти виявляються та виправляються. Потім той самий результат передається наступній групі, яка буде над ним працювати.

# 3) Виявлення дефектів:

Видалити всі дефекти з системи і зробити систему бездефектною практично неможливо. Але виявити дефекти можна раніше, ніж вони стануть дорожчими для проекту. Можна сказати, що виявлений дефект означає, що він був офіційно доведений до відома команди розробників, і після аналізу цього команда розробників дефектів також прийняла його як дефект.

Етапи, пов’язані з виявленням дефектів, такі:

  • Знайдіть дефект : Виявити дефекти до того, як вони стануть головною проблемою системи.
  • Повідомте про дефект : Як тільки команда тестування виявить дефект, їх відповідальність полягає в тому, щоб повідомити команду розробників про те, що є виявлена ​​проблема, яку потрібно проаналізувати та виправити.
  • Визнати дефект : Після того, як команда тестування призначить дефект команді розробників, його команда розробників зобов’язана визнати дефект і продовжити його виправлення, якщо це дійсний дефект.

# 4) Вирішення дефектів:

У вищезазначеному процесі команда тестування виявила дефект і повідомила команду розробників. Тепер тут команді розробників потрібно приступити до вирішення дефекту.

Етапи вирішення дефекту такі:

  • Розмістіть пріоритет ризику : Команда розробників аналізує дефект і надає пріоритет усуненню дефекту. Якщо дефект має більший вплив на систему, тоді вони роблять виправлення дефекту високим пріоритетом.
  • Виправити дефект : На основі пріоритету команда розробників виправляє дефект, дефекти вищого пріоритету вирішуються першими, а дефекти нижчого пріоритету виправляються в кінці.
  • Повідомте про резолюцію : Команда розробників несе відповідальність за те, щоб команда тестування знала, коли дефекти збираються виправити, і як дефект був виправлений, тобто шляхом зміни одного з файлів конфігурації або внесення деяких змін у код. Це буде корисно для групи випробувачів, щоб зрозуміти причину дефекту.

# 5) Удосконалення процесу:

Хоча в процесі усунення дефектів дефекти мають пріоритети та виправляються, з точки зору процесу, це не означає, що дефекти нижчого пріоритету не важливі і не сильно впливають на систему. З точки зору вдосконалення процесу, всі виявлені дефекти є однаковими як критичні дефекти.

Навіть ці незначні дефекти дають можливість навчитися вдосконалювати процес та запобігати появі будь-яких дефектів, які можуть вплинути на вихід з ладу системи в майбутньому. Виявлення дефекту, що має менший вплив на систему, може бути не великою проблемою, але виникнення такого дефекту в самій системі - велика проблема.

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

Висновок

Процесу управління дефектами слід дотримуватися під час загального процесу розробки програмного забезпечення, а не лише для конкретних заходів тестування або розробки.

c та c ++ різниця

Якщо дефект виявлений на етапі тестування, то можна поставити питання про те, що якщо дефект буде виявлений на цій фазі, то як бути з іншими дефектами, які є в системі, що може спричинити збій системи, якщо він виникає і ще не виявлений.

Отже, усі процеси, такі як процес перевірки, статичне тестування, перевірка тощо, повинні посилюватися, і всі учасники проекту повинні серйозно ставитися до цього процесу та сприяти там, де це необхідно. Вищий керівник організації також повинен розуміти і підтримувати процес управління дефектами.

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

Сподіваюся, ця інформативна стаття про Процес управління дефектами дуже вам допоможе.

Рекомендована література

^