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

Това, което ви предлагам е следното…да си структурите по следният начин цялата информация за общите сведения за тест плана:

Цел на документа
Тук опишете какво се цели със създаването на тест плана – провеждането на тестове с цел осигуряване на качествто на продукта, информация за всички видове тестове прилагани върху системата.
Включете информация за това на какви документи се базира създаването на този тест план. Обикновенно това е функционална спецификация, use cases и/или бизнес анализ.

Обхват на документа
Поместете информация за обхвата на тест плана, какво ще се тества и с какво.

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

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

Срокове на провеждане на тестове
След като вече сте попълнили информация за обхвата и целта на тест плана, записали сте кои са участниците, идва ред да определите график за провеждане на тестовете.Това нещо не може да го направите, ако предварително не сте го коментирали с ръководител проект. Той ще ви каже какво време имате отделено за тестване. Борете се, борете се то да е максимално – колкото повече време имате, толкова повече свеждате възможността от поява на сериозни бъгове и дефекти в приложението.
За да определите и фиксирате точно определеното ви време за провеждане на тестовете, мога да ви препоръчам да си направите една проста табличка. Тя се състои от три колони:

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

Документи в тест плана
След като вече сте определили първоначалните срокове, тук е добре опишете с какви документи е свързано създаването на този тест план. Това включва функционална спецификация, доклади и репорти от извършени
тестове и т.н. Ако разполагате със resource сървър (SVN и друго) поместете и пълен адрес къде могат да се достъпят те. За да си ви по-подредени нещата, може да си направите една проста табличка с няколко реда и колони, където да поместите информацията за тези документи.

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

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

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

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

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

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

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

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

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

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

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


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

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

Днес се натъкнах на един бъг в любимата ми безплатна поща от Abv.bg.

Както може да видите и на прикаченият файл системата ми показва, че имам 2 непрочетени писма, а всъщност са 3 !
Втори бъг на които съм се натъквал е при превод на езика от български на латиница. Преводача на abv.bg не може да превежда буквата Щ, ако е в първа буква в изречението … пробвайте го!
Третия път, ама нещо не мога да го хвана точно, че не съм си поставил за цел де :) , когато ви дойде писмо след 22:00 часа, системата автоматично го приема като 10:00 и ако не сте си проверявали пощата един ден да кажем, това писмо дошло в 23:35, автоматично ще се отбележи с час на пристигане 11:35 .. отива отдолу в списъка.
За сега толкова от Abv.bg :)

На 12 Април започва, подготвения от мен курс “Качество на софтуера”. Той ще се проведе във Факултета по математика и информатика към Пловдивския Университет “Пайсии Хилендарски”.
След доста опити, най-накрая доц. Рахнев склони, този курс да стане реална факултативна дисциплина. (всичко това не и без подкрепата на доц. Крушков, за което искрено благодаря!).
На 12 Април в зала 536 (ако не се лъжа номера де) ще бъде първата лекция и ще съдържа неща за въведение в материята.
Всеки които има желание да науче повече за Software Quality Assurance е добре дошъл. Най-важното е да направим нещо полезно за колегите и да предизвикаме у тази професия в младите хора. Защото последната година все по-усилено се говори за качествто на софтуера и все по-засилено се търсят QA кадри.