Меню

Сценарій тестування проти тестового випадку: у чому різниця між ними?

test scenario vs test case

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

Різниця між сценарієм тестування і тестовим кейсом.

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

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

Тестовий сценарій проти тестового кейсу

Через 4 роки , компанія отримала проект тестування, де єдиним обмеженням був час, а єдиним очікуванням було повне підтвердження тестування.

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

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

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

Чи швидко замінюються тестові справи сценаріями тестування?

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

запитання для співбесіди з веб-службами для досвідчених

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

Коли документація тестових справ важлива?

  1. Клієнт попросив те саме в рамках проекту.
  2. Тут немає обмежень у часі (я не думаю, що це можливо).
  3. Тестери свіжіші або невідомі продукту.
  4. Політика компанії (я впевнений, що її можна змінити).

Дозвольте поділитися з вами одним досвідом:

Я та моя команда брали участь у тестуванні проекту від компанії Fortune 500 із гнучкими термінами. Ми задокументували тестові випадки з найкращим доступним шаблоном і отримали схвалення клієнтом.

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

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

За їхніми словами, більше не було про що думати, оскільки ми охопили всі сценарії. І переконати їх у цьому думайте нестандартно і генеруйте більше ідей було дійсно жорстким.

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

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

c ++ генерує випадкове число від 0 до 1

Ще один досвід:

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

Усі члени команди, включаючи тих, хто запізнився або не відповів, висувають ідеї. Чому? Не було офіційної документації, де вони повинні були заповнити очікуваний результат для кожної послідовності функціональних можливостей та попередніх умов для кожного тестового випадку. Ми зібрали 40 тестових сценаріїв за день, і це було чудовим досвідом.

На користь мого досвіду, Я хотів би навести приклад.

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

Але якщо сценарії тестування повинні бути написані, це буде питання з 10 рядків, як показано нижче:

Сценарій високого рівня: Функціональність входу
Сценарії низького рівня :

1. Перевірити Запуск програми
2. Перевірити текстовий вміст на сторінці входу
3. Перевірити поле Ім'я користувача
4. Перевірити поле Пароль
5. Перевірити кнопку входу та функцію скасування кнопки

Дивитися також=> 180+ зразків сценаріїв тестування для тестування веб- і настільних програм.

Оскільки нам усім не вистачає часу, тестові сценарії працюють як знеболюючий спрей, а не як старий IODEX. І все-таки ефект однаковий.

Відмінності між сценарієм тестування та тестовим прикладом у табличному форматі

Нарешті, я хотів би підсумувати різницю між сценарієм тестування та тестовим кейсом:

Тестові кейсиТестові сценарії
Що це => Концепція, яка надає детальну інформацію про тестування, кроки, які слід вжити, та очікуваний результатКонцепція, яка надає однорядкову інформацію про те, що тестувати.
Йдеться про => Це більше стосується документування деталей.Це скоріше думка та обговорення деталей.
Важливість => Це важливо, коли тестування заборонено, а розробка на місці. Написання тестових кейсів із деталями допоможе як розробнику, так і команді з контролю якості.Важливо, коли часу менше, і більшість членів команди можуть узгодити / зрозуміти деталі за сценарієм, що складається з одного лайнера.
Перевага => Одноразова документація всіх тестових випадків корисна для відстеження 1000-ти раундів регресійного тестування в майбутньому.
Здебільшого це корисно під час повідомлення про помилки. Тестувальнику просто потрібно вказати ідентифікатор тестового кейсу і не вимагає згадувати кожну детальну інформацію.
Економія часу та діяльність із генерування ідей, яку віддає перевагу спільнота тестування програмного забезпечення нового покоління.
Модифікація та доповнення є простим і не специфічним для людини.
Для величезного проекту, де група людей знає лише конкретні модулі, ця діяльність дає можливість кожному зазирнути в інші модулі та подумати про обговорення та обговорити
Вигідний => Повноцінний документ про тестування - це порятунок для нового тестувальника.Хорошого охоплення тестом можна досягти, розділивши застосування в тестових сценаріях, і це зменшує повторюваність і складність продукту
Недолік => Витрата часу та грошей, оскільки вимагає більше ресурсів для детального викладання всього, що тестувати та як тестуватиЯкщо його створив конкретний користувач, рецензент або інший користувач може не синхронізувати точну ідею. Потрібно більше обговорень та командних зусиль.

Висновок

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

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

Як завжди, ми вітаємо ваші думки та запитання. Будь ласка, налаштуйтесь.

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

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

^