Кой тества вашия продукт?
Процесът на тестване на продукта отдавна е утвърден в теорията на софтуерното производство и даже съществува ролята на тестера – човек който притежава специфични качества и умения (различни от тези на програмиста), и е специално обучен да провери дали това, което произвеждаме, отговаря на зададените изисквания и се държи стабилно.
В интерес на истината, до неотдавна у нас съществуваха фирми, които не практикуваха никакво тестване, т.е. оставяха откриването на грешки като изненада за клиента, и такива, които възлагаха тази работа на самите програмисти. Странно решение, въпреки че практиката отдавна е установила, че този, който пише даден код, не е в състояние да открие по-голямата част от бъговете си. Това е така, защото програмистът не може да разчупи мисленето си и да погледне на продукта от друг ъгъл. Вярвам, че такива фирми вече не са останали в днешно време, а ако все още съществуват, съм убеден, че пазарът ще ги принуди да променят отношението си към качеството на продукцията си или просто ще ги смачка.
По-интересен е случаят, в който тестването е неотменна част от жизнения цикъл на продукта и с това се занимават нарочно определени хора. Тук отново съществува едно принципно разделение:
в някои фирми тестерите са част от проектния екип –
те участват в тестването на всички документи – още в най-ранната фаза на проекта – и остават в екипа до окончателното предаване на продукта на клиента, че даже и малко след това – по време на процеса на поддръжка.
В други фирми пък за тестването отговаря специален отдел по качеството,
който не се числи към нито един проект, а извършва оценка на качеството на всички продукти, които се разработват в компанията. Обикновено този отдел се ръководи от Quality Manager – човек, който има последната дума по отношение на това дали продуктът покрива критериите за качество, зададени при самото стартиране на проекта. На този тип организация му казват Testing as service или тестването като услуга.
Въпросът е:
Кой е по-ефективният метод и кой е по-подходящ за нашия проект?
Напоследък се налага организация от типа “тестване като услуга”, може би поради това, че тестерите от отдела по качеството могат да бъдат по-ефективно натоварени. От друга страна, тестването като услуга има и своите недостатъци, един от които е изискването за предварително подготвена детайлна документация, което на практика е рядко срещано явление – най-вече поради постоянно променящите се изисквания от страна на възложителя.
В подкрепа на организацията, при която тестерите са равноправни членове на проектния екип, Johanna Rothman е публикувала един пост в блога PM Hut, озаглавен Тестването не е услуга. В него тя аргументира своята позиция със следното:
- Когато работят като услуга, тестерите превключват постоянно между различни продукти, без да могат да изучат който и да е от тях в детайли. Поради това тестването на всеки един от тях е доста повърхностно, което означава некачествено.
- Не е ясно какъв е приоритетът на различните проекти и на кой от тях ще бъдат отделени повече внимание и ресурси.
- Тестерите не работят заедно с разработчиците и списъците с открити бъгове се тълкуват повече като обвинение към програмистите, отколкото като конструктивна обратна връзка.
- Вместо работа в екип се създават отношения “ние срещу тях”. Разработчиците загубват интерес сами да тестват кода си, прехвърляйки всичко в ръцете на тестерите. По този начин се губи значително време на тестерите да се занимават с елементарни и очевидни грешки, които биха могли да бъдат отстранени от програмистите още преди кодът да бъде предаден за тестване.
Ако разработчиците и тестерите са част от един екип, те формират дух на колегиалност и партньорство. Тогава
тестването и изчистването на продукта от бъгове става тяхна обща цел
и повод за гордост от добре свършената работа.
Аз вярвам, че добре организираният и мотивиран екип е ключов фактор за успеха на който и да е проект. А това още по-силно важи за софтуерните проекти. В този смисъл напълно подкрепям позицията на Джоана и смятам, че тестването може да бъде много по-ефективно, ако се провежда вътре в проекта от тестери, които са членове на същия проектен екип, който и разработва продукта.
Бих искал да разбера каква е ситуацията при вас и какво е вашето мнение за тестването и ви приканвам да споделите как тествате вашите продукти във фирмите, в които работите. Коментари за това как би трябвало да бъде също са добре дошли.
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл
Отдела по качество в дадена фирма не пречи на това хората,занимаващи се със софтуерно тестване, да бъдат част от проектния екип -в единия случай става въпрос за организационна структура(Quality manager-а да се грижи за обучението на хората си, за правилното им алоциране в съответните проекти, за участие в дискусии по сложни казуси за тестване в проекти и т.н.);паралелно с това говорим и за проектна структура, където хората извършващи софтуерно тестване, стават част от екипа на проекта още от самото му създаване, преминавайки през всички фази на SDLC.
В тази връзка, смятам, че тестинга Е услуга към определен проект. Както всяка друга дейност, която може да подлежи на аутсорсинг. Това дали ще аутсорснете PM, бизнес анализа, софтуерната архитектура, самата имплементация, подръжка или тестинга(цялостен или специфичен(напр. security или performance)), няма никакво значение. Въпроса наистина е в правилната комуникация, осъзнаването на участниците в общата цел, и предотвратяване в зародиш на споменатите от Вас “отношения “ние срещу тях””
За да бъде един QA наистина полезен за проекта, той трябва да взима участие още от самото начало. така той има цялостна представа относно развитието и възможностите на продукта.
Ако искате може да поставите този въпрос и тук: http://sqa.bg
@Bascos: Съгласен съм, че отделът по качеството има и други функции и неговото наличие не означава автоматично, че тестването се аутсорсва. Дилемата, която поставям е дали тестерите да бъдат част от екипа или тестването може да се аутсорсне – дори и към друг отдел в същата фирма.
Категорично не съм съгласен, обаче, че това “няма никакво значение”, както казваш ти. Напротив, смятам, че има огромно значение дали хората работят заедно в един екип или част от функциите се аутсорсват към някакви други хора, които може и да не познаваме. Има значение за сработването на екипа, а оттам и за по-ефективната работа.
В този смисъл подкрепям позицията на Стефан.
Майк, уважавам мнението ти, макар че разработки от типа “Пенчо, Генчо, Атанас & аз” са неактуални в съвременното софтуерно производство(или поне преобладаващата част от него). Реалността са географските и културни различия,с които се налага да се сблъскваме постоянно.
Някъде ти убягна мисълта ми за “правилната комуникация”. Така или иначе, в момента(вече n-та година и m-ти release, където m,n>2), работим доста успешно в екип, в който бизнес анализа идва от държава А, разработката и продукт мениджъра са в държава Б, а тестинг се извършва в държави Ц, Д, Е, Ф.. С повечето от участниците в проекта се познаваме само и единствено от коментари по планиране, изисквания и открити проблеми в имплементацията. Разбира се, не е лошо ако се познаваме, но поне според мен не е определящо. Даже като се позамисля в някои случаи е по-полезно визуално да не познаваш човека отсреща, макар да не съм расист 🙂
Bascos, мисля, че се заяждаш. Това, че напоследък в големите корпорации се налагат разпределени проекти, е факт, който се обуславя от две неща: (1) някои хора си мислят, че така им излиза по-евтино (което е спорно) и (2) така е модерно (това е по-точната дума от “актуално”).
Предполагам, че “Пенчо, Генчо, Атанас и аз” е обидно наименование на малък екип в гаражна фирма. Но това не е моята позиция, така че не се обиждам. Просто смятам, че когато хората от екипа работят заедно, те могат да бъдат по-ефективни и да работят с повече хъс за успеха на проекта. Когато екипът е съставен от различни хора, разделени от пространства, часови зони и културни различия, тогава е много по-вероятно да се създаде “blaming environment”, в който основната задача на всеки човек става спасяването поединично и намиране на някой, който да отнесе вината за провала на проекта.
Работил съм с екипи от по 30 човека и знам, че може да се създаде една креативна среда и колегиален дух, и това не е модела на Пенчо и Генчо. 🙂
Майк, не се заяждам, провокирам, съжалявам ако е прозвучало като заяждане. Сигурно има и примери за “blaming environment”. Ако всички мислеха така обаче (особено пък хората от т.нар. “бели” държави), нямаше да има работа(като визирам работа имам предвид финансиране, не идеи :)) за хората от малките държави като нашата -щяхме да се ограничим до мащаба “държавния служител Генчо дава поръчка на братовчед си Пенчо”. Едва ли искаме това.
OK, приемам позицията ти, но си мисля, че примерите с Пенчо и Генчо, които все се опитваш да намесиш, са малко встрани от темата на поста ми. Кой на кого поръчва софтуер няма връзка с това как се тества софтуер в една фирма, нали? 🙂
[…] беше: Кой тества вашия продукт? Общо гласувалите в анкетата са 66 човека, като […]