Bevezetés
Frissítve: 2022. november 04-én, kiegészítve a Rossz gyakorlat: Egy projekten már teszteltünk, nem vált be,
a Rossz gyakorlat: nem megfelelő üzleti fogalmakat használok, a Rossz gyakorlat: nem megfelelő branch-en történik a tesztelés, és a Rossz gyakorlat: nem bontom részproblémákra a problémát fejezetekkel
Frissítve: 2022. augusztus 21-én, kiegészítve a Naplózás fontossága résszel, valamint a cache-re vonatkozó ajánlásokkal
Ahhoz, hogy sikeres szoftvert tudjunk szállítani, hiszem, hogy nagyon fontos a fejlesztők és
a tesztelők közötti szoros együttműködés. És mikor tesztelőket említek, ugyanúgy gondolok
a manuális és automata tesztelőkre is. Az irányzat, mely a fejlesztők és az üzemeltetők
közötti kapcsolat fontosságát hangsúlyozza, a DevOps nevet kapta. Célja egy olyan kultúra
kialakítása, gyakorlatok és eszközök kiválasztása, ahol a fejlesztők és az üzemeltetők
közös munkával tudnak gyorsan, megbízhatóan alkalmazásokat és megoldásokat szállítani.
Ez a fogalom manapság igencsak felkapott, de méltatlannak érzem, hogy a tesztelőkkel
való közös munka fontosságának kiemelése korántsem ennyire hangsúlyos.
Történetileg kialakult, hogy a fejlesztés és az üzemeltetés a legtöbb cégnél elvált
egymástól, tisztán elválasztott szervezeti egységekben, sőt akár külön cégekben működtek,
melyek között a kommunikáció finoman szólva is döcögős volt. Sőt, úgy érződött, hogy a két csoportnak
eltérő a célja. Az üzemeltetők stabilitást, biztonságot, tervezhetőséget szerettek volna,
míg a fejlesztők mindig az örökös változásért, fejlődésért harcoltak. Észrevehetjük,
ugyanez megfigyelhető a tesztelőknél is, egyrészt a különválás, a nehézkes kommunikáció,
és a látszólag ellentétes cél. Van, hogy a fejlesztők által késznek minősített alkalmazást
a tesztelők “visszadobnak”. Kezdjük felismerni, hogy az üzemeltetés és a fejlesztés
szétválasztása káros, de vajon így érezzük a tesztelők munkájával kapcsolatban is?
Ráadásul az egyes agilis módszertanok, mint pl. a Scrum szerint a csapat felelős
a sprint végén a kész termék leszállításáért, és ebben olyan egyenrangú csapattagok vesznek részt,
akik persze rendelkeznek speciális ismeretekkel, pl. üzleti elemzés, fejlesztés, tesztelés vagy
üzemeltetés.
Voltam olyan helyen, ahol a fentebb bemutatott elszigeteltség jelen volt, és mindig dolgoztam ennek
csökkentésén. Voltan olyan projekten is, ahol ezen különböző ismeretekkel rendelkező
szakemberek egy csapatban dolgoztak. Régóta tartok fejlesztői tanfolyamokat, köztük
kezdő fejlesztői tanfolyamokat, amin egyre több tesztelővel találkozok, aki el akar mozdulni
az automata tesztelés irányába. Sőt részt vettem tesztelői bootcampek megszervezésében is, ahol nagyon sokat
tanultam a tesztelő kollégáimtól, és beleláthattam ennek a szakmának a szépségeibe is, és erősítették bennem a hitet,
hogy mennyire fontos az együttműködés. Sőt, automata teszt eszközökkel kapcsolatos képzéseket is tartok, amin szintén sok tesztelő vesz részt.
Ezen tapasztalataim alapján, és a tesztelők (akár szünetekben elmesélt) történeteit meghallgatva gyakran úgy látom,
hogy a fejlesztőknek a teszteléssel kapcsolatban rengeteg tévhit él a fejében, és rengeteg rossz gyakorlatot folytatnak. Ebben a posztban ezeket próbálom felsorolni, megcáfolni. Lesz szó általános elvekről, de pár helyen lemegyek technológiai szintre is. Egyes szám első személyben fogok írni, fejlesztő lévén, még akkor is,
ha magam nem így gondolkozom, így megpróbálok senkit sem megsérteni. Félreértés ne essék, nem ellentéteket szeretnék szítani, hanem megoldásokat kínálni.