Hogyan fejlődik a szoftvertesztelés szerepe

• 

A szoftvertesztelés tűnhet dögunalmasnak, de akár szexinek is, ahol a tesztelő a felhasználói élmények úttörőjévé válhat.

Képzeld el az alábbi túlságosan is gyakori forgatókönyvet: A szoftvertesztelőket megkérik, hogy ellenőrizzék az applikáció új funkcióit, miután a fejlesztők úgy ítélték meg, hogy azok készen vannak. A tesztelők rendelkeznek egy listával, a végrehajtandó tesztekről, és manuálisan rákattintanak minden egyes lépésre – próbálják hűségesen követni az összes utasítást és módszeresen dokumentálni az egyes lépések eredményét, ha valami hibás dolgot találnak. Nem igazán ismerik az üzleti oldalt és az alkalmazás felhasználóit, valamint ritkán lépnek kapcsolatba a fejlesztőkkel és a többi projekttaggal. Elsődleges feladatuk, hogy üssenek be X-et és ellenőrizzék le, hogy Y-t kaptak és nem Z-t.

Ez tagadhatatlanul unalmas, de nem hiszem, hogy ez lenne a tesztelés. És biztosan nem az a fajta szoftvertesztelés, amely ahhoz szükséges, hogy rendkívüli felhasználói élményt adjon a usereknek.

A digitális taranszformáció tengere gyakorlatilag minden egyes vállalkozás minden üzletágára hatással van és kevés QA-osztály maradhat csak érintetlenül. Ezen tenger valamelyik hullámja valószínűleg eltörli majd a fentebb vázolt “unalmas szar” manuális ellenőrzést. Egyben növelheti a tesztelés szexuális vonzerejét is ahol a tesztelők az ügyfélélmény úttörői lehetnek.

Valószínűleg ez lehet a legemlékezetesebb megállapítása a közelmúltban megrendezett “Nagy szoftvertesztelői vita” című rendezvénynek ahol Jeff Wilkinson az Accenture ügyvezető igazgatójával és Anders Wallgren az Electric Cloud CTO-jával közösen vettem részt. Miután megvitattuk a tesztelés alakulását olyan témákat is érintettünk mint az SDET-ek (Software Development Engineer in Test) feltörekvő szerepe és a TCoE-k (Testing Center of Excellence) jövője. Mindannyian egyetértettünk abban, hogy az a zavar, amellyel a mai napig szembenézünk nagyszerű lehetőséget biztosít arra, hogy a tesztelést ne hátráltató, hanem innovációt ösztönző tudományágként pozícionáljuk. Az ördög azonban a részletekben rejlik. Pontosan mit is kell változtatnunk, hogy eljussunk ebbe a pozícióba? Íme pár részlet a beszélgetésből:

Egy csapat, egy cél

Wallgren-nek van egy nagyon jó mondása, mely megfogalmazza, hogy a minőség mindenki felelőssége: “Egy csapat, egy cél.” Amikor a felhasználó lát egy hibát, nem a tesztelőt, vagy a fejlesztőt fogja hibáztatni, hanem a céget, amely kibocsájtotta a rossz minőségű szoftvert.

E témánál maradva Wallgren szerint hogyan kell megközelítenünk a minőséget, mint folyamatot: Figyelembe kell vennünk az összes különböző dolgot, ami a kódunkkal történhet miközben áthalad sok-sok ember keze alatt a fejlesztési folyamatban. Miután ezeket felderítettük, elkezdhetjük optimalizálni a folyamatunkat. Amennyiben egy hiba keresztüljut a folyamatunkon és eléri az Ügyfelet, az azt jelenti, hogy valahol szervezeti probléma van amit azonosítani, elemezni és kezelni kell.

A sokféleség szükségessége

Wilkinson a sokszínűség szenvedélyes bajnoka. Számos konferencián hallhattam érdekes előadásait arról, hogy a széleskörű háttérrel rendelkező alkalmazottak bevonása nemcsak a tesztelők számára előnyös, hanem összességében javítja a tesztelés minőségét.
Wilkinson arra fókuszál, hogy a devops-ra való áttérés számos lehetőséget kínál a különböző ismeretek elsajátítására. Például a korábbi manuális tesztelők különbözőképpen segíthetnek az automatizált tesztelésben. Azok akik folytatni kívánják a tesztelési útjukat megtanulhatják a model-alapú automatizálást, és/vagy a Selenium-ot, hogy piacképes tesztelési ismeretekre tegyenek szert. Néhányan a tesztadatok kezelésére fókuszálhatnak. Mások jobban beletanulnak a devops feladatok felosztásába. Az Accenture-nél 40.000 tesztelő dolgozik. Mindannyian különböző személyiséggel és képességgel rendelkeznek, és ennek eredményeképpen az Accenture egy erős vállalat.

A unit tesztelés fontossága

Wallgren a unit tesztelés támogatója. Megköveteli a fejlesztőktől, hogy írjanak unit teszteket a kódjaikhoz, mivel ezen a szinten sokkal olcsóbb és gyorsabb a hibákat elkapni. Véleménye szerint az éles termékben fellelt hibák zömét fel lehetett volna deríteni egy jobb minőségű unit teszteléssel.
Egyetértek azzal, hogy a unit tesztelés fontos és értékes. Ez képezi az agilis tesztelési piramis stabil alapját. Abban viszont már kevésbé vagyok biztos, hogy a unit tesztelés képes elkapni azokat a hibákat, amelyek a felhasználói élményt nagyban befolyásolják. Különösen a nagyvállalatoknál láttam azt, hogy egy idő után a unit teszt készlet olyan szintre romlik, hogy már senki sem fordít figyelmet rá. Azt is felfedeztem, hogy a userek által jelentett hibák nagy része nem fedezhető fel unit tesztekkel; ezekhez egy olyan profi, komoly domain tudással rendelkező tesztelőre lett volna szükség, aki az integrációs teszteket, rendszer teszteket, vagy end-to-end teszteket végezte volna. Ez az a dolog, amiben egyetértünk, hogy nem értünk egyett.

Fejlesztők tesztelnek, nem tesztelők

Úgy gondolom, hogy hacsak nem vagy a Google, Apple, Facebook, vagy az Amazon, nem nagyon fogsz SDET-eket felvenni, olyan fejlesztőket, akik tesztelésre adják a fejüket. Ha mégis találsz ilyen fejlesztőket, nem biztos, hogy ők a legjobb megoldás a végfelhasználói élmény védelmére.
Természetesen a fejlesztőknek ellenőrizni kell statikus elemzéssel, unit tesztekkel, code review-kal a kódjukat. Ahogy Wallgren is említi, az a jó, ha minél hamarabb és olcsóbban találjuk meg a hibákat. Ugyanakkor vegyük figyelembe, hogy az az ember, aki a dolgok létrehozásában jó, nem mindig jeleskedik a dolgok elrontásában. Ezek merőben különböznek egymástól. Ha egy újépítésű házba költözöl, te sem a tervezővel felügyeltetnéd az építést, hanem egy erre szakosodott műszaki ellenőrt bíznál meg.
Wilkinson úgy fogalmaz: “A QA egy gondolkodásmód. Ahhoz hogy valaki igazán jó legyen benne, muszáj hogy elköteleződjön a minőség iránt.”
Waalgren szerint: “A tesztelői gondolkodásmód alapjában a kérdés körül forog, hogy hogyan tudom hibára futtani a rendszert. Ez azért nagyszerű, mert a fejlesztők épp ellenkezőleg gondolkodnak, mivel nem akarják hogy hibát találjanak benne és ennek eredményeként lesz a szoftver sokkal ellenállóbb.

Told (még távolabb) balra

Egyre több szervezet – pl Accenture, Electric Cloud, és számos megrendelője a cégünknek (Tricentis) – a tesztelést tesztmérnöki feladattá alakítják. A változás nem csak felszínes, mert míg a tesztelés reaktív, addig a tesztmérnöki feladat proaktív. Nem csak megkeresed a hibákat, hanem elsősorban már azt próbálod megakadályozni, hogy a kódba kerüljenek.
Ez azt jelenti, hogy sokkal korábban kell foglalkoznunk a minőséggel, mint azt manapság a legtöbb szervezetben tesszük. A megoldás nem csupán az, hogy alkalmazzuk a “told balra a tesztelés”-ként ismert technikákat, hanem arra is vonatkozhat, hogy a tesztelők már a tervezői üléseken is részt vesznek és már ott megkezdik a tesztelhetőség és a minőség útját egyengetni. Ezzel a balra tolódással a tesztelők a munka “szexi oldalára” kerülhetnek, megbízható tanácsadókká, a minőség nagyköveteivé emelkedhetnek és az “unalmas szar meló” a múlt emlékévé válhat.

Forrás: https://www.infoworld.com/article/3279209/how-the-role-of-software-testing-is-evolving.html