Bár a tesztelõket mostanában már a fejlesztési csoportokba sorolják, sokan még kívülállóknak tekintenek rájuk. Hozzáadott értéküket ez a státusz adja, tartja fenn és egyben folyamatosan veszélyezteti. A korai idõszakban egyfajta szentség lengte körül.

Elkerülendõ a fejlesztõk befolyásolását a tesztelõket különválasztották: szeparált csoportok, más szervezeti egységben. A tesztelõk külön csoportokban voltak elhelyezve, külön szervezeti hierarchiában, hogy elkerüljék a fejlesztõk befolyásoló hatását. A tesztelõi vízió egyszerû volt. A tesztelt rendszerek olyan fekete dobozok voltak, amelyekhez a tesztelõk alkalmazhatták a bemeneteket, és megítélhették az eredményeket.

Az eredeti szándék szerint továbbra is elfogulatlan szószólói szerettek volna lenni a minõségnek, a dolgok a visszájukra fordultak és egyre bürokratikusabbak lettek.

Az agilis fejlesztési módszerek létrejöttével és népszerûsödésével, egyre kevesebb hely maradt az ügyfél visszajelzéseket és minõségi problémákat felkaroló említett kívûlállók számára.

A nagy, klasszikus értelemben vett teszteléssel foglalkozó csapatok átadták helyüket a fejlesztési csapatokban ülõ tesztelõ, minõségbiztosító munkatársaknak.

A kapcsolatok javultak, de a “kívülálló” státusz továbbra is fennáll. Bizonyos értelemben ez azt jelenti, hogy a tesztelõ értékét nem kézzelfogható vagy mérhetõ készségek határozzák meg, hanem az egyedi gondolkodásmódjuk. E gondolkodás “hordozója” misztikus vagy természetfeletti képességekkel és tulajdonságokkal rendelkezik. Egyedülálló világnézettel büszkélkedik, amely betekintést enged olyan körülményekbe és cselekvésekbe, amelyek megfelelõ végrehajtás esetén kritikus problémákat vagy sérülékenységeket tárhatnak fel a szoftverben.

Ebben a világban a tesztelõ értékét az határozza meg, hogy mennyire tud másképp gondolkodni, mint a többi csapattag, valamint azt is jelenti, hogy készségeiket és befolyásukat könnyebb nélkülözni, mivel a tesztelõk által képviselt hozzáadott értéket képtelenek megérteni, felmérni. Ittlétüket tekinthetjük mint egy jelképes felajánlás a Minõség Isteneinek.

Módszerek és keretrendszerek

A vállalatok és magánszemélyek nagy erõfeszítéseket tettek a fejlesztési gyakorlatok kialakítására és szabványosítására. Ennek a munkának eredményeképp létrejött egy közös szókincs, amelyet a problémák magyarázatához, megértéséhez, az ötletek megvitatásához, egy szó mint száz a hatékony elõrelépéshez használják fel.

Ezzel ellentétben elmaradt a megegyezés arról, hogy mi legyen a sztenderd a tesztelõkkel való megfelelõ együttmûködésre.

Igazodás általi befolyás

Ha az emberek nem igazán tudják, mit csinálsz, hogyan csinálod, vagy hogyan lehet róla beszélni, mennyire lehetsz sikeres a csapatodban? Ahogyan a fejlesztõknek, úgy a tesztelõknek is bevett gyakorlatokra és közös szókincsre van szükségük ahhoz, hogy könnyen kommunikálhassák szándékaikat és cselekedeteiket. A probléma az, hogy a tesztelés nem rendelkezik akkora súllyal és befolyással, hogy csapataikkal új eljárásokat és terminológiát fogadtassanak el. A tesztelés egyszerûen nem a domináns tevékenység egy szoftverfejlesztõ csapatban.

Ez azt jelenti, hogy a tesztelési gyakorlatnak és a szókincsnek összhangban kell lennie az elfogadott fejlesztési szabványokkal, folyamatokkal és kifejezésekkel. Minden más szemantika és folyamatdefinicíó csak arra jó, hogy a tesztelést mint megörökölt, bürokratikus, drága kiegészítõnek tartsák.

Az igazodás folyamata három lépésbõl áll: megértés, közös folyamatok és kommunikáció.

Megértés

Minden a módszertan és a folyamat elveinek és elõnyeinek megértésével kezdõdik. Ez nem azt jelenti, hogy egy adott témában világszínvonalú szakértõvé kell válni, de szükség van arra, hogy megértsük az adott témát.

Közös folyamatok

Az új megértéssel felfegyverkezve meg tudjuk állapítani, hogy az alapvetõ fogalmak és szókincsek közül melyek helyezhetõk új kontextusba a tesztelés fõbb szempontjainak támogatása érdekében. Követvén ezt az új irányt, a tesztelési tevékenységeket a fejlesztõ csoport által már elfogadott folyamatokba tudjuk beágyazni.

Kommunikáció

Az alapvetõ fogalmak jobb megértése nyomán, a csoportod megbeszélésein jobb szereplés drámai hatással lehet arra, ahogy az emberek megítélik a képességeidet. Meglepõdnél, ha tudnád, hogy az emberek mennyire elkötelezettek lesznek segíthetni, tanítani, vagy mentorálni, onnan kezdve, hogy érdeklõdést mutatsz a munkájuk iránt. A cél, hogy bizalom és szavahihetõség épüljön közted és a fejlesztõk között, amelyre alapozva a folyamatok közös értelmezését a tesztelés szolgálatába tudod állítani a mindennapokban.

Nézzünk pár példát:

Tesztautomatizálás

Az automatizálás már követte ezt a modellt; ez a sorozatgyártásnak a szoftverfejlesztésre való hatása. A szervezetek felismerték, hogy a hatékonyság növelése és tevékenységük felgyorsítása érdekében a számítógépek erejét fel kell használniuk, hasonlóan, mint a szerelõsorokon a robotokat.

A tesztelõk egy mûködõ tervet láttak és tanulmányozták. A megértési folyamat alatt beemelték ötleteiket az automatizálásba. Mûködõ és kézzelfogható példa volt a fejlesztõk és a szélesebb szervezet elõtt, így az új ötletek elfogadása sokkal gyorsabbá vált.

Az automatizálás a fejlesztõk, a tesztelõk és a üzlet képviselõi közötti legbarátságosabb határterület. Ez egy biztonságos hely, ahol az emberek tanulhatnak egymástól. A fejlesztõk megbeszélhetik a tesztelést, és a tesztelõk beszélni tudnak a kódról, mivel általában egyik csoport sem számít szakértõnek a másik területén, de elvárt, hogy közös célért dolgozzanak együtt.

Sprint tervezés

A sprint tesztelést végzõ csoportok megbecsülik és azonosítják a kívánt feladatokat a user story-k szállítása érdekében. A fejlesztõktõl általában elvárják, hogy munkájukat funkcionális feladatokra bontsák, amelyek könnyen mérhetõk, leírhatók és megoszthatók.

A fenti részletezés sokkal kevésbé valószínû, hogy igaz a tesztelés egészére, inkább csak egyetlen “teszteld le” feladat jelenik meg. A tesztelési feladatok részletes leírása jellemzõleg különálló rendszerben, teszt tervben kerül dokumentálásra.

Miért kell a tesztelési feladatot külön választani a fejlesztési feladatoktól? Ez azért van, mert a tesztelõk még mindíg kívülállók, akiknek folyamatai kevésbé vannak definiálva és kevésbé értik õket. Lényegében hiányzik az összehangolás a fejlesztõk és a tesztelõk között.

A sprinttervezés során a tesztelõ és a fejlesztõ általánosan elfogadott szerepe disszonáns.

Elõször is megpróbáljuk azt megérteni, hogy miért kell a fejlesztõknek ilyen magasszintû átláthatóságot biztosítania a munkájukkal kapcsolatban.

Nem olyan régen a fejlesztés olyan fekete doboz volt, mint manapság a tesztelés. Abban az idõben a fejlesztõk megkapták egy projektet és néhány követelményt, majd egyedül hagyták õket, amíg minden kész nem lett.

A fejlesztés túl sok idõt és erõforrást égetett el ahhoz, hogy a végeredményt a megrendelõk késõn kapják kézhez, amely sokszor nem is az lett amit vártak.

Az agilis mozgalom célja, hogy a munka kisebb szakaszokra bontásával, valamint a szereplõk közötti gyakoribb kommunikáció és résztermékek bemutatásával a fenti problémát orvosolja. Aktív visszacsatolás érdekében megnöveltük a szereplõk közötti átláthatóságot.

Teszt tervezés

De ebben az értelemben a tesztelés sok csapatban ma sem változott, így nem szokatlan, hogy az agilis fejlesztési folyamat egy mini tesztelési vízesésmodellben végzõdik.

Tervünk, ami sikerre vihet már van, csak megvalósítani kell, hogy az agilis tesztelési sprinttervezés inkább az agilis fejlesztési sprinttervezéséhez hasonlítson. A sprintekben tapasztalt, a tesztelést jellemzõ mini vízesés modellt agilis tesztelési munkafolyamattal szeretnénk kiváltani.

Ugorjuk át a kimerítõen dokumentált teszttervet. Nem arról van szó, hogy nincs szükségünk tervre, de ha megnézzük a fejlesztést, láthatjuk, hogy ott sincsenek kiterjedt tervek, mert ez nem része a megközelítésnek. Vegyünk egy tesztelési stratégiát, körvonalazzuk az elfogadási kritériumokat az adott tesztelési erõfeszítéshez, ahogyan azt az agilis fejlesztésnél megismertük.

Nincs többet bedobozolt tesztelés. Ha megakadályozod, hogy a fejlesztõ egy kódold le feladat alá dolgozzon, akkor akkor a tesztelési munkát sem szabad így kezelni.

Kezdjük néhány feladattal azokon a területeken, ahol tudjuk, hogy szükség van a tesztelésre. Gyõzõdjünk meg arról, hogy mindegyiknek van fókusza, célja amelyet verbálisan le lehet írni, idõbeni keretek között tartható, és olyan eredményei vagy kimenetei vannak, amelyek könnyen kommunikálhatók.

Az elsõ sikerek után iteratív utat javaslunk: ahogy befjezetél egy tesztelési feladatot, nézzd végig mit tanultál belõle, vizsgáld meg, mennyire haladtál elõre a fenti folyamatban, és igény szerint bõvítsd a tesztelési munkádat leíró feladatokat.

A kód felülvizsgálata

A kód felülvizsgálat meglehetõsen egyszerû folyamat. Mielõtt a kódot beillesztjük a termékbe, megosztjuk egy vagy több emberrel, akik felülvizsgálják és visszajelzést adnak róla

Ahogy sejthetõ, ez a folyamat nem mindenkinek tetszik, és nincs elfogadott szabvány, amely alapján a kódot értékelik. Ha a kódminõség szubjektív, milyen végeredményre számíthatnak a csapatok?

Az elsõ gondolat az, hogy hibakeresésre jó. A következõ a sorban, hogy a stílus, a szabványok és a konvenciók fenntartása a kódban következetesen érvényesüljön. Ezek természetesen elõfordulnak a felülvizsgálat során, de az igazi elõny az, hogy az emberek másképp viselkednek, jobban odafigyelnek, ha tudják, hogy munkájuk minõségét ellenõrizni fogják.

Az a tény, hogy egy fejlesztõ tudja, hogy meg kell mutatnia a kódját valaki másnak, megváltoztatja a kód írásakor hozott döntéseit.

A kód felülvizsgálat lehetõséget nyújt arra is, hogy beszélgessünk a kódról. Tudás adható át arról, hogy miért pont így lett megírva, növelvén az általános ismeretséget a kóddal kapcsolatban, ahelyett, hogy csak akkor nézzük meg valaki kódját, amikor vészhelyzet van.

A kód felülvizsgálatról, gondolhatjuk azt is, hogy ülünk egy szobában, kihallgatáson, cselekedeteink alapos felülvizsgálat alatt… – szörnyû, és idõrabló gondolat.

Ennek leküzdésére a kód felülvizsgálatot gyakran nem szemtõl szemben, sõt nem is egyidõben végzik el. A csapatok olyan eszközöket használhatnak, amelyek lehetõvé teszik, hogy valaki felülvizsgálatot kérjen, megossza a változtatásokat és visszajelzést adjon. Így kevésbé valószínû, hogy a szubjektív problémák egy része elõforduljon, és az áttekintés olyan dolgokra fókuszálhat, mint a design vagy a unit teszt lefedettsége.

Teszt felülvizsgálat

Maga a tesztelés akkor is zavaros maradhat, ha a csapat részletes teszteseteket ír. A probléma az, hogy a tesztelõk gyakran nem férnek hozzá a kód felülvizsgálat által biztosított visszacsatoláshoz.

A kódfelülvizsgálatban a fejlesztõ munkáját megvitatták és megosztották. Ha van tesztfelülvizsgálat, akkor az általában arra koncentrál, hogy mit fognak tesztelni (teszt terv), és nem arra, hogyan lett elvégezve maga a tesztelés. Ezt általában azzal szokták indokolni, hogy biztosítani akarják a jó minõségû tesztelés kivitelezését. Ebben az értelmezésben, a fejlesztõk által elõször lekódolt, majd felülvizsgált megoldás ugyanazt a kockázatot kellene hogy jelentse.

Ahelyett, hogy áttekintjük, mit kéne csinálni, helyezzük a teszt felülvizsgálat elõterébe a stratégia megvitatását, majd amikor kész a tesztelés rendezõdjünk át, hogy megvitassuk az eredményeket és adjunk esélyt a lefedettségrõl és visszajelzésekrõl való beszélgetéseknek. A továbbiakban fontoljuk meg az aszinkron eszközökkel támogatott teszt felülvizsgálatot, hasonlóan ahhoz, ahogy a fejlesztõk dolgoznak, hogy csökkentsük a felülvizsgálatokra szánt közös idõt.

A teszttervek és tesztesetek sokszor használhatóak képzési anyagnak. Ahelyett, hogy számolgatnánk a teszteseteket és mindenrõl sokszor homályos „átment/sikertelen” csoportosítással számolnánk be, inkább a tesztelõk, teszt futtatás közbeni lépéseinek, kiegészítõ gondolatainak feljegyzésére koncentráljunk; melyeket a kódsorokhoz hasonlóan ugyancsak átlehet nézni, és elmenteni a megfelelõ részhez.

Példamutatás

Az elsõ lépés, mindíg a megértés, minnél mélyebb, annál nagyobb betekintést nyerünk. Minél nagyobb a betekintés, annál hatékonyabb a kommunikációnk, ennek nyomán tesztelõként csapatunk folyamataira ráhatásunk jelentõs mértékben megnõ. Ennek nyomán a tesztelõ példaképpé válik csapata szemében.

A felhalmozott tudás átadandó más tesztelõknek is, gyakorlatban bemutatva, hogyan lehet a tesztelési szempontokat integrálni egy-egy csoport általános folyamataiba.

Ez mûködhet tesztelõk és fejlesztõk között is. Tesztelési igények elfogadtatása a belsõ folyamatokban jobb sprint tervezést, és termékenyebb kód felülvizsgálatot eredményezhet. A csapatban bemutatott, élesben alkalmazott példaértékû megoldással nehéz vitatkozni.

Ragadd meg a lehetõséget befolyásod növelésére és mutasd az utat.

Forrás: Leading By Example
Szerző: Brendan Connolly