Идеята на БАСТ е да обедини всички QA и да наложи качество на процесите, като в същото време обучава специалисти. Все пак нали осигуряваме качество на софтуерните продукти :-)
Повече за Асоциацията може да научите на www.sqa.bg.

Семинара ще бъде от 3 лекции, както следва:
1. Фактори за успешен agile тестинг – моя милост (Калин Василев) ще говори за успешни практики и стъпки при участието на тестъри в agile екипи, както и правилни подходи при работа в agile среда.
2. Testing of mobile applications – Васил Табаков, заедно със своя над 10 годишен опит в осигуряване на качеството на софтуерни продукти, ще говори за тестване на мобилни приложения и как да направим читаво приложение под формата на задължителни стъпки и добри практики.
3. ROI of automation testing – Румен Банов ще сподели, защо е добре да инвестираме в инструменти за автоматизирано тестване и как една такава инвестиция се връща многократно с времето.

След презентациите ще пийнем по чаша червено вино с колегите, които между другото ще са представители на VMware Bulgaria, SAP Bulgaria, eCommera, Quick Start Global, Бианор, Вискомп и други, че ако започна да ги изреждам всички – рискувам да забравя някой, а не искам!

Да се надяваме, че ще стане добър семинар и най-вече полезен. Защото най-полезното от такива мероприятия е сладката приказка с колеги :-)

П.П. Това е само началото от БАСТ !

SEO vs. Usability

Виж повече презентации от Oggin.

В презентацията се говори за правилните подходи и взаимовръзките между SEO и ползваемостта на Вашият сайт. Лично аз съм леко раздвоен и не мога да кажа, кое е най-точното. Определено качественото SEO И ползваемостта ще Ви донесат голяяям трафик и повече печалби от уеб сайта Ви.
Огнян ще представи лекцията на Семинар по ползваемост, който е предвиден за днес и се организира от Джими от Лукрат. Навремето с него имахме един конфликтен момент, но всичко си остава там…поне се надявам :)

Тези дни ще публикувам и една моя презентация, която изнесох на колегите от EHA corp., Германия преди време – Usability и SEO – ръка за ръка.

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. Като пишете документа, пишете го така, че да може и останалите да го разбират.

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

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

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

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

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

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


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

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

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

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

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

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

Скъпи приятели от superhosting.bg,
може ли да ми кажете как да достъпя страницата за поддръжка ? Нима ще Ви струва чак толкова, да си купите сертификат, а не да използвате тип “гаражно” производство. Оправете си страничката за support, защото тя е едно от свързващите звена между вас и вашите клиенти. Хубаво сте го докарали на дизайн и usability, ама поне погледнете и useful на тази функционалност от дейността ви :)

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

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

Но да преминем по-надолу към централната част на сайта.
Предвидливо са оставили място за новини, който се въртят с един джаваскрипт, който повече би отивал на сайт за продажба на дрехи втора употреба, отколкото да уважавана институция като УХТ. Имаме и още едно помощно меню, чийто основни категории са dolno3, dolno4 и т.н. Поне да бяхте се потрудили преди да го пуснете официално да създаде някакви категории, дори и да няма текст в тях.
Мога само да ги похваля, че са предвидили място за начините да стигнете до УХТ и за анкета. Все пак обратната връзка с посетителите е много важна. Има един сектор “Реклама”. Ние да не сме сайт за запознанства или някакъв сайт за продажба. Това рекламно каре, много не на място е сложено на сайт за висше учебно заведение. Ние да не сме комерсиален сайт ?
Всяка една страница на сайта има опция за оставяне на коментари. Не се излагайте, това не е блог всеки да може и да хули навсякъде. Защото това ще стане, като го знам средно статистическия потребител – студент. Това прилича на блог – сериозно!
Преди време ви бях разказал затова как намерих спонсори за нов сайт на УХТ, но Ректора не даде да се спомене затова. Старата версия била отлична и пълна с информация.
Ми айде радвайте се на новият сайт на УХТ, който още в началото вдъхва мрачност и негостоприемственост.
Мисля, да спра с критиките до тук и да кажа нещо положително. При всички положения сайта е по-добър от предния. Но не и в този си вид. Трябваше от УХТ да положат още малко усилия и да понапълнят с информация и оформят сайта, а не да го пускат в този му вид. Има какво да се работи.

Вярно, www.dao.bg е базирана на готов CMS скрипт (pligg), но това не пречи да намираме бъгове, нали?
Не че няма и други, ама мисля да си ги документирам само за мен си :D
Оги, ще ме прощаваш, ама просто не удържах да го репортна :)

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

ДОВИЖДАНЕ, MICROSOFT!
При вас беше интересно, имаше тръпка да опиташ и тестваш новите продукти, преди всички останали. Супер яко отношение и приятелска атмосфера, независимо от разстоянията. Само напред и не им са давайте на линуксджийте :P

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

“Индустриални стандарти. При проектирането и изграждането на приложението да се използват и поддържат индустриалните стандарти и най-добрите практики, както и Интернет стандартите HTML, XML, HTTP, JDBC, SQLJ, JAVA(TM), Web Server Definition Language (WSDL), Universal Discovery Description and Integration (UDDI), и Simple Object Access Protocol (SOAP), BPEL, SOA”

“Тест процедури
Системата да мине през следните етапи на тестването:
- Прецизиране на Плана за тестване и Test case
- Тест за отделните елементи
- Тест на модулите
- Интеграционни тестове
- Тест за предварително приемане
- Тестване на пилотната система
- Тестване на системата
- Тестване при приемане на системата”

Да обърнем внимание на първия цитат, в който се упоменава на кои технологии да се наблегне при създаването на системата. Изискването по моето скромно знание е да се използват JAVA технологии.
Системата изработена от Сирма е чисто PHP, написано чрез помощта на Zend studio технология. Така показваше инфото на сървъра, което беше налично за преглед в деня на пускане на сървъра.
Малко да поразсъжваме…PHP е идеален език за програмиране на уеб сайтове и леки по натовареност портали. Сравнение между JAVA и PHP от гледна точка на сигурност не може и да става дума. Джавата е доста пъти по-сигурна и приложенията писани на нея издържат на голямо натоварване.
Тук е редно да си зададем само един въпрос: Защо след като от Възложителят е имало изискване да се използва JAVA технология за направата на системата от Сирма са предпочели PHP ?

Вярно става по-бързо, но и по-несигурно при натоварване. Аз не съм програмист, поне вече не :) , че да давам повече коментари за това. Има хора, които са по-кадърни и ще го направят.
Относно втория цитат за процесите на тестване. Няколко пъти представители от Сирма в телевизионен ефир споменават, че са провели тестове за натоварване (Load testing) на системата. Къде това е описано в документацията ? Къде става дума за тестове на натоварване?
Аз не виждам такова нещо. Това е недопустимо, една система да не мине през Load и Stress тестове, за да се изследва нейното състояние при екстремални условия. Разбира се, Сирма са извършили тези тестове…но на приказки. Никъде в документацията не присъстват тези род тестове…колкото и да я четох не можах да ги намеря. Задължително е било да проведат и performance тестове на сървъра, за да се определи при какво натоварване той ще гръмне.
Но не…от Сирма всички отдават на хакерски атаки. Много ви се моля…ние може да ядем зелена салата, ама не пасем трева! Това, че за Вас се поява идеалния вариант да се измъкнете от ситуацията като обвините, т.н. ХАКЕРИ. Искате да кажете, че всеки един гражданин на страната е хакер!
Още един ваш пропуск е липсата на добавена функционалност за уникалност на потребителите. След като очаквате такъв голям брой регистрации, защо беше нужно да позволявате повече от една регистрация на ЕГН. Това щеше да ви реши много проблеми и ненужна обработка на информацията.
Трябваше да предвидите такъв наплив и голям брой заявки, отправени към системата, защото за този сайт се говори от една седмица…очакваше се голям брой посещения. Но вие решихте да си измиете ръцете и всички тези заявки да ги отдадете на хакерска атака. За какво им е на хакерите да нападат сайт за регистрация на деца в детски градини ???
Изправете се гордо и признайте грешката си. Грешка, която ако признаете ще се приеме по-добре, отколкото целият ИТ бранш да ви се смее с тези “хакерски атаки”.

Вижте бъга.

Колкото и невероятно да звучи, май най-голямият български портал за информация има доста сериозни проблеми напоследък. Сигурно им липсва някой и друг качествен QA да им помогне и окаже съдействие при уеб тестовете :)

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

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

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

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

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

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

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