Van egy elv, amelyet a szoftvertesztelésben évek óta bölcsességként adnak tovább: „tesztelj korán és gyakran”. Ez a Shift Left szemlélet lényege, és sokáig ez jelentette a modern minőségbiztosítás csúcsát. A logikája megcáfolhatatlan: minél korábban találjuk meg a hibát, annál olcsóbb kijavítani.
Csakhogy a mai szoftverek már nem úgy néznek ki, mint húsz éve. Egy modern rendszer ritkán egyetlen, zárt alkalmazás. Sokkal inkább szolgáltatások hálózata: felhőben fut, tucatnyi külső rendszerrel kommunikál, folyamatosan változó terhelés alatt. És ebben a világban egyre világosabbá válik egy kényelmetlen igazság: a korai tesztelés önmagában már nem elég.
Ez a cikk arról szól, hogy hová fejlődött a minőségbiztosítás azon túl, hogy „tesztelj korán”, és mit jelent ez egy technológiai vezető számára.
Mi az a Shift Left, és miért működött?
A „Shift Left” kifejezést Larry Smith alkotta meg 2001-ben. A név egyszerű képre épül: ha a fejlesztési folyamatot egy balról jobbra haladó idővonalként képzeljük el (a tervezéstől az éles üzemig), akkor a tesztelés hagyományosan a jobb szélen, közvetlenül az élesítés előtt helyezkedett el. A Shift Left ezt „balra tolja”: a minőségellenőrzést a folyamat elejére hozza.
Ennek üzleti értéke óriási, és a Mennyi pénzbe kerül egy későn megtalált hiba? című cikkünkben már részletesen bemutattuk: a specifikációs fázisban elkapott hiba töredékébe kerül annak, amelyik csak élesben derül ki. A Shift Left tehát nem divat volt, hanem valós költségmegtakarítás.
A probléma nem az elvvel van. Hanem azzal, hogy közben megváltozott, mit kell tesztelni.
Hol érte el a Shift Left a határait?
A korai tesztelés egy alapfeltevésre épül: hogy a tesztkörnyezetben előállítható ugyanaz a helyzet, ami élesben is bekövetkezik. Húsz éve, egy zárt vállalati alkalmazásnál ez nagyrészt igaz volt. Ma egyre kevésbé az.
Néhány dolog, amit a legjobb korai teszt sem tud teljesen lefedni:
- A valós terhelés. Egy rendszer viselkedése tízezer egyidejű felhasználó alatt minőségileg más lehet, mint tízé alatt. Ezt tesztkörnyezetben csak közelíteni lehet, tökéletesen reprodukálni ritkán.
- A harmadik felek. A modern rendszerek külső szolgáltatásokra támaszkodnak: fizetési szolgáltatók, térképek, azonosítási rendszerek. Ezek viselkedését, kimaradásait, lassulásait nem mi kontrolláljuk, és tesztkörnyezetben nem mindig utánozhatók hűen.
- A valós felhasználói viselkedés. A felhasználók mindig találnak olyan utakat a rendszerben, amelyekre a tervező nem gondolt. Ezt előre, laborban teljes körűen elképzelni nem lehet.
A tanulság nem az, hogy a korai tesztelés felesleges. Hanem az, hogy a valóság egy részét csak maga a valóság mutatja meg. Itt lép be a kép másik fele.
A Shift Right: amikor a minőségbiztosítás nem áll meg a kiadásnál
Ha a Shift Left a folyamat elejére hozza a minőséget, a Shift Right a másik végét célozza: a minőségellenőrzést kiterjeszti az éles üzemre is. Az alapgondolat, hogy a release nem a minőségbiztosítás vége, hanem egy újabb szakasza.
Ez elsőre kockázatosnak hangozhat („élesben tesztelni?“), de a gyakorlatban épp a kockázat csökkentéséről szól. Néhány bevált technika, üzleti nyelvre fordítva:
- Fokozatos kiadás (canary release): az új verziót először nem mindenkinek adjuk ki, hanem a felhasználók egy kis részének. Ha baj van, csak őket érinti, és azonnal visszavonható, mielőtt az egész ügyfélkör találkozna a hibával.
- Kísérleti összehasonlítás (A/B tesztelés): két változatot párhuzamosan futtatunk valós felhasználókon, és adat alapján döntjük el, melyik működik jobban, nem pusztán feltételezés alapján.
- Funkciókapcsolók (feature flag): az új funkciók külön be- és kikapcsolhatók anélkül, hogy újra kellene telepíteni a rendszert. Ha egy funkció gondot okoz, egyetlen kapcsolóval kivehető.
Mindegyik közös nevezője ugyanaz az üzleti logika: korlátozzuk egy esetleges hiba hatókörét, és őrizzük meg az irányítást akkor is, amikor a szoftver már éles. Hogy mindez vezetői szemmel mit jelent egy kiadás sikerességére nézve, arról a <CIKK: Mit jelent egy sikeres release a CIO szemével?> című cikkünkben írtunk.
Continuous Testing: a minőség, mint folyamatos állapot
A Shift Left és a Shift Right együtt egy nagyobb szemléletváltás két fele. Ennek neve Continuous Testing, azaz folyamatos tesztelés. A lényege, hogy a minőségbiztosítás megszűnik különálló „fázis” lenni, és a teljes életciklust végigkísérő, folyamatos tevékenységgé válik: a tervezéstől az éles működés megfigyeléséig.
A gyakorlatban ez azt jelenti, hogy a tesztelés beépül a szállítási folyamatba (a CI/CD pipeline-ba), és emberi indítás nélkül, automatikusan lefut minden lépcsőnél. Egy tipikus folyamat így néz ki:
- A fejlesztő kiteszi a kódot a dev környezetbe: azonnal ráfutnak az egységtesztek (unit tesztek), amelyek a legkisebb kódegységek helyességét ellenőrzik.
- Az első sikeres dev build után: automatikusan megtörténik a telepítés, majd sorra lefutnak a magasabb szintű automatikus tesztek. Az API tesztek a rendszer belső interfészeit, a GUI tesztek a felhasználói felületet, a további integrációs és regressziós tesztek pedig a modulok együttműködését és a korábbi funkciók sértetlenségét vizsgálják.
- A magasabb környezetekben is (teszt, staging, éles előtti): nem csak a dev környezetben, hanem minden szinten lefut a hozzá illő tesztkészlet, mielőtt a kód továbblépne a következő környezetbe.
Ez a fajta folyamatos, automatikus ellenőrzés csak akkor működik, ha mögötte magas fokú tesztautomatizálás áll, méghozzá a tesztpiramis minden szintjén: az egységtesztektől az API és integrációs teszteken át a GUI tesztekig. Ha bármelyik szint hiányzik vagy megbízhatatlan, a lánc ott szakad meg, és a hibák újra átcsúsznak a következő környezetbe.
Ebben a folyamatban egyre gyakrabban kap szerepet az AI is. Nem a tesztelő helyett, hanem éppen a megnövekedett mennyiség kezelésében: segít összeállítani egy adott változtatáshoz a megfelelő tesztkészletet a meglévő tesztekből, kiszűrni vagy kijavítani a megbízhatatlanul viselkedő (flaky) teszteket, és értékelni a több ezer tesztfutás eredményét, hogy az ember arra figyelhessen, ami valóban számít.
Az éles működés oldalán ehhez két, egyre fontosabb képesség társul:
- Monitoring (megfigyelés): a rendszer folyamatos figyelése éles üzem közben: lassul-e, hibázik-e, elérhető-e. Nem akkor tudjuk meg, hogy baj van, amikor az ügyfél felhív, hanem előbb.
- Observability (megfigyelhetőség): egy lépéssel több ennél. Nemcsak azt látjuk, hogy baj van, hanem azt is meg tudjuk mondani, hol és miért. Így egy éles hiba forrása percek, nem órák alatt lokalizálható.
A DevOps kutatásokra szakosodott DORA éves jelentései következetesen ugyanazt mutatják: a legjobban teljesítő szervezetek nem azért stabilak, mert lassabban vagy ritkábban adnak ki, hanem mert a minőségellenőrzést (a korai teszteléstől az éles megfigyelésig) beépítették a teljes folyamatba. Gyorsan és biztonságosan egyszerre: ez ma nem ellentmondás, hanem elvárás.
Összegzés
A Shift Left nem tévedés volt, és nem is avult el. Egyszerűen kiderült, hogy önmagában csak a történet fele. A hibák egy részét a legjobb korai teszt sem képes megelőzni, mert azokat csak a valós éles környezet hozza felszínre: a valós terhelés, a valós integrációk, a valós felhasználók.
A modern minőségbiztosítás ezért nem egy pont a fejlesztési idővonalon, hanem egy 360 fokos, folyamatos szemlélet: a specifikációtól az éles rendszer megfigyeléséig tart. Aki ma úgy gondol a tesztelésre, mint egy fázisra, amit „letudunk” a kiadás előtt, az a hibák egyik legdrágább csoportját eleve nem is látja.
Források
- Larry Smith: Shift-Left Testing, Dr. Dobb’s Journal, 2001. A fogalom eredeti megfogalmazása; áttekintés: Shift-left testing (Wikipedia)
- DORA (DevOps Research and Assessment): Accelerate State of DevOps jelentések. dora.dev/research
