A tesztelés és az üzemeltetés kapcsolata

A tesztelés és üzemeltetés együttműködéséről bizonyára mindenki hallott már. Tudjuk, hogy mennyire fontos lenne, ha a két szervezet együttes erővel dolgozhatna egy projekten. Mivel általában nem ez a helyzet, ezért kivételes, ha példákat találunk a közös munkára.

A legutóbbi cikkemben, melyet a tesztrendszerekről írtam, már megemlítettem, hogy mennyire fontos a megfelelő tesztelési környezet megválasztása ahhoz, hogy jó, pontos és minőségi tesztelést lehessen végezni. A fent említett tesztrendszer karbantartása és működtetése azonban nem a tesztelési csoport, hanem az üzemeltetési csapat felelőssége. 

Ahhoz, hogy az üzemeltetők a munkájukat megfelelő minőségben tudják végezni, szükséges, hogy tudják, hogy egy megbízható, ellenőrzött alkalmazást kell üzemeltetniük. Ennek a feltételnek az ellenőrzése azonban már a tesztelési csapat felelőssége. Íme a kapocs, mely összeköti őket. Van azonban más is, amellyel a két csapat által nyújtott munka minőségi színvonala emelhető. A következőkben erről írok. 

A tesztrendszerekről szóló cikkem idején még csak egy tesztelési csapatot vezettem, de már akkor éreztem, hogy mennyire megkönnyítené a munkát az, ha az üzemeltetés és a tesztelés egy kézben lenne, elősegítve ezáltal azt, hogy a két csoport hatványozottan magasabb effektivitással járuljon hozzá a vállalat működési hatékonyságához, céljaihoz és ezáltal a vevői elégedettséghez. A legutóbbi publikációm idején még nem is gondoltam, hogy az élet majd úgy hozza, hogy lehetőséget kapok arra, hogy a fentiekben leírtakat ténylegesen kipróbálhassam, hogy a tesztelési és az üzemeltetési csapatot is én vezethessem egy időben.  

A tesztelés és az üzemeltetés kapcsolata ritkán van fókuszban, pedig ennek nem így kellene lennie. Véleményem szerint a szinergia a két terület között nélkülözhetetlen a mai világban sikeresen működni kívánó vállalatok életében. Fontosnak éreztem tehát, hogy saját tapasztalataimat kiemeljem és leírjam, ezért született meg ez a cikk.

Javaslom, vegyük át először azt, hogy melyek azok az alapvető feladatok, melyeket a tesztcsapat végez el, illetve melyek azok a feladatok, amelyek az üzemeltetési csoporthoz tartoznak:

A tesztcsapat feladatai:

• Dokumentációs ellenőrzés
• Tesztesetírás és -futtatás
• Regressziós készlet létrehozása
• Funkcionális, aktivációs, teljesítménytesztelés, stb.
• Futási eredmények kiértékelése
• Tesztriportok készítése
• Élesítés jóváhagyása vagy megállítása

Üzemeltetési csapat – IT Ops:

• Az infrastruktúra problémamentes működtetése
• A rendszerek frissen tartása
• Az IT Biztonság fenntartása és kialakítása
• Élesítés
• A rendszerek monitorozása és optimalizálása
• A rendszerek bővítése
• A céges (belsős) felhasználók kiszolgálása

Most vizsgáljuk meg azt, hogy hol lehetnek és vannak is közös kapcsolatok a két csapat között:

• Élesítés
• A rendszerek optimalizálása
• A rendszerek bővítése – mely bővítés lehet software-es és hardware-es is
• A rendszerek frissen tartása

Vegyük sorba, hogy milyen előnyei lehetnek annak, ha a tesztelésnek lehetősége van az üzemeltetési csapat által karbantartott és fejleszteni kívánt rendszert is tesztelni, és nem csak a fejlesztés által élesíteni kívánt új alkalmazásverziót:

• A rendszer tesztelése során hamar – akár a tervezési fázisban kijöhetnek olyan hibák, melyeket ilyenkor a legkönnyebb javítani.
• A rendszerek frissen tartása során a tesztcsapat folyamatosan teszteli az újonnan telepíteni kívánt software-frissítéseket.
• Architektúraváltozás során a tesztelési csapat teljes körű regressziós tesztelést végez annak érdekében, hogy az éles üzembe helyezés során minden problémamentes legyen. Az ellenőrzés nem az amúgy is általában leterhelt üzemeltetési csapat idejéből megy el.
• Élesítés során az éles rendszeren a tesztcsapat gyorsan, – de természetesen a mennyiségtől és az érintett rendszerek komplexitásától függően – képes az üzemeltetési csapat felügyeletével megvizsgálni, hogy a felhasználók mit látnak, minden megfelelően működik-e. Más szóval képes élesítés során aktivációs tesztet futtatni, mégpedig úgy, hogy mindezt az üzemeltetési csapat felügyeletével teszi.
• A fejlesztői és a tesztelői rendszer karbantartása gyorsabban és pontosabban hajtódik végre, hiszen azok ellenőrzését már nem az üzemeltetési csapat, hanem a tesztelés végzi.

A korábbiakban általánosan leírt száraz tények és jellemzők felsorolása után szeretnék megemlíteni néhány olyan példát, amikor a tesztelés és az üzemeltetés közös erőfeszítésének hála komolyabb nehézségek nélkül sikerült a problémákat úgy áthidalni, hogy a felhasználók azon kívül semmit sem vettek észre, hogy több funkciót stabilabban és gyorsabban tudnak elérni.

A következő példák egy vezető, internetes portált fejlesztő és üzemeltető cég életéből valóak, melyekkel akkor találkoztam, amikor ezen cég üzemeltetési és tesztelési csapata is az én vezetésem alatt állt. Az alábbi két példa bemutatásakor először leírom, hogy milyen feladatot is kellett megoldania a munkatársaimnak, majd részletezem, hogy azt hogyan sikerült megoldani akkor, amikor még az üzemeltetés nem működött szorosan együtt a teszteléssel /OPS (operations) megoldás/, illetve akkor, amikor a két csoport kart karba öltve dolgozott /TOPS (testing&operations) megoldás/.

Jira-frissítés és upgrade

A feladat a következő volt: a Jira és a telepített pluginek frissítése úgy, hogy a frissítés után a rendszer a  meglévő beállításokkal és felvitt ticketekkel működjön problémamentesen. A régi verzió nem támogatta az akkori verziókban már működő upgrade funkciót. A régi, rosszul felépített operációs rendszeren futó alkalmazás frissítése, valamint az operációs rendszer cseréje is elengedhetetlen feltétel lett. Az új rendszernek pedig az új virtualizált környezetben kellett működnie.

OPS megoldás

Lássuk, hogy is történt egy Jira-frissítés, amikor a két csapat irányítása még két külön kézben volt.

A Jira-frissítésekben ekkor a tesztcsapat, mint aktív szereplő nem vett részt. Az üzemeltetési csapatnak a felhasználók jelezték, hogy szükséges lenne egy frissítés. Az üzemeltetői csapat hozzá is látott a feladatnak, mégpedig az alábbi módon: a csoport minden frissítést mellőzve klónozta a már működő Jirát futtató gépet.

Ezek után törölte a klónozott gépen futó Jirát az adatbázis változatlanul hagyása mellett, majd a Jirához telepített plugineket is átmásolta az új rendszerbe. Ezek után feltelepítette az új Jirát, bemásolta a régi pluginokat, és kicserélte az éles rendszert ezzel a klónozott géppel.

Tesztelésre nem került sor. Természetesen nem lett ellenőrizve, hogy a pluginok jól működnek-e vagy sem, valamint az sem, hogy az adatbázis konzisztens maradt-e. Kiderült, hogy a pluginok nem voltak kompatibilisek az új Jira-verzióval, és közülük néhányat nem is lehetett automatikusan frissíteni.

Rengeteg időt elvett mindezek után az, hogy egyeztetni kellett, hogy melyik verziót kellene használni, hiszen az akkori üzemeltetés nem vizsgálta meg a rendszert időhiány miatt. A rendszer gyakran kifagyott, illetve gyakori adatbázisproblémára utaló hibák jöttek elő, és ezeket nem is lehetett javítani, mert az üzemeltetés nem tudta, hogy mi okozhatta a problémát. Egyszerűen a Jira lett kinevezve bűnbaknak. A felhasználók nem voltak megelégedve az eredménnyel, és a régi verziót szerették volna visszakapni, hiszen még az is stabilabban működött, mint az új.

TOPS megoldás

A két csapat közösen állt neki a feladatnak. Az üzemeltetési csapat egy teljesen új, alap operációs rendszert is szeretett volna használni a régi helyett. Ebben az esetben az Ubuntu 10.04 LTS-t szerette volna alkalmazni a régi Ubuntu 9.10-es helyett. Az üzemeltetés első feladatként elkészített egy új virtuális gépet, melyre feltelepítették az alap operációs rendszert, majd egy teljesen új Percona MySQL-t, melybe a Jira adatbázisa került. Ezek után feltelepítették az új verziós Jirát, és a beállításokat a backup file-ból visszatöltötték. A tesztelés ekkor lépett be a folyamatba. Elkezdte vizsgálni, hogy a visszatöltés után a beállítások megmaradtak-e, a meglévő (régi rendszerben) ticketek átkerültek-e ugyanazzal az azonosítóval, a pluginok működtek-e és frissítve lettek-e, a licencek működőképesen átkerültek-e.

Ezen ellenőrzés során a tesztcsapat észrevette, hogy a tickethez tartozó csatolmányok nem kerültek át, ezt jelezte az üzemeltetésen dolgozó kollégáknak, akik azonnal átmásolták a csatolmányokat a megfelelő mappastruktúrába. A tesztcsapat azt is észrevette, hogy az új rendszerben néhány esetben probléma van a ticketek elérésével, és hibát kaptak. Az üzemeltetési csapattal közösen elkezdtek vizsgálódni, hogy mi lehetett a probléma. Kiderült, hogy a java futtatási környezetet le kellett cserélni a legfrissebb Oracle Javára, hogy a problémák megszűnjenek.

A problémák gyors kijavítása után a tesztcsapat elkezdte átnézni a fontosabb funkciókat, majd a sikeres teszt után az üzemeltetési csapat az új, kitesztelt gépnek az IP-címét átállította a régi rendszerére, majd azt gyorsan le is kapcsolta.

Ezután egy gyors aktivációs tesztet hajtott végre a tesztelési csapat. A sikeres eredmény után pedig kommunikáltuk az összes Jira-használónak, hogy frissítést hajtottunk végre, mely megoldja a használat közben korábban felmerült problémákat. A felhasználók nem vettek észre semmit a változásból, és boldogak voltak, hogy minden tökéletesen hajtódott végre.

A két megoldás összehasonlításakor látszik, hogy a tesztelés és az üzemeltetés együttműködése gyorsabb és minőségibb megoldást eredményezett, ami pedig növelte a felhasználói elégedettséget is. Azt is meg kell jegyeznem, hogy az időhiány és az egyéb munkák sokasága miatt, valamint a tesztelői mentalitás hiánya miatt nem tudott az üzemeltetés tesztelni, ezért igen fontos, hogy a tesztelők is be legyenek vonva a folyamatba.

Operációs rendszer és webserver cseréje

A feladat a következő volt: Az éles rendszeren futó operációs rendszer cseréje és teljes újratervezése, valamint az alkalmazást futtató webserver lecserélése. Mindezt úgy kellett megtenni, hogy az ne befolyásolja az éles rendszer működését.

OPS megoldás

Az üzemeltetés szeretett volna egy Ubuntu 8.10-es verzióról Ubunt 9.10-re váltani. Nem mérték fel az igényeket, hanem egyből kivették az első szervert az éles rendszerből és elkezdték a frissítést. Ezután láttak neki a frissített rendszer teszteléséhez. Sajnos nem vették figyelembe, hogy az alkalmazást is tesztelni kellene, de igazából nem is lett volna idejük rá. Mindent maguknak kellett visszaellenőrizni, és mivel nem rendelkeztek tesztelői tudással, nem is tudták feltérképezni, hogy mi mindent kellett volna tesztelni.

Ezt a gondot úgy orvosolták, hogy nem frissítették a régi Apache – PHP – Xcache megoldást, hanem meghagyták a régebben forgatott verziókat. Ezzel csak annyi volt a probléma, hogy így semmilyen biztonsági javítást nem tettek fel, így hagyva biztonsági rést a rendszerben. Nem kértek segítséget a váltáshoz a teszteléstől, mivel azt gondolták, maguk is meg tudják oldani a problémát. A szerverek nem lettek optimalizálva, nem történt performanciamérés sem.

TOPS megoldás

A tesztelők és az üzemeltetők leültek, és elkezdték megvizsgálni, hogy mit érinthet a fenti változás. Az üzemeltetési csapat elmondta, hogy melyek azok a követelmények, amelyek ehhez a változáshoz vezettek.

Az üzemeltetők szerették volna az Ubuntu 9.10-es operációs rendszert egy 10.04 LTS verzióra lecserélni, valamint szerették volna a a partíciós elosztásokat is újra gondolni, hogy optimálisabbak legyenek a szerverek. Az akkor alkalmazott Apache – PHP – Xcache megoldást szerették volna lecserélni Ngninx – PHP-fpm – APC megoldásra.

Erre azért volt szükség, mivel a kód, melyet a rendszernek kellett futtatni, egyáltalán nem volt optimalizálva, mivel a fejlesztők egy része nem figyelt oda a sebességre. Az üzemeltetés azon a véleményen volt, hogy az általuk kiválasztott eszközzel jelentős sebességnövekedést érhetne el a rendszer. A PHP-verzión is történt változás. PHP 5.2-ről 5.3-ra váltás történt.

A tesztelési csapat az igények felmérése után elkezdte kidolgozni, hogy milyen és mekkora erőforrás szükséges ahhoz, hogy ezeket a változtatásokat problémamentesen ki lehessen élesíteni.

A tesztelők felállítottak egy listát arról, hogy miket kell végignézni. Mivel az applikáció, melyet ellenőrizni kellett nagyon nagy, így kockázatelemzéssel lett összeállítva egy tesztterv, illetve az ehhez tartozó tesztesetek. Az üzemeltetés első lépésként a staging környezetben állította át a rendszert, melyen ők végeztek teljesítményméréseket, amelyeket majd a tesztelőkkel közösen kiértékeltek. A finomhangolások után következett az applikáció ellenőrzése. Az összeállított tesztterv alapján elkezdődött az automatizált tesztelés. A felmerült hibákat a tesztelés jelezte az üzemeltetői csapatnak, akik javították a hibákat. Következő lépésként az éles rendszerből kivettek egy webszervert, melyen elkezdték az átalakítást. Az átalakítás után a tesztelők ismét lefuttatták az automatizált eseteket, majd az eredményt kiértékelték. Amint hibát találtak, jelezték az üzemeltetőknek, majd a tesztelés befejeztével megadták a GO-Live engedélyt.

Az üzemeltetés visszahelyezte a kivett szervert, és elkezdte a ráterhelést. A rendszer problémamentesen futott. Az ezt követő héten nem kezdtek el átállítani másik szervert, hogy amennyiben probléma merül fel, azt könnyen lehessen javítani, illetve megállapítani a hibát. Az egy hét türelmi periódus után következett a többi szerver, mely pontosan ugyanazzal a folyamattal lett átállítva, mint a legelső szerver.

Öszefoglalás

A két megoldást összehasonlítva láthatjuk, hogy a tesztelés rengeteg feladatot át tud venni az amúgy is igen sok munkával rendelkező üzemeltetőkről, hozzátéve azt a tesztelői tudást, mely segít megtalálni a hibákat, mielőtt azok komolyabb problémát okoznának az éles rendszeren.

A felsorolt előnyöket figyelembe véve felhívnám minden IT, üzemeltetési és tesztcsapat vezető figyelmét, hogy nagyon fontos, hogy a korábban említett csapatok olajozottan, effektíven tudjanak együtt dolgozni. Ehhez nagyon fontos, hogy jó kommunikációs csatorna legyen fenntartva a két csapat között; ez a vezetők felelőssége.

Amennyiben ezt nem teszik meg, úgy sokkal lassabban fog a rendszer stabilan és naprakészen működni. Szeretném azt is leszögezni, hogy csak látszólag különbözik egymástól a két csapat. A feladatuk azonban nagyon is hasonló, a céljuk megegyezik. Mindkét csapatnak feladata, hogy védjék és stabilizálják a már éles rendszeren működő kódot vagy rendszert. Ennek a célnak az elérése érdekében véleményem szerint elengedhetetlen, hogy a két csapat egymással szorosan összedolgozva, egyeztetve működjön.

A cikk végén szeretnék köszönetet mondani feleségemnek, aki kitartóan javította és lektorálta cikkemet. Nélküle ez a cikk nem jöhetett volna létre. Köszönöm!

Szerző: Szenfner János