Вступ до тестового сценарію

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

Навіщо створювати тестові сценарії?

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

Причина їх створення полягає в наступному:

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

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

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

Як можна записати тестові сценарії?

Наступні кроки може здійснити тестер для створення тестових сценаріїв:

  • Крок 1: Документ про вимоги, такі як Специфікація бізнес-вимог (BRS), Специфікація функціональних вимог (FRS) та Специфікація системних вимог (SRS) програми, яка перевіряється, повинна бути прочитана ретельно і уважно. Посібники, книги, випадки використання тощо для тестованої програми можна віднести до тих самих.
  • Крок 2: Усі можливі цілі та дії користувача повинні бути розроблені належним чином для кожної потреби. Усі технічні особливості кожної вимоги також повинні бути визначені.
  • Крок 3: Усі можливі причини злому системи та оцінки користувачів слід робити з точки зору хакера. Оцінку користувача можна здійснити, знайшовши всі можливості роботи користувачів додатками.
  • Крок 4: Повний перелік усіх можливих тестових випадків для перевірки всіх функціональних можливостей заявки повинен бути складений після повного прочитання документа-вимоги та завершення аналізу.
  • Крок 5: Після залучення всіх до них, для перевірки вимоги та її тестового сценарію відповідають матриці відстеження.
  • Крок 6: Усі створені тестові сценарії переглядаються та оцінюються керівником. Він також додатково перевіряється всіма зацікавленими сторонами.

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

Приклади

Нижче наведено кілька прикладів тестового сценарію

Тестовий сценарій для онлайн-додатків для покупок Buykart

Тестові сценарії, які можуть бути враховані для перевірки інтернет-програми для покупок Buykart, є наступними:

Тестовий сценарій 1: Перевірка функціональності входу

Тестові приклади, які можуть бути розглянуті для створення:

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

Тестовий сценарій 2: Перевірка функціональності пошуку

Тестові приклади, які можуть бути розглянуті для створення:

  • Поведінка програми під час пошуку дійсного продукту.
  • Поведінка програми під час пошуку недійсного продукту.

Сценарій випробувань 3: Перевірка деталей продукту

Тестові приклади, які можуть бути розглянуті для створення:

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

Тестовий сценарій 4: Перевірка функціональності платежів

Тестові приклади, які можуть бути розглянуті для створення:

  • Поведінка програми, коли вибрано кожен варіант оплати.
  • Поведінка програми, коли вибрано дійсний варіант оплати.
  • Поведінка програми, коли вибрано недійсний варіант оплати.
  • Поведінка програми, коли платіж успішний.
  • Поведінка програми, коли платіж відхилений.

Тестовий сценарій 5: Перевірка функціональності деталей замовлення

Тестові приклади, які можуть бути розглянуті для створення:

  • Поведінка програми, коли вибрано кожне замовлення.
  • Поведінка програми, коли вибрано варіант Повернути продукт.
  • Поведінка програми, коли вибрано варіант відстеження продукту.
  • Поведінка програми, коли вибрано варіант Переглянути продукт.

Висновок

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

Рекомендовані статті

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

  1. Стрес невпевненості в роботі
  2. Самомотивований і відданий
  3. Що таке Agile Testing?
  4. Як написати тестовий випадок?