Здравей,
Тестовото планиране е един от най-сложните етапи на тестването, който изисква много креативност и професионални умения, понеже трябва да се отговори на въпроса: „ Как ще тестваме тези feauture-и?“
Качеството на продукта до голяма степен ще зависи от решенията, които вземаме като QA инженери.
Имаме 2 задачи:
Намиране на кратък, прост и елегантен начин за тестване.
Намиране на компромиса между обема на тестване, който е възможен на теория и обема на обема на тестване което е възможно в реалния живот.
Както знаем, задачата ни като QA е да намерим бъгове в предоставения ни код с помощта на test case-овете, който сме направили в предния етап:
Това става като първо тестваме на новите feature-и, ползвайки нови тест кейсове и после направим регресивно тестване, ползвайки старите ни тест кейсове.
Като през цялото това време се опитваме да „счупим програмата“ и да намерим бъгове.
Веднага щом намерим бъг трябва да го report-нем като направим bug report и го вкараме в bug tracking системата.
След като програмистът оправи бъга, тестваме да видим:
1)Дали бъга наистина е fix-нат – опитваме се да възпроизведем бъга наново.
2)Ако докато се опитваме да го възпроизведем забележим нови бъгове, трябва да направим quick тест на feature-ите, които може да са засегнати.
Стъпките 1) и 2) са с други думи regressive testing.
Един план за тестване може да изглежда така:
1.General info
2.Introduction
3.Schedule
4.Feature documentation
5.Test documentation
6.Things to be tested
7.Things not to be tested
8.Entry/Exit criteria
9.Suspension/Resumption criteria
10.Other things
1.GENERAL INFO
Под формата на таблица :
Author (Автор): Name (Име)
Last updated (последно обновено) : номер и име на версията
Status (Draft/Finished) като Драфт значи, че тест плана все още се пише, а Finished, че е завършен
To-do list (нещата, които трябва да се направят. Стои празно, когато всичко е направено) : .../празно
2.Introduction (Въведение)
Описание с 2 думи какво ще се тества и т.н.
3.Schedule (Разписание)
Пак под формата на таблица може да се отбелязват например докога трябва да бъде свършено нещо, кога е свършено и кой е отговорен за самата задача и датата:
Дата (примерно 20/05/16) , Резултат (кодирането е свършено успешно) , Отговорник (примерно Иван) и team (Dev)
4.Feature documentation (Документация на фийчърите)
Заглавие и линк пак в таблица, с които да покажеш как трябват всички фийчъри да работят.
5.Тестова документация
Списък с линкове към тест документацията, която е нужна за да се тества дадения feature. Обикновено са test suites (колекциите)
6.Things to be tested (Нещата, които трябва да се тестват)
Под формата на таблица -обект на тестване,начин на тестване и нужда от automation helper (някакъв специален инструмент, например credit card generator)
7.Things not to be tested (Които не трябва да се тестват)
Пак в табличен вид
Обект на тестване и причина да не тестваме:
8. Entry/ EXIT критерий
Отново под формата на таблица – в единия блок какво се случва в началото, във втория какво се е случило – например не са открити никакви бъгове и т.н.
9.Suspension/Resumption критерий
В табличен вид
Suspension – определни условия, при които тестването трябва да бъде спряно.
Resumption- определени условия, при които тестването трябва да бъде възобновено след спиране.
10.Други неща
Неща, които бихте изкали да добавите в тестовия план, например някакъв трейнинг, хардуер/софтуер, изисквания, информация за контакти и т.н.
Това е :)
