Miért válik egyre nehezebbé a regressziós tesztelés a szoftver növekedésével?

Egy kisebb alkalmazásnál még egyszerűnek tűnhet minden fontos funkciót újratesztelni egy release előtt. Ahogy azonban a rendszer növekszik, új modulok, integrációk és üzleti folyamatok jelennek meg, emellett a meglévő funkciók is folyamatosan változnak. A regressziós tesztkészlet ezzel együtt bővül, a rendelkezésre álló tesztelési idő viszont ritkán nő ugyanilyen ütemben.

Egy ponton ezért már nem az a kérdés, hogy szükség van-e egyáltalán regressziós tesztelésre, hanem az, hogyan lehet a folyamatosan növekvő tesztkészletből kiválasztani azokat a teszteket, amelyek az adott release szempontjából a legtöbb információt adják.

Több funkció több lehetséges kapcsolatot jelent

A szoftver méretének növekedésével nemcsak a tesztelendő funkciók száma emelkedik. Az egyes komponensek közötti függőségek is összetettebbé válnak. Egy látszólag kisebb módosítás érinthet közös szolgáltatásokat, adatmodelleket vagy API-kat, amelyeket több funkció is használ. Emiatt egy változtatás hatása nem feltétlenül korlátozódik arra a modulra, ahol a fejlesztés történt.

Ez a regressziós tesztelés egyik alapvető nehézsége: nemcsak azt kell ellenőrizni, hogy az új funkció megfelelően működik-e, hanem azt is, hogy a változtatás nem okozott-e problémát valahol máshol.

A regressziós tesztkészlet gyorsabban nőhet, mint a tesztelési idő

Minden új funkcióval új tesztesetek kerülhetnek a rendszerbe, miközben a korábbi tesztek jelentős része is megmarad. Egy hosszabb ideje fejlesztett szoftver esetében így több száz vagy több ezer regressziós teszt halmozódhat fel.

Ha minden release előtt a teljes készletet végre szeretnénk hajtani, a tesztelési idő fokozatosan növekedne. Gyors release-ciklusok mellett pedig könnyen előfordulhat, hogy már nincs elegendő idő minden teszteset lefuttatására.

A regressziós tesztelés optimalizálása ezért nem egyszerűen azt jelenti, hogy kevesebb tesztet hajtunk végre. A cél az, hogy tudatosabban válasszuk ki azokat a teszteseteket, amelyek az aktuális változásokhoz és kockázatokhoz a leginkább kapcsolódnak.

Nem minden release ugyanazokat a teszteseteket igényli

Egy sprintben módosulhat a felhasználói felület, egy másikban az adatkezelés vagy egy kritikus backend szolgáltatás. Ennek ellenére a hagyományos regressziós folyamat gyakran ugyanazt a tesztkészletet futtatja újra minden alkalommal.

A változás alapú tesztelés ehelyett abból indul ki, hogy először azt vizsgáljuk meg, mi változott az adott sprintben. Ha azonosítható, hogy mely kódterületeket érintette a módosítás, akkor ezekhez kapcsolódó teszteket nagyobb figyelemmel lehet kezelni.

Így a regressziós tesztelés jobban alkalmazkodhat az adott kiadás tényleges tartalmához, és kisebb szerepet kapnak azok a tesztek, amelyek az aktuális módosításoktól távoli területeket ellenőriznek.

Mely teszteket futtassuk le először?

A probléma különösen akkor válik láthatóvá, amikor a release határideje közeledik, de a teljes regressziós tesztkészlet végrehajtására már nincs elegendő idő.

Ilyen helyzetben a tesztesetek kockázatalapú priorizálása segíthet meghatározni, mely teszteket érdemes előre venni. A prioritás alapja lehet például az érintett kódterület, a változás mértéke, a funkció üzleti jelentősége, a korábbi hibák vagy a rendelkezésre álló lefedettségi információ.

A kérdés tehát nem feltétlenül az, hogy mely teszteket hagyjuk ki, hanem az, hogy milyen sorrendben hajtsuk végre őket ahhoz, hogy a rendelkezésre álló idő alatt a lehető legtöbb releváns információt kapjuk a release állapotáról.

Hogyan segíthet ebben a TestNavigator?

A TestNavigator tesztmenedzsment és döntéstámogató platform a tesztfuttatások eredményeit és a kódlefedettségi adatokat a release változásaival együtt teszi vizsgálhatóvá. Ez segít megérteni, hogy az egyes tesztek milyen kódterületeket érintenek, és hogy az adott sprint során módosított részekhez milyen tesztelési információ áll rendelkezésre.

Ez különösen nagy regressziós tesztkészlet esetén lehet hasznos. Ahelyett, hogy minden verziós teszteléskor ugyanabból a statikus tesztlistából indulnánk ki, a változások és a lefedettségi adatok alapján pontosabb kép alakítható ki arról, mely területek igényelnek nagyobb figyelmet.

A tesztelési eredmények, a változott kód és a lefedettség együttes vizsgálata abban is segíthet, hogy hamarabb felismerhetővé váljanak azok a kódrészek, amelyek változtak, de még nem kaptak megfelelő prioritást.

A növekvő szoftverhez a tesztelési stratégiának is alkalmazkodnia kell

A regressziós tesztelés nehézsége nem pusztán abból fakad, hogy egy nagyobb rendszerhez több teszt tartozik. A változások közötti összefüggések, a rövidebb release-ciklusok és a növekvő tesztkészlet együtt teszik egyre összetettebbé a feladatot.

Hosszabb távon ezért nem feltétlenül az összes teszt egyre gyorsabb végrehajtása jelenti a megoldást. Fontosabb lehet annak pontosabb meghatározása, hogy az adott sprintben mi változott, hol jelentkezik nagyobb bizonytalanság, és mely tesztek adhatnak ezekről a területekről érdemi információt.