A webalkalmazás fejlesztés folyamatának, mint bármely más fejlesztési folyamatnak, a tesztelés egy igen fontos, mégis sokszor háttérbe szorított része. Arról, hogy miért fontos a tesztelés és hogy mikor érdemes elkezdeni a tesztelést, Rédei Krisztiánt, az EPAM Systems egyik Tesztelési Vezetőjét kérdeztük.
Hogyan csöppentél ebbe a szakmába?
Régebben nem volt gyakori a tesztelés, tesztautomatizálás tantárgy az egyetemeken, így ilyen végzettséggel nem is rendelkezem. Tíz éve kezdtem el dolgozni a Nokia Siemens Networksnél. A legtöbb kolléga szoftverfejlesztő mérnök (software engineer) volt, de nem működött az, hogy egyszerre fejlesztenek és tesztelnek, ezért szétváltak ezek a szerepek. Engem a tesztelés érdekelt jobban. A tesztelőknek jobban át kellett látni az egész terméket és annak működési környezetét, illetve felhasználói szemmel is látnia kell a terméket. Tehát egy standard szoftverfejlesztőként kezdtem, aztán egyre több szoftver automatizáló feladatot kértem és kaptam, így lettem szoftver tesztelő mérnök (software test engineer).
Melyik fejlesztési módszertant szereted, mint tesztelő?
Az agilis módszertan elterjedt manapság, és nagyon könnyen hozzáilleszthető a tesztelés. Én is ezt szeretem. A waterfall módszertan ma már nagyon ritka, de előfordul, pl. katonai projekteknél vagy egészségügyi műszerek fejlesztésénél. Ezzel csak azt akarom mondani, hogy a szigorú szabványoknak való megfelelési kötelezettségek esetén használunk nem agilis módszereket is.
Saját tapasztalataid szerint mikortól érdemes a tesztelést elkezdeni a fejlesztések során?
Minél hamarabb. Van egy ipari standard, az ISTQB (International Software Testing Qualifications Board). Ez egy tesztelői minősítés, aminek több szintje van. Szabványosították a tesztelés típusait és definiálták a főbb fogalmakat. A standard alapvetése, hogy el kell kezdeni a tesztelést amilyen hamar csak lehet. Már a dokumentumok átnézésénél is szükség van rá.
Minél hamarabb elkapod a hibát, annál olcsóbb lesz a javítás: a dokumentáció – design – implementáció – gyártás folyamatában nem mindegy, hogy hol találják meg a problémát. Ha a design fázisban, akkor csak a dokumentációt kell átírni és a designon kell javítani, de ha a gyártásnál derül ki, akkor visszamenőleg minden fázisban javítani kell és ez költséges.
Miért tartod fontosnak a tesztelést?
A döntéshozatalban is segít a tesztelés. Mindig van valaki, aki meghozza a döntést, hogy kiadhatjuk a terméket a kezünk közül. Ezt a döntést segítik a tesztek azzal, hogy mérhető dolgot mutatnak. Mint például a kritikus hibák száma, tesztekkel lefedett funkciók aránya, stb...
Az előbb említett tesztelési jelentések figyelembe vételével magabiztosabban tudnak döntést hozni az ügyfelek.
Jelentős anyagi erőforrás megtakarítását is lehetővé teszi a tesztelés. A professzionális tesztelők díja alacsonyabb a fejlesztők díjánál. Más szemmel tekintenek a termékre, nem a saját „házi feladatukat” ellenőrzik. Emellett, a szakértelemnek köszönhetően, jelentősen csökken a kritikus hibák száma. Persze a tesztelők által feltárt hibák javítása erőforrást igényel, de minőséget hoz.
Összességében azt mondanám, hogy a teszteléssel hatékonyabbá tehető a fejlesztés. Minden esetben mindkét fél, a megrendelő és a fejlesztő cég érdekeit is szolgálja.
Mit tartasz tesztelés során a legfontosabbnak?
Hogy mind a négy tesztelési szint megvalósuljon. Ezek a szintek; unit, integration, system, és acceptance szintek. Ha ezek megvalósulnak, akkor jó eséllyel a terméket minden irányból leteszteltük. A négy szintet piramisként képzeljük el. Unit szinten lévő tesztekből készül a legtöbb és acceptance-ből a legkevesebb.
Ennek miértjét gyorsan megérthetjük, ha átnézzük ezek jelentését:
Unit teszt: ez a legkisebb tesztelhető program egység tesztelése, legtöbbször a fejlesztők végzik. Általában automatizált tesztek futtatását jelenti.
Integration teszt: azt vizsgálja, hogy az interface-ek működnek-e, azaz, ha a program egységeket, egymás mellé rakom és összekötöm, tudnak-e ezek rendesen kommunikálni.
System teszt: funkcionális specifikáció alapján történő tesztelés.
Acceptance tesztelés: követelmény specifikáció alapján történik. Az éleshez nagyon közeli környezetben működik. A pozitív forgatókönyvre fókuszál, hogy minden jól működik-e.
Ezen a négy szinten különböző tesztelési típusok valósulnak meg:
A leggyakoribb tesztelési típusok: funkcionális és nem funkcionális tesztek.
Funkcionális tesztek, amik a funkcionális specifikáció alapján készülnek.
A nem funkcionális tesztek közé tartozik a performance teszt és néha ide sorolják a security tesztelést is.
Ezen kívül meg kell említenünk a két tesztelési technikát is: a black box és a white box technika a leggyakoribb.
Konyha nyelven, black box tesztelési technikának azt hívjuk, ha úgy tesztelsz, hogy az implementációról nem tudsz semmit. Fekete dobozként nem látsz bele, de van egy leírásod arról, hogyan kell működjön. Az acceptance tesztek például szinte mindig black box tesztek.
White box technikánál tudod és látod, hogy hogyan működik és így teszteled az alkalmazást. Ilyenek például a unit tesztek.
Említetted, hogy a manuális és az automatikus tesztelés kezd összeolvadni, szerinted miért van ez?
Részben az Agilis szoftverfejlesztés miatt van szükség a gyors visszajelzésre. Itt segít a teszt automatizálás. Emiatt manapság egyre többen elvárják egy manuális (másnéven funkcionális) tesztelőtől, hogy értsen az automatizáláshoz is. Szóval inkább kéz a kézben jár a kettő, mint összeolvad.
Tesztelőcsapat szempontjából van ideális ügyfél?
Az ideális ügyfél rugalmas. Például, megtervezzük a tesztelés folyamatát, aztán a gyakorlat változtatási igényeket hoz. Hogy mi történik, az komolyan függ az ügyféltől. Ha a szerződés betű szerinti betartását kéri, lehet, hogy nem fogjuk elérni a célunkat. Sokszor az ügyfelet edukálni kell, el kell magyarázni, hogy miért szükséges a változtatás, akár egy plusz ember felvétele. A legjobb, ha a fejlesztés elején tisztázzuk, hogy előfordulhat ilyen eset.
Ideális ügyfél az, akivel lehet kommunikálni. Nyitott, érzi, hogy vele vagyunk. Figyelembe veszi a QA-s jelentéseket. Kikéri a tesztelésvezető véleményét. Ha kritikus hibát tárunk fel, annak megfelelően viselkedik. Tehát az ideális ügyfél nyitott és együttműködő, épp úgy ahogy az ideális fejlesztő csapat is.
Az interjút Mátis Eszter Léna és Hetes Réka készítette.
Fotó: Marc Mueller, Unsplash