Category: Тестування ПЗ

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

Дефект (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 Інструменти

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

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

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

Переваги

Основні переваги використання контрольних списків у тестуванні включають:

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

Загальною метою використання контрольних списків є покращення якості тестування та забезпечення відповідності програмного продукту встановленим вимогам.

Контрольні списки (Summary)

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

Приклад

Наведемо приклад контрольного списку:

Секція	Підсекція	Опис	Статус
Домашня сторінка	Логотип компанії	Відображується вгорі екрану зправа
	Інформація про додаток	Текст над кнопкою “Спробувати безкоштовно”, нема граматичних помилок
	Кнопка “Спробувати безкоштовно”	Кнопка розміщена внизу екрана, по центру, активна, колір синій RGB(25,25,170)

В цьому відео поговоримо про:
00:00 Контрольні списки
03:12 Переваги
05:17 Приклад

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

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

Процес підготовки тест-кейсів

Процес підготовки тест-кейсів можна розділити на кілька етапів:

1. Розуміння вимог	Ознайомлення з вимогами до програмного продукту, які визначають функціональність, особливості та очікувані результати. За рахунок цього тест-кейси відображають потреби клієнта та бізнес-вимоги.
2. Визначення обсягу тестування	Визначення функціональності, яка потребує тестування, і аспектів, які можуть бути виключені або включені у тест-кейси.
3. Вибір тестових сценаріїв	Вибір конкретних тестових сценаріїв, які будуть включені в тест-кейси. Це може включати позитивні та негативні тести, тестування різних вхідних даних і умов.
4. Створення тест-кейсів	Створення конкретних тест-кейсів, що включають вхідні дані, кроки виконання, очікувані результати та інші деталі. Кожен тест-кейс повинен бути чітко структурованим і задокументованим.
5. Перевірка та рецензія	Перевірка тест-кейсів командою тестування або іншими зацікавленими сторонами. Рецензія допомагає виявити можливі пропуски, неточності або невідповідності вимогам.
6. Схвалення тест-кейсів	Затвердження тест-кейсів від зацікавлених сторін (зазвичай, тест-лідер, бізнес-аналітик, представники замовника). Це підтвердження, що тест-кейси відповідають вимогам та очікуванням.
7. Модифікація тест-кейсів	Модифікація тест-кейсів в разі змін у вимогах або програмі. Тест-кейси повинні залишатися актуальними та відображати поточний стан програмного продукту.
8. Збереження та організація	Збереження та організація тест-кейсів у зручному для використання репозиторії. Це може включати каталогізацію за функціональністю, модулями або іншими критеріями.

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

Рекомендації щодо підготовки тест-кейсів

Кілька кроків і рекомендацій для створення ефективного тест-кейсу:

1. Чітка мета тесту	●Визначте, що саме ви хочете перевірити. ●Опишіть коротко і зрозуміло, якщо можливо, одним або двома реченнями.
2. Структурованість	●Розділіть тест-кейс на логічні розділи, такі як “Введення”, “Кроки виконання”, “Очікуваний результат”. ●Створіть чітку послідовність кроків для тестування.
3. Простота і ясність	●Використовуйте просту мову, уникайте термінів чи скорочень, які можуть бути незрозумілими для читача. ●Уникайте використання складних фраз і надлишкових технічних деталей.
4. Специфікація вхідних даних	●Визначте вхідні дані, які необхідні для виконання тесту. ●Вказуйте конкретні значення і параметри.
5. Опис кроків виконання	●Кожен крок повинен бути чітко описаний і нумерований. ●Уникайте зайвих деталей, надлишкової інформації.
6. Очікуваний результат	Чітко визначте, що зміниться або який результат повинен бути отриманий після виконання кроків тесту.
7. Вихідні дані	Якщо тест вносить зміни в систему, вказуйте, які саме зміни мають відбутися
8. Стан системи перед тестуванням	Визначте початковий стан системи перед початком тесту.
9. Попередження	Надайте будь-які необхідні попередження або інструкції перед виконанням тесту.
10. Легкість супроводу	Зробіть текст-кейс таким чином, щоб інші члени команди змогли легко розуміти і виконати його.
11. Актуалізація	Регулярно переглядайте та оновлюйте тест-кейси у випадку змін у вимогах або програмі.

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

Поширені помилки

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

1. Надмірна складність	Уникайте зайвої технічної деталізації. Тест-кейс повинен бути зрозумілим для широкого кола людей, а не лише для фахівців.
2. Недостатній опис	Уникайте неповного або невірного опису кроків. Кожен крок має бути чітко описаний і має бути зрозумілим і легким для виконання.
3. Неконкретні очікувані результати	Уникайте формулювань накшталт “перевірити, чи все працює”. Очікувані результати повинні бути конкретними і вимірюваними.
4. Неконкретні вхідні дані	Уникайте вказівки “ввести дані” без конкретизації, які саме дані слід вводити. Вказуйте конкретні значення та параметри.
5. Нестабільні тест-кейси	Уникайте тест-кейсів, які можуть бути нестабільними або залежати від зовнішніх умов. Такі тест-кейси можуть призвести до непередбачуваних результатів.
6. Надмірна кількість кроків	Уникайте надмірної деталізації, яка може призвести до великої кількості кроків. Тест-кейси повинні бути компактними та легкими для розуміння.
7. Невідповідність вимогам	Уникайте створення тест-кейсів, які не відображають вимоги до програмного забезпечення. Кожен тест-кейс повинен бути зорієнтованим на вимоги.
8. Відсутність актуалізації	Уникайте неоновлених тест-кейсів. Якщо програма змінюється, тест-кейси також повинні бути актуалізовані.

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

Приклади

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

Назва	Перевірка авторизації користувача.
Опис	Спроба авторизації з правильними логіном і паролем.
Вхідні дані	Логін, пароль
Кроки виконання	1. Відкрити сторінку авторизації. 2. Ввести правильний логін. 3. Ввести правильний пароль. 4. Натискання на кнопку “Увійти”.
Очікуваний результат	Користувач повинен бути успішно авторизований та перенаправлений на головну сторінку.

Узагальнений варіант тест-кейсу пошуку за ключовим словом:

Назва	Пошук за ключовим словом
Опис	Пошук елементів за певним ключовим словом
Вхідні дані	Ключове слово для пошуку
Кроки виконання	1. Відкрити сторінку пошуку. 2. Ввести ключове слово у поле пошуку. 3. Натиснути на кнопку пошуку.
Очікуваний результат	Відображується список елементів, які відповідають ключовому слову.

Узагальнений тест-кейс для тестування експорту даних:

Назва	Експорт даних у форматі CSV.
Опис	Завантаження даних у файл CSV через функцію експорту.
Вхідні дані	Обрані дані для експорту.
Кроки виконання	1. Перейти до розділу, де є можливість експорту даних. 2. Вибрати параметри експорту. 3. Натиснути на кнопку “Експорт”.
Очікуваний результат	Файл CSV має бути згенерований і містити правильні дані.

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

Інструменти управління тест кейсами

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

TestRail	TestRail дозволяє створювати, організовувати та виконувати тест-кейси. Він також надає можливість генерувати звіти і відстежувати прогрес тестування. Free trial 14 days.
Jira	Jira використовується для керування проєктами, але також має модуль для управління тест-кейсами. Jira дозволяє створювати та виконувати тест-кейси, а також ведення журналу багів. Безкоштовно до 10 користувачів.
TestLink	Відкрите програмне забезпечення для управління тест-кейсами та тест-сценаріями. Воно дозволяє вам організовувати тести відстежувати їх виконання.
Qmetry	Це платформа для управління тестовими процесами, яка дозволяє створювати, виконувати та відстежувати тест-кейси. 15 days free trial.
TestCollab	Дозволяє організовувати тест-кейси, вести журнал багів і створювати звіти. Безкоштовно для маленьких команд.
PractiTest	Це хмарна платформа для управління тестовими кейсами, яка надає розширені засоби відстеження і аналізу тестування.  14 day free trial.
Xray	Xray – розширення для Jira, призначене для управління тест-кейсами і тест-сценаріями. Воно також надає можливість автоматизації тестування.
Zephyr	Zephyr є розширенням для Jira і дозволяє створювати, виконувати та відстежувати тест-кейси безпосередньо в середовищі Jira.

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

В цьому відео поговоримо про:
00:00 Тест-кейси
02:25 Процес підготовки тест-кейсів
05:57 Рекомендації
08:44 Поширені помилки
10:47 Приклади
14:47 Інструменти управління тест-кейсами