Interjú Török Gáborral

A mindössze három évvel ezelőtt indult, a prezentációs iparágat teljesen megújító Prezi rendkívüli ütemben növekszik, és újabb platformokon jelenik meg. A cég tesztelési módszereiről Török Gáborral beszélgettünk, aki a Prezi QA csapatának vezetője.

A Prezi igazi újítása, hogy a hagyományos prezentációs technikával szakít, a térben mozgó előadás pedig a felhasználók számára egy teljesen új élményt, illetve szabadságot ad, a korábbi lapozáson alapuló korlátok ugyanis megszűnnek. Ez a teljesen új szemlélet milyen elvárásokat, illetve kihívásokat támasztott a fejlesztés és a tesztelés során?

A legnagyobb kihívás talán éppen az, hogy a Prezi egy teljesen új koncepciót valósít meg, egy teljesen új felhasználói interfészt ad a felhasználók kezébe. Ezt a zoom-ing user interfészt használja, ami nem egy megszokott dolog, és éppen ezért egyrészt nekünk is ez egy kihívás a fejlesztői oldalról, mert nincsenek még annyira bevett praktikák, amik mentén magabiztosan lehet dolgozni, vagy amilyen szakirodalomhoz vissza lehetne nyúlni.

Másfelől pedig a felhasználóink felé is ez egy teljesen újszerű dolog, és meg kell ismernünk azt, hogy Ők hogy tudják használni ezt az alkalmazást, ezt a felületet, illetve meg is kell Őket tanítanunk, tehát egy olyan felületet kell a kezükbe adnunk, ami magától értetődő, és amit tudnak használni, tehát a usability kérdés egy nagyon fontos aspektusa ennek a fejlesztésnek, amivel foglalkoznunk kell.

Mint startup vállalkozás, nálatok mennyire elfogadott a tesztelés a csapaton belül?

Maximálisan, már a cég indulásától kezdve ez egy nagyon fontos szempont volt, hogy odafigyeljünk a minőségre; a menedzsment is támogatja a tesztelést és a tesztelési törekevéseinket, illetve abból kifolyóan, hogy start-upok vagyunk, abban a szerencsés helyzetben vagyunk, hogy nem utólag kell már egy meglévő valamilyen céges szervezetbe bevezetni a tesztelést és megismertetni a dolgozókkal, illetve hozzáilleszteni a meglévő projektvezetési módszertanhoz, hanem kezdettől fogva a tesztelés része az egész fejlesztésnek, és mindenki magáénak érzi emiatt a minőséget. Nem egy önálló dolog az, hogy tesztelünk, hanem egész végig odafigyelünk, és ez része a fejlesztésnek.<

Startup vállalkozásként, milyen egyedi problémákkal kell megküzdenie a csapatnak a szoftvertesztelés területén?

Legfőképpen a növekedéssel, illetve a változással; amikor én a Prezi-hez jöttem, feleennyian voltunk, most ahhoz képest dupla annyian vagyunk, és még szeretnénk, ha ez a szám újra duplázódna. Ez igazából nagyon sok kihívást ad nekünk, másfelől lehetőségeket is, hiszen ha gyorsan változunk, lehetőségünk van gyorsan korrigálni is. Ehhez igyekszünk megfelelő, a gyors változást támogató projektvezetést, illetve projektmenedzsmentet használni, és igazából a tesztelésben is ez a legnagyobb kihívás, hogy amit ma jónak gondolunk és bevált tesztelési folyamat, azt lehet, hogy holnap meg kell változtatnunk.

Ezeket a problémákat hogyan tudjátok kiküszöbölni?

Egyrészt azt, hogy egy agilis módszertant, a kanbant használjuk a projektmenedzsmentre. Ez azt jelenti, hogy folyamatosan kis csapatokban dolgozunk, úgynevezett ilyen ProductTeam-ekben. A PruductTeam-ben van designer is, fejlesztő is, projektmenedzser is, illetve tesztelő és QA-s is. Az egész folyamatban részt vesz a QA-csapat. Nem azt a módszert követjük, hogy elkészítünk egy designt, egy protótípus, amit aztán implementálunk, aztán a fejlesztők kidolgozzák, és a végén a QA leteszteli, hanem ez egy körkörös, és önmagára visszaható folyamat.

A QA nem csupán tesztel, hanem minden olyan információt a csapatában eljuttat, ami a minőséggel kapcsolatos, része a support-nak is, illetve folyamatosan figyeli a user-experience csapattal együtt dolgozva a useability, és ezeket is visszacsatornázza a fejlesztési módszertanba, hiszen a termék használhatósága nagyban befolyásolja, hogy hány felhasználónk van.

Mit tesz a csapat, hogy a tesztelés meghatározó részévé váljon a fejlesztésnek?

Annak köszönhetően, hogy már a kezdetektől fogva tesztelünk, az egy kihívás, hogy az új csapattagokat integráljuk ebbe a módszertanba, tehát nekik is megtanítsuk, hogy mi hogyan gondolkodunk a tesztelésről. Amiatt, hogy a QA szervesen része ezeknek a PruductTeam-eknek, igazából az egész csapat együtt dolgozik a minőségen, az egész csapat érintett a minőségben, és emiatt folyamatosan része a fejlesztésnek, designnak maga a tesztelés is literrációkon keresztül egészen addig, amíg azt ki nem rakjuk a felhasználóink felé. Illetve megvan minden olyan eszközünk, ami ezt segíti, és dolgozunk rajta, hogy ezek mindenki számára elérhetők legyenek, és kényelmesen lehessen tesztelni.

Miért érzitek fontosnak, hogy a megoldást alapos tesztelésnek vessétek alá?

Ami talán a legfontosabb, hogy noha a Prezi egy szoftver, mi nem egy szoftvert árulunk, hanem egy szolgáltatást nyújtunk a felhasználok felé. A Prezi-nek az a legfontosabb, hogy a felhasználói elégedettek és boldogak legyenek, hiszen csak akkor fogják használni a szoftvert. 

Ha egy olyan eszközt adunk a kezükbe, amit nehézkesen tudnak használni, ami tele van hibákkal, akkor nem fogják szeretni és nem fogják használni, pedig mi azt szeretnénk, hogy minél többen és többen használják. Ennek a legfontosabb aspektusa az, hogy tudjuk garantálni azt, hogy amikor kiteszünk egy újdonságot a Prezi-ben, akkor biztosak lehessünk abban, hogy nincsen benne hiba, és ebben pedig a tesztelés egy nagyon jó barátunk, nagyon jó partner. Minden fejlesztési literrációval egy időben a tesztelés is része a rendszerünknek folyamatosan, ahogy dolgoznak a fejlesztőink, folyamatosan futnak a háttérben a tesztek.

Célunk továbbá az, hogy a continuous integration jegyében folyamatosan tudjunk újdonságokat kitenni, hogy ne egy- vagy kéthetes ciklus legyen, amikor egy új relase-t ki teszünk a felhasználóknak, hanem, ha arra van szükség, akár ezt óránként is meg tudjuk tenni.  

A fejlesztések során leginkább milyen tesztelési feladatokra és módszerekre koncentráltok?

Célunk az, hogy lehetőség szerint mindent automatizáljunk, Aautomatizált tesztjeinkből legyen sok, hiszen csak ez tudja azt garantálni, hogy humán beavatkozás nélkül folyamatosan tudjunk tesztelni. Egy úgynevezett acceptancet tesztvezérelt termékfejlesztést próbálunk kialakítani a csapatokon belül, ami azt jelenti, hogy a tesztelés már a funkció designolásakor jelen van rendszerünkben.

Agilis módszertant használunk, amiről sokan azt gondolják, hogy nincsenek specifikációk, nem kell specifikációt írni, de természetesen ez nincsen így, hiszen ha nem tudjuk, hogy mi a funkció, azt nem tudjuk designolni vagy lefejleszteni. 

Ahelyett, hogy egy száraz, és önmagában nem használható specifikációt írnánk, az egyes funkciók user stroy-ait,  úgymond specifikációját írjuk le, és azt megpróbáljuk egyből funkcionális tesztekbe megfogalmazni. Ez azért nagyon jó, mert már a design szakaszban is előhoz olyan problémákat, amiket nem gondoltunk volna, de a teszt írása közben kiderül, hogy ez a funkció így nem fog tudni futni, tehát már nem is kell eljutni a fejlesztéshez.

A fejlesztőnek ez pedig egy nagyon jó dolog, hiszen miközben fejleszt, már rendelkezésére áll az a teszt, amit ha a fejlesztése végén lefuttat és zöldet mutat, akkor jól dolgozott, és akkor kész a funkció. Ez segíti azt, hogy igazán komolyan vegyük ezeket a teszteket, hiszen mindenki érzi, hogy ez neki fontos, az Ő munkáját is segíti. Ezért nem kell külön azért dolgoznunk azon, hogy meggyőzzük arról az embereket, hogy a tesztek fontosak, hiszen mindenki a saját bőrén tapasztalja, hogy milyen jó az a teszt. Ezért is van egy ilyen robotunk az irodában, ami megszólal akkor, ha valaki elront egy ilyen tesztet, és ez is egy olyan visszacsatolás arról, hogy egyből akarunk róla tudni, ha hibáztunk és egyből ki tudjuk javítani, még mielőtt véletlenül azt kiadjuk a felhasználóinknak.

Szerző: Török Gábor