4. óra · Szoftvertesztelés gyakorlat

A tesztelés pszichológiája és a független tesztelés

Hogyan adjunk használható visszajelzést, és ki milyen szerepben tesztel?

Az óra végére képes leszel

  • Tényszerű, együttműködő hibajelzést írsz minősítő megfogalmazás nélkül.
  • Felismered a megerősítési torzítást és a szerzői vakságot egy tesztelési helyzetben.
  • A feladathoz illő függetlenségi szintet és szerepmegosztást választasz.
A munka menete
  1. 1MegfigyelésPontosan mi történt?
  2. 2ElvárásMelyik szabálytól tér el?
  3. 3ÚjrajátszásVerzió, adat, lépések.
  4. 4EgyeztetésKérdés és közös értelmezés.
  5. 5KövetésJavítás, újratesztelés, tanulság.
01 / TANANYAG

Egy hiba felfedezése társas helyzet is

A tesztelő gyakran olyasmit mond el a csapatnak, amit kellemetlen hallani: egy működés eltér a megbeszélt eredménytől. A visszajelzés célja nem a fejlesztő vagy a megrendelő minősítése, hanem az eltérés reprodukálása és javítása. Az olyan mondat, hogy „ezt teljesen elrontottad”, védekezést vált ki, és nem ad vizsgálható információt.

A jó hibajegy leírja a környezetet, az előfeltételeket, a lépéseket, az elvárt és tényleges eredményt. A beszélgetésben nyitott kérdés segít: „E szerint a szabály szerint mit kellene látni a harmadik kölcsönzés után?” Ha a követelmény kétértelmű, nem feltételezzük azonnal, hogy a kód hibás; egyeztetjük az elvárást.

02 / TANANYAG

Torzítások, amelyek teszt közben hatnak

A megerősítési torzítás miatt a saját elképzelésünket alátámasztó eseteket könnyebben választjuk. Ha a fejlesztő „tudja”, hogy legfeljebb három eszköz kölcsönözhető, talán csak az egy, kettő és három darabos sikeres utat próbálja ki. A negyedik, tiltott eset, a már kiadott eszköz és a hálózati megszakadás kimaradhat.

A szerző közelről ismeri a megoldás belső logikáját; ezért hajlamos azt látni, amit építeni akart. Egy új szemű tesztelő más bemenetet, félreértett feliratot vagy hiányzó visszajelzést vesz észre. A függetlenség segítheti a hibák felismerését, de önmagában nem garantál jobb teszteket: fontos a szaktudás, a kommunikáció és az együttműködés is.

03 / TANANYAG

Ki a tesztelő?

A saját munkáját ellenőrző fejlesztő gyorsan kap visszajelzést és jól ismeri a kódot. Egy másik csapattag könnyebben találhat eltérő használati utat. Független tesztelőcsoport külön nézőpontot adhat; bizonyos szakterületeken külső szereplő vagy valódi felhasználó is részt vehet a vizsgálatban. Ezek eltérő függetlenségi szintek, nem egymást kizáró módszerek.

A teljes elszigetelés akadályozhatja a pontos egyeztetést, az átadási hibák pedig csökkenthetik a teszt hatását. A fejlesztő és tesztelő közös célja a használható termék. Például a fejlesztő írhat egységteszteket, a másik csapattag funkcionális teszteket, a kölcsönzőt ténylegesen használó munkatárs pedig visszajelzést adhat a folyamat érthetőségéről.

04 / TANANYAG

Együttműködő hibamegbeszélés

Egy vitás eltérésnél először ugyanazzal a verzióval és adattal újrajátsszuk a lépéseket. Utána a követelmény megfogalmazását vizsgáljuk: melyik szabály alapján vártuk az eredményt? Csak ekkor döntjük el, valódi hiba, környezeti gond, hiányzó követelmény vagy félreértés áll-e fenn.

A tesztelő ne hallgassa el a kockázatot a konfliktus elkerüléséért, de ne állítson okot bizonyíték nélkül. A fejlesztő visszakérdezhet a reprodukáláshoz; a tesztelő új adatot adhat. A tanult szabályt frissítsük a tesztesetben, hogy ugyanaz a vita ne ismétlődjön meg.

4. ÓRA · FELADATSOR

Szoftvertesztelés feladat

Olvassa el az alábbi e-mailt, és keress támpontokat arra vonatkozóan, hogy mik lehettek a probléma forrásai! Osztályozza különböző az e-mailben lévő problémákat!

  • személyi, pszichológiai és viselkedési problémák
  • tesztmenedzsmentet, a munkaköröket, illetve a terméket érintő más lehetséges problémák
  • van néhány olyan termékhiba, azonban funkcionális és technikai hibák nincsenek. Nem minden hiba funkcionális vagy technikai probléma, amivel tesztelőként találkozunk. Van néhány nem funkcionális probléma – különösen a használhatóság amik kényelmetlenül érinthetik a valós felhasználót, esetleg súlyosabb következménnyel járhatnak.

Szia!

Képzeld, ma majdnem pánikot okoztam a cégnél. Azt hittem, hogy találtam egy kritikus programhibát (showstopper) a kereskedelmi rendszerben, amit teszteltünk. A tesztmenedzser és a többiek elkezdték vizsgálni az adatbázisokat, először csak a szerveren, majd a klienseket kiszolgáló átjáróknál is. Ellenőrizték az éjszaka futtatott folyamatok frissítési naplóját és a kliensnek juttatott adatokat is. Aztán végül én bukkantam a problémára. A kliens futtatásánál rossz .bat fájlra klikkeltem, és így a klienst nem megfelelő környezetben indítottam el. Ekkorra már a tesztmenedzser majdnem odamondott nekem valamit, főleg amikor a srácok a fejlesztésről is elkezdtek ezzel foglalkozni, és ők ugye nagyon nem tolerálják, ha a tesztelők hibáznak. Csak az mentett meg, hogy én találtam meg a hibát és nem ők.

Így utólag érdekes hiba volt. Amikor bejelentkezel a szerver tesztelési környezeteibe, a vezérlőpanel mindig azt a környezetet mutatja, amihez kapcsolódsz. A mi esetünkben két tesztelési környezet van. A Systest14 vagy a Systest, és a tesztjeim a 15–ösben voltak beállítva. Hogy klienseket indítsuk, a 14-eshez vagy a 15-öshöz tartozó klienseket .bat fájljait kell futtatniuk. A két klienst indítottam el, ami kér csereforgalmi résztvevőnek felel meg, hogy majd kereskedést szimulálok köztük.

Úgy tűnik, hogy az első klienst a 15-ös környezetben indítottam el, szóval az még OK volt, de a másodiknál véletlenül elmozdult az egér, és az 14-es .bat indítottam, ami az Explorer fájllistáját pont mellette van. Egy fokkal súlyosbította a helyzetet, hogy a kliensek kezelőfelülete nem mutatja, hogy majd melyik környezetedben futtatod.

Először kicsit rosszul hülyén éreztem magamat, hogy ekkora felhajtást okoztam, és pazaroltam a többiek idejét és energiáját. De így visszagondolva, ha én, mint hozzáértő személy, egy ilyen hibát el tudok követni, akkor valami nincs rendben. A szervernél, ha felcsatlakozom egy tesztelési környezethez, akkor be kell írnom a környezet nevét, ami utána megjelenik a panelen. A kliensnél a kliens tesztkörnyezetének futtatása úgy történik, hogy egy listából kiválasztok egy .bat fájlt azok közül, teát ügyelnem kell arra, hogy a megfelelő fájlra klikkeljek. Sem kijelző, sem egyéb lehetőség nincs arra, hogy megbizonyosodjak arról, hogy a megfelelő klienskörnyezetben dolgozom.

Ezt most magas prioritású vagy kritikus hibaként fogom naplózni – a kliens nem jelzi ki a környezetet. Egy hétköznapi példával élve: megtörténhet, hogy a tényleges felhasználó, hogy a tesztelési rendszerhez kapcsolódik, miközben valójában az éles rendszerhez kapcsolódott és elrontja a kereskedést. Tudom, hogy ez egyszer már megtörtént a részvénykereskedelem rendszerében, amikor egy kereskedő véletlenül egy csomó teszttranzakciót pötyögött be az éles rendszerbe, amiből káosz lett.

Hogy tovább fűzzem a történet szálát, pár nappal később az egyik tesztelő talált valamit, ami szintén kritikus hibának tűnt. Ő és a tesztmenedzser három órán keresztül szenvedett a rendszerrel, míg megtalálták a „hibát”. Egy új szűrő került bevezetésre a kliens szoftverben, amely a földrajzi piac alapján szűrte a panelek kijelzőjére kerülő tranzakciókat. Fogalmuk sem volt arról, hogy alapértelmezett piacként a németországi volt beállítva, azt hitték, hogy a brit piacon vannak. Következésképpen első látásra úgy tűnt, mintha alapvető hibák lettek volna a hálózati tranzakciós összeköttetésben és az üzenetközvetítő rendszerben. Eltekintve attól, hogy a módosításról tájékoztatni kellett volna őket, hasonló problémáról van szó, mint amivel én szembesültem – a kliensrendszer nem jelzi ki, hogy melyik piacon kereskedünk.

Nah, megyek, vár egy szép új nap az irodában.

Minden jót!

Ugrás a teljes megoldásra ↓
A FELADATSOR TELJES MEGOLDÁSA · SZÖVEGESEN

40 1. fejezet A tesztelés alapjai

A FELADAT MEGOLDÁSA

Személyi, pszichológiai és viselkedési problémák, többek között:

  • A tesztelési team és a tesztmenedzser, valamint a tesztelők és a fejlesztők közti rossz viszony. Erre utal pl.: „Ekkorra már a tesztmenedzser majdnem odamondott nekem valamit, főleg, mikor a srácok a fejlesztésről is elkezdtek ezzel foglalkozni, és ők ugye nagyon nem tolerálják, ha a tesztelők hibáznak. Csak az mentett meg, hogy én találtam meg a hibát, és nem ők.”
  • A nyelvezet érzelmekkel fűtött – az adott körülmények között érthető, de nem alkalmas problémák jelentésére: „Képzeld, ma majdnem pánikot okoztam a cégnél. Azt hittem, hogy találtam egy kritikus programhibát (showstopper) a kereskedelmi rendszerben, amit teszteltünk.” „Hogy tovább fűzzem a történet szálát, pár nappal később az egyik tesztelő talált valamit, ami szintén kritikus hibának tűnt.”
  • A kezdeti önbizalomhiányt legyőzi a problémával való újbóli szembesülés – ha egy ember el tudta követni ezt a hibát, akkor mások is el fogják követni. „Először kicsit hülyén éreztem magam, hogy ekkora felhajtást okoztam, és pazaroltam a többiek idejét és energiáját. De így visszagondolva, ha én, mint hozzáértő személy egy ilyen hibát el tudok követni, akkor valami nincs rendben.”
  • Szarkazmus használata, ami talán érthető… „Na, megyek, vár egy szép új nap az irodában.”

A tesztmenedzsmentet, a munkaköröket, illetve a terméket érintő más lehetséges problémák:

  • Konfigurációmenedzsment és kiadási felügyelet: „Egy új szűrő került bevezetésre a kliens szoftverben, mely a földrajzi piac alapján szűrte a panelek kijelzőjére kerülő tranzakciókat.”
  • Konfigurációmenedzsment, kapcsolatok, kommunikáció: „Eltekintve attól, hogy a módosításról tájékoztatni kellett volna őket…”
  • A tesztmenedzser vajon tényleg tudja, hogy mi tartozik a munkakörébe? „Ő és a tesztmenedzser három órán keresztül szenvedett a rendszerrel, míg megtalálták a »hibát«” valamint „A tesztmenedzser és a többiek elkezdték vizsgálni az adatbázisokat”.

Termékhibák és használhatósági problémák

Van néhány termékhiba, azonban funkcionális és technikai hibák nincsenek. Nem minden probléma funkcionális vagy technikai probléma, amivel tesztelőként találkozunk. Van néhány nem funkcionális probléma – különösen a használhatóság – amik kényelmetlenül érinthetik a valós felhasználót, esetleg súlyosabb következményekkel járhatnak.

  • „Rossz .bat fájlra klikkeltem a kliens futtatásánál.”
  • „Egy hétköznapi példával élve: megtörténhet, hogy a tényleges felhasználó azt hiszi, hogy a tesztelési rendszerhez kapcsolódik, miközben valójában az éles rendszerhez kapcsolódott, és elrontja a kereskedést. Tudom, hogy ez egyszer már megtörtént (…), amikor egy kereskedő véletlenül egy csomó teszttranzakciót pötyögött be az éles rendszerbe, amiből káosz lett.”
  • „…hasonló a problémáról van szó, mint amivel én is szembesültem – a kliensrendszer nem jelzi ki, hogy melyik piacon kereskedünk.”
  • „Sem kijelző, sem egyéb lehetőség nincs arra, hogy megbizonyosodjak arról, hogy a megfelelő klienskörnyezetben dolgozom.” és „Egy fokkal súlyosbította a helyzetet, hogy a kliensek kezelőfelülete nem mutatja, hogy melyik környezetben futtatod.”
  • „Fogalmuk sem volt arról, hogy alapértelmezett piacként a németországi volt beállítva, azt hitték, hogy a brit piacon vannak.”

Erre a példára még visszatérünk az 5. fejezetben, ahol azzal foglalkozunk, hogyan kell írni egy jó incidensjelentést.

További gyakorlófeladatok

Előbb oldd meg a feladatot, majd nyisd meg a segítséget és a mintamegoldást.

1. Fogalmazd át

Alakítsd tárgyilagos hibajeggyé ezt az üzenetet: „A kölcsönzőt elrontottad, a visszaadás rossz!” A visszavett E42 eszköz kiadva státuszban marad.

Kérek egy tippet

Az elvárt és a tényleges állapot legyen külön, és add meg az újrajátszható lépést.

Mintamegoldás megtekintése

Cím: Visszavétel után E42 státusza kiadva marad. Előfeltétel: E42-t D11 kölcsönzi. Lépés: D11 visszaveszi/visszaadja E42-t, majd frissítjük az eszközlistát. Elvárt: E42 szabad, a kölcsönzés lezárult. Tényleges: a kölcsönzés lezárt, de E42 kiadva státuszú. Környezet és verzió mellékelendő.

2. Keresd a torzítást

A fejlesztő a saját funkcióját csak egy és két eszközre tesztelte, mert „háromnál biztosan jó”. Milyen torzítást látsz, és milyen három esetet javasolsz?

Kérek egy tippet

A feltételezést cáfoló és a szabály határán lévő esetekre is gondolj.

Mintamegoldás megtekintése

Megerősítési torzítás: a sikeresnek várt esetekre koncentrál. Javasolt a harmadik kölcsönzés megengedése, a negyedik elutasítása és egy már kiadott eszköz kölcsönzésének tiltása. Mindegyiknél ellenőrizzük a mentett állapotot is.

3. Szerepek megosztása

Egy négyfős csapatban fejlesztő, másik fejlesztő, tesztelő és kölcsönzési ügyintéző dolgozik. Rendelj mindegyikükhöz egy hasznos ellenőrzési feladatot.

Kérek egy tippet

A belső működés, az új szem, a követelmény és a valós munkafolyamat más-más nézőpont.

Mintamegoldás megtekintése

A funkció szerzője egységtesztet írhat a korlátra. A másik fejlesztő áttekinti a kódot és az integrációt. A tesztelő tervezett funkcionális és negatív eseteket futtat. Az ügyintéző végigjárja a tényleges kölcsönzés-visszavétel folyamatot és értékeli a felület érthetőségét.

4. Vitás követelmény

A specifikáció szerint „három eszköz kölcsönözhető”. Nem világos, hogy a harmadik még megengedett-e. Hogyan jársz el a hibajegy előtt és után?

Kérek egy tippet

Először tisztázzátok a szabály pontos jelentését az illetékessel.

Mintamegoldás megtekintése

Dokumentálom a két lehetséges értelmezést, és a követelmény gazdájával tisztázom, hogy legfeljebb három aktív eszköz-e a szabály. Ezután pontosítjuk az elvárást és a tesztesetet. Ha a rendszer a tisztázott szabályt sérti, reprodukálható hibajegyet írok; ha nem, a korábbi feltételezést javítom.

ELLENŐRIZD MAGAD

Melyik visszajelzés segíti legjobban a hiba javítását?

Amit érdemes megjegyezni

  • A visszajelzés a termék viselkedéséről és a követelményről szól, nem az emberek minősítéséről.
  • A független nézőpont hasznos, ha együttműködéssel és jó szakmai információval párosul.
  • A saját feltételezést cáfoló tesztek segítenek a megerősítési torzítás ellen.

Visszajelzés erről a leckéről

Mennyire volt hasznos? Az értékelést és a megjegyzést csak a tanár látja.

Értékelés, 1–5

Név és e-mail-cím megadása nem szükséges. Más tanulók értékelései és megjegyzései nem jelennek meg ezen az oldalon.