Управління дефектами (версія 3.1)
Оскільки однією з цілей тестування є виявлення дефектів, дефекти, виявлені під час тестування, слід реєструвати. Спосіб реєстрації дефектів може відрізнятися залежно від контексту компонента або системи, що тестується, рівня тестування та моделі життєвого циклу розробки програмного забезпечення. Будь-які виявлені дефекти слід досліджувати та відстежувати від виявлення та класифікації до їх усунення (наприклад, виправлення дефектів і успішне підтверджувальне тестування рішення, відкладення наступного релізу, прийняття як постійне обмеження продукту тощо). Для того, щоб керувати всіма дефектами до вирішення, організація повинна встановити процес управління дефектами, який включає робочий процес і правила класифікації. Цей процес має бути узгоджений з усіма, хто бере участь в управлінні дефектами, включаючи архітекторів, дизайнерів, розробників, тестувальників і власників продуктів. У деяких організаціях реєстрація дефектів і відстеження можуть бути дуже неформальними.
Під час процесу керування дефектами деякі звіти можуть описувати помилкові спрацьовування, а не фактичні збої через дефекти. Наприклад, тест може бути невдалим, якщо мережеве з’єднання розірвано або минув час очікування. Така поведінка не є результатом дефекту тестового об’єкта, а є аномалією, яку необхідно дослідити. Тестери повинні намагатися звести до мінімуму кількість помилкових спрацьовувань, про які повідомляється як про дефекти.
Про дефекти можна повідомляти під час кодування, статичного аналізу, оглядів або під час динамічного тестування чи використання програмного продукту. Про дефекти можна повідомити через проблеми в коді чи робочих системах або в будь-якій документації, включаючи вимоги, історії користувачів і критерії прийнятності, документи розробки, тестові документи, посібники користувача або посібники зі встановлення. Щоб мати дієвий і ефективний процес управління дефектами, організації можуть визначити стандарти для атрибутів, класифікації та робочого процесу дефектів.
Типові звіти про дефекти мають такі цілі:
- Надайте розробникам та іншим сторонам інформацію про будь-яку несприятливу подію, що сталася, щоб вони могли визначити конкретні наслідки, ізолювати проблему за допомогою мінімального відтворювального тесту та виправити потенційний дефект за потреби або іншим чином вирішити проблему
- Надайте менеджерам тестування засоби відстеження якості робочого продукту та впливу на тестування (наприклад, якщо повідомляється про багато дефектів, тестувальники витрачатимуть багато часу на звітування про них замість того, щоб запускати тести, і буде потрібно більше підтверджуючих тестувань)
- Надати ідеї для розробки та вдосконалення процесу тестування
Звіт про дефект, поданий під час динамічного тестування, зазвичай містить:
- Ідентифікатор
- Назва та короткий опис дефекту, про який повідомляється
- Дата звіту про дефект, організація, та автор
- Ідентифікація тестового елемента (елемента конфігурації, що тестується) і середовища
- Фаза життєвого циклу розробки, на якій спостерігався дефект
- Опис дефекту, щоб зробити можливим відтворення та вирішення, включаючи журнали, дампи бази даних, знімки екрана або записи (якщо їх виявлено під час виконання тесту)
- Очікувані та фактичні результати
- Масштаб або ступінь впливу (серйозності) дефекту на інтереси зацікавлених сторін
- Терміновість/пріоритет виправлення
- Стан звіту про дефект (наприклад, відкрито, відкладено, дублікат, очікує на виправлення, очікує тестування підтвердження, повторно відкрито, закрито)
- Висновки, рекомендації та схвалення
- Глобальні проблеми, наприклад інші області, на які можуть вплинути зміни внаслідок дефекту
- Історія змін, як-от послідовність дій, виконаних членами команди проєкту щодо дефекту, щоб ізолювати, виправити та підтвердити його як виправлений
- Посилання, включаючи тест кейс, який виявив проблему
Деякі з цих деталей можуть бути автоматично включені або керовані під час використання інструментів управління дефектами, наприклад, автоматичне призначення ідентифікатора, призначення та оновлення стану звіту про дефекти під час робочого процесу тощо. Дефекти, виявлені під час статичного тестування, зокрема переглядів, зазвичай документуються в інший спосіб, наприклад, у примітках до наради з перегляду.
Приклад змісту звіту про дефект можна знайти в стандарті ISO (ISO/IEC/IEEE 29119-3), де звіти про дефекти називаються звітами про інциденти.
Управління дефектами (версія 4.0)
Оскільки однією з основних цілей тестування є виявлення дефектів, налагоджений процес управління дефектами має важливе значення. Незважаючи на те, що тут ми говоримо про «дефекти», повідомлені аномалії можуть виявитися справжніми дефектами або чимось іншим (наприклад, помилковим спрацьовуванням, запитом на зміну) — це вирішується під час обробки звітів про дефекти. Про аномалії можна повідомити на будь-якому етапі SDLC, а форма залежить від SDLC. Як мінімум, процес управління дефектами включає робочий процес для обробки окремих аномалій від їх виявлення до їх закриття та правила для їх класифікації. Робочий процес, як правило, включає дії з реєстрації повідомлених аномалій, їх аналізу та класифікації, прийняття рішення щодо належної відповіді, як-от виправити чи залишити все як є, і, нарешті, закрити звіт про дефекти. За цим процесом повинні стежити всі зацікавлені сторони. Бажано обробляти дефекти статичного тестування (особливо статичного аналізу) подібним чином.
Типові звіти про дефекти мають такі цілі:
- Надати особам, відповідальним за обробку та усунення повідомлених дефектів, достатньо інформації для вирішення проблеми
- Забезпечити засоби відстеження якості робочого продукту
- Надати ідеї щодо вдосконалення розробки та процес тестування
Звіт про дефект, який реєструється під час динамічного тестування, зазвичай містить:
- Унікальний ідентифікатор
- Назва з коротким описом аномалії, про яку повідомляється
- Дата, коли була помічена аномалія, організація, та автор, включаючи роль
- Ідентифікація тестового об’єкта та тестового середовища
- Контекст дефекту (наприклад, тестовий кейс, що виконується, тестова діяльність, фаза SDLC та інша відповідна інформація, така як методика тестування, контрольний список або тестові дані, що використовуються)
- Опис збою, щоб уможливити відтворення та вирішення, включаючи кроки, які виявили аномалію, а також будь-які відповідні журнали тестування, дампи бази даних, знімки екрана або записи
- Очікувані та фактичні результати
- Серйозність дефекту (ступінь впливу) на інтереси зацікавлених сторін або вимоги
- Пріоритет виправлення
- Статус дефекту (наприклад, відкрито, відкладено, дублікат, очікує на виправлення, очікує перевірки підтвердження, повторно відкрито, закрито, відхилено)
- Посилання (наприклад, на тестовий приклад)
Деякі з цих даних можуть автоматично включатися під час використання інструментів керування дефектами (наприклад, ідентифікатор, дата, автор і початковий статус). Шаблони документів для звіту про дефекти та приклади звітів про дефекти можна знайти в стандарті ISO/IEC/IEEE 29119-3, де звіти про дефекти називаються звітами про інциденти.
В цьому відео починаємо працювати з секцію 5.6.
00:00:54 Defect Management
00:08:50 Defect reporting
00:13:19 Defect Report