Month: March 2024

Тест-датасет (Test Data) – це набір даних, які використовуються для виконання тестів під час тестуванна ПЗ. Ці дані вводяться у тести для перевірки різних аспектів програмного продукту, таких як правильність роботи, відповідність вимогам, ефективність та інші характеристики. Тест-датасети можуть включати в себе різні види даних, такі як числа, рядки, дати, файли, зображення тощо, в залежності від конкретного тестового сценарію. Основні аспекти тест-датасетів:

Відповідність вимогам	Тест-датасети повинні відображати реальні умови використання програмного продукту та включати дані, які можуть виникнути в реальному середовищі.
Репрезентативність	Дані в тест-датасетах повинні бути достатньо репрезентативними, щоб враховувати різноманітність можливих сценаріїв використання.
Граничні значення	Тест-датасети часто включають в себе граничні значення, які перевіряють межі допустимих значень і можуть призвести до помилок.
Тестові сценарії	Кожен тестовий сценарій може вимагати власного тест-датасету, який відображає умови саме цього тесту.
Повторне використання	Тест-датасети можна використовувати повторно для різних тестів або в різних частинах тестового циклу.

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

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

Числові дані	◦ Цілі числа. ◦ Дійсні (з плаваючою комою) числа. ◦ Великі та малі значення для перевірки меж та роботи з екстремальними значеннями.
Рядкові дані	◦ Тексти різної довжини. ◦ Спеціальні символи та символи з різних алфавітів. ◦ Дані з пробілами або іншими спеціальними символами.
Дані дат та часу	◦ Дати з різних періодів (сьогодні, минуле, майбутнє). ◦ Різні формати дат та часу. ◦ Дані, які включають в себе зміну часового поясу або літній/зимовий час.
Дані для тестів граничних значень	Границі допустимих значень параметрів, межі допустимого діапазону.
Дані для тестів на введення	◦ Коректні дані, щоб перевірити правильність обробки валідних вхідних даних. ◦ Некоректні дані, щоб перевірити обробку невалідних вхідних даних.
Дані для тестів на функціональність	◦ Вхідні дані, що відображають різні сценарії використання продукту. ◦ Дані, які перевіряють взаємодію з іншими частинами системи.
Дані для тестів на продуктивність	◦ Великі обсяги даних для перевірки ефективності та завантажувальної здатності.
Дані для тестів безпеки	◦ Дані, що можуть викликати помилки безпеки (SQL-ін’єкції, переповнення буфера тощо). ◦ Дані для тестування доступу до обмежених ресурсів.
Дані для тестування інтерфейсів	Дані для введення через різні інтерфейси (веб, мобільний, API).
Дані для тестів на відновлення	Дані, які моделюють втрату з’єднання чи аварійне вимкнення системи.

Переваги

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

Реалістичність тестів	Тест-датасети можуть відображати реальні умови використання продукту, допомагаючи впевнитися, що тести проводяться в умовах, близьких до реального використання.
Покриття різноманітних сценаріїв	Тест-датасети дозволяють вам покривати різноманітні сценарії використання, включаючи граничні умови, неправильні вхідні дані та інші аспекти, що сприяє високій якості тестування.
Впевненість в правильності результатів	З використанням тест-датасетів можна більш впевнено стверджувати, що результати тестів є об’єктивними і релевантними для реального використання продукту.
Автоматизація тестування	Тест-датасети є важливим елементом автоматизованих тестів. Вони дозволяють легко повторювати тести з різними вхідними даними та аналізувати результати.
Спрощення створення тестів	Застосування тест-датасетів полегшує створення тестових сценаріїв. Замість ручного введення великої кількості даних можна використовувати готові тест-датасети або автоматизовані генератори тестових даних.
Прискорення процесу тестування	Завдяки попередньому підготовленню тест-датасетів можна ефективно виконувати тести та отримувати результати швидше, що важливо для процесу Continuous Integration / Continuous Delivery (CI/CD).
Масштабованість тестового процесу	Тест-датасети дозволяють розширювати обсяг тестів і визначати, як продукт веде себе при великій кількості різних вхідних даних.
Покращення виявлення помилок	Тест-датасети допомагають виявляти різні види помилок, такі як проблеми з обробкою великих обсягів даних, некоректними вхідними даними та інших.

Складнощі

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

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

Інструменти

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

Excel або інші електронні таблиці	Електронні таблиці, такі як Microsoft Excel чи Google Sheets, можуть бути використані для створення і редагування тест-датасетів. Вони надають зручний інтерфейс та можливості часткової автоматизації завдяки макросам та формулам.
Генератори тестових даних	Існують спеціальні інструменти для генерації випадкових чи реалістичних тестових даних. Приклади цих інструментів включають Faker (для різних мов програмування), Mockaroo, DataFactory та інші.
SQL-запити	Для тестування можна використовувати SQL-запити для створення, оновлення чи видалення тестових даних. Це може бути корисно, зокрема, при тестуванні систем, що використовують бази даних.
API для генерації даних	Деякі компанії та сервіси надають API для генерації тестових даних. За допомогою таких API можна отримати реалістичні дані для тестування.
Спеціалізовані інструменти для тестування баз даних	Деякі інструменти, такі як DbUnit для Java чи tSQLt для Microsoft SQL Server, можуть допомагати в підготовці та управлінні тестовими даними в базах даних.
Середовища розробки та інструменти тестування	Інколи тестові дані можна підготовити за допомогою розробницьких середовищ та інструментів тестування, таких як Eclipse, Microsoft Visual Studio, Atom, SlickEdit.

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

В цьому відео поговоримо про:
00:00 Тест-датасети
06:13 Переваги
09:56 Складнощі
14:15 Інструменти

Логи тестування (Test Logs) – це записи або документація, яка фіксує події, результати та іншу інформацію, пов’язану з процесом тестування програмного забезпечення. Ця інформація може включати в себе різні аспекти тестування, такі як виконані тести, отримані результати, помилки, виправлення помилок та інші аспекти тестового циклу.

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

Логи тестування (Test Logs) можуть містити різноманітну інформацію, залежно від конкретних потреб проєкту та виду тестування. Однак типові елементи інформації, які часто включаються в логи тестування, включають:

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

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

Переваги

Використання логів тестування має кілька значущих переваг:

Відстеження прогресу	Логи тестування дозволяють команді відстежувати прогрес тестування. Записи про виконані тести, їхні результати та стан системи допомагають визначити, наскільки продуктивно використовуються ресурси для тестування.
Виявлення і аналіз помилок	Якщо тест виявляє помилку або несправність, логи надають деталі про цю проблему. Це сприяє швидкому виявленню, відлагодженню та виправленню помилок.
Документація тестування	Логи служать важливим джерелом документації тестового процесу. Вони фіксують введені тести, очікувані результати, виявлені помилки та інші важливі аспекти, що характеризують якість продукту.
Верифікація відповідності до вимог	Логи допомагають перевірити, чи відповідає програмний продукт встановленим вимогам. Вони можуть включати в себе результати виконання тестів, що вказують на те, чи функціональні вимоги виконуються належним чином.
Покриття тестування	Аналіз логів дозволяє визначити, які частини програмного продукту були покриті тестами, а які ще потребують уваги. Це важливо для забезпечення високої якості продукту та визначення стратегій тестування.
Спрощення співпраці в команді	Логи є ефективним інструментом для обміну інформацією між членами команди тестування та розробниками. Вони надають об’єктивну та конкретну інформацію про стан продукту, що полегшує взаємодію та вирішення питань.
Автоматизація та реалізація CI/CD	Логи є необхідною частиною автоматизованих тестів і процесів Continuous Integration / Continuous Delivery (CI/CD). Вони дозволяють визначити стабільність тестів та автоматизованих процесів.

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

Складнощі

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

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

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

В цьому відео поговоримо про:
00:00 Тестові логи
04:24 Переваги
07:03 Складнощі

Дефекти, Помилки, Збої

Дефект (Defect, Bug, Fault) – недосконалість або недолік робочого продукту, коли він не відповідає вимогам або специфікаціям.

Помилка (Error) – дія людини, що призводить до неправильного результату.

Збій (Failure) – подія, під час якої компонент або система не виконує необхідну функцію в межах визначених обмежень.

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

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

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

Причини помилок

Помилки можуть виникати з багатьох причин, наприклад:

• Тиск часу
• Людський фактор
• Недосвідчені або недостатньо кваліфіковані учасники проєкту
• Непорозуміння між учасниками проєкту, в тому числі нерозуміння вимог і дизайну
• Складність коду, дизайну, архітектури, основної проблеми, яку потрібно вирішити, або використовуваних технологій
• Непорозуміння щодо внутрішньосистемних і міжсистемних інтерфейсів, особливо коли таких внутрішньосистемних і міжсистемних взаємодій велика кількість
• Нові, незнайомі технології

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

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

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

Дефекти та першопричини

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

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

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

Види дефектів

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

• Неправильне трактування вимог (Misinterpretation of Requirements): Це відбувається, коли розробник чи команда неправильно розуміють вимоги до програми. Як результат, програма може працювати правильно з точки зору розробника, але не відповідати потребам користувачів чи замовника.
• Невірне управління пам’яттю (Memory Leaks): Це відбувається, коли програма неправильно використовує пам’ять, і в результаті, обсяг доступної пам’яті зменшується, що може призводити до витоку пам’яті та неправильної роботи програми.
• Відсутність або неефективна обробка помилок (Error Handling Issues): Якщо програма не вміє або неправильно обробляє помилки, це може призводити до непередбачених ситуацій або навіть витоку конфіденційної інформації.
• Проблеми з безпекою (Security Issues): Програмне забезпечення може бути вразливим до атак, якщо розробники неправильно враховують аспекти безпеки. Невірна обробка даних, недостатня аутентифікація та авторизація можуть призвести до серйозних проблем з безпекою.
• Проблеми з використанням ресурсів (Resource Usage Issues): Дефекти в коді можуть призводити до неправильного використання системних ресурсів, таких як процесор, пам’ять чи мережеві ресурси.
• Проблеми з взаємодією (Interoperability Issues): Якщо програмне забезпечення не взаємодіє ефективно з іншими системами чи програмами, це може призводити до невірної передачі даних, невідповідності стандартам чи іншим проблемам.
• Проблеми з продуктивністю (Performance Issues): Несправності, що впливають на продуктивність, можуть включати у себе повільну реакцію програми, зависання чи інші проблеми з продуктивністю.

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

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

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

Новий (New)	Дефект виявлений та зареєстрований в системі управління дефектами. Це початковий статус, коли дефект ще не розглянутий розробниками чи тестувальниками.
Розподілений (Assigned)	Дефекту призначено відповідальну особу, яка має вирішити виявлену проблему.
Відкладено (OnHold)	Дефект зареєстровано, але через певні причини відкладено процес його розв’язання.
Неможливо відтворити (Can’t Reproduce)	Зареєстрований дефект не вдається відтворити, потрібна додаткова інформація чи уточнення в описі.
Відхилено (Rejected)	Дефект не підтверджено через певні причини (хибне спрацьовування, неточності в описі).
Виправлений (Fixed)	Розробник виправив дефект у вихідному коді програми.
Перевірений (Verified)	Після успішного повторного тестування виправленого дефекту визначається, що дефект більше не виявляється в програмі.
Закритий (Closed)	Дефект вважається вирішеним і закритим після виправлення та успішної перевірки.
Повторно відкритий (Reopened)	Якщо під час перевірки виявляється, що дефект не був повністю виправлений, або з’явився знову, він може бути відкритий знову для подальшого виправлення.

В залежності від проєкту і практик, які застосовуються, можуть бути додаткові статуси. Наприклад, потребує повторного тестування (Pending retest), на розгляді (In Review), підтверджений (Confirmed) тощо.

Управління дефектами

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

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

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

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

Звіт про дефект

Звіт про дефект, поданий під час динамічного тестування, зазвичай містить:

• Ідентифікатор
• Назва та короткий опис дефекту, про який повідомляється
• Дата, організація, та автор
• Ідентифікація тестового елемента (елемента конфігурації, що тестується) і середовища
• Фаза життєвого циклу розробки, на якій спостерігався дефект
• Опис дефекту, щоб уможливити відтворення та вирішення, включаючи журнали, дампи бази даних, знімки екрана або записи
• Очікувані та фактичні результати
• Масштаб або ступінь впливу (серйозності) дефекту на інтереси зацікавлених сторін
• Пріоритет виправлення
• Статус звіту про дефект (наприклад, відкрито, відкладено, дублікат, очікує на виправлення, очікує підтверджувального тестування, повторно відкрито, закрито)
• Висновки, рекомендації та схвалення
• Глобальні проблеми, наприклад інші області, на які можуть вплинути зміни внаслідок дефекту
• Історія змін, таких як послідовність дій, виконаних членами команди проєкту щодо дефекту, щоб ізолювати, виправити та підтвердити його як виправлений
• Посилання, включаючи тест-кейс, який виявив проблему

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

Приклад вмісту звіту про дефект можна знайти в стандарті ISO (ISO/IEC/IEEE 29119-3) (де звіти про дефекти називаються звітами про інциденти).

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

Заголовок (Title)	Короткий, але інформативний заголовок, що вказує на суть проблеми.
Опис (Description)	Детальний опис проблеми.
Кроки для відтворення (Steps to Reproduce)	Послідовність кроків, які дозволяють відтворити проблему. Це допомагає розробникам швидше ідентифікувати та виправити дефект.
Очікуваний результат (Expected Result)	Опис того, як мав би виглядати правильний результат без дефекту.
Фактичний результат (Actual Result)	Опис того, як виглядає результат у зв’язку з виявленим дефектом.
Інформація про середовище (Environment Information)	Версія програми, операційна система, конфігурація апаратного забезпечення та інші технічні деталі, які можуть впливати на виявлення дефекту.
Пріоритет (Priority)	Вказує на те, наскільки терміново дефект повинен бути виправлений.  Зазвичай пріоритети класифікуються за шкалою, такою як “Низький,” “Середній,” “Високий,” “Надвисокий”.
Важливість (Severity)	Вказує на вплив дефекту на роботу програми чи користувача. Це визначає, наскільки серйозною є проблема. Наприклад, дефект, який призводить до краху програми чи втрати даних, має високий рівень важливості. Класифікація важливості може включати категорії, такі як “Критична,” “Важлива,” “Звичайна”, “Мінорна”
Прикріплені файли (Attachments)	Скріншоти, журнали, логи або інші файли, які демонструють проблему або допомагають в її аналізі.

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

Приклад

Заголовок (Title)	Неможливо видалити елемент зі списку контактів
Опис (Description)	При спробі видалити контакт із списку, елемент не зникає, і контакт залишається у списку.
Кроки для відтворення (Steps to Reproduce)	1. Зайти в меню “Контакти”. 2. Обрати конкретний контакт. 3. Спробувати видалити контакт, натиснувши кнопку “Видалити”.
Очікуваний результат (Expected Result)	Контакт має бути видалений і зникнути зі списку.
Фактичний результат (Actual Result)	Контакт залишається в списку.

Інструменти

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

Jira	Це один з найвідоміших інструментів для управління проєктами, що включає в себе модуль управління дефектами. Jira дозволяє визначати, відстежувати та призначати пріоритети дефектам, а також координувати роботу розробників і тестувальників.
Bugzilla	Це відкрите програмне забезпечення для управління дефектами. Bugzilla надає можливості створення, відстеження і вирішення дефектів, а також генерації звітів та статистики.
Redmine	Ще один інструмент управління проєктами, який також має модуль для ведення списку дефектів. Redmine дозволяє створювати та відстежувати дефекти, присвоювати їм пріоритети та важливість.
Mantis Bug Tracker	Це відкрите програмне забезпечення для управління дефектами, яке надає засоби для реєстрації, відстеження та розгляду дефектів.
Trello	Це інструмент для керування завданнями, проте його можна використовувати для ведення списку дефектів. Він дозволяє створювати картки для дефектів, перелік дефектів та працювати в режимі спільної роботи.

В цьому відео поговоримо про:
00:00 Дефекти, Помилки, Збої
01:46 Причини помилок
03:38 Дефекти та першопричини
06:12 Види дефектів
09:37 Життєвий цикл дефекту
13:33 Управління дефектами
15:55 Звіт про дефект
24:04 Інструменти