Menü Bezárás

A tesztelhetőség közös felelősség

„A szoftver nehezen tesztelhető. Nehéz kontrol alatt tartani. Nehéz a rendszer által küldött információkat értelmezni. A komponenseknek között kölcsönhatások vannak, melyeket nem lehet elkülöníteni egymástól. Korlátozott az információáramlás a közreműködők között.”

Amikor egy új céggel konzultálok, alapból három dolgot feltételezek. Túl sok munka van, amit egyidőben kell elvégezni. Nincs elég időt a technikai hátrányok kiküszöbölésére. És végül, a rendszerük nagyon, nagyon nehezen tesztelhető. Bizonyítsd be, hogy nincs igazam!

Egy nagy médiavállalatnál dolgoztam, ahol pontosan ilyen problémák voltak. Bonyolult volt a rendszerük, problémás összefüggésekkel, 10 évvel is meghaladva a tervezett élettartamot. Sok programnyelv alkalmazásával készült, nehéz a telepíthetősége, átláthatatlan bevezetési kérdések, problémák. Megvan a kép, ugye?

Amikor a tesztelhetőség problémája éles helyzetben merül fel, sokan kérdezik a tesztelőktől: „Miért tart ilyen sokáig a tesztelés?” „Mikor lesz letesztelve?” Amikor a fejlesztéssel és teszteléssel kapcsolatos feladatok az én felelősségemhez tartoztak és megkaptam ezeket a kérdéseket az alábbi választ adtam „Mi, mint egy szoftverfejlesztő csapat nem vállalhatunk kollektív felelősséget a tesztelhetőségért.”

Ebben a cikkben ezt a témát fogom körül járni. Ez segítséget jelent majd a csapatoknak, hogy minél jobban tudjanak összpontosítani a tesztelhetőségre, illetve elősegíti az ebben a témában érdekelt felekkel megértetni, hogy mennyire fontos ez.

A tesztelhetőség segít abban, hogy a minőségileg legmegfelelőbb termék készüljön, olyan, ami a résztvevő feleknek leginkább megfelel. Ez versenyelőny.

Minden szereplőre szükség van, aki a tesztelhetőség kialakításában részt tud venni. Ebbe a folyamatba be kell vonni más területek képviselőit is, beleértve a fejlesztőket, a műveleti területért és a tervezésért felelős embereket is.

Bár nem a tesztelők a tesztelhetőség kizárólagos katonái, nekünk ott kell kezdeni, ahol éppen vagyunk. Mi vagyunk azok, akiknek el kell kezdeni.

A tesztelhetőség versenyelőnyt jelent

Lássunk munkához! A cégeknél valószínűleg sok „minőségjavító” kezdeményezés van folyamatban. Miért fontosabb a többinél a tesztelhetőség? Hiszem, hogy a tesztelhetőség valódi versenyelőnyt biztosít.

A különböző munkaszakaszok közötti (programozás, tesztelés, telepítés) időbeli késések miatt a szoftverfejlesztés nagyon költséges dolog. „Dwell time” – egy helyen való tartózkodási idő. Az értékek várják a sorukat. Amikor a viszonyítási alap az erőfeszítés, akkor a valódi költség a „Dwell time”-ban, azaz az egy helyen tartózkodási időben rejlik.

A tesztelhetőség javítása kétféle módon segít:

  • A jobb tesztelhetőség összetartóbb csapatokat eredményez. Ha a csapatok együttműködésre képesek, egy egységként tudnak együtt dolgozni, akkor csökken a dwell time, különösen igaz ez a kicsi, de értékes dolgok elkészítésekor. A tesztelhetőség javítása segíti a csapatok együttműködését, amivel hamarabb elkezdődhet a tesztelés. Gyakran találkozom olyan tesztelőkkel, akik sokáig csak várakoznak, majd hirtelen rohamtempóban kénytelenek tesztelni. Általában azt szokták mondani, hogy a tesztelés a szűk keresztmetszet. Ez a megfogalmazás többek között azt is mutatja, hogy nem túl nagy a csapatok közötti összetartás és ez végső soron a rossz tesztelhetőségre vezethető vissza.
  • A jobb tesztelhetőség kevesebb technikai problémát is jelent. Ez abban az esetben igaz, ha rendelkezésre áll egy világos, jól érthető tesztstratégia. Megbízható tesztek segítségével változtatni lehet a rendszeren azáltal, hogy ezeket a teszteket biztonságosan és gyorsan végre lehet hajtani. Például sokan küzdenek szoftverfüggőséggel, amit csökkenteni szeretnének, vagy frissítenék központi tárolóhelyeiket, de nem tudják ennek milyen hatása lesz. Ennek azonban nem feltétlenül kell ilyennek lennie.

Vezesd a csapatodat!

Ahol beszélek, vagy írok a tesztelhetőségről, főképpen arra gondolok, hogyan lehet „eladni” ezt egy csapatnak vagy egy még szélesebb körnek pl. egy szervezetnek. A válasz erre mindig az: “ez attól függ.” Attól függ, hogy milyen típusú az ügyfél. Legtöbbjüknek a saját környezetében kell látnia a tesztelhetőség előnyeit, mielőtt megvásárolná. Előfordulhat az is, hogy az ügyfél egyáltalán nem akar beszélni a tesztelhetőségről.

Ha te olyan ember vagy, aki szívesen szervez ilyen típusú megbeszéléseket, akkor próbáld ki a következő két lehetőség egyikét:

Mutasd be a csapatnak a tesztelhetőséget teszteken keresztül!

https://github.com/ConfluxDigital/testability-questions

Ennek az előnye az, hogy nem említi a tesztelhetőséget, mint fogalmat. Kevésbé valószínű, hogy elfogultságot vált ki a hallgatókból. Azoknak szól, akik azt gondolják, hogy teljes körűen és mindig csak a tesztelők felelősek a tesztelhetőségért.

Egy közös „Run book” kialakítása

https://github.com/SkeltonThatcher/run-book-template

Itt azért van egy kis titok. Ugyanis minél működőképesebb a rendszer, annál inkább tesztelhető. Gondolok itt olyan tulajdonságokra mint pl. könnyen telepíthető (tesztelhető a kívánt felépítésben), érthetőbb (modellezett a működése, üzleti szereplők bevonása is megtörtént), rugalmasabb (bármikor tesztelhető) és még sok más.

Szerezz be kávét és finom nassolni valókat. Foglalj egy tárgyalót, és mutasd be a csapatodnak a Run book sablonok világát. Ne aggódj, ha nem minden rovatot tudtok kitölteni, itt a hangsúly a közös megbeszélésen van. Mindenki nyer, ha működőképesebb lesz a rendszer. Miért ne nyerhetnének a tesztelők is?

Ha kevésbé társasági megoldásra vágysz, mint egy megbeszélés megszervezése, akkor keress egy támogató személyt, aki segítségedre lehet. A legtöbb tesztelőnek van egy-két olyan munkatársa a csapatból, akivel gyakrabban és szívesebben dolgozik együtt, mint a többiekkel. Őket próbáld megnyerni először.

Íme néhány stratégia:

  • Fejlesztési terület: A fejlesztők gyors visszajelzést akarnak, majd mennek is tovább a következő feladathoz. Nekik gyakran úgy adom el tesztelhetőséget, hogy a kevesebb kontextusváltást hangsúlyozom ki. Beszélek nekik egy olyan világról, ahol a tesztelés az összes szinten helyben futtatható, ahelyett, hogy meg kellene várni a fejlesztés befejezését. Olyan világot vázolok fel, ahol pl. felfedező tesztelést lehet végezni a kódjukon, mialatt az még fejlesztés alatt van. Azonos ütemben haladhat a fejlesztés a teszteléssel.
  • Műveleti terület: Az adatbázis-rendszergazdák és az alkalmazás-támogatók gyakran kínlódnak. Kiváló szövetségesek lehetnek, akik a tesztelhetőségre összpontosítanak. A nagyobb rugalmasság, naplózás, megfigyelési lehetőségek, a jobb konfiguráció és a magasabb biztonság kevesebb munkát jelent számukra.
  • Tervezés és elemzés területe: Tesztelhetőség szempontjából gyakori szövetségesek a tervezők, a felhasználói tapasztalattal rendelkező szakemberek és az elemzők is. Ők általában közvetlenül nem képesek javítani egy rendszer tesztelhetőségén, ám a tesztelhetőség ennél is messzebbre mutat. Az ügyfelekkel való kapcsolatokról is szól. Tesztelni kell az ötleteket és feltételezéseket, meg kell fogalmazni, hogy mire is van szükség. Ez kevésbé jelent konkrét építő munkát, de ez is a jó cél irányába halad. Tesztelőként is ugyanerre kell törekednünk: a legfontosabb dolgokat le kell tesztelni, de a cél az, hogy ez minél kevesebb teszteléssel történjen.

A tesztelőknek kell megtenni az első lépéseket

A cél az együttműködés kialakítása, de ez a folyamat csak onnan indulhat, ahol éppen vagyunk. Az általános vélekedés szerint a tesztelők felelősek a tesztelhetőségért. Meg kell változtatni ezt a nézetet, mindenkinek vállalnia kell a felelősséget a tesztelhetőségért.

Íme három gyors módszer, amivel elindíthatod ezt a szemléletváltó folyamatot:

  • Mutasd meg a korábban megtalált támogatóidnak, hogyan és mit tesztelsz. Lehet, hogy ezen a ponton egy kicsit sebezhetővé is válsz. Amikor egy rendszer tesztelése hosszú időn keresztül tart, tudat alatt mindenki megpróbálja elkerülni a nehezen tesztelhető részeket. Meglepetés lehet a tesztelés módja és tartalma is a támogatód számára. A nehézségek bemutatása gyakran elemi változásokhoz vezet, amelyek sokkal jobbá teszik a tesztelési folyamatot.
  • Beszélj arról, ami a hallgatóságodnak fontos. Ha a közönségedet a működőképesség érdekli, akkor beszélj arról. Végül is, ha nem lehet biztonságosan telepíteni egy rendszert, akkor használ valamit is egy briliáns tesztelés? Vagy lehet valami más is egy cégen belül. Ha pl. elosztott mikro rendszereket kell tesztelni, akkor a megfigyelhetőségen van a hangsúly. Keresd a kulcsot, próbáld különböző nézőpontokból megvizsgálni a témát!
  •  Az elmúlt tíz évben a helyi fejlesztési környezetben teszteltem. Ugyanúgy, mint a fejlesztők, egy csapatban, együttműködve. Nem tudom ezt elégszer hangsúlyozni. Még mindig vannak fenntartások a közös környezettel kapcsolatban, de próbáld meg csökkenteni az ezek iránti bizalmatlanságodat. Ez segítség azoknak, akik fenntartják. A tesztkörnyezettel kapcsolatos minden panasz általában csak többletmunkát okoz valaki másnak. Ez nem segít.

Itt van három kulcsfontosságú útravaló:

  •  A tesztelhetőség valódi versenyelőnyt jelent. A csapataid együttműködésével és kiváló technikai megoldásokra összpontosítva a tesztelhetőség segít csökkenteni a felhalmozódott tartózkodási időt (dwell time).
  • Találd meg azt a módszert, amellyel megmutathatod a tesztelhetőségből fakadó előnyöket. Szerencsére a tesztelhetőség javulhat más módon is, például a működőképesség növelésével. A „tesztelhetőségi tűt” csoportos gyakorlatokkal vagy akár egyéni interakciókkal is mozgathatod.
  •  Csak ott kezdheted el, ahol vagy. Gyakran nekünk, a tesztelőknek kell megtenni az első lépéseket, amelyek beindítják a tesztelhetőség növelésére irányuló változásokat.

Forráshoz katt ide <-

A szerző

Ash Winter
Független tesztelő és konferencia-előadó vagyok. A tanácsadói éveim alatt nagy tapasztalatot szereztem és széles ismereteket kaptam a szoftverfejlesztés területén.
Van tesztelési tapasztalatom, teljesítménymérési és automatizálás tapasztalatom mind a fejlesztés, mind a tesztelés területén.
Még egy ideig Scrum mester és Product Owner is voltam. Ez felkészített a startup világba való belépésre, amelyről mesélhetnék egy két történetet.
Miután megvizsgáltam ezeket a lehetőségeket, úgy döntöttem a tesztelésre összpontosítok és a saját magam ura leszek.
Előadásokat, tréningeket tartok, írok, ügyfelek felkérésére tesztelek, és ha valami bonyolult és nehéz problémával keresnek meg, akkor a coach szerepét is vállalom.
Vissza