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

След като сме отбелязали основните видове тестове, които планираме на този етап да се изпълняват върху проекта е време да опишем и тест сценариите.

Тук вариантите са много, но лично аз предпочитам по-опростеният формат. Това ще рече, че слагаме един скрийншот от един тест сценарии и описваме коя част от него за какво е.  Например:

- Елемент 1 – име на ТС
Името на ТС е свързано със функционалността / модула, който се проверява от системата.
Това действие се извършва от дизайнера на ТС.
- Eлемент 2 – уникален номер на ТС
Номера е уникален идентификатор, по който всеки един ТС се различава от всичките написани за проверка на функционалностите на системата.
Това действие се извършва от дизайнера на ТС.
- Елемент 3 – предусловие
Действия които трябва да бъдат извършени преди за започне изпълнението на ТС. Те могат да включват:
- навигация до определен екран от системата
- избор на даден елемент / параметър преди да започне изпълнението на ТС
- Създаване на даден обект / елемент
- Настройка на даден обект / елемент
Това действие се извършва от дизайнера на ТС.
- Елемент 4 – действия за изпълнение
Тук се съдържа последователност от дейстия, които трябва да се извършат, за да се провери дадената функционалност описана в ТС.
Всички действия трябва да се изпълнят последователно стъпка по стъпка
Това действие се извършва от дизайнера на ТС.
- Елемент 5 – очакван резултат
Очакваният резултат се определя въз основа на това как е реагирала системата, изпълнявайки всички нужни действия за проверка на дадената функционалност / модул според описаните стъпки. Възможно е наличието на повече от един очакван резултат. Тук той се отнася само за дадената стъпка.
Това действие се извършва от дизайнера на ТС.
- Елемент 6 – Pass/Fail статус (бележки)
Тук се отбелязва дали системата реагира според описаните параметри във функционалната спецификация.
Тестовите резултати, които могат да бъдат отбелязани в този раздел са:
- PASS – когато очакваният резултат отговаря на резултата описан във функционалната спецификация
- FAIL – когато очакваният резултат не отговаря на резултата описан във функционалната спецификация
- NOT TESTED – когато дадена стъпка / ТС не е проверена
- HOLD– когато провеждането на проверката е отложена поради някаква причина
Този раздел може да се използва от тестъра за записването на бележки към даденият ТС при необходимост.
Тези действия се извършват от QA консултанта, който изпълнява самият ТС.
- Елемент 7 – Краен очакван резултат
Очакваният резултат въз основа на функционалната спецификация общо за целият сценарии след изпълнението на всички стъпки.

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

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

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

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

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

Performance testing – тестове за проверка на състоянието на системата

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

Провеждането на този вид тестове ще се осъществи след като бъде завършена първата версия на On demand системата и се пусне бета версия на приложението.

Load Testing

Задачата на тези тестове е да провери състоянието на системата в процес на натоварване. Ще се изследва необходимото време от създаване на дадена заявка от потребител до получаването на краен резултат като вузуализиция в портала. Провеждането на този вид тестове ще се осъществи след като бъде завършена първата стабилна версия на On demand системата.

Stress Testing

Целта е да се изследва системата в процес на наторване. Ще се симулират определен брой виртуални потребители, възпроизвеждащи заявки към системата. Всичко това ще се проведе, за да се отчете състоянието на системата при максимален трафик. Тестовете ще се осъществи основно върху използването на модулите „Приложения” и „Абонаменти”, защото там се очаква да е най-натоварената част от системата.

Провеждането на този вид тестове ще се осъществи след като бъде завършена първата версия на On demand системата – бета версия.

Regression Testing

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

User-interface testing

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

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