Меню

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

what is defect bug life cycle software testing

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

Вступ до життєвого циклу дефектів

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

Я також додав найпоширеніші запитання щодо інтерв’ю щодо життєвого циклу дефектів. Це важливо знати про різні стани дефекту для розуміння життєвого циклу дефекту. Основний намір проведення тестової діяльності - перевірити, чи є у продукту проблеми / помилки.

Підручник з життєвого циклу дефектів

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

Тепер виникає питання про те, що таке Дефект?

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

Що таке дефект?

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

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

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

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

Отже, давайте дізнаємось більше про життєвий цикл дефектів.

Наразі ми обговорювали значення дефекту та його зв’язок у контексті тестової діяльності. Тепер перейдемо до життєвого циклу дефекту та зрозуміємо робочий процес дефекту та різні стани дефекту.

Детальний життєвий цикл

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

Процес дефектів

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

Життєвий цикл дефектів

Дефекти

# 1) Новий :Це перший стан дефекту в життєвому циклі дефектів. Коли виявляється будь-який новий дефект, він потрапляє в стан «Новий», і перевірка та тестування виконуються на цьому дефекті на пізніх стадіях життєвого циклу дефекту.

# 2) Призначено: На цьому етапі новостворений дефект призначається команді розробників для роботи над дефектом. Це призначається керівником проекту або менеджером групи тестування розробнику.

# 3) Відкритий: Тут розробник запускає процес аналізу дефекту та за потреби працює над його виправленням. Якщо розробник вважає, що дефект невідповідний, він може бути перенесений у будь-який із наведених нижче чотирьох штатів, а саме Повторюване, відкладене, відхилене чи не помилка -на основі конкретної причини.

Я трохи обговорю ці чотири стани.

# 4) Виправлено: Коли розробник закінчить завдання виправити дефект шляхом внесення необхідних змін, він може позначити статус дефекту як «Виправлений».

як зробити підроблені облікові записи електронної пошти

# 5) Очікує повторного тестування: Після виправлення дефекту розробник призначає дефект тестувальнику для повторного тестування дефекту в їх кінці, і поки тестер не працює над тестуванням дефекту, стан дефекту залишається в «Очікує повторного тестування».

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

# 7) Повторно відкрити: Якщо якась проблема не зникає з дефектом, вона буде призначена розробнику знову для тестування, а статус дефекту змінено на «Відкрити повторно».

# 8) Перевірено: Якщо тестер не виявив жодної проблеми у дефекті після призначення розробнику для повторного тестування, і він відчуває, що якщо дефект був виправлений точно, то статус дефекту призначається 'Перевірено'.

# 9) Закрито: Коли дефект більше не існує, тестер змінює статус дефекту на «Закритий».

Дещо більше:

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

обов'язкові поля коли тестер реєструє будь-яку нову помилку, це версія збірки, надсилання, продукт, модуль, серйозність, конспект та опис для відтворення

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

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

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

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

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

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

Коли помилка буде призначена розробнику, і він / вона може почати над нею працювати. Розробник може встановити статус помилки як не виправити, Не вдалося відтворити, Потрібна додаткова інформація або Виправлено.

Якщо статус помилки, встановлений розробником, є «Потрібна додаткова інформація» або Виправлено, тоді QA відповідає конкретною дією. Якщо помилка виправлена, QA перевіряє помилку і може встановити статус помилки як перевірений закритим або повторно відкритим.

Вказівки щодо впровадження життєвого циклу дефектів

Деякі важливі рекомендації можна прийняти перед початком роботи з життєвим циклом дефектів.

Вони такі:

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

Далі, обговоримо питання співбесіди на основі життєвого циклу дефектів.

Важливі запитання та відповіді на запитання щодо життєвого циклу помилок

Q # 1) Що таке дефект у перспективі тестування програмного забезпечення?

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

Питання 2) Яка основна різниця між помилками, дефектами та помилками?

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

Дефект: Якщо тестери виявляють невідповідність фактичної та очікуваної поведінки програми на етапі тестування, вони називають її Дефектом.

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

Q # 3) Який статус дефекту, коли він був спочатку виявлений?

Відповідь: Коли виявляється новий дефект, він перебуває у стані 'Новий'. Це початковий стан нещодавно знайденого дефекту.

Q # 4) Які різні стани дефекту у життєвому циклі дефекту, коли дефект схвалений та виправлений розробником?

Відповідь: У даному випадку різні стани дефекту: Новий, Присвоєний, Відкритий, Виправлений, Очікує на повторне тестування, Перевірка, Перевірка та Закриття.

Q # 5) Що станеться, якщо тестувальник все ще виявить проблему в дефекті, виправленому розробником?

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

Q # 6) Що таке продуктивний дефект?

Відповідь: Дефект, який повторюється неодноразово при кожному виконанні, і кроки якого можна фіксувати при кожному виконанні, тоді такий дефект називається «продуктивним» дефектом.

Q # 7) Який тип дефекту є невідтворюваним дефектом?

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

Q # 8) Що таке звіт про дефект?

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

Q # 9) Які деталі містяться у звіті про дефекти?

відкрити файл .apk у вікні

Відповідь: Звіт про дефект складається з таких деталей:

Ідентифікатор дефекту, Опис дефекту, Назва функції, Назва тестового випадку, Відтворюваний дефект чи ні, Статус дефекту, Тяжкість та Пріоритет дефекту, Ім'я тестувальника, Дата тестування дефекту, Версія збірки, в якій виявлено дефект .

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

Q # 10) Коли дефект змінюється на 'відкладений' стан у життєвому циклі дефекту?

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

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

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

Держави дефекту

S.No. Початковий стан Повернута держава Держава підтвердження
1Зберіть інформацію про особу, відповідальну за відтворення ДефектуДефект відхиляється або просять отримати додаткову інформаціюДефект виправлений, його слід перевірити та закрити
дваШтати відкриті або новіШтати відхиляються або роз'яснення.Штати вирішені та перевірка.

Недійсний та продубльований звіт про дефекти

  • Іноді виникає дефект не через код, а через тестове середовище або непорозуміння, такий звіт слід закрити як Недійсний дефект.
  • У випадку дубліката звіту один зберігається, а другий закривається як дублікат. Деякі недійсні звіти приймаються менеджером.
  • Менеджеру випробувань належить загальне управління дефектами та процес, а міжфункціональна група інструментів управління дефектами, як правило, відповідає за управління звітами.
  • Серед учасників - керівник випробувань, розробники, прем'єр-міністр, керівник виробництва та інші зацікавлені сторони, які зацікавлені.
  • Комітет з управління дефектами повинен визначити дійсність кожного дефекту та визначити, коли його виправляти чи відкладати. Щоб визначити це, враховуйте вартість, ризики та вигоду від усунення дефекту.
  • Якщо дефект повинен бути виправлений, слід визначити його пріоритет.

Дані про дефекти

  • Ім'я особи.
  • Тип тестування
  • Підсумок проблеми
  • Детальний опис дефекту.
  • Кроки до відтворення
  • Фаза життєвого циклу
  • Робочий продукт, де був представлений Defect.
  • Серйозність та пріоритетність
  • Підсистема або компонент, де вводиться дефект.
  • Діяльність за проектом, що виникає при введенні дефекту.
  • Метод ідентифікації
  • Тип дефекту
  • Проект і продукт, у якому існує проблема
  • Поточний власник
  • Поточний стан звіту
  • Продукт роботи, де стався дефект.
  • Вплив на проект
  • Ризик, втрата, можливість та переваги, пов’язані з виправленням або не усуненням дефекту.
  • Дати, коли відбуваються різні фази життєвого циклу дефекту.
  • Опис способу усунення дефекту та рекомендації для тестування.
  • Список літератури

Можливість процесу

  • Інформація про введення, виявлення та видалення -> Покращення виявлення дефектів та вартості якості.
  • Вступ -> Преторський аналіз процесу, при якому вводиться найбільша кількість дефектів для зменшення загальної кількості дефектів.
  • Інформація про корінь дефектів -> знайти підкреслені причини дефекту, щоб зменшити загальну кількість дефектів.
  • Інформація про дефекти -> Виконати кластерний аналіз.

Висновок

Це все про життєвий цикл та управління дефектами.

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

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

^