< Къде съм сега ? > Начало >

| RSS

Качество на софтуера

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

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

[ More ] November 10th, 2009 | No Comments | Posted in SQA |

Бета тестър на RadView

Днес получих писмо от израелската компания RadView, произвеждаща инструмента за автоматизирано тестване – WebLoad. Писмото дойде от Eyal Shalom – Ръководител отдел “Продажби” за зона EMEA (Европа, средния Изток и Африка).

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 форум – повече за интервюто тук.

[ More ] July 15th, 2009 | No Comments | Posted in SQA |

Тест план – тест сценарии

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

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

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

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

Група от Тест Сценарии Тест сценарии ID
Действия на нерегистриран потребител
Основно меню ТC № Guest  1
Регистрация на физическо лице ТC № Guest  2
Регистрация на юридическо лице ТC № Guest  3
Администрация
Администрация ТC № Admin 1
Потребители ТC № Admin 2
Добавяне на потребител като физическо лице ТC № Admin 3
……

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

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

[ More ] July 14th, 2009 | No Comments | Posted in SQA |

Тест план – видове тестове

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

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

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

  • Очавакваните резултати при правилно въведени данни според функционалната спецификация.
  • Визуализицията на информационни съобщения и състоянието на системата при неправилно / некоректно зададени входящи данни
  • Всяка една потребителска и бизнес роля за правилно прилагане в системата
Критерии за успешно завършване на тези тестове:
  • Всички предвидени и създадени ТС са изпълнени
  • Всички намери бъгове / дефекти са документирани
Бележки:

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

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

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

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

-          нормална среда на функциониране на система

-          натоварена среда на функциониране на система

Техника: Използване на ТС създадени за проверка на функционалностите на системата.

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

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

Критерии за успешно завършване на тези тестове:
  • Един потребител: успешно завършване на ТС без отбелязването на грешки и идентично с очакваният резултат, според функционалната спецификация
  • Множество симулирани заявки: успешно завършване на ТС без отбелязването на грешки и идентично с очакваният резултат, според функционалната спецификация. Документиране на всички открити грешки / дефекти
Бележки:

Load Testing

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

Цел: Проверка на функционалностите на система според определено време за натоварване.
Техника: Създаване на ТС, които да потвърдят правилното дейстие на проверяваната функционалност.

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

Тези тестове ще се извършват, чрез инструмент за провеждане на автомазирани тестове

Критерии за успешно завършване на тези тестове:
  • Един потребител: успешно завършване на ТС без отбелязването на грешки и идентично с очакваният резултат, според функционалната спецификация
  • Множество симулирани заявки: успешно завършване на ТС без отбелязването на грешки и идентично с очакваният резултат, според функционалната спецификация. Документиране на всички открити грешки / дефекти
Бележки:

Stress Testing

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

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

Цел: Проверка на системата според написаните ТС за функционални тестове. Тук ще се проверява системата в режим на натоварване, според следните параметри:

-          липса на достатъчно памет на сървърната машина (RAM)

-          максимален брой на свързаните клиенти (connections)

-          извършване на едно и също действие, по едно и също време от две и/или повече регистрации.

Техника: Използване на ТС, създадени за провеждането на Load или Performance тестове.

Тестове трябва да бъдат извършени от една и съща машина, като паметта на сървъра трябва да бъде намалена (или лимитирана).

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

Regression Testing

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

Цел: Проверка на документираните бъгове / дефекти за тяхното отстраняване. При репродуциране отново се документират.
Техника: Използване на ТС, създадени за провеждането на функционални тестове
Критерии за успешно завършване на тези тестове:
  • Всички предвидени и създадени ТС са изпълнени
  • Всички документирани бъгове / дефекти са ретествани. При наличие на репродуциране на грешки, те отнове се документират
Бележки:

User-interface testing

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

Цел: Потвърждаване на следните параметри:

-          Навигацията в системата отговаря на бизнес логиката и логиката на процесите

-          Всички обекти отговарят на стандартите, включително менюта, размери, полета, позиции.

Техника: Провеждане на тестове за всеки един екран , за да се провери за размествания по екрана, размествания на обекти и полета, използвайки браузъри с различни ядра – Internet Explorer, Mozilla Firefox, Opera.
Критерии за успешно завършване на тези тестове: Всеки един екран отговаря на стандартите и изискванията.

Липса на различия по дизайна, използвайки различни браузъри

Бележки:
[ More ] July 7th, 2009 | No Comments | Posted in SQA |