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

Автор: Томас Гамільтон Томас Гамільтон
Hours оновлений
Ключові винесення У цьому посібнику пояснюються етапи життєвого циклу дефектів, допомагаючи читачам зрозуміти відстеження помилок, процес комунікації та ефективне вирішення проблем від виявлення до їх закриття.

Життєвий цикл дефекту/помилки

Що таке життєвий цикл дефекту/помилки?

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

Статус дефекту

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

Робочий процес станів дефектів

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

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

Робочий процес станів дефектів

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

СТАТТІ ПО ТЕМІ

Пояснення життєвого циклу дефекту/помилки

Життєвий цикл дефекту чи життєвого циклу помилки – речі, які ви повинні знати!

  1. Тестер виявляє дефект
  2. Дефекту присвоєно статус - Новий
  3. Дефект передається керівнику проекту для аналізу
  4. Керівник проекту вирішує, чи є дефект дійсним
  5. Тут дефект недійсний – надається статус «Відхилено».
  6. Отже, менеджер проекту присвоює статус відхилені. Якщо дефект не відхилено, наступним кроком є ​​перевірка, чи він знаходиться в межах. Припустімо, що ми маємо іншу функцію – функцію електронної пошти для тієї самої програми, і ви виявили проблему з нею. Але це не є частиною поточного випуску, коли такі дефекти призначаються як a відкладено або відкладено Статус.
  7. Далі менеджер перевіряє, чи був подібний дефект раніше. Якщо так, дефекту присвоюється статус дублювати.
  8. Якщо ні, дефект призначається розробнику, який починає виправляти код. На цьому етапі дефекту присвоюється статус в процесі.
  9. Як тільки код буде виправлено. Дефекту присвоюється статус фіксованою
  10. Далі тестер повторно перевірить код. У випадку, Тестовий випадок проходить дефект є closed. Якщо тестові випадки знову зазнають невдачі, дефект є знову відкрили і передано розробнику.
  11. Розглянемо ситуацію, коли під час першого випуску Flight Reservation у замовленні факсу було виявлено дефект, який було виправлено та присвоєно статус закрито. Під час другого випуску оновлення той самий дефект знову з’явився. У таких випадках буде закритий дефект знову відкрито.

Це все, що стосується життєвого циклу помилок

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

 

Натисніть тут якщо відео недоступне

Поширені запитання

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

  • Новий/Відкритий – Дефект виявлено та зафіксовано.
  • Призначений – Його передають розробнику для виправлення.
  • Виправлено/Вирішено – Розробник застосовує рішення.
  • Повторне тестування/перевірка – Тестери підтверджують виправлення.
  • Закрито – Дефект підтверджено усунутим, або Відновлено якщо це триватиме.

Життєвий цикл дефекту (також званий життєвий цикл клопа) Є серія сходинок Дефект проходить під час тестування: виявлення, реєстрація, призначення, виправлення, повторне тестування та закриття. Це забезпечує систематичне відстеження та покращує якість програмного забезпечення в усіх командах. Такий систематичний підхід гарантує підзвітність, прозорість та кращу якість надання програмного забезпечення. Уявіть собі це як світлофор для дефектів — кожен знає, коли зупинитися, коли йти або перевірити ще раз.

Для управління життєвим циклом дефектів доступні різні інструменти, залежно від потреб проекту. Деякі з популярних варіантів: JIRA, Bugzilla, HP ALM, Redmine і MantisBTВони дозволяють командам реєструвати, призначати та відстежувати дефекти. JIRA є найбільш широко використовуваною в Agile та обговореннях на співбесідах.

In ДЖИРА, життєвий цикл дефектів керується за допомогою налаштовуваних статуси робочого процесуЗа замовчуванням він відображає стандартне відстеження дефектів, але команди часто його адаптують. Типовий цикл дефектів JIRA виглядає так:

  • Зробити / Відкрити – Зафіксовано дефект.
  • В Процесі – Розробник починає виправляти.
  • Вирішено / Готово – Виправлення застосовано, очікується підтвердження тестувальником.
  • Відновлено – Якщо виправлення не вдається, дефект повертається до активного стану.
  • Закрито – Перевірено тестерами та позначено як завершене.

Терміни «життєвий цикл помилки» та «життєвий цикл дефекту» часто використовуються як взаємозамінні, але деякі фахівці проводять тонку різницю:

  • Життєвий цикл помилок – Зазвичай використовується в технічному контексті, стосуючись проблем у коді, які спричиняють несправність.
  • Життєвий цикл дефекту – Ширший за обсягом, що охоплює відхилення від вимог, які можуть бути пов’язані з кодуванням, а можуть і не бути.

На практиці:

  • Помилка = Помилка програмування.
  • Дефект = Будь-який розрив між очікуваними та фактичними результатами (може бути пов'язаний з проектуванням, вимогами або процесом).

Тим не менш, цикли однакові: виявлено → виправлено → перевірено → закрито.

Ось переваги життєвого циклу дефекту:

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

Підсумки

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