A flaky teszt egy olyan automatizált teszt, amely néha sikeresen fut le, néha pedig meghiúsul a kód lényeges módosítása nélkül. Első pillantásra technikai kellemetlenségnek tűnhet: sikertelen build, újrafuttatás, késedelem a CI/CD-ben – azonban a bizonytalan tesztek üzleti kockázatot jelentenek. Lassítják a kiadásokat, pazarolják a mérnöki időt, csökkentik az automatizált tesztelésbe vetett bizalmat, elrejtik a valódi hibákat, és gyengítik az üzletileg kritikus szoftverekbe vetett bizalmat. A banki, telekommunikációs, repülőipari és más szabályozott vagy nagy megbízhatóságú környezetben működő szervezetek számára a tesztek bizonytalansága nem csupán minőségbiztosítási probléma, hanem működési kockázat is, amelyet tudatosan kell kezelni.
A flaky teszt inkonzisztens eredményeket produkál azonos vagy egyenértékű feltételek mellett. A Google a flaky teszteredményt úgy definiálja, mint olyan eredményt, ahol ugyanaz a kód sikeres és sikertelen eredményeket is produkál. Más szóval, a hiba nem kapcsolódik megbízhatóan egy valódi termékhibához vagy egy adott kódváltozáshoz. A Google olyan gyakori okokat is azonosított, mint a párhuzamossági problémák, a nemdeterminisztikus viselkedés, a meghatározatlan viselkedés, a harmadik féltől származó kód instabilitása és az infrastrukturális problémák.
A flaky tesztek az automatizált tesztelés bármely szintjén megjelenhetnek, de különösen gyakoriak összetett integrációs, végponttól végpontig terjedő, felhasználói felület, mobil és teljesítményhez kapcsolódó környezetekben. Ezek a tesztek gyakran az időzítéstől, a hálózati feltételektől, a tesztadatoktól, az aszinkron folyamatoktól, a külső szolgáltatásoktól, a böngésző viselkedésétől, az eszközöktől vagy a megosztott infrastruktúrától függenek. Minél több mozgó alkatrésztől függ egy teszt, annál nagyobb az esélye annak, hogy az eredmény instabillá válik.
A Slack a flaky teszteket két nagy típusba sorolja: független flaky tesztek és rendszerszintű problémák által okozott flaky tesztek. A független flaky tesztek akkor is meghiúsulhatnak, ha elszigetelten futtatják őket. A rendszerszintű flaky tesztek a megosztott állapot, a CI-környezet különbségei vagy a tágabb tesztkészlettel való interakciók miatt buknak meg. A Slack megjegyzi, hogy a rendszerszintű egyenetlenséget nehezebb észlelni és a hibákat megkeresni, mert a viselkedés a tesztkörnyezet vagy a tesztkészlet változásával változik.
Ez a különbségtétel fontos. Egy flaky teszt nem mindig „rossz teszt”. Néha valódi architektúrai gyengeséget tár fel: versenyfeltételeket, rejtett függőségeket, gyenge izolációt, rossz tesztadat-kezelést, instabil infrastruktúrát vagy elégtelen megfigyelhetőséget. A egyenetlen tesztek csak zajként való kezelése azt okozhatja, hogy a csapatok olyan jeleket nem vesznek észre, amelyek mélyebb megbízhatósági problémákra utalnak.
Egy flaky teszt közvetlen költségét könnyű alábecsülni. Egy sikertelen build apróságnak tűnhet. Egy újrafuttatás nem tűnhet drágának. Egyetlen vizsgálat csak néhány percet vehet igénybe. De nagy mérnöki szervezetekben ez a költség gyorsan összeadódik.
A Google arról számolt be, hogy a tesztkorpuszában az összes tesztfuttatás körülbelül 1,5%-a egyenetlen eredményeket hozott, és a tesztek közel 16%-ában volt valamilyen mértékű egyenetlenség. A Google azt is megfigyelte, hogy a beküldés utáni tesztelés során a sikeres tesztek körülbelül 84%-a flaky teszteket tartalmazott, ami ismétlődő munkát eredményezett annak meghatározása érdekében, hogy a hiba valódi vagy egyenetlen volt-e.
A Slack tapasztalatai ugyanezt a problémát egy másik oldalról mutatják. Mobil kódbázisaikban több mint 120 fejlesztő hetente több mint 550 pull requestet készített, míg a tesztcsomag több mint 16 000 Android automatizált tesztet és több mint 11 000 iOS automatizált tesztet tartalmazott. A Slack megállapította, hogy minden egyenetlen teszthiba manuális triázsa körülbelül 28 percet vett igénybe. Ez a triázsi idő indokolta a külön automatizálási erőfeszítést a egyenetlen tesztek észlelésére és elnyomására.
Az Atlassian is számszerűsítette a hatást. A Jira Frontendben a tesztek egyenetlensége a múltban a master build hibák akár 21%-ához is hozzájárult. A Jira backend adattáraiban a hibák körülbelül 15%-át egyenetlen teszteknek tulajdonították, ami újrafuttatásokhoz és évente több mint 150 000 órányi fejlesztői idő pazarlásához vezetett.
A költség nem csak a fejlesztői időt jelenti. A bizonytalan tesztek felemésztik a CI-erőforrásokat, késleltetik a pull requesteket, blokkolják a kiadásokat, megszakítják a tervezett munkát, növelik a felhő- vagy eszközfarm-végrehajtási költségeket, és frusztrációt keltenek a mérnökcsapatokban. Az Atlassian arról számolt be, hogy a Flakinator rendszere több mint 22 000 buildet állított vissza és 7000 egyedi bizonytalan tesztet azonosított, javítva a buildek megbízhatóságát és csökkentve a CI-erőforrások felhasználását.
A bizonytalan teszt károsítja a tesztautomatizálás legfontosabb eszközét: a bizalmat.
Az automatizált tesztelés csak akkor teremt üzleti értéket, ha a csapatok hisznek az eredményekben. Ha egy rossz build általában azt jelenti, hogy „újra kell futtatni”, akkor a bizalom már meggyengült. Ha a fejlesztők azt feltételezik, hogy a hibák zajok, akkor a valódi hibák átcsúszhatnak. Ha a vezetőség ismétlődő késéseket lát egyértelmű ok nélkül, a szállítási folyamatba vetett bizalom csökken.
A Google arra figyelmeztet, hogy a jogos hibákat gyakran figyelmen kívül hagyják, amikor a bizonytalan tesztekben megjelennek, mert az emberek megszokják a téves pozitívakat. Ez késleltetheti a valódi problémák felfedezését, és növelheti a hibákhoz hozzájáruló változtatások számát. A beküldés előtti tesztelés során a jogos hibák figyelmen kívül hagyása hibás kód beküldéséhez vezethet.
A Slack hasonló megállapítást tesz: a hibák egyenetlen teszt álcája mögé bújhatnak, és egy teszt elveszíti célját, ha a fejlesztők egyenetlen jellegük miatt figyelmen kívül hagyják a hibákat. A Slack azt is megjegyzi, hogy a flaky tesztek csökkentik a konfigurációelemzés stabilitását, növelik az egyesítéshez szükséges időt, csökkentik a fejlesztők bizalmát, és károsítják a fejlesztői élményt.
Ezért jelentenek üzleti kockázatot a flaky tesztek. Gyengítik a kiadással kapcsolatos bizalmat. Bizonytalanságot teremtenek a szállítási dátumok körül. Kevésbé megbízhatóvá teszik a minőségi mutatókat. Lassítják a piacra jutási időt. Szabályozott vagy üzletileg kritikus környezetben gyengítik a kiadási alkalmazás alátámasztásához szükséges bizonyítékokat is.
Egy bank nem engedheti meg magának a tranzakciófeldolgozási tesztekkel kapcsolatos bizonytalanságot. Egy telekommunikációs szolgáltató nem kezelheti a kiépítési vagy számlázási hibákat véletlenszerű zajként. Egy légiipari vállalat nem támaszkodhat instabil validációs bizonyítékokra a kritikus munkafolyamatok esetében. Ezekben az esetekben a megbízhatatlan tesztek megbízhatatlan döntéseket hoznak.
A flaky tesztek ott fájnak a legjobban, ahol a szoftverszállítás a gyors, megbízható visszajelzéstől függ.
Ha egy build kiszámíthatatlanul meghiúsul, a fejlesztők időt veszítenek a nem kapcsolódó problémák kivizsgálásával. A pull requestek tovább várnak. A kiadások lelassulnak. A csapatok elkezdik megkerülni vagy figyelmen kívül hagyni a teszthibákat. Ez veszélyes hurkot hoz létre: minél kevésbé megbízható a folyamat, annál kevésbé hatékonyan védi a termelést.
2. Regressziós tesztelés
A regressziós tesztelés célja, hogy bizalmat nyújtsanak arra vonatkozóan, hogy a meglévő funkciók a változtatás után is működnek. Ha a regressziós tesztek egyenetlenek, a szervezet elveszíti az egyik fő védelmét a hibák kiszivárgása ellen. Egy egyenetlen regressziós tesztcsomag technikailag nagy lehet, de stratégiailag gyenge.
3. Teljes körű tesztelés
Az E2E tesztek gyakran lefedik a felhasználók és az üzleti érdekelt felek számára legláthatóbb munkafolyamatokat. Emellett hajlamosabbak az instabilitásra, mivel számos rendszerrétegtől függenek. A Slack megfigyelte, hogy a tesztek meghibásodási aránya teszttípusonként változik, az egységtesztek általában kevésbé egyenetlenek, mint a funkcionális tesztek, és a funkcionális tesztek kevésbé egyenetlenek, mint az E2E tesztek.
4. Teljesítmény- és infrastruktúra-függő tesztelés
Az üzletileg kritikus rendszerek gyakran nemcsak funkcionális hibák miatt hibásodnak meg, hanem az időzítés, a terhelés, a párhuzamosság, a környezet instabilitása vagy külső függőségek miatt is. Ha a teljesítmény- vagy integrációs tesztek egyenetlenek, a csapatok elmulaszthatják a skálázhatóságra, a rugalmasságra vagy a szolgáltatás romlására vonatkozó korai figyelmeztetéseket.
5. Szabályozott szállítás
A banki, telekommunikációs és repülőgépipari szektorban a minőségi bizonyítékok fontosak. A egyenetlen teszteredmény kétértelműséget okozhat: hibás volt a rendszer, instabil volt a környezet, rossz volt a teszt, vagy soha nem értették meg megfelelően a kockázatot? A kétértelműség költséges, ha a kiadás jóváhagyása nyomon követhető, megismételhető, auditálható bizonyítékoktól függ.
Az első megoldás a detektálás. A csapatoknak azonosítaniuk kell, hogy mely tesztek hibásak, milyen gyakran hibásodnak meg, mely rendszereket érintik, ki a tulajdonosa, és hogy a bizonytalanság trendje javul vagy romlik-e. Adatok nélkül a bizonytalan tesztek anekdotikussá válnak. Adatokkal kezelhetővé válnak.
A második megoldás az osztályozás. Nem minden hibát kell ugyanúgy kezelni. A Slack hangsúlyozza a bizonytalan tesztek megkülönböztetésének fontosságát a következetesen hibás tesztektől, az infrastruktúra hibáitól, az összeomlásoktól és a backend/API hibáktól. Megoldása magában foglalja a detektálást, a blokkolást, a Jira jegyek létrehozását, a tulajdonjogi feltérképezést és a csapatértesítéseket.
A harmadik megoldás a karantén, de óvatosan. A Google leír egy enyhítő stratégiát, ahol a túlzottan bizonytalan teszteket automatikusan karanténba helyezik és eltávolítják a kritikus útvonalról, miközben hibát jelentenek a fejlesztőknek a bizonytalanság csökkentése érdekében.
A Google azonban arra is figyelmeztet, hogy a karantén elfedheti a valódi versenyfeltételeket vagy a tesztelt kód egyéb hibáit.
A negyedik megoldás a tulajdonjog. A tulajdonos nélküli bizonytalan teszt állandó zajjá válik. Az Atlassian kiemeli az irányítópultok, a trendelemzés, a kiváltó ok elemzése, az egyéni küszöbértékek és a meglévő CI/CD munkafolyamatokba való zökkenőmentes integráció fontosságát is.
Az ötödik megoldás a jobb tesztarchitektúra. Csökkenteni érdemes a felesleges, teljes körű lefedettséget. Ahol lehetséges, el kell végezni le az ellenőrzéseket API, komponens, szerződés vagy egység szintre, majd izolálni a tesztadatokat, felszámolni el a rejtett függőségeket. Ahol lehetséges, a teszteket determinisztikussá szükséges tenni.
A hatodik megoldás a folyamatos mérés. Kövesse nyomon a bizonytalan tesztek arányát, az újrafuttatási arányt, a build stabilitását, az egyesítéshez szükséges időt, a triázsidőt, a megkerült hibákat, a tesztek tulajdonjogát és a megoldáshoz szükséges időt.
Üzletileg kritikus szoftverek esetében a flaky tesztek kezelésének a tágabb minőségbiztosítási stratégia részének kell lennie.
Először az üzletileg kritikus útvonalakat lefedő teszteket szükséges azonosítani: fizetések, számlázás, hitelesítés, kiépítés, jelentéskészítés, megrendelésfeldolgozás, integrációk, biztonsággal kapcsolatos munkafolyamatok és ügyfélkapcsolati szolgáltatások. Ezeknek a teszteknek a legmagasabb megbízhatósági elvárásokkal kell rendelkezniük, mivel ezek támogatják a legfontosabb kiadási döntéseket.
Ezután határozzuk meg az elfogadható egyenetlen tesztelési küszöbértékeket. Egy egységtesztnek szinte semmilyen toleranciát nem szabadna tanúsítania az egyenetlenséggel szemben. Egy összetett E2E vagy mobil teszt eltérő kezelést igényelhet, de továbbra is felelősségvállalásra, monitorozásra és korrekciós folyamatra van szüksége.
Ezután kapcsoljuk össze a teszteredményeket az üzleti kockázattal. Egy ritkán használt belső függvényben végzett flaky teszt nem hordozza ugyanazt a kockázatot, mint egy flaky teszt egy alapvető fizetési folyamatban. A priorizálásnak tükröznie kell az üzleti hatást, nem csak a technikai gyakoriságot.
Végül, a egyenetlen tesztek kiküszöbölését termékminőségi befektetésként kell kezelni. A cél a gyorsabb visszajelzés, a kevesebb blokkolt kiadás, a jobb fejlesztői termelékenység, az erősebb audit bizonyítékok és a csökkentett termelési kockázat.
A flaky teszt több mint egy technikai bosszúság. Figyelmeztető jel, hogy a tesztelési folyamat, a tesztarchitektúra, a CI/CD-folyamat vagy a tesztelt rendszer esetleg nem elég megbízható ahhoz, hogy támogassa a magabiztos szállítást.
Ha figyelmen kívül hagyják, a flaky tesztek pazarolják a mérnöki időt, károsítják a fejlesztők bizalmát, késleltetik a kiadásokat, növelik a CI-költségeket, és lehetővé teszik, hogy a valódi hibák téves riasztások mögé bújjanak. Megfelelő kezelés esetén lehetőség nyílik a tesztautomatizálás érettségének javítására, a szállítás stabilizálására és az üzletileg kritikus minőségbiztosítás megerősítésére.
A ProofIT megfelelő referenciákkal rendelkezik a banki, telekommunikációs és légiipari komplex, kritikus rendszerek automatizált tesztelésében és teljesítménytesztelésében. Ha csökkenteni szeretné a bizonytalan tesztelési kockázatot, javítani szeretné a CI/CD megbízhatóságát, és megbízható automatizált tesztelést szeretne építeni az üzletileg kritikus útvonalak köré, a ProofIT segíthet a valós körülmények közötti ellenálló képességre épülő tesztelési stratégia megtervezésében, stabilizálásában és skálázásában.
Értékelje a bizonytalan kitettségét. Kérjen bizonytalansági auditot vagy konzultációt szakértőinktől a business@proofit.tech címen vagy a +44 73 6048 4722 telefonszámon. Szakértői csapatunk segíthet az Ön komplex és kritikus vagy sürgős funkcionális és teljesítménytesztelési folyamatában.
