Цей посібник пояснює, що таке тестовий сценарій, а також важливість, реалізацію, приклади та шаблони тестових сценаріїв:
Будь-яка функціональність/особливість програмного забезпечення, яку можна протестувати, називається тестовим сценарієм. Під час написання будь-яких тестових сценаріїв враховується перспектива кінцевого користувача.
Цей підручник допоможе вам відповісти на питання: навіщо потрібні тестові сценарії, коли пишуться тестові сценарії і як їх писати.
Що таке тестовий сценарій?
Розглянемо гіпотетичну ситуацію: Існує величезний океан, який треба перетнути, щоб дістатися від одного берега до іншого. Наприклад, з Мумбаї, узбережжя Індії, до Коломбо, узбережжя Шріланки.
Ви можете обрати один з наступних способів подорожі:
(i) Авіалінії: Сядьте на літак до Коломбо
(ii) Водні шляхи: надайте перевагу кораблю для подорожі до Коломбо
(iii) Залізницею: Сядьте на поїзд до Сріланки
Тепер про тестові сценарії: Подорожі з узбережжя Мумбаї до узбережжя Коломбо - це функціонал, який ще потрібно протестувати.
Тестові сценарії включають:
- Подорожую авіалініями,
- Подорожуючи водними шляхами або
- Подорож залізницею.
Ці тестові сценарії матимуть тестові кейси.
Тестові кейси, які можна написати для вищезазначених тестових сценаріїв, включають в себе наступні:
Сценарій випробування: Подорожі авіалініями
Тестові кейси можуть включати такі сценарії, як
- Виліт за розкладом.
- Виліт не за розкладом.
- Виникла надзвичайна ситуація (сильні зливи та шторм).
Так само можна написати окремий набір тестових кейсів для інших сценаріїв, що залишилися.
Тепер перейдемо до технологічних сценаріїв тестування.
Все, що можна протестувати, є тестовим сценарієм. Таким чином, ми можемо стверджувати, що будь-яка функціональність програмного забезпечення, що тестується, може бути розділена на декілька менших функціональностей і може бути названа "тестовим сценарієм".
Перед тим, як передати будь-який продукт клієнту, необхідно оцінити його якість. Тестовий сценарій допомагає оцінити функціональну якість програмного додатку, яка відповідає бізнес-вимогам.
Сценарій тестування - це процес, під час якого тестувальник тестує програмний додаток з точки зору кінцевого користувача. Продуктивність і якість програмного додатку ретельно оцінюються перед впровадженням у виробниче середовище.
Важливість тестового сценарію
- Один тестовий сценарій може мати декілька "тестових кейсів". Його можна уявити як велике панорамне зображення, а тестові кейси - це маленькі частини, які важливі для завершення панорами.
- Він являє собою один рядок, а тестові кейси містять покроковий опис для досягнення мети тестового сценарію.
- Приклад:
Сценарій випробування: Оплатіть послугу таксі, якою ви скористалися.
Для цього буде декілька тестових кейсів, як зазначено нижче:
(i) Спосіб оплати: PayPal, Paytm, кредитна/дебетова картка.
(ii) Платіж виконано успішно.
(iii) Платіж виконано неуспішно.
(iv) Між ними процес оплати переривався.
(v) Неможливо отримати доступ до способів оплати.
(vi) Між ними програма виходить з ладу.
- Таким чином, тестові сценарії допомагають оцінити програмне забезпечення відповідно до реальних ситуацій.
- Тестові сценарії, коли вони визначені, допомагають розділити сферу тестування.
- Таке роздвоєння називається розстановкою пріоритетів, яка допомагає визначити важливі функції програмного додатку.
- Пріоритетне тестування функціональних можливостей значною мірою сприяє успішному впровадженню програмного додатку.
- Оскільки тестові сценарії визначають пріоритети, найважливіші функціональні можливості можна легко визначити і протестувати в першу чергу. Це гарантує, що більшість критично важливих функціональних можливостей працюють нормально, а дефекти, пов'язані з ними, належним чином фіксуються і виправляються.
- Тестові сценарії визначають потік бізнес-процесів програмного забезпечення, і, таким чином, можливе наскрізне тестування програми.
Різниця між тестовим сценарієм і тестовим кейсом
| Сценарій тесту | Тестові кейси |
|---|---|
| Тестовий сценарій - це концепція. | Тестові кейси - це рішення для перевірки цієї концепції. |
| Тестовий сценарій - це функціонал високого рівня. | Тестові кейси - це детальна процедура для тестування високорівневої функціональності. |
| Сценарії тестів виводяться з Вимог/Історій користувачів. | Тестові кейси походять від тестових сценаріїв . |
| Сценарій тестування - це "Яка функціональність буде протестована | Тестові кейси - це "Як протестувати функціонал". |
| Тестові сценарії мають кілька тестових кейсів. | Тестовий кейс може бути пов'язаний або не пов'язаний з декількома тестовими сценаріями. |
| Окремі тестові сценарії ніколи не повторюються. | Один і той самий тестовий кейс може бути використаний кілька разів у різних сценаріях. |
| Потрібні короткі документи. | Потрібна детальна документація. |
| Для того, щоб завершити розробку тестового сценарію, необхідно провести мозковий штурм. | Потрібні детальні технічні знання програмного забезпечення |
| Економія часу, оскільки дрібні деталі не потрібні. | Це забирає багато часу, оскільки потрібно подбати про кожну дрібницю. |
| Витрати на обслуговування низькі, оскільки необхідні ресурси невеликі. | Витрати на обслуговування високі, оскільки потрібні великі ресурси |
Чому тестові сценарії незамінні?
Тестові сценарії створюються на основі вимог або користувацьких історій.
- Візьмемо приклад тестового сценарію для замовлення таксі.
- Сценарії можуть стосуватися варіантів бронювання таксі, способів оплати, GPS-трекінгу, правильного чи неправильного відображення карти доріг, правильного чи неправильного відображення даних про таксі та водія тощо - все це перераховано в шаблоні тестового сценарію.
- Тепер припустимо, що тестовий сценарій повинен перевірити, чи увімкнено служби визначення місцезнаходження, і якщо їх не увімкнено, вивести повідомлення "Увімкнути служби визначення місцезнаходження". Цей сценарій пропущено і його не вказано у шаблоні тестових сценаріїв.
- Сценарій "Служба визначення місцезнаходження" породжує інші тестові сценарії, пов'язані з ним.
Це може бути:
- Служба визначення місцезнаходження стала сірою.
- Служба визначення місцезнаходження увімкнулася, але інтернету немає.
- Обмеження на локаційні послуги.
- Відображається неправильне місце розташування.
- Не вистачає одного сценарію може означати втрату багатьох інших критичні сценарії або тестові кейси Це може мати великий негативний вплив Це призводить до значних втрат ресурсів (дедлайнів) під час реалізації програмного додатку.
- Тестові сценарії значною мірою допомагають у уникнення вичерпного тестування Це гарантує, що всі важливі та очікувані бізнес-потоки будуть протестовані, що в подальшому допоможе в наскрізному тестуванні програми.
- Це економить час. Крім того, не потрібен більш детальний опис відповідно до тестових кейсів. Достатньо одного рядка про те, що потрібно протестувати.
- Тестові сценарії пишуться після мозкові штурми Таким чином, ймовірність пропустити будь-який сценарій (важливий чи другорядний) є мінімальною. Це робиться з урахуванням технічних аспектів, а також бізнес-процесів програмного додатку.
- Більше того, тестові сценарії можуть бути затверджені або бізнес-аналітиком, або обома клієнтами, які мають чіткі знання про програму, що тестується.
Таким чином, тестові сценарії є невід'ємною частиною SDLC.
Реалізація тестових сценаріїв
Розглянемо реалізацію тестових сценаріїв або як писати тестові сценарії:
- Формуються епічні/бізнес-вимоги.
- Приклад епічного твору Створіть акаунт Gmail. Епічність може бути головною особливістю програми або бізнес-вимогою.
- Епопеї поділяються на менші користувацькі історії в рамках спринтів.
- Історії користувачів створюються на основі Epics. Ці історії користувачів мають бути базовими та схваленими зацікавленими сторонами.
- Тестові сценарії створюються на основі історій користувачів або BRS (Документ бізнес-вимог), SRS (Документ специфікації системних вимог) або FRS (Документ функціональних вимог), які доопрацьовуються і вирівнюються.
- Тестувальники пишуть тестові сценарії.
- Ці тестові сценарії затверджуються керівником команди, бізнес-аналітиком або менеджером проекту, залежно від організації.
- Кожен тестовий сценарій повинен бути прив'язаний принаймні до однієї історії користувача.
- Необхідно визначити як позитивні, так і негативні тестові сценарії.
- Історії користувачів включають Критерії прийнятності, такі як :
- Критерії прийнятності - це перелік умов або стан намірів щодо вимог замовника. При написанні критеріїв прийнятності враховуються очікування замовника, а також непорозуміння.
- Вони є унікальними для однієї користувацької історії, і кожна користувацька історія повинна мати принаймні один критерій прийнятності, який можна перевірити незалежно.
- Критерії прийнятності допомагають визначити, які функції входять в обсяг проекту, а які виходять за його межі. Ці критерії повинні включати як функціональні, так і нефункціональні функції.
- Бізнес-аналітики пишуть критерії прийнятності, а Власник продукту затверджує їх.
- Або в деяких випадках власник продукту може сам написати критерії.
- Сценарії тестування можна отримати з критеріїв прийнятності.
Приклади тестових сценаріїв
#1) Тестові сценарії для Kindle App
Kindle - це програма, яка дозволяє користувачам шукати електронні книги в Інтернеті, завантажувати та купувати їх. Amazon Kindle дає читачеві електронних книг реальний досвід, коли він тримає книгу в руках і читає її. Навіть перегортання сторінок добре імітується в додатку.
Тепер давайте запишемо тестові сценарії ( Зауважте: Нижче перераховані обмежені сценарії, щоб отримати загальне уявлення про написання тестового сценарію. З нього може бути отримано декілька тестових кейсів).
| Тестові сценарії # | Тестові сценарії |
|---|---|
| 1 | Переконайтеся, що Kindle App запускається належним чином. |
| 2 | Переконайтеся, що роздільна здатність екрану налаштовується на різних пристроях після запуску програми. |
| 3 | Переконайтеся, що текст на екрані читабельний. |
| 4 | Переконайтеся, що опції збільшення та зменшення масштабу працюють. |
| 5 | Переконайтеся, що сумісні файли, імпортовані в програму Kindle, можна читати. |
| 6 | Перевірте обсяг пам'яті Kindle App. |
| 7 | Переконайтеся, що функція завантаження працює коректно. |
| 8 | Перевірте, чи правильно працює імітація перегортання сторінок |
| 9 | Перевірте сумісність форматів електронних книг з додатком Kindle. |
| 10 | Перевірте шрифти, що підтримуються додатком Kindle. |
| 11 | Перевірте час автономної роботи програми Kindle. |
| 12 | Перевірте продуктивність Kindle залежно від підключення до мережі (Wi-Fi, 3G або 4G). |
З кожного тестового сценарію, описаного вище, можна отримати кілька тестових кейсів.
#2) Критерії прийнятності для Google Документів
"Документи Google" - це веб-додаток для створення, редагування та обміну текстовими документами, електронними таблицями, слайдами та формами. До всіх файлів можна отримати доступ онлайн за допомогою веб-браузера, підключеного до Інтернету.
Створені документи можна поширювати у вигляді веб-сторінки або готового до друку документа. Користувач може встановити обмеження на те, хто може переглядати і редагувати документи. Над одним документом можуть спільно працювати різні люди з різних географічних точок.
Нижче наведено обмежені тестові сценарії для загального розуміння. Сценарії поглибленого тестування для Google Документів можуть бути окремою темою.
| Критерії прийнятності # Критерії прийнятності | Критерії прийняття заявок |
|---|---|
| 1 | Word, аркуші або форми можуть бути успішно відкриті без помилок. |
| 2 | Шаблони доступні для документів, аркушів і слайдів. |
| 3 | Доступні шаблони доступні для користувачів. |
| 4 | Використовуваний шаблон можна редагувати (наприклад, шрифти, розмір шрифту, додавання тексту, видалення тексту, вставка слайдів). |
| 5 | Якщо підключення до Інтернету тимчасово недоступне, файл може бути збережений локально і завантажений за наявності підключення до Інтернету. |
| 6 | Зміни, внесені кількома користувачами, не перезаписуються. |
| 7 | Кілька користувачів можуть працювати над одним документом. |
| 8 | Виконана робота зберігається, якщо під час завантаження файлу втрачається інтернет-з'єднання. |
| 9 | Обмеження на спільний доступ застосовуються коректно. |
| 10 | Користувачі з обмеженням перегляду не можуть редагувати документи. |
| 11 | Документи можуть бути опубліковані в Інтернеті для широкого загалу. |
| 12 | Зміни, внесені до документів, зберігаються з відміткою часу та даними про автора. |
Кількість тестових сценаріїв для Google Docs буде дуже великою і дуже великою. У таких випадках, як правило, лише критерії прийнятності встановлюються і затверджуються зацікавленими сторонами, і члени команди працюють над цими критеріями прийнятності. Написання тестових кейсів або, скоріше, тестових сценаріїв може бути вичерпним завданням для величезних додатків.
Ці критерії прийнятності відіграють важливу роль в ітеративному плануванні процесу і ніколи не повинні залишатися поза увагою. Визначення їх заздалегідь і наперед дозволяє уникнути несподіванок або шоків в кінці спринтів або релізів
Враховуючи передумовою.
Коли щоб зробити щось.
Тоді результат очікуваний.
Формати "Дано", "Коли" і "Потім" корисні для визначення критеріїв прийнятності.
Приклад шаблону тестового сценарію
| Використовуйте ідентифікатор історії | Ідентифікатор тестового сценарію ID | Версія # | Тестові сценарії | # Кількість тестових кейсів | Важливість |
|---|---|---|---|---|---|
| USID12.1 | TSID12.1.1 | Kin12.4 | Переконайтеся, що Kindle App запускається належним чином. | 4 | Високий |
| USID12.1 | TSID12.1.2 | Kin12.4 | Перевірте обсяг пам'яті Kindle App. | 3 | Середній |
Висновок
У будь-якому тестуванні програмного забезпечення розуміння життєвого циклу і створення тестових сценаріїв є дуже важливим елементом. Якість програмного забезпечення можна покращити, маючи хорошу основу для тестових сценаріїв. Часто використання тестових кейсів і тестових сценаріїв може бути взаємозамінним.
Однак основне правило полягає в тому, що тестовий сценарій використовується для написання декількох тестових кейсів, або ми можемо сказати, що тестові кейси є похідними від тестових сценаріїв. Добре визначені тестові сценарії забезпечують хорошу якість програмного забезпечення.