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

Критерии за успеваемост
Както всеки един проект има нужда да се създадат критерии, по които той да бъде оценяван и да се счита за успешен, така трябва да си определите и фиксирате критерии. Критерии, според които ще считате провежданите тестове за успешни и можете да дадете зелена светлина за следващата фаза от развитието на проекта.
Например, може да зададете следните критерии, чрез покриването на който да считате дадена фаза за успешна:
- 100% от изготвените тест сценарии трябва да са със статус PASS
- 100% от всички документирани бъгове и дефекти със статус „Critical” трябва да бъдат затворени
- 100% от всички документирани бъгове и дефекти със статус „High” трябва да бъдат затворени
- над 65% от всички документирани бъгове и дефекти със статус “Medium” трябва да бъдат затворени
- над 50% от всички документирани бъгове и дефекти със статус „Low” трябва да бъдат затворени
- над 35% от всички документирани бъгове и дефекти със статус “Trivial” трябва да бъдат затворени
- Системата трябва да отговаря на 98% от заявките за търсене, като извежда списък с резултатите, чиито преглед и редактиране е в срок до Х секунди от стартиране на заявката
- Системата не трябва да прекъсва потребителската сесия при неактивност на потребителя в продължение на максимум Х минути.
За пускането на продуктова версия се позволява да се преструктурират документираните бъгове, като се работи според приоритета и важността им, за всеки един раздел от системата.

След като дефинирате критериите идва ред, в тест плана да упоменете какви тестове ще извършвате върху приложението. За всеки вид тест отделете по няколко реда и описание какво ще се случва.
Например може да започнете така:
Тестове
За да се установи и упражни контрол върху качеството на система „ЦИСОМ” е необходимо да се извършат следните видове тестове:
Провеждане на тестове
С провеждане на тези тестове, се цели да се установи максимална проверка на всички функционалности, според наличните на системата. Ръчни тестове ще се проведат, за да се проверят всички фукционалности, според наличните в системата.
Автомазирани тестове
Автомазираните тестове ще се провеждат да се провери системата в процес на натоварване. Те ще рефлектират с най-голяма степен при провеждането на performance, stress и load тестове. Чрез тяхна помощ ще се симулират определен брой виртуални потребители при определен времеви период, за да се следи състоянието на системата в режим на натоварване. Те ще се ползват и за BAT (build acceptance testing), за да се провери всяка една версия от системата, дали е годна за тестване.
——–
В следващата статия ще се запознае с по-основната част от тестовете, които са задължителни за прилагане върху дадена система и как да ги структурираме в тест плана.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Тези дни проведох един интересен разговор. В него ставаше въпрос затова дали QA специалист може да бъде ръководител проект. Разбира се, аз защитавах позицията че може, дори има много примери за това. Отсрещната страна в дискусията също беше QA Lead. За него един QA не може да е ръководител проект на софтуерни разработки, защото ако дойде един старши програмист и го попитал някакъв казус, няма да мога да му отговоря. Тук се предполага, че дадената фирма ще има ресурс, ще се отдели нужното време за research и изследване на проблема, след което ще се вземе решение.
Нима, за да си ръководител проект трябва да бъдеш програмист ? Нима ръководител проект трябва да пише код, а не да контролира и координира процеса и жизнения цикъл на проекта ?
Много странно ми стана за позицията на този човек – QA може да е ръководител проект само на чисти QA-ски проекти.

Доста PM-та четат този блог, а и хора, заемащи места във висшият мениджмънт. Искам да ви попитам вас, какво мислите по този въпрос. Бихте ли доверили проект на QA, дори и да не е старши програмист и да не е запознат изцяло с програмистките задължения :) ?
Нима трябва да си “техничар-програмист”, за да можеш да управляваш процеса на създаване на софтуерния продукт ?

Картинката е взета от www.areait.info