Hi Kalin,

I am happy to let you know that you are one of the first customers who will be a part of beta testing program for WebLoad PRO v8.4.
In order to complete your beta registration please review the attached document, sign
the beta program terms & conditions document attached (last page) and fax it to +972*******.

This will secure your participation.

Regards,
Eyal

Е, включвам се в бета тестовете на WebLoad – най-добрият продукт на пазара за автоматизирани тестове. По предварителна информация знам, че ще сме 10тина човека извън екипа от бета тестъри на WebLoad. След работата към Mircosoft по проекта Windows Vista, идва ред и на израелците от RadView.
Между другото, много готини пичове са. Навремето, Eran Witkon (вицепрезидент “Продукти и разработка” на RadView) даде ексклузивно интервю за Българският SQA форум – повече за интервюто тук.

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

- Елемент 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Редакция: доживях да видя реклами на неразбираем за мен език (тип шльокавица) в блога. Между другото от какво е сложен adsense на блога, до момента съм си изкарал половината парички за домейна sqa.bg. Явно има файда да се върти там :)

Заповядайте! Ще ви очакваме!

Доста неща се случиха, но като цяло мога радостно да кажа някой от тях:

1. Успях да се срещна с Декана на ФМИ в ПУ и да уговорим една аула за семинара, който подготвям от името на SQA-Bulgaria.Info и Българската Асоциация за Качество на Софтуера. Често казано, като човек Декана не ми хареса…но всякакви хора има по тази чудна земя :)

2. Най-накрая от утре 24 Октомври, като мой колега във Верео Текнолоджис, започва един мой добър приятел – Стефчо. Доста усилия положих, за да го убедя да остави настрана, като хоби програмирането, и сега ще положа още усилия, за да направя от него добър QA :) Да се надяваме само, че ще има желанието.

Май с тези неща се изчерпват всичко положително, случило се покрай мен тези дни.

Осносно SEO състезанието, сайта с който участваме нашият екип взе, че ме изненада. Класира се на 11 място за “яицазимитпо лъгуг” в google.bg от общ индекс до момента 743 000 резултата. Скоро очаквам влизане в топ 10 :)

Тук искам да изкажа и благодарността на съпортта на InBG.eu, че ми предоставиха бекъпите на базата от неделя и понеделник…като в последствие те не ни бяха нужни. Както и да е….най-важното е, че всичко си работи с пълна пара.

Тази седмица ми предстои още работа по организацията на семинара на Качество на софтуера, които се огранизира от името на Българската асоциация за качество на софтуер и SQA-Bulgaria.Info. Трябва да отида да уредя една аула от ПУ или ТУ. Очаквайте още новини съвсем скоро. Както и информция за лекциите и гост лекторите.

А и oggin го няма да метне едно рамо, защото ползвам неговият хостинг от inbg.eu. Той е един от най-добрите като съпоставка условия, качество и цена. Не му правя реклама, просто истината е такава :) А й неговият партньор Панайот от HostBulgaria го няма да го питам какво става. Тук има две алтернативи, поради които може да се е появил проблема. Едната е да са правили някакъв ъпдейт на SQL-а и от там да се получават тези недоразумения с моя сайт. Втората, която не искам и да си помисля, е че може да са хакнали сайт. Ако е това…пази, Боже, че само това са успели да направят (което силно ме съмнява де).

Пред мен остава единствената възможност да сложа “Moderate mode” на форума и да мисля какво да правя като се прибера от работа. Дано да няма много “сърдити” и разстроени от този факт, че все пак форума е единственото място в България за търсене и получаване на помощ за Software Quality Assurance въпроси (малко да се рекламирам де :P )

След осем часа чакане да се разреши проблема от съпорта на inbg.eu, все още няма резултат. След като им пратих едно писмо доста пояснително написани с всичките му там термини и обяснения, получих отговор в които на съпорта не им ставало ясно къде е проблема. Е, какво да се направи…наложи се да обяснявам доста ламерски (нещо от сорта на това, че компютрчетата ми са зачертани, като се обадя на съпорта на моето ISP). Да видим дали ще отстранят проблема или чак когато се прибера към 7-8 вечерта ще го отстранявам сам.

Съпорт…какво да го прави човек. Ако всички си вършеха работата както трябваше и както на мен ми са искаше, света би бил по-лесен :)