App-ok és DevOps: Hova illeszkedik a QA?

A szoftverfejlesztés hosszú utat járt be a kezdeti, mindenki csinálja a saját dolgát és majd megbeszéljük mire jutottunk megközelítésbõl

A DevOps változást hozott, az amúgy természetesnek tekinthetõ, megrögzött gondolkodásmódba, amely szerint hagyd, hogy befejezzem, amit csinálok és csak utána tudok veled foglalkozni. Az igazság az, hogy senki sem szereti, ha megmondják neki mit csináljon és valószínûleg ezért népszerûek a minõségbiztosítási csoportok a szervezetben.

Ha a DevOps folyamatos fejlesztésrõl és ennek élesbeállításáról szól, hol jön a képbe a QA? Sokszor merül fel az a tévhit, miszerint a DevOps szoftverfejlesztési gyakorlat csak egy õrült rohanás a célegyenesig. A kódot fontos idõben elkészíteni, de a hibák csökkentése ugyanolyan fontos része a DevOps-nak, mint bármi más.

Az automatizálás mögötti alapgondolat az, hogy csökkenti az emberi hibákat, mivel kevesebb emberi beavatkozással jár. Amikor a feladatok unalmassá és ismétlõdõvé válnak, az emberek hajlamosak hibázni, ha ekkor egy automatizált munkafolyamatra bízzuk a monoton dolgokat, az embereknek lehetõségük nyílik kreatív irányba kibontakozni.

Megtörni a mintát

A DevOps alapvetõen megváltoztatta a QA csapat szerepét és csak azok számára jelent majd sikert, akik hajlandóak résztvenni a termelési folyamatban. Volt idõ amikor a minõség ellenõrök bementek egy szobába, felsõbbrendûségük tudatában elvégezték vizsgálataikat és úgy sétáltak ki, mintha mindenkinél jobbak lennének. A mobilos fejlesztéseket kifejezetten figyelembe véve, már értelmetlen egy külsõ, független QA csapatról beszélni.

A hagyományosabb gondolkodásmód persze az, hogy mindig legyen egy külsõs QA csoport, amely biztosítja az integritást és a minõséget. A új gondolkodásmód szerint, a QA mindenki munkájának részévé kell hogy váljon, addig a pontig, hogy a termelési ciklus minden pontjában jelen legyen. Nem mindenki örül a változásnak és páran úgy érzik, hogy ha folytatják azt, amit eddig csináltak, akkor minden rendben lesz. De a „csak a késztermékre” alkalmazott QA nyomán észlelt nehézségek hamarosan arra bírják õket, hogy beintegrálják a termelési folyamatba.

Új alapok

A DevOps a problémák közvetlen megközelítésrõl és az eddigi határainkon átlépésrõl szól. Bizonyos módokon módszerekkel történõ szoftverfejlesztést tanultunk, és a DevOps ezt a hátteret töri meg. Mindenki, aki valaha tett írásbeli vizsgát tudja, hogy a szokásos gyakorlat az, hogy befejezed az írást és átadod a papírodat értékelésre. Ez a megközelítés lényegében olyan, mint a hagyományos vízesés módszer a QA csapat számára, azt leszámítva, hogy az értékeléseket nekik kell elvégezni és visszajuttatni a többi csoportnak, kijavítandó a hibákat.

Valószínûleg egy sokkal jobb gyakorlat lenne, hogy legyen melletted egy tanár, aki azonnal ki tudja javítani a hibáidat. Ez nem csak idõt takarít meg számodra, hanem kiemelkedõ eredményeket is hoz. Igen, ha iskolában lennénk, akkor valószínûleg csalásnak neveznénk ezt, de egy vállalkozás esetén ez az eljárás dicséretes és követendõ.

Folyamatos tesztelés

Egy belsõ QA csapat elõnye, hogy hamarabb kapod meg a véleményüket, mielõtt egy tévedés vagy hiba bekövetkezne. A QA csoport véleménye arról, hogy mely funkciók lesznek megvalósíthatók, milyen tesztelésre lenne szükség az egyes szolgáltatások esetében és milyen problémák merülhetnek fel, felbecsülhetetlen értékû. A QA csoport bevonása a kezdetektõl azt is jelenti, hogy kapsz tõlük a feladatokra vonatkozó becslést és a tesztelés automatizálásnak esélyét a szoftverszállítási folyamat különbözõ szakaszaiban.

Arról nem is beszélve, hogy ez a gyakorlat gyorsan megváltoztatja azt a népszerû véleményt, miszerint a QA mérnökök kívülállók, valamint a vállalat alapértékeit is kiegészíti. A minõség tudatosságnak a szervezeten belül, a levegõvételhez hasonló, természetes folyamattá kell válnia. Ha a DevOps folyamatos fejlesztést jelent, akkor folyamatos tesztelést is. A teszt-vezértelt fejlesztési megközelítésnek azt kellene jelentenie, hogy a fejlesztõk a saját fejlesztéseiket tesztelik, hibákat keresnek és addig mennek tovább amíg azokat ki nem javították.

DevOps, QA és mobil alkalmazások

Különösen a mobilalkalmazások tekintetében, a cégek nagy része a DevOps folyamatok felé lép. A QA csoportok különleges helyzetben vannak, ahol eredeti pozíciójukból, a Dev és az Ops közötti területrõl, egy „mindent körbeölelõ” entitás felé építkeznek. A QA sikeréhez a DevOps-ban, a reaktív, kész terméken minõségi ellenõrzést végzõ világból tudni kell váltani, proaktív, a fejlesztõkkel együttmûködõ, õket minõségi termék elõállításában segítõ új világba.

A nap végén arra kell koncentrálnod, amiben jó vagy. Amíg a fejlesztõk abban jók, hogy kódot írjanak, nem olyan módon tekintenek a dolgokra, mint egy QA szakember. A QA szakember mindig is a gyártási rendszer szerves része kell, hogy legyen, inkább tanári, mint ellenõri szerepben.

Automatizált tesztelés

Eltekintve attól, hogy minden abba az irányba fejlõdik, hogy a minõség mindenki érdeke legyen, a QA csapatok a jövõben fejlett automatizáló képességekkel fognak rendelkezni. A teszt automatizálás a QA jövõje a Devops szerint mûködõ vállalatokban. A mobilalkalmazásokra nézve ez egy újabb szint a tesztelésben, egész konkrétan nagyjából három szintrõl beszélünk. A mobil alkalmazások elõször az emulátorok automatizált tesztelésén mennek keresztül, majd valós eszközökön végeznek automatizált tesztelést a felhõben és végül cégen belül funkcionális/UI tesztek következnek valós eszközökön.

Az egyik legnépszerûbb nyílt forráskódú automatizált tesztelõcsomag a Selenium nevéhez fûzõdik. Valójában annyira népszerû, hogy az ilyen eszközökön végzett tesztelést gyakran „Selenium tesztelésnek” nevezik. Ez a tesztrendszer egyszerre több eszközzel vagy emulátorral mûködik és támogatja a „hot-swapokat”.

Számos érdekes tesztelési termék létezik, mint például a Sauce Labs , amely széleskörû tesztelést segítõ eszközöket tartalmaz Seleniumra és annak mobilos változatára, az Appiumra. A Sauce valódi eszközhasználatot biztosít a felhõben, tehát nem kell saját labort létrehoznod a cégen belül.

Egy másik egyszerû, mégis érdekes alternatíva a TestingWhiz’s Enterprise Edition, amely több mint 290 beépített tesztelési paranccsal rendelkezik, lehetõvé téve a tesztek rögzítését és lejátszását, programkód használata nélkül.

A HPE Unified Functional Testing , ismertebb, régebbi nevén HP Quick test, szintén a népszerûbb automatizált teszteszközök közé tartozik. Funkciói közé tartozik a Mercury Business Process Trainingel való integráció, fejlett hibakezelési mechanizmusok és automatizált dokumentum készítés.

A QA jövõje

Jó lenne, ha a minõség mindenki munkájának része lenne és nem lenne szükség további QA csapatokra az ellenõrzéshez és a tesztekhez. A jövõt nem lehet elképzelni minõség elemzõk nélkül. Sokkal inkább a szerepek dinamikus elmozdulását fogjuk látni és a QA csapatok mélyebb beépülését a rendszerbe és valószínûleg egy új fajta QA-t, ami a teljesen automatizált tesztelésre összepontosít.

Forrás: Apps And Devops: Where Does Qa Fit In?
Szerző: Twain Taylor