Какво е тест план и кои са най-важните части на тест плана?

+6 гласа
2,161 прегледа
попитан 2016 май 18 в Тестване на софтуер от Kalina.Mincheva. (1,330 точки)
Здравейте,

уча за тест специалист и стигнах до частта за тест план. Може ли някой да ми даде пример на разбираем език за това какво преставлява тест плана?

1 отговор

+2 гласа
отговорени 2016 май 19 от Daniel Ivanov (11,160 точки)
редактиран 2016 август 23 от Daniel Ivanov

Здравей,

Тестовото планиране е един от най-сложните етапи на тестването, който изисква много креативност и професионални умения, понеже трябва да се отговори на въпроса: „ Как ще тестваме тези 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.Други неща

Неща, които бихте изкали да добавите в тестовия план, например някакъв трейнинг, хардуер/софтуер, изисквания, информация за контакти и т.н.

Това е :)

...