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

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

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

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

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

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

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

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

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

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

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

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


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

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

След като вече намерихме един бъг в abv.bg, редно е да има и част 2.
В прикаченият файл може да видите как abv.bg визуализира кирилица при опит да се напише писмо. Полето за заглавие на писмото правилно енкодва подадените символи, за разлика от полето за текст.
Бъга се наблюдава, ако се ползва Google Chrome за браузър, като през Mozilla Firefox всичко е наред.
Бива ли такова нещо питам аз, след като abv.bg е най-големият email публичен доставчик в страната. Ако трябва да Ви предложим QA услуги :-)

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

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

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

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

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

Тези дни ми се наложи да търся решение на следния проблем. Имам два домейна, разположени на shared хостинг при Superhosting.bg Идеята е, че в първият сайт се публикува информацията, като при този процес автоматично се публикува и на вторият. Казуса идва от там, че на първо време кода е написан без да се копират снимките. Трябва през определен период от време да се обновява съдържание и да се синхронизира в двете папки. Например папката images/ на първият сайт, трябва да е идентична с папката images/ на вторият сайт.
След известно време на рисърч се оказа, че най-лесно може да стане с използването на cron job от хостинг сървъра, където ни са разположени сайтовете. Лошото на споделите хостинг услуги е, че имате опредено време и ресурс, което може да заемате от машините. Командата copy нямаше да бъде ефективна, поради по-дългото заемане на процесорно време. Затова като cron job може да зададете следната команда:
rsync -a /пътя_до_първата_папка/ /пътя_до_втората_папка/
Чрез синхронизацията си спестявате доста ресурси, които иначе бихте заели. А това се оказва пагубно при споделият хостинг.
Има и второ решение, което съпорта спомена. Създаването на Symlink на втората папка – втората папка се създава като shortcut на първата и фактически сочи към нея. Идеално решение, което пък на мен не ми вършеше много полезна работа.