Идеята на БАСТ е да обедини всички 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, Бианор, Вискомп и други, че ако започна да ги изреждам всички – рискувам да забравя някой, а не искам!

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

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

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

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

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

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

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

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

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

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

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

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


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

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