Menü Bezárás

Elegem van a hibákból!

Minél tovább vagyok a tesztelési szakmában, annál inkább hiszem benne, hogy a „hiba“ fogalma nem egyértelmû, haszontalan.Egy alkalmazás tartalmazhat kódolási hibát, ami tisztán ellentmond a specifikációban leírtaknak, és ezek alapján állíthatom, hogy amit találtam az biztosan egy hiba. A minap egy automatizált frissítés állt meg a folyamat közepén, és tette az alkalmazást használhatatlanná. Kétségtelenül hiányosság. Nézzünk meg még néhány konkrét esetet:

  • Rengeteg tesztet futtatunk talált hiba nélkül, de a kód ellenõrzése során azt tapasztaljuk, hogy a jelenlegi architektúra képtelen lesz a késõbbi változások kezelésére. A további változtatások nagyon kockázatosakká válnak. Hiányosságot találtunk? Mennyi hibát találtunk pontosan?
  • Azt látom, hogy az alkalmazás szakszerûen lett kódolva, de a specifikáció csapnivaló. Ez az alkalmazás hibás?
  • Az alkalmazás remekül lett megírva és a specifikáció is kifogástalan. A specifikációt író kolléga nagyszerû munkát végzett, de a követelmények rosszul lettek értelmezve. Hívhatom ezt az alkalmazás hibájának?
  • A fejlesztés a kiadás közelébe ért, de közben felfedezzük, hogy van már egy ilyen alkalmazás, amely tökéletesen így mûködik. Ez az alkalmazás hibás?
  • A felhasználók fele azt mondja, hogy az alkalmazás úgy mûködik, ahogy kell, de ocsmány és nehéz megtanulni a használatát, a másik fele azt mondja, a kinézet nem számít, ha egy ideig használod gyorsan és egyszerûen meg lehet benne oldani a feladatokat. Azonosítottam egy hibát?
  • A termék nem rögzíti a logokat. Ha lenne log fájl, akkor a tesztelés sokkal gyorsabb és hatékonyabb volna. Ha az alkalmazás rosszabbul tesztelhetõ, mint elvárt, nevezhetem hiányosságnak?
  • Azt vettem észre, hogy a pizza rendelõ alkalmazás ebédidõben nagyon belassul, amikor a legtöbben rendelnek. Arra következtetek, hogy a rendszer lassulása miatt rengeteg megrendelõt vesztünk, persze számszerûsíteni nem tudom. Ebben a pillanatban minden flottul mûködik. Ez hiányosság? Ez jelenleg nem hiányosság, de késõbb valamilyen varázsütésre hiányossággá fog válik?

Ráadásul mindezek mellett a „hiba“ áll rengeteg olyan használhatatlan ötlet középpontjában, mint hogy hogyan mérjük a szoftver vagy a tesztelés minõségét: hibaszám, hiba felderítési arány, hiba megoldási arány. De mi az a hiba? Ha használod a LinkedIn-t, ott olvashattál már régi beidegzõdéseket arról, hogy mi is a hiba pontosan. Azok az emberek, akik a hibákról beszélnek, az olyan dolgokat értik rajta, amelyek kétségkívül rosszul mûködnek a termékben. Az eddigi tapasztalataim szerint a dolgok nem ennyire egyértelmûek. Ha nem tiszta, hogy mi a hiba, vagy mi nem az, akkor igazából megszámolni sincs értelme.

Ezért mint tesztelõ sokkal jobban foglalkoztat a problémán való gondolkodás. A probléma az, hogy „mit érzékelünk ahhoz képest, amit akarunk“ vagy az, hogy „a nem elvárt mûködés megoldható, de valószínûleg sok energiába és nehézségbe ütközünk majd a megoldás során“. (Bõvebben írok errõl itt: http://www.developsense.com/blog/2012/04/problems-with-problems/.) A probléma nem egy olyan dolog, ami felismerhetõ a kódban. A probléma relatív. A probléma a felhasználó és a szoftver közötti kapcsolatból adódik. A probléma lehet, hogy hiba formájában jelentkezik, vagy valami ami veszélyezteti a termékünk értékét, vagy egy kérdés, vagy veszélyeztetni a tesztelés/projekt/üzlet értékét.

Mint tesztelõ, nem szoftvereket teszek tönkre. Egy viccel szoktam emlékeztetni magam az aktuális szerepkörömre Alan Jorgensontól, de az egyik kollégám, James Bach elõadásában: Nem teszem tönkre a szoftvert, már eleve rossz volt amikor megkaptam. Ahelyett, hogy a tönkretevéssel foglalkoznék, inkább azon gondolkodom, hogyan és hol romlott el. De ettõl sem érzem teljesen jól magam. Mindig azt veszem észre, hogy nem tudom azt mondani, hogy az alkalmazás rossz, inkább azt látom, hogy a kapcsolat az alkalmazás és a felhasználó között valahol felbomlott. Feltételezések, jóslatok segítségével azonosítom és megvilágítom a problémás kapcsolatokat, vagyis mi mint tesztelõk felismerjük a problémákat, tehát tesztelünk.

jóslatok nem tökéletesek és a tesztelõk nem bírók. Tõlem függ, mit jelzek hibának. Ahogy James mondja, „Ha azt mondom a feleségemnek, hogy van egy hibája, az nem fog jól elsülni, de ha azt mondom, hogy van valami, ami zavar, az egész más helyzet“. Vagy ahogy Cem Kaner mondta „Ha olyan szoftvert szállítasz, amiben általad ismert hiba van, akkor hibás szoftvert szállítasz, ami már egyéb jogszabályi kérdéseket is felvet.“ (példák itt: http://kaner.com/pdfs/defects4.pdf 
és itt: http://kaner.com/pdfs/asqkaner.pdf).

Másrészt ha kifejezetten hibát keresek, az túl közvetlen, túl személyes, és politikailag is rizikós a számomra. Ha az elõbb említett eseteket nézed, amelyekben a hibák megkérdõjelezhetõek, könnyebben és kevésbé ellentmondásosan lehet leírni a problémákat amelyek esetleg a termék minõségét és használhatóságát veszélyeztetik. Tehát így „kutatni a problémák után“ szélesebb körû felismerést és kisebb szubjektivitást eredményez. Ez azt jelenti, hogy fel kell adni az eddigi beidegzõdéseket, mert sokkal többre jutunk ha

  • több minõségre vonatkozó modellt használunk
  • rengeteg minõségi kritériumot veszünk figyelembe
  • és nem csak a funkcionális hiányosságokat, hanem minden olyan körülményt megvizsgálunk amely veszteséget, kárt, vagy bosszúságot okozhat

Ezen kívül a hiba-koncepció elvetése segít abban, hogy ezen túl ne a hibák számolására koncentráljunk. Tekintettel a „probléma“ nyitott és bizonytalan jellegére, sok ember számára azok megszámlálása is ostobán hangozhat, de legalább tudunk beszélni róluk. Ez egy jó kezdés lehetne a megoldásukra – mindezt azoknak az embereknek címeztem, akiknek számít rámutatni arra, hogy mi a különbség a tapasztalt és az elvárt mûködés között.Nos, ezért szeretem én jobban a problémák utáni kutatást, és ezek az én problémáim a hibákkal szemben.

Nos, ezért szeretem én jobban a problémák utáni kutatást, és ezek az én problémáim a hibákkal szemben.

Forrás: http://www.developsense.com/blog/2014/04/ive-had-it-with-defects/
Szerző: Michael Bolton

A szerző

Michael Bolton
12 éve foglalkozik szoftver- tesztelők oktatásával, öt kontinensen. Ő a társszerzője - James Bach mellett - a Rapid Software Testing című kiadványnak, amely bemutatja a bizonytalan körülmények és extrém határidők között végzett szakszerű szoftvertesztelés módszertanát.
Elérhetősége:
michael@developsense.com
http://www. developsense.com
Vissza