test plan tutorial guide write software test plan document from scratch
Кінцевий посібник із документації плану тестування програмного забезпечення:
Цей посібник пояснить вам все про документ плану тестування програмного забезпечення та допоможе вам написати / створити детальний план тестування програмного забезпечення з нуля разом із відмінності між плануванням тесту та виконанням тестів.
Тренінг з контролю якості проекту 3 дня - Після ознайомлення наших читачів із живим додатком нашого безкоштовне навчання з тестування програмного забезпечення в Інтернеті , ми дізналися як переглянути SRS та написати сценарії тесту . І зараз настав час заглибитися глибше в найважливішу частину життєвого циклу тестування програмного забезпечення - тобто Планування тестів .
Список ВСІХ підручників цієї серії:
Документ планування тесту:
Підручник No1: Як написати документ плану тестування (Цей підручник)
Підручник No2: Зміст шаблону простого плану тестування
Підручник No3: Приклад плану тестування програмного забезпечення
Підручник No4: Різниця між планом випробувань та стратегією випробувань
Підручник No5: Як написати документ про стратегію тестування
Поради з планування тестів:
Підручник No6: Управління ризиками під час планування випробувань
Підручник No7: Що робити, коли для тестування недостатньо часу
Підручник No8: Як ефективно планувати та керувати тестовими проектами
Планування тестів на різних етапах STLC:
Підручник No9: Планування регресійного тесту
Підручник No10: План випробувань UAT
Підручник No11: План приймальних випробувань
Планування автоматизації тестів:
Підручник No12: План автоматизації випробувань
Підручник No 13: Планування тестування додатків ERP
Підручник No14: Планування випробувань HP ALM
Підручник No15: Планування тесту Mindmap
Підручник No16: План випробувань JMeter та WorkBench
Що ви дізнаєтесь:
Створення плану випробувань - найважливіший етап тестування
Цей інформаційний посібник пояснить вам шляхи та процедури написання документа про план тестування.
Наприкінці цього підручника ми поділилися 19-сторінковий вичерпний документ про план випробувань який був спеціально створений для прямого проекту OrangeHRM, який ми використовуємо безкоштовно QA серії навчальних занять
Що таке план випробувань?
План випробувань - це динамічний документ . Успіх проекту тестування залежить від добре складеного документа про план тестування, який є актуальним у всі часи. План випробувань більш-менш схожий проект того, як відбувається тестування брати участь у проекті.
Нижче наведено кілька підказок щодо плану випробувань:
# 1) План випробувань - це документ, який діє як орієнтир і лише на основі цього тестування проводиться в межах команди контролю якості.
# два) Це також документ, яким ми ділимося з бізнес-аналітиками, менеджерами проектів, командою розробників та іншими командами. Це сприяє підвищенню рівня прозорості роботи групи з контролю якості для зовнішніх команд.
# 3) Це задокументовано менеджером з контролю якості / керівником з контролю якості на основі даних членів команди з контролю якості.
як відкрити файл .air
# 4) Планування тестування зазвичай виділяється 1/3рдчасу, що займає все залучення до контролю якості. Інша 1/3рдпризначений для проектування тестів, а решта - для виконання тесту.
# 5) Цей план не є статичним і оновлюється на вимогу.
# 6) Чим детальнішим та вичерпнішим є план, тим успішнішим буде тестування.
Процес STLC
Зараз ми на півдорозі до нашої живої серії проектів. Отже, давайте зробимо крок назад від програми і поглянемо на процес тестування програмного забезпечення (STLC).
STLC можна приблизно розділити на 3 частини:
- Планування тестів
- Дизайн тесту
- Виконання тесту
У нашому попередньому навчальному посібнику ми дізналися, що в рамках практичного проекту з контролю якості ми розпочали огляд SRS та написання сценарію тестування - що насправді є другим етапом у процесі STLC. Дизайн тесту включає деталі щодо того, що тестувати і як тестувати.
Чому ми не почали з планування тестів?
Планування справді є першим і головним заходом, який відбувається в будь-якому проекті тестування.
Планування тестів на етапах SDLC
| Фаза SDLC | Діяльність з планування тестів |
|---|---|
| Розклади => | Підготовка до сценарію тесту |
| Ініціювати | В ідеалі команда QA повинна брати участь, поки обсяг проекту збирається від замовника / клієнта у формі бізнес-вимог. Але в реальному світі це не так. З практичної точки зору, участь команди з контролю якості є NIL. Наприкінці цього етапу БРР доопрацьовується та створюється базовий План проекту. |
| Визначте | ЄСВ створюється з BRD. Створено початковий проект плану тестування. На даний момент, оскільки команда з контролю якості не закінчила огляд SRS, обсяг тестування не ясний. Отже, ТП на цьому етапі буде містити лише інформацію про те, коли відбуватиметься тестування, інформацію про проект та інформацію про команду (якщо вона у нас є). |
| Дизайн | Проводиться огляд SRS та визначається обсяг тестування. Ми маємо набагато більше інформації про те, що тестувати, і гарну оцінку кількості тестових кейсів, які ми можемо отримати тощо. Створена друга версія плану тестування, що включає всю цю інформацію. |
З наведеної таблиці ясно видно, що план тестування - це не просто документ, який можна створити відразу і використовувати з цього моменту.
Складові документа плану
| Елементи у шаблоні плану випробувань | Що вони містять? |
|---|---|
| Обсяг => | Сценарії тесту / Цілі тесту, які будуть перевірені. |
| Поза зоною дії => | Покращена ясність щодо того, що ми не збираємося висвітлювати |
| Припущення => | Усі умови, які повинні виконуватися, щоб ми могли успішно діяти далі |
| Тестова документація - тестові кейси / дані тестів / налаштування середовища | |
| Виконання тесту | |
| Тестовий цикл - скільки циклу | |
| Дата початку та закінчення циклів | |
| Ролі та обов'язки => | Члени команди перераховані |
| Хто що повинен робити | |
| перелічено власників модулів та їх контактну інформацію | |
| Результати => | Які документи (тестові артефакти) збираються виготовити в які часові рамки? |
| Що можна очікувати від кожного документа? | |
| Навколишнє середовище => | Які вимоги до довкілля існують? |
| Хто буде керувати? | |
| Що робити у разі проблем? | |
| Інструменти => | Наприклад, JIRA для відстеження помилок |
| Увійти | |
| Як користуватися JIRA? | |
| Управління дефектами => | Кому ми будемо повідомляти про дефекти? |
| Як ми будемо звітувати? | |
| Що очікується - ми надаємо скріншот? | |
| Ризики та управління ризиками => | Ризики перераховані |
| Аналізуються ризики - імовірність і вплив задокументовані | |
| Складено плани зменшення ризику | |
| Критерії виходу => | Коли припиняти тестування? |
Оскільки вся вищезазначена інформація є найбільш важливою для щоденна робота проекту з контролю якості , важливо періодично оновлювати документ плану.
Зразок документа плану тестування для реального проекту
Для нашої “ ORANGEHRM ВЕРСІЯ 3.0 - МОЙ ІНФОРМАЦІЙНИЙ МОДУЛЬ ” Проект та додається нижче. Погляньте, будь ласка. Для пояснення розділів до документа червоним кольором додано додаткові коментарі.
Цей план тестування призначений як для функціональної, так і для фаз UAT. Це також пояснює процес управління тестами за допомогою інструмента HP ALM.
Завантажте зразок плану випробувань:
Формат документа => Клацніть тут, щоб завантажити план тестування у форматі Doc це той, який ми створили для прямого проекту OragngeHRM, і ми також використовуємо його для нашого курсу аварійного тестування програмного забезпечення.
Формат PDF => Клацніть тут, щоб завантажити план тестування у форматі pdf .
Файли робочих аркушів (.xls), згадані у вищевказаних версіях doc / pdf => Завантажте Згадані файли XLS у наведеному вище Плані випробувань
Наведений вище шаблон є дуже вичерпним і детальним. Тому, будь ласка, прочитайте його уважно для найкращих результатів.
Оскільки план також створений і пояснено добре, перейдемо до наступного етапу як SDLC, так і STLC.
Код SDLC:
Поки решта проектів витрачала свій час на створення TDD, ми QA визначили обсяг тестування (сценарії тестування) та створили перший надійний проект плану тестування. Наступним етапом SDLC є перевірка, коли відбувається кодування.
На цьому етапі розробники - основна увага для всієї команди. Команда QA також віддається найважливішому завдання, яке є нічим іншим, як «Створення тестового кейсу» .
Якщо сценаріями тестування було “Що тестувати”, тоді тестові випадки стосуються “Як тестувати”. Створення тестового кейсу є переважною частиною етапу тестового проектування STLC. Вхідними даними для діяльності зі створення тестового сценарію є Тестові сценарії та документ SRS.
Для таких тестерів, як ми, Тестові кейси є справжньою угодою - це речі, в яких ми проводимо більшу частину часу. Ми їх створюємо, переглядаємо, виконуємо, підтримуємо, автоматизуємо - і добре, ви отримуєте картину. Незалежно від того, наскільки ми досвідчені та яку роль ми відіграємо у проекті - ми все одно працюємо з тестовими кейсами.
Планування тестів проти виконання тесту
Планування тестування програмного забезпечення залишає набагато кращий обсяг порівняно з Фаза STLC . Постачання якісного програмного забезпечення забезпечується командою випробувачів. І що потрібно зробити під час тестування, насправді вирішується на етапі планування тестування.
найкращий безкоштовний відеоконвертер для Windows 10
Цей розділ надасть повний огляд та включить ілюстрації щодо важливості планування випробувань та фаза виконання . Прочитавши це, ви зрозумієте важливе значення фази планування у порівнянні з фазою виконання з більшою живі приклади та приклади для ілюстрацій .
Планування тестів
Нижче наведено деякі важливі речі, на які слід звернути увагу під час планування:
Планування тесту - це основний важливий розділ циклу тестування. Результат етапу тестування визначатиметься якістю та обсягом планування, проведеного для тестування.
Планування тестування зазвичай відбувається на етапі розробки з метою економії часу на виконання тесту за взаємною згодою всіх залучених сторін.
Серед важливих фактів, на які слід звернути увагу, є:
- Планування слід починати паралельно з розробкою, за умови, що вимоги були заморожені.
- Під час доопрацювання плану слід залучити всіх зацікавлених сторін, таких як дизайнери, розробники, клієнти та тестувальники.
- Планування не може бути розроблене для непідтверджених або будь-яких не затверджених потреб бізнесу.
- Подібні плани випробувань застосовуватимуться до нових вимог, які вимагатиме бізнес.
Приклад №1
Команда розробників працює над програмним забезпеченням XYZ після отримання кількох вимог від клієнтів. Тестова група майже розпочала підготовку до етапу визначення або планування тесту. Планування тестування повинно бути розроблено з урахуванням початкових вимог, які цитують клієнти. Це було зроблено командою випробувачів.
Жодна з інших зацікавлених сторін не брала участі на цьому етапі, і планування було заморожено.
Зараз команда розробників внесла деякі зміни в бізнес-потік, щоб вирішити кілька питань у своїй роботі з дозволу клієнта. Тепер програмне забезпечення прийшло до тестувальної групи для тестування. Розробивши план тестування за старим потоком бізнесу, команда тестування розпочала свій раунд тестування. Це вплинуло на результати тестування з великою кількістю затримок, оскільки модифікований бізнес-потік не передавався команді тестувачів.
Спостереження з прикладу 1:
З наведеного прикладу є певні спостереження.
Вони є:
- Розуміння нового потоку бізнесу зайняло багато часу.
- Затримки в результатах проекту.
- Переробка планування та інші завдання на етапі.
Усі ці спостереження необхідно перетворити на основні потреби для ефективного результату тестування.
Основні компоненти на етапі планування
Нижче наведено основні компоненти, які беруть участь у фазі планування.
- Тестова стратегія: Це один з найважливіших розділів, який може пояснити стратегію, яка буде використана під час тестування.
- Покриття тесту: Це, по суті, потрібно, і це зробить відображення відповідності бізнес-потреб та тестових кейсів, щоб можна було переконатися, чи все програмне забезпечення було протестовано чи ні.
- Випробувальні цикли та тривалість: Це може стати дуже критичним в залежності від раундів розробки та часу, необхідного для проходження кожного раунду.
- Критерії проходження / невдачі: Дуже потрібен той, у якому визначено критерії проходження та відмови. Кілька разів це також визначатимуть клієнти.
- Ділові та технічні вимоги: Потрібно мати програмне забезпечення, і цілі, які вони служать, будуть чітко визначені разом із поясненнями низького рівня.
Обмеження
Є кілька речей, які насправді можуть контролювати фазу тестування програмного забезпечення, особливо фазу планування.
Ось такі кілька областей:
- Особливості, які слід перевіряти та не перевіряти: Це чітко вкаже на те, що має бути перевірено, а що не повинно бути.
- Критерії призупинення та вимоги відновлення: Це особа, що приймає рішення щодо розробленого програмного забезпечення та критеріїв, призначених для призупинення тестування або відновлення тестування.
- Обов'язки: Тестер буде виконувати численні обов'язки щодо забезпечення проблем, помилок та дефектів тестованого програмного забезпечення. Крім того, помилки повинні бути перевірені розробниками для їх виправлення.
- Ризики та непередбачені обставини: Ризики, пов'язані з тестуванням, повинні бути чітко зазначені, а належні непередбачені ситуації протягом часу повинні бути чітко визначені.
Тематичне дослідження №1
Команда розробників з Приклад №1 планує випустити програмне забезпечення XYZ у 2 етапи. Фаза 1 має багато функцій, які потрібно протестувати, і лише кілька не перевіряти. Знову програмне забезпечення було випущено для тестування, не повідомляючи команду тестування про функції, які ще слід розробити.
Тепер команда тестування починає її виконання на основі планів тестування, які вони вже розробили. Вони придумують велику кількість помилок. І після перевірки командою розробників більшість з них втрачають свою силу.
Зауваження з вищенаведеного прикладу:
- Команда розробників випустить програмне забезпечення команді тестувальників із примітками про випуск та примітками про охоплення вимог (примітки про випуск)
- Функції, що перевіряються, а не тестуються, повинні враховуватися на основі випущеного програмного забезпечення перед тестуванням.
- Критерії призупинення та відновлення для випробування повинні бути визначені належним чином.
- Ризик та плани на випадок непередбаченості програмного забезпечення повинні бути зображені досконало.
Також читайте=> Як керувати ризиками на етапі планування випробувань
План виконання тесту
Виконання тестових кейсів є одним із етапів на етапі STLC. Це доведеться виконувати відповідно до планів, розроблених раніше. Отже, планування завжди продовжує домінувати на всьому етапі тестування. Нижче наведено приклад, коли команда тестування зазнає впливу змін у планах тестування.
Приклад №2
Тестування програмного забезпечення А було розпочато на основі плану 1, розробленого командою. Пізніше, внаслідок бізнес-потреб та змін, план тестування повинен був зазнати певних змін. Це, в свою чергу, змусило змінити тестові кейси або виконання.
Спостереження:
- План тестування визначатиме виконання тестового випадку.
- Частина виконання варіюється відповідно до плану.
- Поки план та вимоги діють, тестові кейси теж діють.
Шляхи подолання проблем під час виконання
Під час виконання тесту тестувальники частіше стикаються з різними сценаріями. Саме тоді тестерам доведеться зрозуміти і знати шляхи вирішення проблеми або, принаймні, знайти вирішення проблеми.
Приклад №3
Під час виконання тестового випадку програмного забезпечення B, команда тестування стикається з багатьма проблемами. Мало хто з них є пробними пробками. Вони вимагають від розробників, щоб допомогти їм подолати проблему. Це траплялося кілька разів, і результатом цього є затримка тестування результатів.
Спостереження:
- Існує залежність від подолання екологічних проблем та проблем.
- Для тестувальників потрібно належне розуміння навколишнього середовища.
- Часто виникаючі та відомі проблеми повинні бути задокументовані для їх подолання в майбутньому.
Контроль версій та управління ними
Контроль версій і управління планами тестування та тестовими кейсами дійсно важливі для того, щоб продемонструвати своєчасні результати. Це стає більш значущим і часто робиться за допомогою інструмента контролю версій.
Засіб контролю версій не тільки допомагає їм контролювати плани випробувань, але також допомагає в управлінні дефектами. Коли існують проекти тестування з декількома циклами та випусками, ці інструменти дійсно можуть дуже допомогти у зниженні показників для підтримки результатів тестування.
Також читайте=> Управління ризиками на етапі виконання тесту
Різниця між плануванням та виконанням тестів
Нижче наведено кілька важливих сфер, які вкажуть на те, як планування буде відрізнятися від етапу виконання тесту.
| Площа порівняння | Планування тестів | Виконання тесту |
|---|---|---|
| Позиціонування результатів | План випробувань буде розглядатися як основний результат для випробувальної діяльності. Це буде зроблено як перший крок у процесі тестування. | Це відбудеться як останній член стенду на етапі тестування. Після виконання дефектів / помилок статус разом із статусом виконання тестового випадку будуть надані як один із результатів тестування |
| Відповідальна особа | Керівник тестування готуватиме план тестування та надаватиме його всім зацікавленим сторонам для їх перегляду. | Зазвичай це робить тестер, маючи на увазі, що підготовлені тестові кейси схвалено та підписано. |
| Основна увага | Основними напрямками плану тестування є те, як слід проводити тестування, що слід враховувати, а що ні, середовище, яке можна використовувати, графіки тестування тощо. | Виконання тесту зосереджується головним чином на виконанні тестових кейсів, що надаються для тестування на програмному забезпеченні. |
| Повторний або повторюваний режим | Це одноразова діяльність. Сказавши, що воно може вимагати або не вимагати модифікацій для майбутніх випусків програмного забезпечення. | У цій області є 3 частини, коли ми говоримо про ітерацію. 1. Функціональне тестування. 2. Регресійне тестування. 3. Повторне тестування. |
| Вхідні дані | Вхідні дані для створення плану тестування дійсно потрібні і повинні надаватися бізнес-аналітиками, архітектором, клієнтами тощо, | Документ тестового кейсу є основним внеском. |
| Період, коли його можна розпочати | Його слід розпочати разом із циклом розробки для досягнення ефективних результатів та економії часу. Але таких моделей, як модель падіння води, мало, де фаза випробування розпочнеться лише після завершення фази розробки. | Виконання слід розпочинати строго після розробки програмного забезпечення. |
| Період закриття | План випробувань не матиме такого періоду закриття. Як правило, буде надана підписка від усіх зацікавлених сторін за програмне забезпечення. | Виконання певного випуску або циклу вважатиметься закритим, коли всі тестові випадки будуть виконані щодо програмного забезпечення. |
| Використання інструментів | Використовуватиметься не так багато інструментів, оскільки діяльність з планування буде стосуватися більше обговорень та документації. Щоб відстежувати будь-які зміни до плану, менеджери тестів зазвичай використовують будь-який інструмент контролю версій, такий як VSS або щось інше. | Це буде залежати від способу виконання. У випадку вручну жоден інструмент не буде використаний для виконання. Але для реєстрації дефектів та управління ними будуть використані деякі інструменти. У разі автоматичного тестування виконання буде виконуватися за допомогою таких інструментів, як QTP, SELENIUM тощо. |
| Вплив на результати | Це вплине на всі етапи тестування в більшій мірі | Це вплине на наступний цикл або випуск, що перевіряється. |
Наведені вище ілюстрації могли б пояснити у кращій формі важливість діяльності з планування тесту, ніж важливість виконання тесту. Певним чином, етап виконання є своєрідною підмножиною плану тестування.
На основі стратегії тестування, підходу та інших речей, план тестування має більшу ймовірність модифікації, щоб надати можливість змінам. Певна річ, що виконання тесту залежить від тестових випадків. Тестові кейси базуються на планах. Отже, зміни в планах забезпечать зміни у тестових випадках.
Але навпаки, зміни у тестових випадках не повинні обов’язково шукати зміни. Це одна з основних причин, за якими планування не відстає від етапу виконання тесту.
У нашому підручнику ми розповімо вам більше про те, як створювати тестові кейси? Хто вони? І як ми можемо змусити їх працювати для нас разом з різними іншими аспектами, пов’язаними з тестовими кейсами.
НАСТУПНИЙ підручник=> Q-Training Day-4: Написання тестових справ із документа SRS
Ви фахівець у написанні документа про план тестування? Тоді це саме те місце, щоб поділитися вашими цінними порадами щодо вдосконалення майбутніх тестувальників. Не соромтеся висловлювати свої думки з нами в розділі коментарів нижче !!
Рекомендована література
- Зразок шаблону плану тестування програмного забезпечення з форматом та змістом
- Посібник з документації для тестування програмного забезпечення (чому це важливо)
- Ресурси та завантаження програмного забезпечення для контролю якості
- Зразок документа плану тестування (Приклад плану тестування з деталями кожного поля)
- Виконання тесту при тестуванні програмного забезпечення: точний процес та план на прикладі
- Як написати документ про стратегію тестування (із зразком шаблону стратегії тестування)
- Написання тестових справ із документа SRS (ЗАВАНТАЖИТИ Зразки тестових випадків проекту)
- Програма курсу тестування програмного забезпечення - детальний план навчання онлайн-курсу