Változó szerepkörök vizsgálata a teszt- és minőségmenedzsmentben

Mint ahogyan minden iparágban, úgy a tesztelésben is a gyakorlati megoldások alakítják a projekttagok szerepeit, feladatait. Milyen változások zajlanak ma a szoftvertesztelésben a cégeknél? Hogyan kezeljük ezeket az átalakulásokat? Hogyan válhat belőlünk a holnap QA menedzsere?


Bár minden cég és iparág különböző, a legtöbb olyan gyakorlatot alkalmaz – virtualizáció, kevésbbé megelőző tesztelés, ad hoc hibajavítás, apránkénti telepítés, stb. – ami módosítja a tesztmenedzserek szerepeit. Az alábbi cikkben az általános fejlesztői irányzatokról lesz szó, amelyeket a piackutatói és teszt-tanácsadói munkám során látok, valamint azokról a tanácsokról, amiket teszt- és minőségügyi menedzsereknek adok.

Irányzatok a tesztvezetésben

Minden egyes cég és szakág különböző, azonban konferenciák résztvevőjeként, és a szakirodalmat olvasva, valamint saját munkám során is felfedeztem, hogy léteznek irányvonalak a szoftverfejlesztésben. Íme néhány ezek közül:

  • Integrált termékcsapatok

Tagjai azok a  tesztelők, akik általában különálló csapatokban dolgoznak projektenkénti alapon, termékcsapatokba tömörülve. Ezek a termékcsapatok projektről projektre együtt maradnak. A teszt- és minőségügyi vezető szerepe elmosódik, mert a tesztelők így egyetlen, mindenhez értő fejlesztői menedzsernek tesznek jelentést; természetesen így radikálisan csökken a tesztmenedzser mint portfólió menedzser hatásköre a tesztelők munkaidejére és feladataira vonatkozóan.

  • Apránkénti telepítések; a „tesztfázis“ vége

Azok a csapatok, akik minimális funkcionalitással rendelkező szoftvert készítenek, sokkal gyakrabban tudnak telepíteni – elméletileg. A folyamatos integráció, átadás és még a telepítés is ez irányba vezérli az infrastruktúrát. Ennek az az eredménye, hogy a tesztelés nem egy vezérlendő fázis lesz, nem egy mini-projekt, hanem egy állandóan folyó tevékenység. Ez még inkább eltörli a teszt- és minőségügyi menedzserek portfólió- és projektmenedzser szerepkörét.

  • Virtualizáció

Mióta a tesztelők egy gombnyomásra fel tudják építeni saját tesztkörnyezetüket, már nem elvárás a tesztkörnyezet, s a csapattagoknak nem kell az erőforrásokon civakodniuk.


  • „Javítsd ki amint megtalálod a hibát“ stratégiák

Bár nem olyan gyakran mint más tendenciánál, de látok csapatokat akik úgy döntenek, hogy azonnal kijavítják a hibát, vagy nem vesznek tudomást róla amikor rábukkannak. Ha figyelmen kívül hagyják a hibát, valószínűleg nem fogják dokumentálni a verziókezelésben sem. Ezáltal a hagyományos hibakövetés, támogatás, mérés kevésbé lesz értékelhető a teszt- és minőségügyi vezetők számára.

  • Hangsúlyos távolodás a megelőző teszteléstől

Ez sem olyan általános, de sok web-fejlesztő cég enged meg hibákat az éles környezeten – amennyiben azok könnyen megtalálhatók és gyorsan helyrehozhatók.

Ha mindezeket a tendenciákat együttesen veszed, láthatod a változást: a hagyományos tesztmenedzsmentnél használt eszközök kezdenek elavulttá válni – vagy legalábbis kevésbé szolgálják már a célt. James Whittaker szakmai guru tavaly a STARWestnél egy vitaindító előadásában azt állította, hogy a hagyományos tesztelés haldoklik. Whittaker később megszervezte a Google Teszt Automatizációs Konferenciáját, ahol Alberto Savoia a Halálnak öltözve s „A teszt halott“ címmel beszélgetést tartva  megerősítette Whittaker állításait.

Ezek a tendenciák többé-kevésbé aktuálisak lehetnek a szakterületeden vagy a cégednél. Egyik ügyfelem nemrég ellenszegült a tendenciáknak: a tesztelők már nem egy általános fejlesztői menedzsernek tesznek jelentést, hanem egy formális minőségügyi menedzsernek.

Minden cég különböző. Nagy múltú cégeknél és hagyományos szakterületeken ellenállásra vagy ezeknek a változásoknak a nyílt figyelmen kívül hagyására számíthatsz olyankor is, amikor a szoftvercsapat magatartását szabályzat vagy szerződés írja elő. Úgy gondolom, hogy kevésbé változtathatók például az avionikai, banki vagy orvostechnikai rendszereknél.

Tesztmenedzserként lehet, hogy kicsit kényelmetlenül érzed magad, ha ezek az irányzatok hatással vannak rád.

Most, hogy már beszéltünk a tendenciákról, beszéljünk azokról a módszerekről, amelyekkel sikeresen alkalmazhatók a QA menedzsment stílusok.

Megfontolandó változtatások

A ScrumMasternek legyen felelőssége. A ScrumMaster egyrészt a folyamat  rendőre (biztosítja, hogy a csapat teljesíti kötelezettségeit), másrészt az akadályok elhárítója. Sok QA menedzsernek megvannak a megfelelő emberei s a gyakorlata, hogy ezeket a feladatokat megoldja. Funkcionális tesztelési szakértő Anna Royzman a saját szerepéhez ScrumMaster-i és projektmenedzseri kötelezettségeket társít.

  • Légy terméktulajdonos!

Amíg az extrém programozás az ügyfelet mint üzleti vezetőt határozza meg, addig a gyakorlatban az üzleti vezetők hajlamosak egy elemzőt megbízni a csapat irányításával. Definiálni azt, hogy egy szoftvernek mit kellene tudnia, valamint meghatározni az irányt a régi tulajdonságok javítására szemben az új tulajdonságok kialakításával, két olyan feladat, amit sok QA menedzser nem hivatalosan végez el. Szükségszerű, hogy a hivatalos kötelességük részéve tegyék ezeket.

  • Törd át a láthatatlan korlátot és szánj több időt a tesztelésre!

Mindezekkel a változtatásokkal talán nem vész el a minőségügyi menedzser szerepe – viszont azt eredményezheti, hogy a menedzsernek több ideje lesz más feladatokra koncentrálni. A Wisconsinban lévő madisoni WTS Paradigm tesztmenedzsere, Benjamin Yaroch azt mondta, hogy bár menedzserként vették fel, de úgy látja, hogy valójában ez a szerep egy vezéré. Döntéseit és tapasztalatait a munkára tudja szorítani, s közvetlenül tud irányítani valamint tanácsot adni.

  • Légy gyakorlati menedzser aki magasabb szinten dolgozik!

Amíg az általános fejlesztési menedzser a tesztelő mindennapi munkáját irányítja egy projektben, addig aligha lesz készsége vagy hajlandósága arra, hogy a tesztelő szakmai fejlődését segítse. A magasabb szintű menedzser sok csapat tesztelőit irányítja, elősegíti a kommunikációt, és segít meghatározni, hogy mit is értsünk tesztelés alatt. Egy kollégám csinálta ezt egy ideig, négy különböző államban irányította számos csapat munkáját.

  • Légy tanácsadó, járj csapatról csapatra!

Amikor megkértem Todd Webbet, a Groupon egyik technikai vezetőjét, hogy írja le munkakörét, azt mondta, hogy néhány hónapig aktívan közreműködik egy csapatban, majd egy másik csapathoz megy. Míg ez a fajta szerep nem túl gyakori, a Microsoftnál évek óta van egy „teszt architect“ szerep, ami nagyban hasonlít a belső tanácsadóhoz. Jason McDonald teszt architect elmondta, hogy sok időt tölt el a tesztelés üzleti értékének irányításával, kereskedelmi kapcsolatkezeléssel, eszközök értékelésével, valamint vállalati kezdeményezések támogatásával.

Tervezd meg saját QA menedzsment karriered

A következő lépés feltenni magadnak a kérdést, hogy milyen cégnél szeretnél dolgozni. A csúcs cégek nyilván a fejlesztés ütemének gyorsításán dolgoznak, összekapcsolva a fejlesztést, a tesztelést és a működést. A QA menedzsereknek új megoldásokat kell találniuk az értékek növelésére, új szerepeket megtanulni és új lehetőségek után kutatni, hogy lépést tudjanak tartani ezekkel a cégekkel.

Másrészről elképzelhető, hogy a te céged elégedett a maga fejlesztési módszerével, s az újításra fordítandó energiáit más területekre szeretné összpontosítani. A termékfejlesztés, új technológiák és egy változtatás az üzleti modellen vagy az ügyfélkörön mind remek út az újításra. A minőségügyi menedzser lehet, hogy teljesen másképpen alkalmazkodik az ilyen típusú cégeknél.

A holnap QA menedzsere

Ahogy egy költő mondaná, hadd virágozzon ezerféle tesztstratégia, a piac ki fogja választani a győzteseket és veszteseket.

Bárhogy is nevezzük, a minőségnek mindig lesznek bajnokai, és a szoftveriparban sokáig szükség lesz még minőségügyi személyzetre.

A szerző köszönetet mond Lanette Creamer-nek, Wade Wachs-nek, Anna Royzman-nek, Ben Yaroch-nak és Debbie Richardson-nak a cikk megírásához szükséges háttérinformációkért és tanácsaikért.


Szerző:
Matt Heusser

<< Vissza