Több csapat, egy release: hogyan tartható átláthatóan a QA?
Több csapat dolgozik ugyanazon a szoftverkiadáson, de vajon hogyan állíthatók össze az egyes csapatok tesztelési eredményei egy átlátható, egységes képpé? A különböző fejlesztések, tesztfuttatások és kódváltozások követése komoly kihívást jelenthet, különösen összetett projektek esetén. A közös release-nézet, a kockázatalapú tesztpriorizálás és a központi tesztmenedzsment segíthet abban, hogy a QA-csapatok ne csak az elvégzett teszteket, hanem a fennmaradó kockázatokat is lássák. Így megalapozottabb döntés születhet arról, hogy a szoftver készen áll-e a kiadásra.
Egy összetettebb szoftverfejlesztési projektben gyakran több csapat dolgozik párhuzamosan ugyanazon a projekten. Az egyik csapat a backend szolgáltatásokat fejleszti, a másik a felhasználói felületet, egy harmadik az integrációkat vagy valamely üzleti modult. A release végén azonban ezek a változások egyetlen rendszerben találkoznak. A QA egyik fontos feladata ezért már nemcsak az egyes funkciók ellenőrzése, hanem annak átlátása is, hogy a különböző csapatok változásai együtt milyen tesztelési kockázatot jelentenek az adott release-ben.
Miért nehéz több csapat tesztelési eredményeit átlátni?
Többcsapatos fejlesztésben gyakran előfordul, hogy az egyes fejlesztői vagy tesztelői csapatok elsősorban a saját területük állapotát követik. Egy modul tesztjei sikeresen lefutottak, miközben egy másik komponensben még vannak nem ellenőrzött változások. Az egyes csapatok eredményei külön-külön megfelelőnek tűnhetnek, a teljes release-ről azonban ettől még nem kapunk pontos képet.
A probléma tovább nő, ha a tesztesetek, futtatási eredmények, kódváltozások és release-információk különböző rendszerekben vagy táblázatokban találhatók. Ilyenkor a QA-csapatnak manuálisan kell összegyűjtenie az információkat, mielőtt egyáltalán megkezdődhet a kiadás állapotának értékelése.
Egy közös release-nézetre van szükség
A TestNavigator tesztmenedzsment platform segítségével a különböző csapatok tesztelési információi ugyanahhoz a release-hez kapcsolhatók. Egy helyen válik láthatóvá, hogy milyen tesztesetek tartoznak a kiadáshoz, melyeket hajtottak már végre, milyen eredménnyel zárultak, illetve milyen változások kerültek a kódba.
Ez azért fontos, mert abból, hogy hány teszt futott le sikeresen, önmagában még nem állapítható meg, hogy a szoftver készen áll-e a kiadásra. Azt is tudni kell, hogy mit ellenőriztek ezek a tesztek, mely területek változtak, és vannak-e olyan módosítások, amelyek még nem kaptak megfelelő tesztelési figyelmet.
Nem minden változás ugyanolyan fontos
Több csapat munkájának összehangolásakor könnyen előfordulhat, hogy több száz vagy akár több ezer teszteset közül kell kiválasztani a végrehajtandó teszteket. Ilyenkor nem feltétlenül hatékony minden tesztesetet azonos prioritással kezelni.
A kockázatalapú teszteset-priorizálás abban segít, hogy a tesztelési sorrendet az üzleti jelentőség, a változások mértéke és hatása, a korábbi hibák, a lefedettségi információk és más releváns kockázati tényezők alapján alakítsuk ki. Nagyobb figyelmet igényelhet például egy üzletileg fontos funkciót érintő, több komponensen átívelő vagy jelentős kódmódosítással járó változás, mint egy kisebb, jól elkülöníthető módosítás. Ez különösen fontos akkor, amikor a release közeledtével korlátozott idő áll rendelkezésre, és a tesztelési kapacitást a legnagyobb kockázatot jelentő területekre kell összpontosítani.
A tesztelési adatokból döntési információ
A release állapotának értékeléséhez több információt kell együtt vizsgálni: mely tesztek futottak le és milyen eredménnyel, mely területek változtak, milyen tesztek kapcsolódnak ezekhez, milyen kódlefedettségi információk állnak rendelkezésre, illetve hol maradt még bizonytalanság.
Az adatvezérelt release döntéstámogatás célja, hogy ezekből az információkból egységes és értelmezhető kép készüljön a kiadás állapotáról. Így a QA nem csupán tesztfuttatási eredményeket szolgáltat, hanem segít azonosítani azt is, hogy mely területeknél áll rendelkezésre megfelelő tesztelési információ a release-döntéshez, és hol lehet szükség további ellenőrzésre.
Hogyan támogatja ezt a TestNavigator?
A TestNavigatorban a tesztesetek, tesztfuttatások, release-ek és a kódlefedettségi információk egy közös platformon kezelhetők. A csapatok így nem elszigetelt teszteredményeket látnak, hanem azt is követhetik, hogyan kapcsolódnak azok az adott kiadás változásaihoz.
A release-szintű nézet különösen hasznos több csapat esetén, mert segít felismerni a még nem megfelelően tesztelt területeket, és összevetni az egyes csapatokhoz vagy komponensekhez kapcsolódó tesztelési állapotokat.
A QA akkor átlátható, ha mindenki ugyanazt a képet látja
A többcsapatos fejlesztésben nem feltétlenül több riport jelent jobb átláthatóságot. Sokkal fontosabb, hogy a fejlesztők, tesztelők és a release-ért felelős szereplők ugyanabból az információs alapból dolgozzanak.
Ha egyértelműen látható, mi változott, mit teszteltünk már, milyen eredménnyel, és mely területek igényelnek még figyelmet, akkor a különböző csapatok tesztelési eredményei is könnyebben összeállnak egy egységes release-szintű képpé.
- AI integrálás üzleti rendszerekbe
- tesztmenedzsment platform
- QA menedzsment