Приймально-здавальна документація із сценаріями реального часу

Кожен тест повинен включати:

• Тест №.
• Опис того, що тестується ( Приклад : Перевірте, чи зможе користувач успішно створити обліковий запис).
• Вимоги бізнесу, яким відповідає цей тест ( Матриця простежуваності ) - Дуже важливо.
• Попередні умови:
  • Стан товару перед початком тестування (Користувач повинен бути успішно зареєстрований, але не активувати обліковий запис, Користувач повинен був отримати доступ до продукту щонайменше 30 днів тому тощо)
  • Будь-які умови сервера - Якщо сервер не працюватиме деякий час.
• Тестові кроки: Детальний нумерований потік ( Приклад: Дивись нижче
  • Відкрийте програму.
  • Спроба увійти з дійсними обліковими даними, встановивши прапорець Запам'ятати мене).
• Очікуваний результат : Яка очікувана поведінка кроку>

Приймальні випробування - якщо є окремі письмові прийомні випробування

Критерії виходу

Ресурси

Ролі та обов'язки

Інструменти

Фактори прийняття бізнес-рішень

Іди або не ходи .>

Процедура підписання

Контактна особа

План приймальних випробувань розглядається як Генеральний план випробувань для етапу .

Перегляд плану приймальних випробувань

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

Тут давайте класифікуємо вміст і побачимо контрольний список проти них.

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

Приймальні випробування

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

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

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

Основні моменти, про які слід пам’ятати перед написанням приймально-здавальних тестів:

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

Загальний та простий шаблон для складання тестів приймання:

Цей шаблон можна знову налаштувати відповідно до потреб проекту та включити додаткову інформацію.

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

Випадок 1: Обробка облікового запису користувача

Це сценарій, коли користувачам дозволяється створювати, переглядати, оновлювати та деактивувати свій обліковий запис. Загалом, це операція CRUD (Створення, читання, оновлення та видалення). Тож безпосередньо ми отримаємо 4 основні сценарії для тестування.

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

Приступаючи до письмових приймальних тестів:

Тест 1: Реєстрація / Реєстрація / Створення облікового запису, перевірте, чи може користувач:

• Створіть обліковий запис.
• Активуйте рахунок.
• Активуйте обліковий запис лише один раз (тут посилання для активації потрібно перевірити на 2^йНезважаючи на те, що це негативне тестування, це один з основних пунктів перевірки, який слід враховувати).

Тест 2: Щоб отримати доступ та переглянути інформацію про обліковий запис, перевірте, чи є користувач у змозі:

• Увійдіть в обліковий запис.
• Перегляньте різні розділи у профілі (якщо розділ 'Профіль' класифікований, то кожна категорія повинна бути доступною для перегляду).
• Переконайтеся, що дані, що відображаються у профілі, є правильними відповідно до введених користувачем даних.

Тест 3: Щоб оновити інформацію про обліковий запис, переконайтесь, що користувач здатний:

• Оновити інформацію про акаунт (профіль):
  • Оновіть кожну категорію профілю.
• Переконайтеся, що інформація про оновлення відображається правильно у профілі.
• Переконайтеся, що Користувач не в змозі оновити інформацію у Профілі (У деяких програмах ім’я, прізвище, ім’я користувача тощо не дозволяється оновлювати. Хоча це негативне тестування, це одна з основних точок перевірки вважати).
• Скасувати потік оновлення (Навіть якщо це негативне тестування, це також є одним з основних пунктів перевірки, який слід враховувати).

Тест 4: Якщо дозволено деактивацію облікового запису, перевірте, чи здатний Користувач:

• Деактивуйте рахунок.
• Скасувати потік деактивації (Незважаючи на те, що це негативне тестування, це один з основних пунктів перевірки, який слід враховувати).
• Доступ до облікового запису після скасування деактивації.

Тест 5: Якщо для електронної адреси або телефонних номерів потрібні перевірки, то перевірте, чи може користувач:

як відтворювати файли .bin на ПК

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

Випадок 2: Закупівля товару

Закупівля товару зазвичай має загальний потік.

Деякі загальні сценарії, на які дивляться кінцеві користувачі, перелічені тут:

Попередня умова: Користувач повинен увійти до програми.

Тест 1: Деталі продукту, переконайтеся, що користувач здатний:

• Перегляньте сторінку деталей продукту.
• Перегляньте всі підрозділи на сторінці Деталі продукту (Опис, Характеристика, Інформація про бренд тощо).
• Виберіть Кількість товару, Колір, Розмір тощо, доступні на сторінці Деталі продукту.
• Перейдіть на сторінку категорії, підкатегорії зі сторінки Деталі продукту (якщо вона доступна на сторінці Деталі товару).
• Перейдіть на сторінку деталей іншого продукту (якщо передбачено відповідний розділ про товари).
• Перегляньте коментарі та оцінки продукту.
• Сортувати коментарі до товару на основі рейтингів.
• Переглянути загальний рейтинг Продукту.
• Додати коментар до продукту.
• Оновіть його / її коментар до товару.
• Видаліть його / її коментар до товару (якщо він наданий).

Тест 2: Додати в кошик, перевірити, чи є користувач:

• Можливість додати товар до кошика:
  • На сторінці Деталі продукту.
  • На сторінці списку товарів.
• Можливість додати потрібну кількість у кошик (від 1 до встановленого максимального обмеження).
• Не вдається додати товар до кошика, якщо його немає в наявності.

Тест 3: На сторінці кошика переконайтеся, що користувач здатний:

• Перегляньте товар у кошику з деталями ціни для додаткової кількості.
• Оновити кількість (від 1 до встановленого максимального обмеження).
• Вийміть виріб із кошика.
• Поверніться до покупок.
• Перейти до оплати.
• Переглянути порожній кошик, коли не додано товар,

Тест 4: На сторінці Деталі облікового запису переконайтеся, що користувач здатний:

• Продовжуйте з існуючими деталями доставки.
• Оновіть адресу доставки.
• Додайте нову адресу для доставки.
• Продовжте з наявним номером телефону.
• Оновіть номер телефону для замовлення.
• Додайте новий номер телефону для замовлення.
• Поверніться до сторінки Кошик.
• Перейдіть на сторінку оплати.

Тест 5: На Сторінці платежів переконайтеся, що Користувач здатний:

• Перевірте правильність суми, яку потрібно виставити.
• Обробляйте замовлення з усіма доступними опціями (по одному варіанту для кожного окремого замовлення).
• Успішно обробити транзакцію. Перейдіть на сторінку підтвердження замовлення.
• Помилка транзакції (хоча це негативне тестування, це слід розглядати як основний сценарій).
• Застосувати купони:
  • Дійсні купони - успіх. Тут перевірте зміну суми, яку потрібно виставити.
  • Недійсні купони - Невдача
• Прострочені купони - Невдача.
• Поверніться до сторінки Деталі облікового запису.

Перегляд приймально-здавальних випробувань

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

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

На рівні індивідуального тесту огляд слід проводити з урахуванням наведеного нижче:

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

Загалом, весь огляд набору тестів приймання повинен охоплювати:

• Двонаправлена ​​простежуваність: Бізнес-вимоги до тестів І тести до бізнес-вимог.
• Чи охоплюються всі вимоги бізнесу?
• Чи всі бізнес-вимоги охоплюються одним або кількома тестами?
• Чи охоплюються правила ведення бізнесу?
• Чи обробляється спеціальний випадок даних?
• Скільки тестів написано, щоб охопити кожну вимогу чи правило?
• Чи можна тести згрупувати та класифікувати за потоками.
• Чи правильно розподілено тести, щоб виконання було ефективним?

Висновок

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

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

=> Завітайте сюди, щоб отримати повну серію навчальних програм з плану випробувань

Попередній підручник | НАСТУПНИЙ підручник

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

Рекомендована література

• Найкращі засоби тестування програмного забезпечення 2021 р. (Інструменти автоматизації тестування якості)
• Позитивне тестування: значення та переваги пояснюються реальними сценаріями тестування
• Завантажити тестувальник електронної книги
• Випущено TimeShiftX для спрощення тестування на зміщення в часі
• Що таке прийомне тестування (повний посібник)
• Зразок шаблону для звіту про прийомні випробування з прикладами
• Ви фахівець з ручного тестування чи автоматизації? Підробіть для нас!
• Тестування навантаження за допомогою підручників HP LoadRunner