test plan tutorial guide write software test plan document from scratch
Крайно ръководство за документ за план за тестване на софтуера:
Този урок ще ви обясни всичко за документа за план за тестване на софтуера и ще ви насочи с начините как да напишете / създадете подробен план за тестване на софтуера от нулата, заедно с разлики между планирането на теста и изпълнението на теста.
Обучение за QA на живо на проекта 3 - След като запознахме нашите читатели с приложението на живо на нашия безплатно онлайн обучение за тестване на софтуер , разбрахме как да прегледате SRS и да напишете тестови сценарии . И сега е подходящият момент да се потопите по-дълбоко в най-важната част от жизнения цикъл на софтуерното тестване - т.е. Планиране на тестове .
Списък на всички уроци в тази поредица:
Документ за планиране на теста:
Урок # 1: Как да напиша документ за план за изпитване (Този урок)
Урок # 2: Съдържание на шаблона за опростен план за тестване
Урок № 3: Пример за план за тестване на софтуер
Урок № 4: Разлика между тестовия план и тестовата стратегия
Урок № 5: Как да напиша документ за тестова стратегия
Съвети за планиране на тестове:
как да чета bin файл
Урок # 6: Управление на риска по време на планирането на теста
Урок № 7: Какво да правите, когато няма достатъчно време за тестване
Урок № 8: Как да планирате и управлявате ефективно проекти за тестване
Планиране на тестове на различни етапи на STLC:
Урок № 9: Планиране на регресионния тест
Урок № 10: План за изпитване на UAT
Урок # 11: План за приемане на изпит
Планиране на тестовата автоматизация:
Урок # 12: План за тестване на автоматизацията
Урок № 13: Планиране на тестове за ERP приложения
Урок # 14: Планиране на тестове на HP ALM
Урок # 15: Планиране на Mindmap тестове
Урок # 16: План за тестване на JMeter и WorkBench
Какво ще научите:
- Създаване на тестов план - най-важната фаза на тестване
- Планиране на тестове срещу изпълнение на теста
Създаване на тестов план - най-важната фаза на тестване
Този информативен урок ще ви обясни начините и процедурите, свързани с написването на документ от тестовия план.
В края на този урок споделихме 19-страничен изчерпателен документ за план за изпитване който е специално създаден за проекта на живо OrangeHRM, който използваме безплатно QA серия за обучение
Какво е план за изпитване?
Тестовият план е динамичен документ . Успехът на проект за тестване зависи от добре написания документ за план за изпитване, който е актуален през цялото време. Тестовият план е горе-долу подобен план за протичане на тестовата дейност да се проведе в проект.
По-долу са дадени няколко насоки за план за тестване:
# 1) Тестовият план е документ, който действа като отправна точка и само въз основа на това тестване се извършва в рамките на екипа за QA.
# две) Това е и документ, който споделяме с бизнес анализаторите, мениджърите на проекти, екипа на Dev и другите екипи. Това помага да се повиши нивото на прозрачност на работата на екипа за осигуряване на качеството за външните екипи.
# 3) Той е документиран от QA мениджъра / QA ръководител въз основа на данните от членовете на QA екипа.
# 4) Планирането на теста обикновено се разпределя с 1/3rdот времето, необходимо за целия ангажимент за осигуряване на качеството. Другата 1/3rdе за тестово проектиране, а останалото за тестово изпълнение.
# 5) Този план не е статичен и се актуализира при поискване.
# 6) Колкото по-подробен и изчерпателен е планът, толкова по-успешна ще бъде тестовата дейност.
STLC процес
Вече сме на половината от нашата поредица от проекти на живо. Следователно, нека направим крачка назад от приложението и да разгледаме процеса на тестване на софтуера (STLC).
STLC може грубо да бъде разделен на 3 части:
- Планиране на тестове
- Тестов дизайн
- Изпълнение на теста
В нашия предишен урок разбрахме, че в един практически QA проект започнахме с прегледа на SRS и писането на сценарий за тестване - което всъщност е втората стъпка в процеса на STLC. Тестовият дизайн включва подробности за това какво да тествате и как да тествате.
Защо не започнахме с тестовото планиране?
Планирането наистина е първата и основна дейност, която се случва във всеки проект за тестване.
Планиране на тестове на фази SDLC
| SDLC фаза | Дейност по планиране на тестове |
|---|---|
| Графици => | Подготовка за тестов сценарий |
| Инициирайте | В идеалния случай екипът за QA трябва да се включи, докато обхватът на проекта се събира от клиента / клиента под формата на бизнес изисквания. Но в реалния свят това не е така. От практическа гледна точка участието на екипа за осигуряване на качеството е NIL. В края на тази фаза BRD е финализиран и е създаден основен План за проект. |
| Определете | SRS се създава от BRD. Създава се първоначалният проект на тестовия план. Към този момент, тъй като екипът за QA не е приключил с прегледа на SRS, обхватът на тестването не е ясен. Така че TP на тази фаза ще съдържа само информация кога ще се проведе тестване, информация за проекта и информация за екипа (ако разполагаме с нея). |
| Дизайн | Извършва се преглед на SRS и се определя обхватът на тестването. Имаме много повече информация за това какво да тестваме и добра оценка за това колко тестови случая бихме могли да получим и т.н. Създадена е втора версия на плана за тестване, включваща цялата тази информация. |
От горната таблица е много ясно, че планът за тестване не е просто документ, който можете да създадете наведнъж и да го използвате оттам нататък.
Компоненти на документ за план
| Елементи в шаблон за план за изпитване | Какво съдържат те? |
|---|---|
| Обхват => | Тестови сценарии / Тестови цели, които ще бъдат валидирани. |
| Извън обхвата => | Подобрена яснота относно това, което няма да покриваме |
| Предположения => | Всички условия, които трябва да бъдат изпълнени, за да можем да продължим успешно |
| Тестова документация - тестови случаи / тестови данни / настройка на средата | |
| Изпълнение на теста | |
| Тестов цикъл - колко цикъла | |
| Начална и крайна дата за цикли | |
| Роли и отговорности => | Членовете на екипа са изброени |
| Кой какво да прави | |
| са изброени собствениците на модули и техните данни за контакт | |
| Резултати => | Какви документи (тестови артефакти) ще се представят в какви срокове? |
| Какво може да се очаква от всеки документ? | |
| Околна среда => | Какви изисквания към околната среда съществуват? |
| Кой ще отговаря? | |
| Какво да правим в случай на проблеми? | |
| Инструменти => | Например JIRA за проследяване на грешки |
| Влизам | |
| Как да използвам JIRA? | |
| Управление на дефекти => | На кого ще съобщаваме за дефектите? |
| Как ще докладваме? | |
| Какво се очаква - предоставяме ли екранна снимка? | |
| Рискове и управление на риска => | Изброени са рисковете |
| Анализират се рисковете - вероятността и въздействието се документира | |
| Изготвят се планове за намаляване на риска | |
| Критерии за изход => | Кога да спрете тестването? |
Тъй като цялата гореспомената информация е най-критичната за ежедневна работа по QA проект , важно е да поддържате документа на плана актуализиран от време на време.
Примерен документ за план за изпитване за проект на живо
Примерен документ за шаблон на план за изпитване е създаден за нашата „ ORANGEHRM ВЕРСИЯ 3.0 - МОЯТ ИНФОРМАЦИОНЕН МОДУЛ ” Проект и приложен по-долу. Моля, погледнете го. Към документа в червено са добавени допълнителни коментари, за да се обяснят разделите.
Този план за тестване е както за функционална, така и за фаза UAT. Той също така обяснява процеса на управление на теста с помощта на инструмента HP ALM.
Изтеглете пример за план за тестване:
Формат на документа => Щракнете тук, за да изтеглите тестовия план във формат Doc това е, което създадохме за OragngeHRM Live Project и го използваме и за курса ни за тестване на софтуер.
PDF формат => Щракнете тук, за да изтеглите тестовия план във формат pdf .
Файлове с работен лист (.xls), посочени в горните версии на doc / pdf => Изтеглете Препратени XLS файлове в горния план за изпитване
Горният шаблон е много изчерпателен и подробен. Затова, моля, прочетете го задълбочено за най-добри резултати.
Тъй като планът също е създаден и обяснен добре, нека преминем към следващата фаза както в SDLC, така и в STLC.
Код на SDLC:
Докато останалата част от проекта отделяха времето си за създаване на TDD, ние, QA, определихме обхвата на тестване (сценарии за тестване) и създадохме първия надежден проект на план за тестване. Следващата фаза на SDLC е да се провери кога настъпва кодирането.
Разработчиците са основната точка на фокус за целия екип през тази фаза. Екипът на QA се отдава и на най-важната задача, която не е нищо друго освен „Създаване на тестови случаи“ .
Ако тестовите сценарии бяха „Какво да тестваме“, тогава тестовите случаи се занимават с „Как да тестваме“. Създаването на тестови случаи е преобладаваща част от фазата на тестовото проектиране на STLC. Входните данни за дейността по създаване на тестови случаи са Тестовите сценарии и документът SRS.
За тестери като нас, Тестови случаи са истинската сделка - това са нещата, в които прекарваме по-голямата част от времето си. Създаваме ги, преглеждаме ги, изпълняваме ги, поддържаме ги, автоматизираме ги - и добре, вие получавате картината. Без значение колко сме опитни и каква роля играем в даден проект - все пак ще работим с тестовите случаи.
Планиране на тестове срещу изпълнение на теста
Планирането на софтуерни тестове запазва далеч по-добър обхват сравнително в STLC фаза . Доставката на качествен софтуер се осигурява от екипа за тестване. И какво трябва да се направи при тестване, всъщност се решава на етапа на планиране на теста.
Този раздел ще предостави пълен преглед и ще включва илюстрации за важността на планирането на тестовете и фаза на изпълнение . След като прочетете това, ще разберете значимото значение на фазата на планиране в сравнение с фазата на изпълнение с повече живи примери и казуси за илюстрации .
Планиране на тестове
По-долу са дадени някои основни неща, които трябва да се отбележат при планирането:
Планирането на тест е основният важен раздел в тестовия цикъл. Резултатът от фазата на тестване ще се определя от качеството и обхвата на планирането, което е направено за тестването.
Планирането на теста обикновено се извършва по време на фазата на разработване, за да се спести времето за изпълнение на теста след взаимно съгласие на всички участващи страни.
Някои важни факти, които трябва да се отбележат, включват:
- Планирането трябва да започне успоредно с разработването, при условие че изискванията са замразени.
- Всички заинтересовани страни като дизайнери, разработчици, клиенти и тестери трябва да бъдат включени, докато финализират плана.
- Планирането не може да бъде разработено за непотвърдени или неодобрени бизнес нужди.
- Подобни планове за тестове ще бъдат приложени към новите изисквания, които бизнесът ще изисква.
Пример # 1
Екипът на разработчиците работи върху софтуер XYZ, след като получи няколко изисквания от клиентите. Екипът за тестване почти е започнал подготовката си за фазата на дефиниране или планиране на теста. Планирането на теста трябва да бъде проектирано така, че да отговори на първоначалните изисквания, цитирани от клиентите. Това е направено от екипа за тестване.
софтуер за ремонт на компютър за Windows 10
Нито една от другите заинтересовани страни не е участвала по време на тази фаза и планирането е замразено.
Екипът на разработчиците сега направи някои промени в бизнес потока, за да разреши няколко проблема в работата си с одобрението на клиента. Сега софтуерът е дошъл в екипа за тестване за тест. С плана за тестване според стария бизнес поток, екипът за тестване започна своя кръг от тестове. Това повлия на резултатите от тестването с много закъснения, тъй като модифицираният бизнес поток не беше споделен с екипа за тестване.
Наблюдение от пример 1:
Има някои наблюдения от горния пример.
Те са:
- Разбирането на новия бизнес поток отне много време.
- Забавяния в резултатите от проекта.
- Преработване на планирането и другите задачи във фазата.
Всички тези наблюдения трябва да бъдат превърнати в основни нужди за постигане на ефективно тестване.
Основни компоненти във фазата на планиране
По-долу са дадени основните компоненти, които участват във фазата на планиране.
- Тестова стратегия: Това е един от най-важните раздели, който може да обясни стратегията, която ще се използва при тестване.
- Тестово покритие: Това по същество се изисква и ще направи съответствие на съответствието на бизнес нуждите и тестовите случаи, за да може човек да се увери дали целият софтуер е тестван или не.
- Тестови цикли и продължителност: Това може да стане много критично в зависимост от кръговете на развитие и времето им за завършване на всеки кръг.
- Критерии за преминаване / неуспех: Много е необходим такъв, в който са дефинирани критериите за преминаване и неуспех. Няколко пъти това също ще бъде определено от клиентите.
- Бизнес и технически изисквания: Необходимостта от софтуер и целите, които обслужват, ще бъдат ясно дефинирани заедно с обясненията на ниско ниво.
Ограничения
Има няколко неща, които всъщност могат да контролират фазата на тестване на софтуера, особено фазата на планиране.
Следват толкова малко области:
- Характеристики, които трябва да бъдат и да не се тестват: Това ясно ще посочи какво трябва да бъде тествано и кое не трябва да бъде.
- Критерии за спиране и изисквания за възобновяване: Това е взимащото решение за разработения софтуер и критериите, определени за спиране на тестването или възобновяване на тестването.
- Отговорности: Тестерът ще има много отговорности за осигуряване на проблемите, грешките и дефектите в тествания софтуер. Освен това грешките трябва да бъдат валидирани от разработчиците, за да бъдат отстранени.
- Рискове и непредвидени обстоятелства: Рисковете, свързани по време на тестването, трябва да бъдат ясно споменати и правилните непредвидени обстоятелства трябва да бъдат дефинирани много ясно.
Казус №1
най-доброто приложение за изтегляне на музика за mp3
Екипът на разработчиците от Пример # 1 планира да пусне софтуера XYZ на 2 фази. Фаза 1 има много функции, които трябва да бъдат тествани, и няколко, които не трябва да бъдат тествани. Отново софтуерът е пуснат за тестване, без да информира екипа за тестване за функциите, които тепърва ще бъдат разработени.
Сега екипът за тестване започва изпълнението му въз основа на плановете за тестване, които вече са разработили. Те измислят голям брой грешки. И след валидиране от екипа за разработка, повечето от тях стават невалидни.
Наблюдения от горния казус:
- Екипът на разработчиците ще пусне софтуера на тестващия екип с бележки за изданието и бележки за покритие на изискванията (бележки за изданието)
- Функциите, които трябва да бъдат тествани, а не да бъдат тествани, трябва да бъдат взети под внимание въз основа на пуснатия софтуер преди тестване.
- Критериите за спиране и възобновяване на изпитването трябва да бъдат правилно определени.
- Рискът и непредвидените планове за недостъпност на софтуера трябва да бъдат представени перфектно.
Прочетете също=> Как да управляваме рисковете по време на фазата на планиране на теста
План за изпълнение на теста
Изпълнението на тестови случаи е една от стъпките във фазата STLC. Това ще трябва да се извърши в съответствие с плановете, разработени по-рано. Следователно планирането винаги продължава да доминира в цялата фаза на тестване. По-долу е даден пример, при който екипът за тестване се влияе от промените в плановете за тестване.
Пример # 2
Тестването на софтуера А започна по план 1, разработен от екипа. По-късно, поради бизнес нуждите и промените, планът за тестване трябваше да претърпи някои промени. Това от своя страна принуди тестовите случаи или изпълнението да бъдат променени.
Наблюдения:
- Планът за тестване ще определи изпълнението на тестовия случай.
- Частта за изпълнение варира според плана.
- Докато планът и изискванията са валидни, тестовите случаи също са валидни.
Начини за преодоляване на проблемите при изпълнение
Тестерите по-често срещат различни сценарии, докато изпълняват тестовото изпълнение. Това е моментът, когато тестерите ще трябва да разберат и да знаят начините за разрешаване на проблема или поне да намерят решение за проблема.
Пример # 3
По време на изпълнението на тестовия случай на софтуер Б, екипът за тестване се натъква на множество проблеми. Малко от тях са тапата на шоуто. Те изискват разработчици да им помогнат да преодолеят проблема. Това се е случило няколко пъти и резултатът от това е забавяне при тестването на резултатите.
Наблюдения:
- Съществува зависимост за преодоляване на екологични проблеми и проблеми.
- За тестерите се изисква правилно разбиране на околната среда.
- Често срещаните и известни проблеми трябва да бъдат документирани за преодоляването им в бъдеще.
Контрол и управление на версиите
Управление на версията и управлението на плановете за тестване и тестовите случаи са наистина важни, за да се покажат навременните резултати. Това е по-важно и често се прави с помощта на инструмент за контрол на версиите.
Инструментът за контрол на версиите не само им помага да контролират плановете за тестване, но също така помага при управлението на дефекти. Когато има проекти за тестване с множество цикли и издания, тези инструменти наистина могат да помогнат много за намаляване на показателите за подкрепа на резултатите от тестването.
Също така, прочетете=> Управление на риска във фаза на изпълнение на теста
Разлика между планирането на теста и изпълнението на теста
По-долу са дадени няколко важни области, които ще посочат как ще се различава планирането от фазата на тестване.
| Сравнителна област | Планиране на тестове | Изпълнение на теста |
|---|---|---|
| Достигащо позициониране | Планът за изпитване ще се счита за основен резултат за тестовата дейност. Това ще бъде направено като първата стъпка в процеса на тестване. | Това ще дойде като последен член на скамейката във фазата на тестване. След изпълнението състоянието на дефектите / грешките заедно със състоянието на изпълнение на тестовия случай ще бъдат споделени като един от резултатите от теста |
| Отговорно лице | Ръководителят на теста ще подготви плана за теста и ще сподели с него всички участници за преглед. | Това обикновено се прави от тестера, като се има предвид, че подготвените тестови случаи са одобрени и подписани. |
| Основен фокус | Областите на фокус на плана за изпитване са как трябва да се проведе тестването, какво трябва да се има предвид и какво не, среда, която може да се използва, графици на тестове и т.н. | Изпълнението на теста се фокусира главно върху изпълнението на тестовите случаи, предвидени за тестване на софтуера. |
| Повтарящ се или итеративен режим | Това е еднократна дейност. Като каза, че може или не може да изисква модификации за бъдещите версии на софтуера. | В тази област има 3 части, когато говорим за итерация. 1. Функционално тестване. 2. Регресионно тестване. 3. Повторно тестване. |
| Входове | Входните данни за създаването на тестов план наистина се изискват и трябва да бъдат предоставени от бизнес анализатори, архитект, клиенти и т.н., | Документът за тестовия случай е основният вход. |
| Период, когато може да бъде стартиран | Трябва да се започне заедно с цикъла на разработка, за да се постигне ефективен резултат и да се спести време. Но има малко модели като модела за падане на водата, при които фазата на тестване ще започне едва след завършване на фазата на разработка. | Изпълнението трябва да започне строго след като е разработено софтуера. |
| Период на закриване | Планът за изпитване няма такъв период на затваряне. Обикновено ще бъде осигурен отказ от всички заинтересовани страни за софтуера. | Изпълнението за конкретна версия или цикъл ще се счита за приключено, когато всички тестови случаи са изпълнени срещу софтуера. |
| Използване на инструменти | Няма да се използват много инструменти, тъй като дейността по планиране ще включва повече дискусии и документация. За да проследяват всякакви промени в плана, тестовите мениджъри обикновено използват всеки инструмент за контрол на версиите като VSS или нещо друго. | Това ще зависи от начина на изпълнение. В случай на ръчно не се използва инструмент за изпълнение. Но за регистриране на дефектите и управление на тях ще бъдат използвани някои инструменти. В случай на тестване за автоматизация, изпълнението ще се извърши с помощта на инструменти като QTP, SELENIUM и др. |
| Въздействие върху резултатите | Това ще повлияе по-широко на всички фази на тестване | Това ще повлияе на следващия цикъл или освобождаване, които ще бъдат тествани. |
Горните илюстрации може да са обяснили в по-добра форма за важността на дейностите по планиране на теста, отколкото тази на изпълнението на теста. По някакъв начин фазата на изпълнение е един вид подмножество на плана за тестване.
Въз основа на тестовата стратегия, подход и други неща, планът за тестване има по-голяма вероятност да бъде модифициран, за да даде място на промените. Определено е, че изпълнението на теста зависи от тестовите случаи. Тестовите случаи се основават на плановете. Следователно промените в плановете ще осигурят промени в тестовите случаи.
Но обратно, промените в тестовите случаи не трябва задължително да търсят промени. Това е една от основните причини, поради които планирането продължава в сравнение с фазата на изпълнение на теста.
Предстоящият ни урок ще ви обясни повече за това как да създавате тестови случаи? Какво са те? И как можем да ги накараме да работят за нас заедно с различните други аспекти, свързани с тестовите случаи.
СЛЕДВАЩ урок=> QA Training Day-4: Писане на тестови случаи от SRS документ
Експерт ли сте в писането на документ за план за изпитване? Тогава това е точното място да споделите вашите ценни съвети за подобрение за предстоящите тестери. Чувствайте се свободни да изразите мислите си с нас в раздела за коментари по-долу !!
Препоръчително четене
- Примерен шаблон за план за тестване на софтуер с формат и съдържание
- Ръководство за документация за тестване на софтуер (защо е важно)
- QA Софтуер за тестване на ресурси и файлове за изтегляне
- Примерен документ за план за изпитване (пример за план за изпитване с подробности за всяко поле)
- Изпълнение на теста при тестване на софтуер: Точен процес и план с пример
- Как да напиша документ за тестова стратегия (с примерен шаблон за тестова стратегия)
- Писане на тестови случаи от SRS документ (ИЗТЕГЛЯНЕ на примерни тестови случаи на проект)
- Учебна програма за тестване на софтуер - Подробен план за обучение на онлайн курс