Bugs

Технології засіву дефектів ПЗ (Software Faults Injection).

Що таке помилка та що таке дефект?

Баг/помилка є наслідком помилки кодування, у той час як дефект – це відхилення від початкових бізнес-вимог.

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

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

• Відкриття (Unit Testing)
• Присвоєння категорії (Integration Testing)
• Рішення (System Testing)
• Верифікація (Acceptance Testing)
• Закриття (Acceptance Testing)
• Складання звіту (Acceptance Testing)

Звіт про помилку

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

• Defect_ID – унікальний ідентифікаційний номер для дефекту.
• Опис дефекту – докладний опис дефекту, включаючи інформацію про модуль, у якому виявлено дефект.
• Версія – версія програми, в якій було виявлено дефект.
• Кроки – докладні кроки разом зі скріншотами, за допомогою яких розробник може відтворити дефекти.
• Дата підвищення – дата виникнення дефекту
• Посилання – де ви надати посилання на документи, як. вимоги, дизайн, архітектура або навіть скріншоти помилки, щоб допомогти зрозуміти дефект
• Виявлено – ім'я/ідентифікатор тестера, який виявив дефект
• Стан – стан дефекту, докладніше про це пізніше
• Виправлено – Ім'я / ID розробника, який це виправив
• Дата закриття – дата закриття дефекту
• Серйозність, яка описує вплив дефекту на додаток
• Пріоритет, пов'язаний із терміновістю усунення дефектів. Пріоритет серйозності може бути Високий/Середній/Низький залежно від терміновості впливу, при якій дефект має бути виправлений відповідно.

Відкриття

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

У такому випадку, як менеджер тестів, що ви робитимете?

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

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

Категорії помилок

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

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

• Високий – дефект негативно впливає основні функції продукту. Наприклад: продуктивність сайту надто низька.

• Середній – дефект вносить мінімальні відхилення від вимог до продукту. Наприклад: неправильно відображається інтерфейс на мобільних пристроях.

• Низький – мінімальний нефункціональний вплив на продукт. Наприклад, деякі посилання не працюють.

Рішення

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

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

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

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

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

Верифікація

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

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

Складання звітів

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

Це питання, яке хоче знати кожен менеджер у тестуванні. Є 2 параметри, які розглядаються таким чином:

• коефіцієнт відхилення браку (DRR)
• коефіцієнт витоку дефектів (DLR)