A szoftverminőség beépítése a fontos, nem a végén az ellenőrzés - Schaffhauser Balázs (QMP #3)

Harmadik adásunk vendége Schaffhauser Balázs tesztmenedzser, agilis coach, akivel Simon Kornél és Hargitai Zsolt többek között arról is beszélgetett miért vált mára helyenként szitokszóvá az agilitás. Csak azért, mert a projektek letudni és megúszni akarják az ezzel járó feladatokat, ahelyett, hogy a mögöttes gondolatiságot helyeznék előtérbe?
Miért lesz jobb mindenki számára, ha a szoftvertesztelő kicsit érti a Javascript alapjait, miközben a fejlesztő tisztában van azzal, miért fontos a korai tesztelés, miközben mindketten értik, hogy mi az az üzleti környezet, amiben a szoftverük létezik.
Mi a viszonya az agilitásnak a dokumentációhoz, tényleg igaz, hogy a működő szoftver fontosabb, mint a specifikáció? És ha ez a specifikáció több, mint ezer oldalra rúgna, akkor elvárható, hogy azt bárki értelmezni tudja? Hol az arany középút, és hol segít ebben az agilis megközelítés.
Schaffhauser Balázs régi motoros már a szakmában, aki nagyon megkapóan és érzékletesen tud beszélni az olyan fogalmakról is, mint a kisebb transzportációs veszteség, vagy a white box tesztelés. Akire kicsit is igaz az a megállapítás, hogy munkájának célja a sikeres szoftverfejlesztés, vagy legalább már egyszer életében mélyen felháborodott egy rosszul működő appon, remekül fog szórakozni ezen az adáson.
Az adás szereplői:
/ kornel-simon
/ bschaffhauser
/ zsolt-hargitai
A Quality Master adásait nem csak itt éred el, hanem még:
Spotify:
spoti.fi/3ywYwXT
KZbin:
bit.ly/3KizsGT
#IT #softwaretesting #szoftvertesztelés #agile #qualityassurance

[@fajoyomi12]

Még csak 10 percnél járok de a projekt sikerességi rátáknál enyhe csúsztatásnak érzem, hogy a sikeresség definiálása nem történt meg (magában a tanulmányban lehet, hogy megvolt). Tejesen mást jelent a sikeresség ugyanis egy waterfall és egy agilis projektnél. Mert az egyiknél nincs mihez viszonyítani a másiknál van. Hogy miért? Egy Agilis projektben mivel nincsenek előre specifikálva a sikerkritériumok (legalábbis nem olyan módon mint a Waterfall-nál) ezért ha a végén van egy működő szoftverem vagy bármi más termékem azt a projektet sikeresnek nevezhetem tekintve hogy nincs mihez viszonyítani csak a végső ügyfél elégedettséghez. Egy waterfall projektben viszont mivel van mihez viszonyítani ezért ha valamit változtatni kell a terméken a specifikációhoz képest így a végtermék esetleg kompromisszumos lesz (ugyan úgy mint ahogy az előfordulna agilis módszertan mellett) azt nem lehet teljesen sikeres terméknek nevezni. Mint project manager ha megkérdeznek az agilis projektem sikerességéről könnyebben mondom, hogy sikeres a projekt ha az ügyfél elégedett mint egy waterfall projektre ahol ugyan az ügyfél elégedett de kimutathatóan nem tudtunk megfelelni a kezdeti elvárásoknak teljes mértékben.

[@kornelsimon2499]

Valóban, a sikeresség definíciója nem hangzott el a podcastban! Azt remélem, hogy ez nem akkora probléma. A statisztikákból ugyanis érdemes a sikertelen projektek arányára is figyelni. Az, hogy egy projekt földbe áll, már mindkét metodológiában ugyanazt jelenti mindenki számára. Az agilis projekteken a sikertelenség aránya feltűnően kisebb. Ezt úgy is megfogalmazhatnám, hogy a felmérésben vizsgált agilis projektek sikeresebbek voltak, mint a waterfall projektek, mivel nagyobb arányban kerülték el a teljes bukást. Ezzel egyetértesz? Ha jól értelek, akkor a sikerességet a waterfall és az agilis projekteken külön definiálnád. Én inkább a közös definíciót részesíteném előnyben. Ha egy waterfall projekten minden kezdeti elvárást sikerül maradéktalanul teljesíteni, azt még nem feltétlenül nevezném sikernek. A dolgokkal (pl. szoftverekkel) kapcsolatos elvárásainknak ugyanis csak egy része az, amit megfogalmazunk. Egy részét nem fogalmazzuk meg, mert annyira magától értetődőnek tűnik, egy másik részét pedig azért nem, mert nem is gondoltunk rá - pedig lehet, hogy kellett volna. (Ezt az első részben a Kano modell ismertetésénél járjuk körbe egy kicsit Zsolttal.) Egy komplexebb projekten egyszerűen nem lehet minden igényt előzetesen megfogalmazni - illetve olyan sok idő kellene rá, ami a felgyorsuló világban már nem áll rendelkezésre. Az agilis megközelítés azért tud sokszor kézreállóbb lenni, mint a waterfall, mert nyitva hagyja a lehetőséget arra, hogy a projekt során az elvárásokat még módosítsuk. Így a Kano modellbeli kétféle (meg nem fogalmazott) követelménycsoport is felszínre kerülhet.