Egyre homályosabb vonalak

Ezt hallom minden alkalommal, amikor PractiTest felhasználókkal beszélgetek. Erről olvashatsz tesztelő honfitársaink blogjaikban, vagy a Twitter bejegyzéseikben. Illetve a QA konferenciákon  is egyre többet beszélnek róla…

Egyértelmű a tendencia.

A legtöbb tesztelőnek, viszont nem ennyire egyszerű a változás.

Kezdetben engem is megijesztett, de aztán megtanultam együtt élni vele. És ahogy egyre jobban elmerülök az új valóságban, kezdem felismerni a benne rejtőző lehetőségeknek és fejlesztéseknek a hihetetlen tárházát amit általában a fejlesztőknek, de különösen a tesztelőknek kínál.

Miről is beszélek?

Az a tény, hogy manapság a fejlesztők és tesztelők közötti vonal kezd eltűnni azt eredményezi, hogy egyre több tesztelési feladatot végeznek a fejlesztők.

Ilyen nem történhet a csapatoddal, vagy mégis?

Amikor feldobom a témát más tesztelők előtt, az első reakció általában az, hogy “Ez az én cégemben, az én csapatommal nem történhet meg”.

Aztán amikor megkérdezem, hogy “A programozók manapság több tesztet csinálnak, mint 3 vagy 5 évvel ezelőtt?” az arcok és a hangok hirtelen elbizonytalanodnak.

Bárhová is nézel a fejlesztők egyre jobban bevonódnak a tesztelési feladatokba. Sokkal több unit tesztet írnak, a folyamatos integráció (Continuous Integration) gyakorlatát sok cégnél használják, egyre több programozó sétál át a tesztelőkhöz a tesztelési forgatókönyvekhez kapcsolódó kérdésekkel, stb…

A virtuális falon - amin keresztül eddig a fejlesztők a tesztelőknek dobálták a termékeket - néhány ablak és ajtó is létrejött amin keresztül a két csapat könnyebben kommunikál, sőt együttműködik!



Mit jelent ez a szervezetnek?

Kezdetben csak annyit, hogy a programozók megtanulják, hogyan is kell tesztelni.

A tesztelők esélyt kapnak, hogy megtanítsák a fejlesztésben résztvevő társaikat, hogy a tesztelés (legalábbis a jó tesztelés) nem csak azt jelenti, hogy véletlenszerűen nyomkodom a képernyőn lévő gombokat, illetve különböző zagyvaságokat próbálok meg írni a rendszer beviteli mezőibe.

Tesztelési mentorokká kell válnunk akik elmagyarázzák, mit jelentenek a tesztesetek, a tesztesetek felülvizsgálata, a pozitív és negatív utak, a tesztadatok, valamint az összefüggést a megtervezett-dokumentált tesztelés és a felfedező tesztelés között.

Továbbá ez a változás többek között az is jelenti, hogy a csapatoknak ezentúl időt kell biztosítaniuk a fejlesztőiknek, hogy tesztelhessék a kódot. Még ha ez triviálisnak hangzik is elsőre, igazából elég nagy változást jelent egy cégnek a feladataik priorizálásában, különösen akkor, ha a projektek eleve rövid határidőkkel futnak. Ilyenkor pont az idő a legszűkösebb erőforrás a csapatban.

Mit jelent ez nekünk tesztelőknek?

Korábban említette, hogy a fejlesztési társaink mentorává kell válnunk. De ez csak annyit jelent, hogy valaki mást betanítunk a mi munkánkra aki a közeljövőben mentesít minket a feladataink alól?

Eleinte az volt az ami megrémisztett. Nem maga a jövő, hanem az egész karrierem jövője.

Attól féltem, hogy a tesztelők egy újfajta VHS kazettává, vagy egy fax géppé válnak, olyanokká akik hasznosak voltak a múltban de pusztulásra vannak ítélve, mert az idő és a technológia eljárt felettük.

De rájöttem, hogy ez csak részben igaz.

Az igaz, hogy a feladataink egy része más csoporthoz vándorol a szervezeten belül, de az is igaz, hogy nagyobb felelősséget kapunk a csapaton belül és szintén fel van ajánlva nekünk a lehetőség, hogy jobban befolyásoljuk a projekt folyamatát és végeredményét.

Ma már sok helyen a tesztelők stratégákká és tanácsadókká váltak. A korai felmérési szakasztól kezdve a projekten dolgoznak és a fejlesztési megközelítésben az egyes funkciók követelményeit tervezik és a kockázatokat elemzik. Valamint ezek alapján megállapítják azt, hogy melyiket és hogyan kell tesztelni.

Úgyszintén több felelősséget kapunk abban, hogy jobban működjünk együtt a felhasználókkal amikor a terméket már leszállítottuk nekik.

Arra is felkérnek minket, hogy segítsünk az automata tesztelési keretrendszer több technikai feladatában (tervezés, rendszer felépítés), amely rendszer feladata, hogy szolgálja a fejlesztőket és tesztelőket egyaránt.

Attól függően, hogy milyen vállalatban és milyen környezetben dolgozunk, számos egyéb feladata is lehet a tesztelőnek. Például számos SaaS (Software as a Service) cégnél (mint a PractiTest-nél) a tesztelők a telepítési- és termékmonitorozási feladatokat látnak el, valamint az Ügyfelek valós környezetében történő hibaelhárításban is segítenek. Ahogy az egyik barátom néhány nappal ezelőtt megfogalmazta: “Nem az a lényeg, hogy a hiba megtörténik-e vagy sem, hanem az, hogy hányszor történik meg és az Ügyfelek hány százalékát érinti.”

Számtalanszor azt is kérik a tesztelőktől, hogy szedjenek össze minden olyan információt, amely a projekthez és a projekt minőségi állapotához kapcsolódik. Amely egy naprakész, tömör, világos áttekintés a többi csapat számára a termék státuszáról, a folyamat állapotáról és hogy ezek milyen módon javíthatóak tovább.

Mi a következő lépés?

Sajnos nem tudom, hogy pontosan mi lesz a következő lépés, de ahogy a cikk elején írtam, a tendencia egyértelmű. A tesztelők és fejlesztők közötti szakadék kezd eltűnni.

Maradjunk optimisták: Számos jó és jobb dolog fog történni a tesztelésben a közeljövőben. Annak érdekében, hogy ez történjen fel kell készülnünk a változásokra.

Tapasztaltál hasonlót a cégednél? Hogyan változnak meg a feladataid napról-napra? Ha tesztelőként dolgozol oszd meg velünk a tapasztalataidat ebben a témában, hogy jobban felkészülhessünk a változásokra!


Eredeti cikk:
http://qablog.practitest.com/2013/11/the-lines-are-getting-blurred/



Szerző:
Joel Montvelisky

<< Vissza