Меню

Написання тестових справ із документа SRS (СКАЧАТИ Тестові зразки проектів у реальному часі)

writing test cases from srs document

Спробуйте Наш Інструмент Для Усунення Проблем

Написання тестових справ із документа SRS (Завантажте зразки тестових випадків проекту) - Тестування програмного забезпечення QA Training Day 4

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

Наразі в цій безкоштовній онлайн-програмі з контролю якості ми закінчили:

  1. Огляд SRS,
  2. Сценарій тесту / ідентифікація обсягу тесту і
  3. Задокументований план випробувань .

Написання тестових справ із документа SRS

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

Як зазначено в статті до цього: Тестові випадки задокументовані командою з контролю якості, поки триває фаза коду SDLC. Іншими словами, поки команда розробників розробляє програмну систему, команда тестування готується до тестових кейсів, які допоможуть нам протестувати систему, як тільки вона буде готова, тобто в кінці фази коду.

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

Давайте негайно дійдемо до цього.

Що ви дізнаєтесь:

Основи написання тестових справ

# 1) Якщо сценарії тестування стосувались «Що ми збираємось перевірити» на AUT - це тестові приклади “Як ми будемо перевіряти вимогу”.

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

# два) Вхідні дані для створення документа тестового випадку - це FRD, сценарії тестування, створені на попередньому етапі, та будь-які інші довідкові документи, якщо вони є.

# 3) Документація з тестового кейсу є важливим результатом роботи команди з контролю якості та передається BA, PM та іншим командам для отримання зворотного зв'язку.

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

# 5) Як і у випадку з тестовими сценаріями, перед тим, як ми почнемо документацію з тестового випадку, слід узгодити загальний шаблон. Для створення тестових кейсів можна використовувати практично все. 2 найбільш часто використовувані варіанти - це MS Excel та MS word.

# 6) MS word шаблон виглядає приблизно так:

Тестові кейси MS word template

# 7) Шаблон Excel може виглядати наступним чином:

qa навчальні тестові кейси зразки xls

# 8) З наведених вище двох шаблонів можна помітити, що поля (або компоненти), що складають тестовий приклад, однакові, різниця полягає лише в тому, як вони організовані.

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

Поля в тестових випадках

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

Ідентифікатор тестового випадку та Опис тестового випадку є загальними.

Інші поля можна пояснити наступним чином:

  • Передумова: Стан AUT (стан, в якому AUT повинен бути для того, щоб ми почали).
  • Вхідні дані: Етапи введення даних. Для цих кроків важливо зазначити, яка вхідна інформація потрібна - Тестові дані.
  • Точка перевірки / тригер / дія : Що зумовлює перевірку? (Клацніть на кнопку, перемикач або доступ до посилання. Переконайтеся, що є принаймні одна точка перевірки тестового випадку - інакше це все буде введенням даних, нічого не потрібно шукати. Також для того, щоб забезпечити достатню модульність, намагайтеся не поєднувати занадто багато точок перевірки в одному тестовому випадку. Оптимальним є 1 на тест.)
  • Вихід: Очікуваний результат.
  • Постумова: Це додаткова інформація, яка надається на користь тестера, лише для того, щоб зробити тест більш проникливим та інформативним. Це включає пояснення того, що відбувається або що можна очікувати від AUT, як тільки всі етапи тестування будуть виконані.

Див. Також => Зразок шаблону тестового кейсу

Зразки тестових випадків проекту в реальному часі (Завантажити)

Тепер, коли ми маємо достатньо довідкової інформації, щоб розпочати процес створення тестових кейсів, давайте почнемо і створимо кілька тестових кейсів для нашого Live Project.

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

=> Завантажте зразок документа про тестування для нашого проекту Live тут .

Примітка: Є декілька зображень, згаданих до зразків документа XLS. Якщо ви переглядаєте це в попередній версії MS Office, ви можете зіткнутися з проблемами сумісності.

Ми перелічили ці зображення нижче відповідно до їх назв у файлах XLS:

Переглянути фото 1
Переглянути фото 2
Переглянути фото 3

Там все зроблено і все добре.

Методи написання / оптимізації тестових кейсів

А тепер уявіть ситуацію, коли на певній сторінці є кілька полів 10 або на ній є складна бізнес-логіка. Щоб переконатись, що ми оптимізуємо процес створення тестових кейсів у подібних ситуаціях, ми, тестери, маємо певні методи оптимізації тестових кейсів.

Нижче наведено посилання для отримання додаткової інформації про ці методи.

Як мені оновити BIOS Windows 10

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

Мало важливих моментів, на які слід звернути увагу

  • Тестові кейси, які ми створюємо, є не лише точкою відліку для фази контролю якості, а й UAT.
  • Внутрішні тести є Рецензований в колективі .
  • Коли певна ситуація не вирішується тестовим випадком - це правило, воно не збирається тестуватися. Отже, це гарне місце, щоб перевірити, чи досягає створений нами набір тестів цілі 100% охоплення тестом чи ні. Для цього можна створити матрицю простежуваності. Перевірте все, що можна знати про Матриця простежуваності тут .
  • Інструменти - такі інструменти управління тестом, як Контроль якості , qТест допоможіть нам у створенні тестового випадку. Для прикладу того, як можна розглядати тестові випадки за допомогою Центру якості, перегляньте це Підручник Центру якості .
  • Засоби автоматизації можна використовувати для створення тестових кейсів - у цьому випадку вони називаються тестовими сценаріями.
Про порада :Будь ласка, виконайте перевірку орфографії та граматики на кожному документі, який ми створюємо. Ми є представниками якості для ІТ-проектів, і це не відображає нас позитивно, якщо самі наші продукти мають нижчу якість.

Це підводить нас до фінішу ще одного цікавого сегменту.

Висновок

Закінчення процесу створення тесту / фази проектування тесту (STLC) та кінець фази коду (SDLC), як правило, означають закінчення фази підготовки до тесту та початок фази виконання тесту.

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

=> QA Training day 5: Виконання тесту

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

Будь ласка, повідомте нам свої запитання та коментарі нижче. Щасливого тестування!

НАЗАД Підручник | НАСТУПНИЙ підручник

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

^