difference between test plan
Дізнайтеся, яка різниця між планом тесту, стратегією тесту, тестовим кейсом, сценарієм тесту, сценарієм тестування та умовами тесту на прикладах:
Тестування програмного забезпечення включає кілька основних, а також важливих концепцій, про які повинен знати кожен тестувальник програмного забезпечення.
У цій статті пояснюватимуться різні концепції тестування програмного забезпечення та їх порівняння.
План тестування проти стратегії тестування, Тестовий кейс проти Тестовий сценарій, Тестовий сценарій проти Тестовий стан та Процедура тестування проти Тестового набору детально пояснені для Вашого легкого розуміння.
=> Клацніть тут, щоб отримати повну серію підручників з плану тестування
Вищезазначене питання, задане Сасі К., є найпоширенішим питанням у нашому Клас тестування програмного забезпечення і я завжди кажу нашим учасникам, що з досвідом ми майже не помічаємо цих слів і що вони стають частиною нашого словникового запасу.
Але часто плутанина оточує їх, і в цій статті я намагаюся визначити декілька загальновживаних термінів.
Різні концепції тестування програмного забезпечення
Нижче наведено різні концепції тестування програмного забезпечення разом із їх порівнянням.
Давайте розпочнемо!!
Що ви дізнаєтесь:
- Різниця між планом випробувань та стратегією випробувань
- Різниця між тестовим прикладом та сценарієм тесту
- Різниця між сценарієм тестування та умовою тестування
- Різниця між процедурою тестування та набором тестів
- Висновок
Різниця між планом випробувань та стратегією випробувань
Стратегія тестування та план тестування - два важливі документи життєвого циклу тестування будь-якого проекту. Тут ми намагаємось дати вам глибокі знання про стратегію тестування та документи плану тестування.
План випробувань
План випробувань можна визначити як документ, що визначає обсяг, мету та підхід до тестування програмного забезпечення. План випробувань - це термін і результат.
План випробувань - це документ, який перелічує всі заходи в рамках проекту контролю якості, планує їх, визначає обсяг проекту, ролі та обов'язки, ризики, критерії входу та виходу, мету випробування та все інше, що ви можете придумати.
План випробувань - це те, що я люблю називати «супердокументом», де перелічено все, що потрібно знати та потребувати. Будь ласка перевірте це посилання для отримання додаткової інформації та зразка.
План випробувань буде розроблений з урахуванням вимог. Доручаючи роботу інженерам-випробувачам, з якихось причин одного з тестувальників замінюють іншим. Тут План випробувань оновлюється.
ручне тестування питання співбесіди для досвідчених
Тестова стратегія окреслює підхід до тестування та все інше, що його оточує. Він відрізняється від плану тестування в тому сенсі, що стратегія тестування є лише підмножиною плану тестування. Це твердий тест-документ, який є певною мірою загальним та статичним. Існує також суперечка щодо того, на яких рівнях використовується стратегія тестування або план тестування, але я насправді не бачу ніякої помітної різниці.
Приклад: План випробувань надає інформацію про те, хто в який час збирається тестувати. Наприклад, Модуль 1 буде перевірений “тестувачем X”. Якщо тестер Y з якихось причин замінює X, план тестування повинен бути оновлений.
Документ плану випробувань
План випробувань - це документ, який надає повну інформацію про завдання тестування, пов’язані з Проектом програмного забезпечення. Він надає такі деталі, як Обсяг тестування, Типи тестування, Цілі, Методологія тестування, Зусилля тестування, Ризики та непередбачені ситуації, Критерії випуску, Результати тестування тощо. Він відстежує можливі тести, які будуть виконуватися в системі після кодування.
План випробувань, очевидно, має змінитися. Спочатку проект плану випробувань буде розроблений на основі чіткості проекту на той час. Цей початковий план буде модифікований у міру прогресу проекту. Керівник контрольної групи або керівник тесту може підготувати документ про план тестування. Він описує Технічні характеристики і може змінюватися на основі тих самих.
Що тестувати, коли тестувати, хто тестувати і як тестувати, буде визначено в плані тестування. План випробувань розбере список питань, залежностей та основних ризиків.
Види плану випробувань
Плани випробувань можуть бути різних типів залежно від стадії випробувань. Спочатку буде генеральний план випробувань для всього виконання проекту. Окремі плани тестування можуть бути створені для певних типів тестування, таких як тестування системи, тестування системної інтеграції, тестування прийнятності користувачами тощо.
Інший підхід полягає у створенні окремих планів тестування функціонального та нефункціонального тестування. При такому підході виконання тестування матиме окремий план тестування.
Зміст документа плану тестування ( Структура плану випробувань IEEE-829 )
Важко скласти чіткий формат плану тестування. Формат плану випробувань може змінюватися залежно від конкретного проекту. IEEE визначив стандарт для планів випробувань, які описані як структура плану випробувань IEEE-829.
Нижче наведено рекомендації IEEE щодо стандартного вмісту плану випробувань:
- Ідентифікатор плану випробувань
- Вступ
- Тестові завдання
- Проблеми програмного ризику
- Особливості, що перевіряються
- Особливості, що не перевіряються
- Підхід
- Критерії проходження / відмови товару (або) Критерії прийняття
- Критерії призупинення та вимоги відновлення
- Тестові результати
- Тестові завдання
- Екологічні вимоги
- Потреби у персоналі та навчанні
- Обов'язки
- Розклад
- Схвалення
Пропоноване читання => Підручник з плану тестування - ідеальний посібник
Тестова стратегія
Стратегія тестування - це набір керівних принципів, які пояснюють схему тестування та визначають спосіб проведення тестування.
Приклад: Тестова стратегія включає такі деталі, як «Індивідуальні модулі перевіряються членами тестової групи». У цьому випадку те, хто тестує, не має значення - отже, це загальний характер, і зміна в члені команди не повинна оновлюватися, зберігаючи її статичною.
Документ стратегії тестування
Метою тестової стратегії є визначення підходу до тестування, типів тестів, тестових середовищ та інструментів, які будуть використовуватися для тестування, та детальних відомостей про те, як стратегія тестування буде узгоджена з іншими процесами. Документ стратегії тестування призначений живим документом і буде оновлений **, коли ми отримаємо більше ясності щодо вимог, параметрів SLA, тестового середовища та підходу до управління збіркою тощо.
Тестова стратегія призначена для всієї команди проектів, до складу якої входять спонсори проектів, бізнес-МСП, розробка додатків / інтеграції, партнери з системної інтеграції, групи перетворення даних, команди управління збіркою / випуском, такі як технічні лідери, архітектурні лідери та команди з розгортання та інфраструктури.
** Деякі стверджують, що колись визначена стратегія тестування ніколи не повинна оновлюватися. У більшості тестувальних проектів воно оновлюється в міру прогресу проекту.
Нижче наведені важливі розділи, які повинен мати документ про стратегію тестування:
# 1) Огляд проекту
Цей розділ може розпочатися з огляду організації, а потім короткого опису поточного проекту. Він може містити деталі нижче
- Яка була потреба у проекті?
- Яких цілей буде досягнутий проектом?
Таблиця скорочень: Краще включити таблицю з абревіатурами, які читач документа може придумати, посилаючись на документ.
# 2) Сфера застосування
Сфера вимог може включати сферу застосування та функціональну сферу
Сфера застосування визначає систему, що перевіряється, та вплив на систему внаслідок нових або змінених функціональних можливостей. Також можна визначити відповідні системи.
| Система | Вплив (нова або змінена функціональність) | Пов’язана система |
|---|---|---|
| Тут описано, як тестувати, коли тестувати, хто тестувати і що тестувати. | У ньому описано, якого типу техніки слід дотримуватися та який модуль тестувати. | |
| Система A | Нові вдосконалення та виправлення помилок | • Система В • Система C |
Функціональний обсяг визначає вплив на різні модулі в системі. Тут буде пояснено кожну відповідну систему щодо функціональності.
| Система | Модуль | Функціональність | Пов’язана система |
|---|---|---|---|
| Система C | Модуль 1 | Функціональність 1 | Система В |
| Функціональність 2 | Система C |
# 3) План випробувань високого рівня
План випробувань - це окремий документ. У стратегію тестування може бути включений план тестування високого рівня. План випробувань високого рівня може включати цілі випробування та обсяг випробувань. Обсяг випробувань повинен визначати як обсяг, так і поза сферою діяльності.
# 4) Тестовий підхід
У цьому розділі описується підхід до тестування, який буде дотримуватися протягом життєвого циклу тестування.
Відповідно до наведеної схеми тестування проводитиметься у два етапи, тобто стратегія тестування та планування та виконання тесту. Етап стратегії тестування та планування буде одноразовим для загальної програми, тоді як етапи виконання тесту будуть повторюватися для кожного циклу загальної програми. Наведена діаграма показує різні етапи та результати (результат) на кожній фазі підходу до виконання.
Тестовий підхід повинен включати нижче підрозділи
а) Графік випробувань: Поясніть запропонований графік проекту у цьому підрозділі
b) Підхід до функціонального тестування: Використання цього підрозділу забезпечує огляд кожної фази та відповідних критеріїв входу та виходу. Різні етапи тестування - це модульне тестування, тестування системи, тестування системної інтеграції, тестування прийнятності користувачами та наскрізне тестування.
в) Тестування ключових показників ефективності:
- Пріоритетність тестового випадку: Визначте підхід до визначення пріоритетів тестових випадків, щоб у випадку часових обмежень тестова група могла виконувати сценарії високого пріоритету. Між зацікавленими сторонами проекту повинна бути домовленість щодо можливих ризиків, пов’язаних з невиконанням усіх запланованих сценаріїв.
- Пріоритетність дефектів: Наступною темою, яку слід тут висвітлити, є стратегія визначення пріоритетів дефектів. Визначте рівень пріоритету та дайте опис кожному рівню, наприклад критичному, високому, середньому тощо
- Час обробки дефектів: Час обробки дефекту визначається як час між тим, коли дефект був вперше піднятий, і коли дефект виправлений і настає для повторного тестування. Швидкий перехід забезпечує швидке тестування та дотримання термінів проекту. Для кожного рівня пріоритету дефекту визначте час виконання.
| Рівень пріоритету | Час обробки дефектів |
|---|---|
| 1 - Критичний | Час реакції: 2 години або менше Виправлення готовності до міграції: 1 робочий день або менше |
# 5) Покриття тесту
У цьому розділі описуються процеси, яких дотримуватиметься команда з контролю якості для оптимізації охоплення бізнес-функціональних вимог у тестових сценаріях та тестових випадках. Матриця простежуваності вимог: (RTM) може використовуватися для відстеження всіх вимог з відповідними сценаріями тестування та тестовими кейсами.
як відкрити розширення файлу json -
# 6) Тестове середовище
Визначте різні доступні середовища контролю якості. Згадайте, яке тестування проводитиметься в якому середовищі та ким. Створіть план резервного копіювання середовища для піклування про надзвичайні ситуації. Доступ до кожного середовища повинен бути регламентованим та чітко викликана.
У цьому розділі також можна згадати інструменти тестування, які збираються використовувати.
| Діяльність | Інструмент | Зауваження |
|---|---|---|
| Управління тестами | HP ALM | Згадайте причину використання цього засобу |
| Управління дефектами | JIRA | Згадайте причину використання цього засобу |
# 7) Результати контролю якості та показники
Перелічіть усі результати контролю якості
| С. Ні. | Результат |
|---|---|
| 1 | Документ стратегії тестування |
| два | Матриця простежуваності вимог |
| 3 | Сценарії тесту ST |
| 4 | Підсумковий звіт про випробування |
| 5 | Список сценаріїв, що відповідають вимогам автоматизації |
Перелічіть усі показники якості
| # | Назва метрики | Визначення метрики | Метрична формула | Метрична одиниця виміру | Звіти, в яких використовуються показники |
|---|---|---|---|---|---|
| 1 | Показники покриття вимог (RCM) | Покриття вимог за допомогою контролю якості | Співвідношення # випробуваних вимог до # визначених вимог | % | Щотижневий звіт про стан контролю якості, Звіт про випробування |
| два | Покриття тесту | Висвітлення тестового випадку | Співвідношення кількості виконаних тестових справ / запланованої кількості тестових справ | % | Щоденний звіт про виконання, Щотижневий звіт про стан контролю якості, Звіт про випробування |
# 8) Управління дефектами
Чітко визначте стратегію управління дефектами, створивши робочий процес, методологію відстеження дефектів та процес сортування дефектів. Згадайте дефект відповідальності за ролі кожного тестувальника. Періодичний аналіз дефектів та аналіз першопричини покращать загальну якість тестування
# 9) Менеджмент комунікацій
Встановіть вказівки щодо звітів про стан, зустрічей щодо статусу та офшорних комунікацій.
# 10) Припущення, ризики та залежності
Опишіть припущення, на яких базується проект. Сюди можуть входити терміни, ресурси та можливості системи. Опишіть будь-які залежності, такі як інші проекти, наявність тимчасових ресурсів, інші терміни, які можуть вплинути на проект
# 11) Додаток
Включіть у цей розділ такі речі, як ролі та обов'язки, робочий часовий пояс та посилання
Подальше читання=> Посібник із написання документа про хорошу стратегію тестування .
План тестування проти стратегії тестування
| ПЛАН ТЕСТУВАННЯ | СТРАТЕГІЯ ТЕСТУ |
|---|---|
| Це походить від специфікації вимог до програмного забезпечення (SRS). | Він походить із документа «Вимоги до бізнесу» (BRS). |
| Він готується керівником тесту або менеджером. | Його розробляє керівник проекту або бізнес-аналітик. |
| Ідентифікатор плану випробувань, особливості, що підлягають випробуванню, методи випробувань, завдання випробування, ознаки, що відповідають критеріям проходження або відмови, результати випробувань, обов'язки та графік тощо - це складові плану випробування. | Цілі та сфера застосування, формати документації, тестові процеси, структура звітування команди, стратегія комунікації з клієнтом тощо є компонентами тестової стратегії. |
| Якщо відбулася нова функція або змінилися вимоги, документ плану тестування оновлюється. | Тестова стратегія підтримує стандарти під час підготовки документа. Його також називають статичним документом. |
| Ми можемо підготувати план тестування індивідуально. | У невеликих проектах стратегія тестування часто зустрічається як розділ плану тестування. |
| Ми можемо підготувати план тестування на рівні проекту. | Ми можемо використовувати стратегію тестування в декількох проектах. |
| Ми можемо описати технічні характеристики за допомогою плану випробувань. | Тестова стратегія описує загальні підходи. |
| План випробувань буде змінюватися протягом проекту. | Після затвердження стратегія тестування зазвичай не змінюється. |
| План тестування пишеться після виходу з вимоги. | Стратегія тестування складається перед планом тестування. |
| Плани випробувань можуть бути різних типів. Буде створений генеральний план тестування та окремий план тестування для різних типів тестувань, таких як план тестування системи, план тестування продуктивності тощо. | Для проекту буде лише один документ стратегії тестування. |
| План випробувань повинен бути чітким і стислим. | Тестова стратегія забезпечує загальне керівництво для поточного проекту. |
Різниця між цими двома документами незначна. Тестова стратегія - це статичний документ високого рівня про проект. З іншого боку, в плані тестування буде вказано, що тестувати, коли тестувати і як тестувати.
Різниця між тестовим прикладом та сценарієм тесту
На мій погляд, ці два терміни можна використовувати як взаємозамінні. Так, я кажу, що різниці немає. Тестовий випадок - це послідовність кроків, які допомагають нам виконати певний тест програми. Тестовий сценарій - це теж саме.
Зараз існує одна думка, що тестовий приклад - це термін, що використовується в середовищі тестування вручну, а сценарій тесту використовується в середовищі автоматизації. Це частково відповідає дійсності, оскільки рівень комфортності тестувальників у відповідних полях, а також те, як інструменти посилаються на тести (деякі викликають тестові сценарії, а деякі викликають їх для тестування).
Отже, по суті, тестовий сценарій та тестовий кейс - це кроки, які слід виконати у програмі для перевірки її функціональності вручну чи за допомогою автоматизації.
Подальше читання=> Як писати ефективні тестові кейси? і Приклад шаблону тестового кейсу .
| ТЕСТОВА СПРАВА | СЦЕНАРІЙ ТЕСТУ |
|---|---|
| Це базова форма для тестування заявки послідовно. | Після того, як ми розробимо, сценарій буде запускати його кілька разів, доки вимога не буде змінена. |
| Це поетапна процедура, яка використовується для тестування програми | Це набір інструкцій для автоматичного тестування програми. |
| Термін Test Case використовується в середовищі ручного тестування. | Термін Тестовий сценарій використовується в середовищі тестування автоматизації. |
| Це робиться вручну. | Це робиться за допомогою сценарію. |
| Він розроблений у формі шаблонів. | Він розроблений у формі сценаріїв. |
| Шаблон тесту включає ідентифікатор костюма тесту, дані тесту, процедуру тесту, фактичні результати, очікувані результати тощо. | У Test Scrip ми можемо використовувати різні команди для розробки сценарію. |
| Використовується для тестування програми. | Він також використовується для тестування програми. |
| Приклад: нам потрібно перевірити кнопку входу в програму, Ці кроки включають: а) Запустіть програму. b) Перевірте, чи відображається кнопка входу чи ні. | Приклад: Ми хочемо натиснути кнопку зображення у програмі. Сценарій включає: а) Клацніть на кнопку Зображення. |
Різниця між сценарієм тестування та умовою тестування
Сценарій тесту: Це спосіб визначити всі можливі способи тестування програми. Це одне твердження, яке охоплює всі можливі способи тестування програми.
Умова тесту: Умова тесту - це специфікація, якої повинен дотримуватись тестувальник для тестування Заявки.
Це однорядковий покажчик, який тестувальники створюють як початковий, перехідний крок до фази проектування тесту. Це здебільшого однорядкове визначення «Що», яке ми збираємось перевірити щодо певної особливості. Зазвичай тестові сценарії вводяться для створення тестових кейсів.
У гнучких проектах тестові сценарії є єдиними результатами проектування тестів, і за ними не пишеться тестових випадків. Тестовий сценарій може призвести до декількох тестів.
Приклади сценаріїв випробувань:
- Перевірте, чи може адміністратор додати нову країну
- Перевірте, чи може адміністратор видалити існуючу країну
- Перевірте, чи можна оновити існуючу країну
З іншого боку, умови тестування є більш конкретними. Це можна приблизно визначити як мету / мету певного тесту.
Приклад умови тесту: У наведеному вище прикладі, якщо ми мали протестувати сценарій 1, ми можемо перевірити такі умови:
- Введіть назву країни як 'Індія' (дійсне) та перевірте, чи не додано країну
- Введіть поле та перевірте, чи додано країну.
- У кожному випадку описуються конкретні дані, і мета тесту є набагато точнішою.
Подальше читання=> 180+ зразків сценаріїв тестування для тестування веб- і настільних додатків.
| СЦЕНАРІЙ ТЕСТУ | УМОВА ТЕСТУ |
|---|---|
| Це одне рядкове твердження, щоб пояснити, що ми збираємось перевірити. | Умова тесту описує основну мету тестування програми. |
| Це процес тестування програми всіма можливими способами. | Умови тестування - це статичні правила, яких слід дотримуватись для тестування програми. |
| Тестові сценарії - це вхідні дані для створення тестових кейсів. | Це дає головну мету перевірити заявку. |
| Тестовий сценарій охоплює всі можливі випадки тестування програми. | Умови тесту дуже специфічні. |
| Це зменшує складність. | Це робить системну помилку вільною. |
| Тестовий сценарій може бути одиночним або групою тестових випадків. | Це мета тестових випадків. |
| Написавши сценарії, буде легко зрозуміти функціональність програми. | Умови тесту дуже специфічні. |
| Приклади сценаріїв тестування: # 1) Перевірте, чи може адміністратор додати нову країну. # 2) Перевірте, чи адміністратор може видалити існуючу країну. # 3) Перевірте, чи можна оновити існуючу країну. | Приклади умов випробування: # 1) Введіть назву країни як 'Індія' та перевірте, чи не додано країну. # 2) Залиште порожні поля та перевірте, чи додано країну. |
Різниця між процедурою тестування та набором тестів
Процедура тестування - це комбінація тестових випадків, заснованих на певній логічній причині, наприклад, виконанні наскрізної ситуації або чогось подібного. Порядок запуску тестових кейсів є фіксованим.
Процедура випробування: Це не що інше, як тестовий життєвий цикл. Є 10 кроків у життєвому циклі тестування.
Вони є:
безкоштовно завантажити брандмауер для Windows 10 -
- Оцінка зусиль
- Ініціювання проекту
- Системне дослідження
- План випробувань
- Тестовий кейс для проектування
- Автоматизація тестів
- Виконайте тестові справи
- Повідомте про дефекти
- Регресійне тестування
- Аналіз та підсумковий звіт
Наприклад , якби я хотів протестувати надсилання електронного листа з Gmail.com, порядок тестових випадків, які я б об’єднав для формування процедури тестування, був би таким:
- Тест для перевірки логіна
- Тест на створення електронного листа
- Тест на прикріплення одного / декількох вкладень
- Форматування електронного листа необхідним способом за допомогою різних опцій
- Додавання контактів або адрес електронної пошти в поля To, BCC, CC
- Надсилання електронного листа та переконання, що воно відображається в розділі “Надіслана пошта”
Усі наведені вище тестові приклади згруповані для досягнення певної цілі в кінці. Крім того, процедури тестування містять кілька тестових випадків, об’єднаних у будь-який момент часу.
Набір тестів, навпаки, являє собою список усіх тестових випадків, які мають бути виконані як частина тестового циклу або фази регресії тощо. Не існує логічного групування на основі функціональності. Порядок виконання складових тестових справ може бути важливим, а може і не бути важливим.
Тестовий набір: Test Suite - це контейнер, що містить набір тестів, які допомагають тестувальникам у виконанні та звітуванні про стан виконання тесту. Він може приймати будь-який із трьох станів, тобто активний, триває та завершений.
Приклад тестового набору : Якщо поточною версією програми є 2.0. Попередня версія 1.0 могла мати 1000 тестових кейсів, щоб перевірити її повністю. Для версії 2 існує 500 тестових кейсів, щоб просто протестувати нову функціональність, додану в новій версії.
Отже, поточним набором тестів буде 1000 + 500 тестових випадків, які включають як регресію, так і нову функціональність. Набір - це теж комбінація, але ми не намагаємось досягти цільової функції.
Тестові набори можуть містити 100 або навіть 1000 тестів.
| ПРОЦЕДУРА ТЕСТУ | ТЕСТОВИЙ ЛЮКС |
|---|---|
| Створення процедур випробувань базується на наскрізному потоці випробувань. | Тестові набори створюються на основі циклу або на основі обсягу. |
| Це комбінація тестових кейсів для тестування програми. | Це група тестів для тестування програми. |
| Це логічне групування на основі функціональних можливостей. | Не існує логічного групування на основі функціональних можливостей. |
| Процедури тестування - це продукти, що поставляються в процесі розробки програмного забезпечення. | Він виконується як частина тестового циклу або регресії. |
| Порядок виконання є фіксованим. | Порядок виконання може бути не важливим. |
| Процедура тестування містить наскрізні тестові кейси. | Набір тестів містить усі нові функції та тести регресії. |
| Процедури тестування кодуються новою мовою, що називається TPL (мова процедури тестування). | Набір тестів містить ручні тестові кейси або сценарії автоматизації. |
Висновок
Концепції тестування програмного забезпечення відіграють важливу роль у життєвому циклі тестування програмного забезпечення.
Чітке розуміння вищезазначених концепцій разом із їх порівнянням дуже важливо для кожного тестувальника програмного забезпечення для ефективного проведення процесу тестування.
Зазвичай такі статті є чудовими вихідними пунктами для глибших дискусій. Тож, будь ласка, внесіть свої думки, домовленості, незгоди та будь-що інше, у коментарях нижче. Ми з нетерпінням чекаємо вашого відгуку.
Ми також вітаємо ваші запитання щодо тестування програмного забезпечення загалом або чогось, що стосується вашої кар’єри тестування. Ми розглянемо їх більш детально в наступних публікаціях цієї ж серії.
Щасливого читання !!
=> Завітайте сюди, щоб отримати повну серію навчальних програм з плану випробувань
НАЗАД Підручник | НАСТУПНИЙ підручник
Рекомендована література
- Підручник з плану тестування: Посібник із написання документа плану плану тестування з нуля
- Як написати документ про стратегію тестування (із зразком шаблону стратегії тестування)
- Як підготуватися до написання тестових кейсів (Поради щодо продуктивності)
- Що таке сценарій тесту: Шаблон тесту сценарію з прикладами
- Різниця між планом перевірки ефективності та стратегією перевірки ефективності
- Як писати тестові справи: Остаточний посібник із прикладами
- Зразок шаблону плану тестування програмного забезпечення з форматом та змістом
- Сценарій тестування проти тестового випадку: у чому різниця між ними?