Author: adminsimplerec

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

Ідентифікатор тест-кейсу	Унікальний номер чи 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 Інструменти управління тест-кейсами

Сценарії тестування (Test Scenarios) – загальні описи сценаріїв тестування, які визначають, як тестування повинно бути виконано для конкретної функціональності чи компонента системи.

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

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

Важливість тестових сценаріїв

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

Поради

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

Написання тестового сценарію

1	Ознайомлення з SRS, BRS, керівництвами використання програмного додатку тощо.
2	Для кожної вимоги потрібно визначити можливі дії та цілі користувачів, технічні аспекти вимоги. Потрібно з’ясувати можливі сценарії зловживання системою та передбачити дії користувачів з хакерським мисленням.
3	Складання списку різних сценаріїв використання, які перевіряють кожну функцію ПЗ.
4	Створення матриці відстеження, щоб переконатися, що кожна вимога має відповідний сценарій тестування
5	Обговорення і затвердження тестових сценаріїв керівниками та іншими зацікавленими сторонами.

Чи завжди тестові сценарії необхідні?

За наявності наступних умов тестові сценарії можуть не використовуватися:

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

Приклади

Тестовий сценарій: Перевірка входу в систему (логіну)

Тестові кейси:     1. Перевіка поведінки системи, якщо введено коректний ідентифікатор електронної пошти та пароль. 2. Перевіка поведінки системи, якщо введено коректний ідентифікатор електронної пошти але некоректний пароль. 3. Перевіка поведінки системи, якщо введено некоректний ідентифікатор електронної пошти та коректний пароль. 4. Перевіка поведінки системи, якщо введено некоректний ідентифікатор електронної пошти та пароль . 5. Перевіка поведінки системи, якщо ідентифікатор електронної пошти або пароль залишено порожніми.

Тестовий сценарій: Оформлення замовлення

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

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

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

В цьому відео поговоримо про:
00:00 Тестові сценарії
01:14 Важливість тестових сценаріїв
02:21 Поради
03:51 Написання тестового сценарію
06:35 Приклади

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

Приклади тестової документації:

• План тестування (Test Plan) – це високорівневий документ, який визначає стратегію тестування, обсяг та графік тестування, ресурси, що використовуються, критерії припинення тестування та інші аспекти організації тестування.
• Сценарії тестування (Test Scenarios) – загальні описи сценаріїв тестування, які визначають, як тестування повинно бути виконано для конкретної функціональності чи компонента системи.
• Тест-кейси (Test Cases) – конкретні кроки, які тестувальники повинні виконати для виклику певного стану системи чи функціональності. Включає вхідні дані, очікувані результати та умови виконання тесту.
• Контрольні списки (Chekclists) – це артефакт, що використовується для систематичного та організованого моніторингу виконання тестових завдань, визначених для певного процесу чи проєкту. Спрощено його також можна називати переліком завдань.
• Матриця покриття тестування (Test Coverage Matrix) – визначає, які частини продукту (функції, модулі, вимоги) покриті тестуванням. Це допомагає забезпечити повне покриття функціональності.
• Звіти про виконання тестування (Test Execution Reports) – містять інформацію про те, як пройшли тести, скільки тестів було виконано, скільки пройшло чи не пройшло, і які проблеми виникли.
• Звіти про дефекти (Defect Reports) – включають опис та ступінь важливості виявлених дефектів. Ці звіти допомагають команді розробників виправити помилки.
• Логи тестування (Test Logs) – записують інформацію про виконання тестів, таку як дата, час, результати тестів, використані дані та інші подробиці.
• Тест-датасети (Test Data) – визначають вхідні дані, які використовуються під час тестування, разом із специфікацією очікуваних результатів.
• Документація з автоматизації тестування (Test Automation Documentation) – інструкції та скрипти для виконання автоматизованих тестів, опис об’єктів, що автоматизуються, та інша важлива інформація.

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

В цьому відео поговоримо про:
00:00 Тестову документацію
01:12 Кілька слів про План тестування (Test Plan), Сценарії тестування (Test Scenarios), Тест-кейси (Test Cases)
02:35 Кілька слів про Контрольні списки (Chekclists), Матриця покриття тестування (Test Coverage Matrix), Звіти про виконання тестування (Test Execution Reports), Звіти про дефекти (Defect Reports)
03:48 Кілька слів про Логи тестування (Test Logs), Тест-датасети (Test Data), Документація з автоматизації тестування (Test Automation Documentation)
07:30 Ліричний відступ про NDA