Efektívny manažment konfliktov pri testovaní softvéru MIROSLAV DÁVID Slovenská technická univerzita Fakulta informatiky a informačných technológií Ilkovičova 3, 842 16 Bratislava Abstrakt. Za úspechom softvérového projektu stoja ľudia, ktorí sa podieľali na jeho vývoji. Týchto ľudí je často veľké množstvo a sú nútení spolupracovať a robiť kompromisy. Vo fáze testovania softvéru sú proti sebe stavaní testeri a vývojári, pretože to čiastočne vyplýva z ich pohľadu a pozície v procese vývoja softvéru. Medzi týmito skupinami ľudí často vznikajú konflikty, ktoré sú ešte vážnejšie, ak sa tam zamiešajú aj medziľudské vzťahy. Pre úspech softvérového projektu je dôležité vedieť týmto konfliktom predchádzať a vedieť ich prípadne zvládnuť tak, aby to bolo prospešné pre projekt aj pre samotných ľudí. Toto je jedna z dôležitých úloh dobrého manažéra. Úvod Táto esej sa bude zaoberať konfliktmi medzi testermi a vývojármi a ich riešením. Príčiny vzniku a štandardné riešenia budú len zhrnuté v prvej časti, pričom jadrom eseje budú tri časti týkajúce sa rôznych všeobecných spôsobov predchádzania vzniku týchto konfliktov. V prvej z týchto troch častí sa venujem myšlienke vzájomného testovania a programovania, čo znamená že testeri a vývojári sú tí istí ľudia. V druhej časti bude rozobraný pohľad na problematiku z uhla agilných metód vývoja softvéru a v poslednej časti sa budem venovať problému z úplne iného pohľadu a to, že vlastne konflikty nemusia pôsobiť vždy negatívne ale môžu byť aj prospešné pre softvérový proces ako aj pre zúčastnených ľudí. Kategórie konfliktov V roku 2002 boli uskutočnené rozhovory s desiatimi profesionálmi z oboru testovania softvéru [1]. Títo ľudia pochádzali zo štyroch rôznych amerických softvérových spoločností. Tento výskum mal za úlohu dopodrobna objasniť príčiny vzniku Manažment v softvérovom inžinierstve, máj 2005, s. 1-7.
2 Miroslav Dávid konfliktov pri testovaní softvéru, ich vplyv na vývojový proces vo firme a možné spôsoby ich riešenia. Z týchto rozhovorov vyplynuli 3 základné problémové oblasti: proces testovania softvéru ľudia organizácia Proces testovania softvéru Nedostatok času. Najčastejšie spomínaným zdrojom konfliktu, ktorý vyplynul z uvedenej štúdie, bolo práve rozdelenie času medzi vývojárov a testerov. Firma sa väčšinou snaží dostať softvér na trh čo najskôr kvôli veľkej konkurencii, prípadne musí splniť termíny na dodávku softvéru. Ak sa však nestihne projekt implementovať vo vyhradenom čase, často sa potrebný čas zoberie z času pôvodne vyhradeného na testovanie tak, aby ostal zachovaný čas dokončenia softvéru. Testeri teda dostanú hotový produkt neraz na poslednú chvíľu, ktorý už nestihnú dobre otestovať (a musia testovať nárazovo, cez víkendy apod.). Narozdiel od testerov si vývojári nerobia ťažkú hlavu z nesplnenia deadlinov, pretože nestoja na konci projektu. Riešenie je v rukách manažérov a je ním dôsledné vyžadovanie plnení dopredu určených termínov implementácie jednotlivých modulov systému ako aj celkového času implementácie. Pri implementácii sa však môžu vyskytnúť aj vopred neočakávané (a možno aj neočakávateľné) problémy, ktoré si vyžiadajú čas naviac. Tu je zrejme najelegantnejším riešením zavedenie istej časovej rezervy (time buffer), z ktorej sa môže isté množstvo času použiť na prekročenia termínov. Teda čas sa neberie z času vyhradeného pre testovanie. Najväčší vplyv na dobrý manažment času majú skúsenosti manažmentu a dobrý plán pre softvérový projekt. Používateľské vs. technické požiadavky. Testeri sú prirodzene zameraní na používateľské požiadavky na rozdiel od vývojárov, ktorí sú zameraní viac na technické záležitosti softvéru. Tieto odlišné pohľady môžu priniesť problémy. Vývojári často hľadajú neobvyklé spôsoby ako dosiahnuť požadované výsledky. Toto môže viesť k odlišným cieľom, ktoré sú nekompatibilné s cieľmi testerov. Napríklad vývojári si často prispôsobujú požiadavky tak, aby využili nové trendy vo vývoji softvéru. Preto je potrebné presne definovať spoločné ciele vývojárov a testerov, nie teda len urobiť softvér, ktorý má najmodernejšie vlastnosti ale softvér, ktorý má predovšetkým vysokú kvalitu kódu. Ako príklad pre definovanie spoločných cieľov môže slúžiť spoločné motivovanie oboch skupín ľudí. Ľudia Odlišný cieľ. Nielen chápanie samotného procesu vývoja softvéru majú testeri a vývojári odlišné, oni majú často aj odlišné charakteristiky osobnosti a iné duševné procesy. Napríklad vývojári napíšu aplikáciu tak, aby fungovala a nemôžu pochopiť, prečo by ju niekto používal iným spôsobom. Preto aj "test modulu" je chápaný odlišne. Testeri sa pozerajú na softvér aj z hľadiska reálneho používania reálnymi používateľmi. Zvažujú, čo sa môže stať v reálnom živote a ako to ovplyvní funkcionalitu a správanie produktu, ktorý sa má nasadiť do reálnej prevádzky. Testeri
Efektívny manažment konfliktov pri testovaní softvéru 3 sa považujú za súdržný kolektív, a jednotlivci ako "detailní" a "spoľahliví", zatiaľ čo vývojári ako "kreatívni", "individuálni". Tieto vlastnosti sú síce potrebné na výkon danej profesie ale môžu byť zároveň zdrojom konfliktov. Riešením je podporovať také vlastnosti ľudí, ktoré pomôžu daným problémom predchádzať. Ide hlavne o komunikačné vlastnosti, schopnosti vyjednávania apod. Je nutné podporovať medziľudské vzťahy medzi testermi a vývojármi, aby neprichádzali do kontaktu len keď sa vyskytne problém, ktorý treba riešiť. Je dobré podporovať vzájomné vzťahy napríklad neformálnymi stretnutiami mimo práce, sociálnym programom, športovými podujatiami. Vlastnosti a vzťahy získané takýmto spôsobom sa mnohokrát zúročia pri riešení problémov v práci. Najlepšia cesta k dosiahnutiu spoločného cieľa je spolupráca [2]. Testeri môžu napríklad pomôcť identifikovať vývojárom potenciálne problémy. Vývojári zasa môžu testerom pomôcť určiť najlepší alebo najefektívnejší spôsob testovania produktu. Obe skupiny potrebujú skúsenosti tej druhej skupiny. Zosobnenie kódu. Veľa programátorov vníma kód, ktorí napísali ako časť ich samých. Preto často berú osobne, ak tester nájde v ich kóde chybu. Vývojári potom nie sú ochotní akceptovať existenciu chyby, ale poukazujú na nesprávnosť testu. Majú totiž pocit, že testeri ničia dizajn ich kódu. Ak tester nájde chybu v kóde, vývojári môžu dokonca ukazovať zdrojový kód testerovi s tým, že predsa v ich kóde žiadna chyba nie je. Riešenie tohto problému je podobné ako v predchádzajúcej časti a to zabezpečiť, že jednotliví členovia tímu sa musia oboznámiť s charakterom práce toho druhého. Jedno z možných riešení je rotovanie pracovných úloh. Toto je rozpracované v ďalšej časti práce. Organizácia Firemná politika a prístup manažéra. Hoci veľa spoločností si uvedomuje dôležitosť a potrebu kvalifikovaných testerov, testeri aj tak musia o svoje uznanie bojovať. Veľa testerov cíti, že si musí svoju pozíciu popri vývojároch doslova vybojovať. Manažéri totiž často neposkytujú potrebné uznanie a podporu testerom na rozdiel od vývojárov. Tento stav má za následok náročnejšiu prácu pre testerov, kedy sa boj o uznanie vo firme stáva súčasťou ich práce. Riešenie je v rukách manažéra. Jeden zo spôsobov potlačenia tohto javu je napríklad umiestnenie testerov a vývojárov do blízkosti. Ak sú totiž testeri zavretí na druhej strane budovy ako vývojári, komunikácia medzi nimi ako aj osobné vzťahy sú oslabené. Osobný kontakt často nenahradia telefóny, prípadne komunikácia cez počítač. Vzájomné testovanie a programovanie Horeuvedené príčiny by sa dali rozdeliť do dvoch skupín. Prvá skupina by vychádzala zo zlého prístupu manažérov (projektového manažéra, vedúceho tímu,...) a druhá vychádza z nedostatočného pochopenia podstaty práce ľudí na druhej strane konfliktu (teda vývojári nemajú dostatočné vcítenie a pochopenie pre prácu testerov a naopak). Toto rozdelenie je nasledovné: 1. skupina: nedostatok času, firemná politika a prístup manažéra
4 Miroslav Dávid 2. skupina: používateľské vs. technické požiadavky, odlišný cieľ, zosobnenie kódu Na prvú skupinu problémov má manažér priamy dosah a je teda v jeho rukách, či sa problémy daného typu vyskytnú a aký vplyv budú mať na prácu na softvérovom projekte. Môžeme predpokladať, že manažér si dá pozor a bude riešiť dané problémy niektorými z uvedených riešení. Na druhú skupinu problémov však nemá priamy dosah a je potrebné nepriamo zabezpečiť čo najmenšiu pravdepodobnosť vzniku konfliktov. Vzhľadom na to, že príčinou sú poväčšine nepochopenie práce toho druhého a najlepším spôsobom, ako pochopiť podstatu práce je priamo vykonávať danú prácu. Naskytuje sa nasledovné riešenie problému: Za určitých okolností by sa zmenili úlohy členov v tíme tak, že vývojári by mali testovacie úlohy a naopak testeri by mali implementačné úlohy. Takto by sa daným ľudom naskytol pohľad na problém z druhej strany, čo by neskôr viedlo na pochopenie problému z iného hľadiska. To by zrejme malo za následok pružnejšie riešenie problémov v budúcnosti, rýchlejšie robenie kompromisov a podobne. Samozrejme, nie je možné jednoducho povedať: "Dobre, odteraz vývojári testujú a testeri programujú". Obe skupiny musia mať na prácu potrebné vedomosti, skúsenosti a kvalifikáciu. Avšak napríklad niektoré testovania môže vykonávať aj človek bez nejakých špeciálnych znalostí. Napríklad často testovanie pozostáva z prechádzaní obrazoviek programu, pričom sa zadávajú rôzne vstupné údaje a kontroluje sa výpočet. Prípadne sa kontroluje funkčnosť programu pomocou vopred vypočítaných či stanovených výsledkov, alebo len z vizuálnej kontroly tlačových formulárov a podobne. Na tieto testovania nie je potrebná špeciálna kvalifikácia. Práve tieto testovania modulov by mohli vykonávať aj vývojári. Naopak, vývojári väčšinou potrebujú pre svoju prácu kvalifikáciu (ovladánie programovacieho jazyka, vývojového prostredia, systému pre správu verzií a programátorskú prax). Mohli by sme povedať, že títo ľudia, čo implementujú aj testujú budú pôvodní vývojári. Oproti pôvodnej štruktúre ľudských zdrojov teda potrebujeme viac vývojárov na úkor testerov. Samozrejme, niektoré na niektoré testovacie úlohy potrebujeme testera odborníka s potrebnou kvalifikáciou, tento by sa sústredil len na testovanie a nemal by vývojárske úlohy. Analógia môže platiť aj u vývojárov. Riadiaci pracovníci v oboch profesiách by zrejme mali byť čistokrvní (teda len testeri alebo len vývojári), pretože tí sú zárukou dobrej práce a úlohami z inej oblasti by boli odpútavaní od vlastnej práce, či dokonca ovplyvňovaní. Prirodzene, vývojári by netestovali vlastný kód, pretože potom by to stratilo zmysel ale testovali by kód druhého vývojára. Tento model (väčšie množstvo vývojárov z ktorých niektorí majú aj testovacie úlohy a menšie množstvo testerov) prináša aj výhodu flexibilnejšej pracovnej sily. Ak potrebujeme hlavne implementovať, všetci vývojári implementujú. Ak potrebujeme testovať, tak všetci vývojári-testeri spolu s testermi testujú. Samozrejme, hlavná výhoda by bola zmena myslenia vývojárov, takže títo by boli schopní vžiť sa do roly testera-používateľa a predišlo by sa tak mnohým konfliktom vo firme.
Agilné metódy vývoja Efektívny manažment konfliktov pri testovaní softvéru 5 Môže byť zaujímavé porovnať procesy vývoja a testovania pri agilných metódach vývoja. Agilné metódy (napríklad extrémne programovanie extreme programming - XP) stoja na viacerých princípoch. Asi najvýznamnejší je práve dôležitosť testovania. Testovaniu sa prejavuje veľká úcta. Medzi charakteristické známky XP projektu patria dobré testy modulov (unit test) a funkcionálne testy (functional test). Jedno z pravidiel XP je, že testy (testovacie scenáre spolu s testovacími algoritmami a súvisiacimi testovacími údajmi) sa vyhotovia už pred začatím samotného programovania (Test-Driven Development). Tieto testy vychádzajú z používateľských požiadaviek. Samotný proces implementácie je vedený týmito testmi. Po každej etape implementácie sa na daný prototyp aplikujú testy, ktoré musí vyvíjaný prototyp splniť. Preto je vlastne samotný proces implementácie vedený používateľskými požiadavkami. Nemôže sa teda stať, že vývojári implementujú niečo, čo nebolo v pôvodných požiadavkách a naopak, že neimplementujú časť používateľských požiadaviek. Ďalším z princípov extrémneho programovania je programovanie v páre za jedným počítačom. Toto je zaujímavé aj z nášho pohľadu. Druhý človek môže nielen kontrolovať správnosť kódu po implementačnej stránke, ale môže kontrolovať aj napríklad implementáciu používateľského rozhrania. Používateľské rozhranie má často veľký vplyv na použiteľnosť softvérového produktu. Z uvedených vlastností extrémneho programovania vyplýva, že táto metodológia je lepšie pripravená na konflikty medzi vývojármi a testermi, pretože splnené testy majú najvyššiu prioritu. Proces testovania nie je "odsunutý na druhú koľaj", ale je integrálnou súčasťou implementačného procesu. Efektívny manažment konfliktov Existuje známy predpoklad, že vznikajúce konflikty sú tak škodlivé. Cieľom dobrého manažmentu by malo byť minimalizovanie rozporov a vznikania konfliktov. Avšak ak je konflikt dobre manažovaný, môže pridať organizácii významnú hodnotu. Zamestnanci totiž môžu využiť opačné názory, prípadne pohľady z druhej strany, na urobenie rozhodnutí, vyjasnenie a vyjednanie rozdielnych názorov, posilnenie vzťahov a dokončenie práce. Konflikt sa teda stáva akýmsi médiom na identifikovanie problémov a prostriedkom na ich vyriešenie. Mohli by sme teda povedať, že konflikt je potrebný na zlepšenie inovácií a produktivity vo firme a spôsobilosti a duševného zdravia zamestnancov. Na využitie všetkých kladných vlastností a potlačenie záporných vlastností konfliktov potrebujeme však ich efektívny manažment. Čo je to efektívny manažment konfliktov? Takýto manažment zahŕňa najmä: zameranie sa na podstatu konfliktu a nie na osobné emocionálne vzťahy zváženie širokej škály alternatívnych riešení kooperačné ovzdušie
6 Miroslav Dávid vyhýbanie sa umelým riešeniam problémov, ako napr. hlasovanie, alebo rozhodnutie vedúceho tímu. Zrejme platí, že v tímoch, ktoré sa správajú podľa týchto princípov, je oveľa pravdepodobnejšie dosiahnutie riešenia. Takéto správanie zachová a buduje vzťahy medzi členmi tímu. Manažér potrebuje nejaké kritéria na identifikovanie efektívneho manažmentu konfliktov. Môžeme povedať, že konflikt bol produktívny, ak obe strany prišli ku konsenzu finálneho riešenia a pritom sú spokojné a prispeli k výslednému riešeniu [3]. Produktívny konflikt ale nie je meraný len podľa finálneho výsledku ale aj podľa procesu, pomocou ktorého dospel tím k riešeniu. Ak napríklad niektorý člen tímu striktne trvá na svojom názore, vyhýba sa kompromisu a odmieta zvážiť iné alternatívy a riešenia, je málo pravdepodobné, že konflikt bude prospešný pre druhú stranu. Preto aj počet zmien stanoviska počas diskusie je druhý indikátor produktívneho konfliktu. Ďalšie dve indície produktívneho manažmentu sú založené na pozorovaní správania tímu pri riešení konfliktu. Vo všeobecnosti poznáme tri typy správania sa počas konfliktu: distributívne správanie vyhýbavé správanie integratívne správanie Pri distributívnom správaní presadzujú účastníci konfliktu len svoje záujmy bez ohľadu na ostatných. Pri vyhýbavom správaní zase účastníci chcú konflikt obísť a integratívne správanie sa pokúša nájsť riešenie tak, aby boli zohľadnené záujmy všetkých strán. Je široko uznávaný názor, že integratívne správanie podporuje konštruktívne riešenia, avšak konflikt môže byť produktívny aj pri tvrdom vyjednávaní, teda pri distributívnom správaní. Tretí indikátor produktívneho konfliktu je vysoká úroveň integratívneho (alebo distributívno-integratívneho) správania vzhľadom na nízky výskyt čistého distributívneho alebo vyhýbavého správania. Toto však neznamená, že prvé dva typy správania by sa vôbec nemali vyskytovať v procese riešenia konfliktu (vyskytujú sa hlavne v počiatkoch konfliktu). Štvrtý indikátor produktívneho konfliktu je teda miera posunu od čistého distributívneho alebo vyhýbavého správania k integratívnemu alebo zmiešanému správaniu na konci konfliktu. Záver Vývojári a testeri sú skupiny ľudí, ktorí často prichádzajú do konfliktu. Existuje veľa príčin, prečo tieto konflikty vznikajú a podobne existuje aj veľa spôsobov, ako sa tieto konflikty dajú riešiť, prípadne ako sa im dá predchádzať. Jedným z možných riešení je vzájomné testovanie a programovanie. Vtedy má časť vývojárov aj testovacie úlohy. Výsledok je lepšie pochopenie práce testerov a následne aj minimalizovanie počtu konfliktov. Ďalším riešením je používanie agilných metód vývoja, napríklad extrémne programovanie. Tam je testovanie integrálnou súčasťou vývoja a preto tiež obmedzuje vznik konfliktov. Dobre manažovaný konflikt môže byť aj produktívny, pretože sa
Efektívny manažment konfliktov pri testovaní softvéru 7 môže stať médiom na identifikovanie problémov a súčasne prostriedkom na ich vyriešenie. Ale ako aj v ostatných oblastiach softvérového procesu alebo aj v bežnom živote, všetky konfliktné situácie sa dajú vyriešiť. Stačí ak zúčastnené strany nechajú svoju prehnanú hrdosť a neomylnosť doma a prejavia trochu pochopenia, empatie a dokážu sa dohodnúť na kompromise. Použitá literatúra 1. Cohen, C.F., Birkin S.J., Garfield M.J., Webb H.W.: Managing Conflict In Software Testing. Communications of the ACM, Vol. 47, No. 1 (2004) 77-81 2. Quality Tree Software: Avoiding Conflict, Developing Mutual Respect, http://www.qualitytree.com/ruminate/042997.htm, 29.April 1997, 7kB (29.3.2005) 3. Poole M.S., Holmes M., Desanctis G.: Conflict Management and Group Decision Support Systems. In: Proceedings of the 1988 ACM conference on Computersupported cooperative work, Computer Supported Cooperative Work, Portland, Oregon, United States (1988) 227-243 Annotation Effective conflict management in software testing Behind successful software project are people, who were working on its development. There is usually big amount of these people and it is required for them to cooperate and make compromises. In the phase of testing of the software testers and developers are struggling, because it is consequence of software process during testing. Among these groups of people there are often rising conflicts, which have even bigger effects when there are also interpersonal relations. For the success of the software project is important to know how to prevent these conflicts and how to deal with them, so it is profitable for project and also for concerned people. This is one of many important task of a good manager.