Блог на Калин Василев

В няколко поредни статии ще се научим да пишем Тест план за софтуерен продукт. Тест плана е основният документ по който се водят QA консултантите в процеса на тестване на софтуерната разработка.

Какво представлява тест плана ?
Тест плана е основният документ, по който се ръководи даденият тестър или QA консултант по време на процеса на провеждане на тестове на софтуерния или уеб продукт.
В тест плана се дефинират обекта на тестване, обхвата на софтуерните тестове, подготовката и насоките при провеждането на тестове за осигуряване на качеството на разработваният продукт.
Процеса на подготовка и разработване на тест плана помага и дава информация за това, какви ресурси и подходи ще трябва да се приложат, за да може да се осигури качеството на софтуера или уеб приложението.
Разработването на един пълен и ефективен тест план, ще даде информация на хората извън QA екип, обиквенно това са клиентите, които незнаят що е то софтуерно тестове, да разберат защо и как преминава процеса на валидация и верификация. Процес, който потвърждава коректността и функционалността на разработвания продукт и потвърждава идентичността с изискванията на възложителя на проекта.
В тест плана се съдържа информация за всички проведени тестове и тест сценарии за тях, график за изпълнението на тестовете, участници. Дефинира основните подходи и насоки, които ще се използват в процеса на осигуряване на качеството на продукта.

Какво съдържа един тест план ?
Тест плана може да варира като съдържание и описание на дейности в него. Според стандарта IEEE – 829, дефиниращ изиксванията за тест документацията, един тест план трябва да съдържа следните точки:
* Идентификатор за тест плана
* Референции
* Въведение
* Обект на тестването
* Софтуерни рискови моменти
* Функционалности, които ще бъдат тествани
* Функционалности, които няма да бъдат тествани
* Подходи в процеса на тестването
* Показатели за успешност/неуспешност на проекта
* Входни и изходни критерии за проекта
* Критерии за преустановяване на тестовете
* Какви тестове ще се провеждат
* График на тестовете
* Тестова среда и изисквания
* Участници и квалификация
* Отговорности
* Планиране на риска и непредвидени ситуации
* Оценка

Точките, по които се разработва един тест план, могат да варират – редуцират или увеличават, в зависимост от нуждите на проекта или приетите вътрешни стандарти в дадена фирма. Тези показатели не са задължителни параметри, които трябва обезателно да присъстват в един тест план. Един тест план се пише, за да бъде в помощ на екипа, който разработва проекта. Всеки един тестър или QA е свободен сам да дефинира точките и параметрите на тест плана, като преди това ги е съгласувал с ръководител проекта.

Въведение в тест плана
Всеки един тест план, включва в началото си информация за това от кой тестър или QA е създаден и история на документа. В последното се помества всяка една направена промяна по тест плана. Всяка една важна корекция на първоначално написаният тест план се приема като нова версия на документа и трябва да се опише тук. Не се страхувайте да правите версии на документа. Това показва, че вие работите по него. Все пак тест плана е динамичен документ, които трае много промени в процеса на работата.
Тук е добре да включите информация за всички, които трябва да одобрят документа. Това по принцип са ръководил проекта и представител на възложителят. Поместете техните имена и заемани позиции в йерархията.
Не забравяйте, че тук е мястото да поместите и информация всички използвани съкращения и абревиатури в документа. Все пак той няма да се чете само от QA. Като пишете документа, пишете го така, че да може и останалите да го разбират.

Предлагам ви следната конфигурация, която да поместите веднага след заглавната страница на тест плана ви:

Автор на документа

История на документа

Списък на одобрилите документа

Списък на съкращения и абревиатури

Веднъж попълнили тази начална част от документа започвате със същинското създаване на тест плана.


Първата точка от него трябва да съдържа общи данни за документа. Това включва обхват и цел на документа. Поместете информация за
основните насоки при процеса на тестване, като фиксирате само като термини видовете тестове, които смятата да проведете върху дадената система или софтуер.
Тук е добр да включите информация, ако имате разбира се, за заетите ресурси в процеса на тестване – както човешки, така и чисто технически и технологически.

Следва продължение….

Последно време работя върху засилване на съвместната работа между два отдела във фирмата, където работя. Става въпрос за коопериране на действията на бизнес анализаторите и QA консултантите.
Според мен тези хора трябва да работят усърдно ръка за ръка, защото ако не са събрани правилно бизнес изискванията, не са дефинирани критериите за успеваемост на един проект и не се планува правилно времето за тестване на съответното приложение, то ние рискуваме неговият провал.

На мнение съм, че работата на QA трябва да започне още на фаза планиране и определяне на основните цели на проекта. QA трябва да се включва, заедно с бизнес анализаторите при проектиране на екрани, полета, типове данни. Активно участие на двете страни при създаването на функционалната спецификация на продукта, както и при управлението на проблемите (issues).
Съвместната работа би допринесла положителни аспекти и при предаването на проекта при клиента и впоследствие, ако се налага при обучението на потребителите за работа със системата.

По-ранното планиране на ресурсите от гледна точка на BA и QA гарантира по-ранно изчистване на големи бъгове и проблеми, които несъмнено ще породят големи загуби, ако се идентифицират в следваща фаза на проекта.
Своевременният и постоянен анализ от страна на BA и QA е едно от златните правила за успешен софтуерен продукт!

А вие какво мислите за връзката BA и SQA – ръка за ръка при създаването на софтуерен продукт ?

* BA = бизнес анализ
SQA = контрол на качество или качество на софтуерните продукти

Преди около близо 3 месеца ви запознах, че ще започна да водя една дисциплина в Пловдивският Университет и по-точно във Факултета по математика и информатика – качество на софтуера. Е днес след положен от страна на студентите на един тест, този курс завърши успешно.
Много съм доволен от себе си :-) Доста голямо предизвикателство бе за мен. От 17 записани студенти, 5-6 бяха най-редовни и видях интерес у тях, а останалите 5-6 студента се явиха на изпита. Оценка под добър не съм писал. Само на тези, които не са дошли дори и един път им писах слаб 2. Не може някои да полагат усилия и да се интересуват от образованието си, а останалите всичко наготово да получават.
С две думи – сполучлив курс за качество на софтуера се получи във ФМИ. Изказвам искрените си благодарности на доц. Крушков – зам. декан на ФМИ, че положи усилие този курс да стане реалност!

Една много готина картинка, която отразява процеса когато се сблъскаме с поредния бъг в системите или приложенията, които разработваме ….

…коментарите оставям на вас :)