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

Драматичен театър – Пловдив организира моноспектакъл на Камен Донев “За народното творчество” на 6ти Юни 2009 в Античният театър. За постановката купих 4 билета, но се оказа, че точно тогава сме възпрепятствани да отидем.

Ако някой от читателите на този блог има желание да отиде на постановката ще дам билетите на цената, на която съм ги купил – 20лв. Дата е 6ти Юни от 21ч. в Античния театър.

Началото на спектакъла е:

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

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

Важното обаче е, че в народното творчество никой не иска да развали направеното,а обратното – да го направи по-хубаво. Просто като боб.

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

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

Цел на документа
Тук опишете какво се цели със създаването на тест плана – провеждането на тестове с цел осигуряване на качествто на продукта, информация за всички видове тестове прилагани върху системата.
Включете информация за това на какви документи се базира създаването на този тест план. Обикновенно това е функционална спецификация, use cases и/или бизнес анализ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Като верен клиент на ПИБ обичам всичко да ми е готино, когато ползвам услугите им. Но честно да си кажа, последно време много почнаха да ме отчайва самото обслужване.
Електронното банкиране ми го откриха след повече от 2 месеца, от както бях подал молбата си в офис на Първа инвестиционна банка. Защо се мотаха толкова ? Просто локалният офис и отделът в София си препращаха топката – молба не била при тях, не било тяхна работа и т.н.
Да не говоря, че вече работното им време е до 17:30, което е страшно неудобно. По време на “фалита” ПИБ работеха до 20:00 и някакси всички бяха по-любезни. Последно време се наблюдава точно отбратното явление.
Преди за извлечения по сметка не се плащаше нищо, а от доста време се таксува 0.20лв. Не е въпроса в парите, а в отношението.
От едим месец карам служителките от офиса, където ми е открита фирмената сметка, да качат досието на фирмата във файлова им система, за да мога да ползвам услугите им от всеки един клон в страната. Те все обещават и все като ида в друг клон чакам по 20мин. за факсове и потвърждения. Поредните оправдания. Писва ми!!!
Днес решавам да докладвам проблем с интернет банкиращата им система. Експорта на месечните извлечения по сметката е на английски. Не искам да Ви говоря за наглото отношение на човека, който пише от името на ПИБ – Интернет клон и ми отговаряше на писмата.
Ето и цялата кореспонденция:

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

Поздрави,
/Калин Василев
———————
Здравейте,
Всичко е кирилизирано – софтуера е български.
Моля, за скрин шот с екраните на латиница на мейла e-bank@fibank.bg
От центъра за поддръжка
———————
Здравейте,
разбира се, че може :-) Скрийншота е от направен експорт преди няколко минути на месечното извлечение по сметката ми за този месец. Под какъвто и тип екпорт, лейаутите са на английски.

Поздрави,
/Калин Василев
——————-
ОК, ще бъде според езика.
——————-
Ако трябва да съм искрен това “ОК, ще бъде според езика” не го разбрах, ама по-важното е всичко да е тип-топ :)
——————
Ако е трудно да се разбере ОК.
Сигурно ще е по-лесно да разберете утре когато пуснете пак експорта.

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

Така клиенти не се печелят, още повече не се задържат в банката !