Ha az a feladat, hogy NE TESZTELJ!

• 

“Valós események alapján..”

Képzeld el, hogy egy webes terméket fejlesztő céghez nyersz felvételt, mint szoftvertesztelő (vagy tesztvezető).

Az első napodon azt látod, hogy körülötted mindenki nagyon okos, a legmodernebb technikával, módszerekkel dolgoznak. De szinte azonnal észreveszel egy furcsa dolgot is a cégben; keveset tesztelnek, mielőtt az új funkciót élesbe állítanák.

Rögtön azt gondolod: “Heuréka! Már meg is találtam az első olyan dolgot, amivel jobbá tehetem a céget: jobb terméket engedünk ki az éles környezetre, ha több tesztet fogunk futtatni!”

De amint közelebbről szemléled a folyamatot két dologra is rájössz:

1. Habár néhány hibát kiengednek az éles környezetbe, ezek száma nem számottevően több, mint az előző munkahelyeiden. És ami még ennél is lényegesebb, hogy amikor ezeket a hibákat észreveszik, szinte azonnal (percek alatt) javítják is, így úgyszólván semmi hatásuk nincs a felhasználókra.

2. Amennyiben megnövelnéd a tesztelést (akár manuális, akár automatikus) a folyamatban, az drasztikusan emelné a költségeket és meghosszabbítaná a fejlesztési ciklust, ami olyan szinten késleltetné a piacra dobás idejét, hogy az már a vállalatnak elfogadhatatlan lenne.

Mit tudsz tenni? Nos, elsősorban ne kezd el a több tesztelést erőltetni! Inkább értsd meg mit és miért csinálnak! Előfordulhat, hogy a kimerítő tesztelés nem a legjobb megoldás.

Elég menő dolog, ha nem szokványosnak tűnő módon dolgozol és hirtelen valaki rámutat arra, hogy mások is így dolgoznak és még blogolnak is róla.

Köszönetet kell mondanom wonnitta-nak, aki nemrégiben megmutatta Gojko Adzic egy posztját, ahol olyan cégekről írt, akik képesek alternative módszerekkel csökkenteni a kimerítő regressziós tesztelésüket. Nem szeretném megismételni amit Gojko írt, de határozottan ajánlom, olvassátok el azt a cikket.

Inkább elmagyarázom, hogyan kezeli sikeresen a fentiekben leírt cég a fejlesztési és tesztelési folyamataikat. Számos olyan alapelvük van, amelyek elősegítik a gyors piacra jutást miközben magas minőséget tartanak fent a termékükben. Nincs varázslat, csak józan ész és fegyelem.

Nem gondolom, hogy ezek a srácok annyira egyediek lennének, vagy olyan technikákat használnának, amelyek nem lennének elérhetőek a legtöbb fejlesztői csapat számára. Egyszerűen csak fejlesztették a folyamataikat és nem triviális módon keresték az utat céljaik eléréséhez, miközben megpróbáltak alkalmazkodni a rendkívül kompetitív üzleti környezetükhöz.

A folyamat nem nehéz, viszont szükség van fegyelemre és a csapattagok együttműködésére (fejlesztők, tesztelők, PO, BA, stb…). Lássuk mik azok az elvek, amelyeket a folyamatuk alapján azonosítottam:

• Rövid iterációk és apró inkrementális változások – kis agilis ciklusokkal dolgozva és a nagyobb részek apróbb iterációkra való bontásával csökkentik a kiadások komplexitását és kockázatát.
• Jó tervezés és kockázatelemzés a projekt elejétől kezdve – hihetetlen, hogy az emberek mindig azt mondják jobb a tervezési fázisban elkapni a hibákat, de semmit nem tesztnek érte. Nos, ha nincs időd arra, hogy hibázz, jobb ha a kezdetektől fogva dolgozol is rajta. A legjobb módja ennek az, hogy még a funkció kódolása előtt megvizsgálod a feltételezéseidet és a terveidet. Ezeket végezve a srácok képesek jó terméket (funkciót, GUI-t, UX-t, …) készíteni, valamint a magas kockázatú területek felismerésével és elemzésével képesek oly módon megtervezni és megírni a funkciókat, hogy jelentősen csökkentsék a hibák előfordulását. A matek nagyon egyszerű: KIS KOCKÁZAT – KEVESEBB HIBA.

• Mindenki tesztel – egyik tulajdonsága a jó fejlesztőnek, hogy nem sznob. A kiváló minűségű termék elérése érdekében ez a vállalat egy “mindenki tesztel” szabállyal rendelkezik, ami annyit tesz, hogy bár feltételezzük a tesztelők jobban tesztelnek, mint a programozók, ez nem jelenti azt, hogy ők nem futtathatják saját tesztjeiket. A tesztelők segítenek a fejlesztőknek meghatározni a legkockázatosabb területeket, ahol ők is futtathatják a saját tesztjeiket, és lehetnek olyan részek is, ahol a tesztelők nem tesztelnek, a tesztelési feladatok a programozókra hárulnak.
  Úgy gondolom ez a szabály két fő célt szolgál: mentesíti a tesztelőket, hogy a folyamat szűk keresztmetszetei legyenek és nagyobb felelősségérzetet ad a programozóknak a saját fejlesztési szabályaik iránt (a kötéltáncos is kisebb lépéseket tesz a kötélen, ha nincs alatta biztonsági háló).

• Folyamatos integráció – ha nem tudod mi ez, akkor keress rá a neten. A CI-ban a legjobb dolog az, hogy lehetővé teszi a csapat számára, hogy folyamatosan stabil terméken dolgozzon és gyorsan megtalálja a triviális hibákat, valamint még gyorsabban ki is javítsa azokat.

• A termék összehangolt fejlesztése – a termék kiadásait, változásait kontrollálni kell. Időzítve és fokozatosan kell végrehajtani őket annak érdekében, hogy ne legyenek egymásnak ellentmondásos fejlesztések egyidőben kitéve. Ugyanazon funkciók többszörös változtatása – különösen ha egymástól különböző csapatok végzik a fejlesztésüket – automatikusan növelik a hibák számát a termékben.

• Fokozatos telepítések – melyek lehetővé teszik, hogy a telepítés közben ellenőrizhessük az új kód milyen hatással van a rendszerre. Ha olyan technikákat használnsz, mint az A/B tesztelés, vagy csak a felhasználók egy részhalmaza férhet hozzá a termék egy verziójához, akkor a módosítások hatását erre a kis felhasználói létszámra korlátozhatod, ezáltal a kockázatot is jobban kontrollálhatod. Ezek az “éles tesztek” nagyon hasonlóak a Béta programokhoz, ugyanolyan információkat nyújtanak, csak sokkal gyorsabban.

• Kiterjedt monitorozás – mert ha van egy hiba a rendszerben arról te szeretnél legelsőnek értesülni, és az összes információt meg akarod kapni róla. Számos felügyeleti eszköz áll rendelkezésedre, de a telepítés csak a munka első része. A terméket is úgy kell fejleszteni, hogy integrálódjon ezekkel a monitorozó eszközökkel és minden olyan információt megadjon nekik, amelyek lehetővé teszik majd a csapat számára a hiba helyének megjatározását, megértését és javítását.
  Bizonyos értelemben olyan, mint a jó öreg dr. Watson, de képes legyen megoldani, hogy a felhasználói hibák AZONNAL jelentve legyenek.

• Előre definiált visszaállítási és javítási folyamat – ha gyorsan és helyes akarunk valamit végezni nyomás alatt, akkor előre meg kell határozni a lépéseket. Van egy héber mondás: “Gyakorolj keményen, hogy a csata során könnyen jöjjön.” A csapatnak szüksége van egy folyamatra, mely lépésről-lépésre visszaállítja a szkripteket, módosított fájlokat és minden egyebet annak érdekében, hogy a rendszer gyorsan visszatérhessen a legutóbb ismert stabil állapotába (ahogy a kiadás előtt volt).
  Mivel ez a folyamat kiadásról-kiadásra változhat ezért ezt mindig újra kell definiálni (vagy legalábbis a fő folyamatot átvizsgálni és a szükséges változásokat megtenni).
  Ne felejtsd el, hogy a visszaállítás nem lehet az egyetlen lehetőséged. Meg kell határozni egy olyan eljárást is, amely eldönti, milyen hibákat lehet az éles környezeten javítani, ezt hogyan lehet megtenni és tesztelni.

Folyamatos tanulás és retrospektív kultúra – mert hibákat fogtok ejteni, de tanulnotok kell belőlük, hogy később ne kövessétek el újra.
A csapatnak van egy olyan folyamata, ahol az élesen észlelt hibákat egy félig formális retrospektív megbeszélésen felülvizsgálják, levonják a tanulságokat és kitalálják azokat a lépéseket, amelyek megakadályozzák, hogy ugyanazt a hibát a jövőben ismét elkövessék.

FIGYELEM:

Nem minden vállalat egyforma!

Fontos megértenünk, nem a vállalatok nem egyformák és sokszor egy cégen belüli két csoport, vagy termék is különbözhet. A technológia, a vállalati kultúra és legfőképpen a felhasználók és a termékek felhasználási módja határozza meg összességében, hogy hogyan fejlesszük és tegyük közzé az applikációinkat és milyen szabadon nyúlhatunk hozzá a folyamatainkhoz.

Vannak olyan iparágak, ahol a egy hibáért nagyon magas árat kell fizetnünk ezért teljes körű, kimerítő tesztelést kell elvégeznünk, például ha egy élettudományi projekten dolgozunk, ahol egy hiba egy beteg életét és halálát jelentheti; vagy banki területen, ahol akár millió, vagy milliárd forint tűnik el egy hiba miatt; vagy lehet akár a légi közlekedés, ahol légi katasztrófákat idézhetünk elő.

A webalapú termékekkel foglalkozó cégek túlnyomó része azonban nem tartozik a fenti csoportba és van egy kézzelfogható előnyük, amely hatalmas szabadságot biztosít nekik, mert a saját üzemeltetésű – on premise – szoftvereket gyártó cégek számára ez nem elérhető.

Sok oka lehet, hogy nem tudod olyan egyszerűen megvalósítani a cégedben azt, amit a srácok a fentiekben csináltak, és valószínűleg igazad lehet a legtöbb indoknál. Ugyanakkor figyelembe kell vennünk azt az üzleti valóságot is, hogy a világon a cégek 95%-a megengedheti magának, hogy egy-két hibát kiengedjen az éles környezetre és ezt egyensúlyba hozza a magasabb minőségű termék és a rövidebb kiadási ciklus előnyeivel.

Végső gondolatként:

Talán erre kell törekednünk amikor munkakörünket minőségbiztosítási mérnökként és nem tesztelőként definiáljuk?

Elvégre mindannyian tudjuk, hogy nincs tökéletes, hibamentes szoftver, és a legtöbbünk valóban a legjobb tudását akarja adni a cégnek, ahol éppen dolgozunk …

Forrás: https://ukalf.com/?q=node/1002