В няколко поредни статии ще се научим да пишем Тест план за софтуерен продукт. Тест плана е основният документ по който се водят QA консултантите в процеса на тестване на софтуерната разработка.
Какво представлява тест плана ?
Тест плана е основният документ, по който се ръководи даденият тестър или QA консултант по време на процеса на провеждане на тестове на софтуерния или уеб продукт.
В тест плана се дефинират обекта на тестване, обхвата на софтуерните тестове, подготовката и насоките при провеждането на тестове за осигуряване на качеството на разработваният продукт.
Процеса на подготовка и разработване на тест плана помага и дава информация за това, какви ресурси и подходи ще трябва да се приложат, за да може да се осигури качеството на софтуера или уеб приложението.
Разработването на един пълен и ефективен тест план, ще даде информация на хората извън QA екип, обиквенно това са клиентите, които незнаят що е то софтуерно тестове, да разберат защо и как преминава процеса на валидация и верификация. Процес, който потвърждава коректността и функционалността на разработвания продукт и потвърждава идентичността с изискванията на възложителя на проекта.
В тест плана се съдържа информация за всички проведени тестове и тест сценарии за тях, график за изпълнението на тестовете, участници. Дефинира основните подходи и насоки, които ще се използват в процеса на осигуряване на качеството на продукта.
Какво съдържа един тест план ?
Тест плана може да варира като съдържание и описание на дейности в него. Според стандарта IEEE – 829, дефиниращ изиксванията за тест документацията, един тест план трябва да съдържа следните точки:
* Идентификатор за тест плана
* Референции
* Въведение
* Обект на тестването
* Софтуерни рискови моменти
* Функционалности, които ще бъдат тествани
* Функционалности, които няма да бъдат тествани
* Подходи в процеса на тестването
* Показатели за успешност/неуспешност на проекта
* Входни и изходни критерии за проекта
* Критерии за преустановяване на тестовете
* Какви тестове ще се провеждат
* График на тестовете
* Тестова среда и изисквания
* Участници и квалификация
* Отговорности
* Планиране на риска и непредвидени ситуации
* Оценка
Точките, по които се разработва един тест план, могат да варират – редуцират или увеличават, в зависимост от нуждите на проекта или приетите вътрешни стандарти в дадена фирма. Тези показатели не са задължителни параметри, които трябва обезателно да присъстват в един тест план. Един тест план се пише, за да бъде в помощ на екипа, който разработва проекта. Всеки един тестър или QA е свободен сам да дефинира точките и параметрите на тест плана, като преди това ги е съгласувал с ръководител проекта.
Въведение в тест плана
Всеки един тест план, включва в началото си информация за това от кой тестър или QA е създаден и история на документа. В последното се помества всяка една направена промяна по тест плана. Всяка една важна корекция на първоначално написаният тест план се приема като нова версия на документа и трябва да се опише тук. Не се страхувайте да правите версии на документа. Това показва, че вие работите по него. Все пак тест плана е динамичен документ, които трае много промени в процеса на работата.
Тук е добре да включите информация за всички, които трябва да одобрят документа. Това по принцип са ръководил проекта и представител на възложителят. Поместете техните имена и заемани позиции в йерархията.
Не забравяйте, че тук е мястото да поместите и информация всички използвани съкращения и абревиатури в документа. Все пак той няма да се чете само от QA. Като пишете документа, пишете го така, че да може и останалите да го разбират.
Предлагам ви следната конфигурация, която да поместите веднага след заглавната страница на тест плана ви:
Автор на документа
Автор | Името на QA или тестър, който създава документа |
Начини за контакти | Попълва се с email и/или телефон за връзка |
Екип | Екипа, от който е част автора на документа. Обикновенно е QA екип. |
История на документа
Версия на документа
|
Дата, на която е направена промяната
|
Автор – човека, който е направил промяната
|
Коментар – къде и защо са направени промените
|
в. 0.1 | 17.05.2009г. | Калин Василев | първоначален вариант на тест план към проект Х |
в. 0.2 | 17.05.2009г. | Калин Василев | Допълнение на в.0.1 |
Списък на одобрилите документа
Име
|
Длъжност
|
Дата
|
Подпис
|
Име на човека | Ръководил проект | 17.05.2009г. | |
Име на човека | Длъжност 1 | 17.05.2009г. | |
Име на човека | Длъжност 2 | 17.05.2009г. |
Списък на съкращения и абревиатури
Съкращение / абревиатура
|
Пълно наименование / значение
|
ТП | Тест план |
ТС | Тест сценарии |
QA | тестър / консултант по качеството |
Веднъж попълнили тази начална част от документа започвате със същинското създаване на тест плана.
Първата точка от него трябва да съдържа общи данни за документа. Това включва обхват и цел на документа. Поместете информация за
основните насоки при процеса на тестване, като фиксирате само като термини видовете тестове, които смятата да проведете върху дадената система или софтуер.
Тук е добр да включите информация, ако имате разбира се, за заетите ресурси в процеса на тестване – както човешки, така и чисто технически и технологически.
Следва продължение….
qaSQAsqa услугикачество на софтуерасофтуер тестовесофтуерни тестоветест плантестове
what do you think?