A BA – QA egyensúly nyomában

A cikk eredetileg a BA Karakter #10 magazinban jelent meg.

Prológus

Szoftver minőségbiztosítást, vagy egyszerűbb nevén a tesztelést képviselve kicsit kakukktojásnak érzem magam itt az V. BA Bridge blogcikkek hasábjain, annak ellenére, hogy az alap belső érzésem az, hogy üzleti elemzők és szoftvertesztelők alapvetően rokonlelkek, vagy legalábbis közeli hozzátartozók, de szomszédok bizonyosan.

2012-ben kezdtem a Fundamenta-Lakáskasszánál IT projektvezetőként dolgozni. Ott nem volt külön tesztelői csapat, hanem csak üzleti elemzői csapat volt. Alapértelmezett volt, hogy a tesztelés dandárját az üzleti elemzők végzik. Egy több IT rendszer bevezetését összefogó program tesztjét, a központi számlavezető rendszer cseréjével együtt elvittek az üzleti elemzők és szakterületi felhasználók, profi külső tesztmenedzserek vezényletével. Az IT program eredménye volt, hogy kialakult a tesztelési szervezet.

Ma, egy tesztelési szolgáltatásokat nyújtó vállalat projektekért felelős vezetőjeként azzal találkozom, hogy minden nagyvállalatnál van tesztelésért felelős szervezet, sokszor még KKV-k esetében is van egy-két tesztelő, tesztelésért felelős személy. Az üzleti elemzői csapatokra kevésbé van rálátásom, ezért lehet, hogy ez az én hozzáférési heurisztikámon alapuló torzítás, de az érzésem az, hogy egy-egy nagyvállalat több tesztelőt foglalkoztat, mint üzleti elemzőt. Nincsenek pontos adataim, statisztikáim, hogy ez valóban így van-e. De egy gondolatkísérlet kedvéért tegyük fel, hogy a vállalatok tényleg több szoftvertesztelőt foglalkoztatnak, mint üzleti elemzőt. Egyébként a Google Gemini is megerősíti.

A szoftvertesztelői többletnek természetesen több oka és magyarázata is van, de akkor is játsszunk el azzal a gondolattal, hogy lehet, hogy azért van szükség több tesztelőre, mert kevés az üzleti elemző?

A tesztelő, mint állatorvos

Van az régi vicc, amikor az állatorvos megbetegszik, és elmegy a háziorvoshoz. A háziorvos behívja: “Jöjjön üljön le, mondja el mik a panaszai!” Erre az állatorvos: “Ja, hát így könnyű.”

Mikor van egy tesztelőnek könnyű dolga? Ha van egy jó specifikáció. Ami eleve úgy íródik, hogy a szükséges egyeztetések, elemzések, döntések megszülettek előtte. Amiben érthető követelmények vannak, amiben a folyamati elágazások végig vannak gondolva, el vannak varrva. Ami eleve az üzleti igényt, a végfelhasználói szempontokat is figyelembe veszi, ehhez kapcsolódó képernyőterveket, drótvázakat is tartalmaz. Ilyenkor könnyen és gyorsan lehet teszteseteket írni, és várhatóan a tesztelés során is kevesebb hibával találkozunk (bár itt még a kivitelezésen, a fejlesztőn is sok múlik).

Ezzel szemben tesztelő kollegáink leggyakrabban azzal találkoznak, hogy „hullik a szoftver szőre”, „fura sípoló hangot ad”, vagy „több napja nem székelt”. Megindul a fejvakarás, hogy miért nem működik jól az a szoftver, mi lehet a baja, mi akadályozza a megfelelő működést? (Ha egyáltalán tudjuk, mi lenne a megfelelő működés.)

Szerencsére azért abban mégiscsak inkább a háziorvosra hasonlítunk, hogy emberekkel dolgozunk, így megindul a kérdezés, az egyeztetések az üzleti terület képviselőivel, jó esetben üzleti elemzővel (ha van a projekten), fejlesztővel, rendszerszervezővel és az egyeztetéseket követően összeáll a kép és a tesztesetek, meg a szoftvertől elvárt működés.

A felborult BA – QA egyensúly

A TestIT-en belül keressük azokat a teszteléssel kapcsolatos feladatokat, illetve use caseket, amelyeknél jól hasznosítható az AI. Ennek kiindulási pontjaként 10-15 különböző projekten dolgozó tesztelési szakértőnktől kértünk becslést arra vonatkozólag, hogy munkaideje hogyan oszlik meg a különböző tesztelési tevékenységek között. A tesztesetírás témakörére, amiben benne van a specifikáció olvasása, követelmények egyeztetése, teszteset megírása, validáltatása, az jött ki, hogy szeniortástól függően eltérő, de azért egy jelentős részét teszi ki egy tesztelő munkájának.

Tesztesetírásra részaránya egy tesztelő feladataiból
Senior tesztelő	30-40%
Medior tesztelő	40-50%
Junior tesztelő	60-70%

A fentiek csak ráerősítettek arra, hogy érdemes a már-már triviális AI felhasználási esettel, a specifikációból teszteset generálással, foglalkozni. A tesztesetírás egy jelentősebb tevékenység a tesztelők számára, és alapvetően a nyelvi modellek számára egy jól értelmezhető feladat, hiszen szöveget kell értelmezni, amelyből bizonyos kritériumok mentén szöveget (teszteset) kell generálni. Ennek az egyik legnagyobb akadálya, hogy nincs vagy gyenge minőségű a specifikáció. Nem elég strukturált, nincs benne minden adat, egymásnak ellentmondó részek szerepelnek benne (agilis projekt esetében a specifikáció a user story-val és az elfogadási kritériumokkal helyettesíthető).

Egy PoC keretében, ahol rendelkezésünkre állt egy jó minőségű specifikáció, amelyből korábban már hagyományos módon megírtuk a teszteseteket, arra jutottunk, hogy a tesztesetírásra szánt idő kb. 60 százalékkal csökkenthető egy tesztesetírásra felkészített LLM modell segítségével. Ez egy első eredmény, a jövőben további méréseket fogunk végezni, de azt feltételezzük, hogy 30-50 százalékkal csökkenthető a tesztesetírási ráfordítása. Ez a nagyságrend ahhoz viszont egy jó irányjelző, hogy jó előkészítéssel, adott esetben több üzleti elemzői ráfordítással a tesztelési tevékenységek ráfordítása csökkenthető vagy kicsit más szemszögből nézve a szoftverminőség azáltal növelhető, hogy a tesztelési ciklus rövidíthető, amely több iterációra is lehetőséget ad egy adott időkereten belül.

Nincs arra vonatkozóan jó irányszámom, hogy egy BA-ra hány QA kell, hogy jusson, de a fenti példa azt mutatja, hogy a BA arány növelésének hatása van a QA feladatokra, és adott esetben a teljes szoftverfejlesztési életciklus összes ráfordítását is csökkentheti egy jól hangolt arány.

Ötletek tesztelői szemmel üzleti elemzőknek

Két olyan ötlet fogalmazódott meg bennem, amely az együttműködést gyakorlati oldalról is tudja támogatni, és akár rövidebb időtávon, nagyobb ráfordítás nélkül bevezethető.

Az egyik a statikus tesztelés, tehát, amikor még kódolást, alkalmazást futtatást megelőzően teszteljük a követelményeket, az elkészült specifikációt tesztelési szempontból ellenőrizzük és a talált hiányosságokat, hibákat javítjuk. Ezt nagyon ritkán látom a gyakorlatban. Ügyfeleink jellemzően akkor vonnak be minket a tesztelésbe, amikor a szoftver már úton van. Pedig ez a Shift-Left-Approach, tehát a tesztelési, szoftverminőségbiztosítási feladatok szoftverfejlesztési ciklusban történő minél korábbi időpontra hozásának, egy nagyon egyszerű és olcsó formája. Kedves üzleti elemző kollegák, ha eddig nem zargattátok tesztelői kollegáitokat a statikus teszteléssel, akkor itt az idő elkezdeni!

A másik gondolatom pedig, az, hogy a Quality Gate-ket már az üzleti igény felmerülési és specifikációs fázisban is be lehetne hozni. Lehet, hogy már vannak jó gyakorlatok erre, de azokban a projektekben, amelyekben mi részt veszünk, sokszor az a tapasztalatom, hogy a Quality Gate fogalma a release-nél kezdődik, tehát onnantól, hogy már van kód (fejlesztői tesztek – funkcionális tesztek – integrációs tesztek – UAT). Jó lenne, ha már az üzleti igényre is lenne Quality Gate, például, megfelelő elemzéseken alapul az üzleti igény, érhető, azonosított a cél-, végfelhasználói csoport. Meglévő szoftver esetében a módosítani kívánt funkciót hány százalékban használják? Specifikáció esetében a szükséges szakterületek jóváhagyták-e a specifikációt, megtörtént-e a dokumentum, user story statikus tesztelése?

Epilógus

A fenitek tükrében azt gondolom, hogy a jó szoftverminőség alapja a jó üzleti elemzői munka, a jól megfogalmazott követelmények. Erre alapozva a szoftver tesztelés jelentősen gyorsítható és a fókusz a követelmények, és az elvárt működés megértése helyett átkerül a kivitelezés minőségének ellenőrzésre.

A jó BA – QA együttműködés szükséges ahhoz, hogy a time-to-market időket rövidíteni tudjuk, és lépést tudjunk tartani az egyre rövidülő release ciklusokkal.

Azt gondolom, hogy a közös célunkat, hogy jó minőségű, a végfelhasználó igényeit kiszolgáló, a folyamatosan módosuló igényekhez gyorsan és hatékonyan igazítható szoftverek, üzleti alkalmazások készüljenek, csak közös erőfeszítéssel tudjuk elérni.

Bízom benne, hogy a jövőben izgalmas együttműködések indulhatnak el közöttünk. Ha már csak annak a feltételezésnek utána tudunk közösen menni, hogy valóban több tesztelőt, mint üzleti elemzőt foglalkoztatnak vállalatok, illetve mi lehet egy megfelelő arány, már az is nagyon izgalmas lenne.

Írta: Gayerhosz Gergely, a TestIT Delivery managere