Menü Bezárás

NYILVÁNOS BEJELENTÉS A FELFEDEZŐ TÍPUSÚ TESZTELÉSRŐL

Ezt az üzenetet kaptam nemrég Oliver Vilsontól:

Oliver

V.: Szia James, éppen most beszéltem Helénával. Felhívta a figyelmemet egy dologra… Nem emlékszem, hogy volt-e ilyen blog bejegyzés vagy RST. Az egyik tesztvezető egy cégtől mesélte, hogy problémáik vannak a tesztelőkkel. Néhány tesztelő úgy gondolja, hogy nem kell teszttervet készítenie a tananyagaid alapján.James Bach: Részletesebben?

Oliver V.: Nyers összegzés a tesztvezetőtől: „Az ET (Exploratory Testing) úgy tűnik inkább azt jelenti „elnézést a silány tesztelésért”. Az emberek nem tudják elmondani, mit csináltak, és hogy miért. Amikor a teszttervet kérem tőlük, vagy magyarázatot a tesztterv hiányára, mindig az a válasz, hogy „…de Bach azt mondja, hogy…”

Időről időre azt hallom, hogy a tesztelők tőlem idéznek, amikor kifogást keresnek a rossz minőségű munkáikra. Ezért gondoltam, hogy egy nyilvános bejelentés feloldja ezt a kényes kérdést.

Figyelem tesztelők és tesztvezetők!

Ha egy tesztelő az én tananyagaimra hivatkozik a silány minőségű munkája védelmében, azt kérem, írják meg nekem az e-mail címemre: james@satisfice.com, vagy Skype-on, Segítek ennek a badarságnak a leállításában.

Én szakképzett tesztelőket tanítok, akik elhivatottak a kiváló minőségű munka elvégzésében. Ez a folyamat szükségszerűen felfedező jellegű. És feltétlenül lesz pár előre megírt eleme – részben a gondolkodásmód tekintetében, részben pedig a kiváló szellemi munka követelményei miatt. 
Nem tanítok kifogásokat és maradiságot. Soha nem mondtam a tesztelőknek, hogy visszautasíthatja a munkát valami képtelenségre hivatkozva. A tesztelés érthetően való elmagyarázása a profizmus felé vezető lépések egyike.

Az emberek miért vannak mégis összezavarodva?

Feltaláltam újra a szoftvertesztelést magamnak az első alapelvtől kezdve. Tehát egy teljesen eltérő feltételrendszert tanítok. Ez elengedhetetlen, mert az általános tesztelési elgondolások nagyon idióták. A tanításaim azonnal zűrzavart tudnak okozni, amikor a szövegkörnyezetből kiemelve valami idiótasággal keverednek. Gondoljuk csak meg, hogy a „Nem készítek részletes teszttervet.” kijelentés teljesen hétköznapi és potenciálisan megalapozott dolog egy RST-ben (Rapid Software Testing). Ez egy állítás a dolgok világossá tételére egy dokumentumban, nem pediglen a tervezés hiányosságára vonatkozó nyilatkozat.Néhány példa arra, hogyan értelmezik félre a tanításaimat:

A Rapid Software Testing (RST) metodológiája nem egyenlő a felfedező típusú teszteléssel (ET). Az ET nagyon egyszerű. Mindenki képes az ET-re, mint ahogy bárki képes egy festményt is megvizsgálni. De nagy különbség van egy szakértői festményértékelés és egy kisiskolás fáradt pillantásai között. Az RST egy metodológia a tesztelés hogyanjára (beleértve az előre leírt és a felfedező tesztelést is). Tehát valamit rosszul csinálni a felfedező tesztelésben, az nem az én metodológiám.

Az RST-ben a tesztterv nem egy dokumentum, hanem egy ötletkészlet. Ezért mondom azt, hogy nincs szükséged terv-sablonra vagy bármilyen leírt tervre a jó tesztelési eredmény elérése érdekében. Gyakran tárolom ezeket az ötletkészleteket különböző módon, éppen melyik használ a legjobban. Tehát a tesztelési terv hiánya (teszt ötletkészletek) éretlen és alkalmatlan tesztelési folyamatot jelent, de a tesztelési terv dokumentált formája nem szükségszerűen probléma.

Az RST-ben a teszt nem egy dokumentum, hanem egy teljesítmény. Tehát a tesztelés dokumentáltságának a hiánya nem feltétlenül probléma, de az alacsony minőségű tesztelés (ami tény a szakképzett tesztelők tapasztalataira alapozva) probléma, ugyanúgy, ahogy egy rossz ácsmunka, vagy egy orvosi szolgáltatás.

Az RST-ben nincsenek sablonok a riportoláshoz, de a riportolás szükségszerű. A riportolási képességek is szükségesek, ahogyan a felelősségek megállapítása és a hitelesség is. Tehát ha valakit megkérdeznek, hogy magyarázza meg mit csinált, és ő elutasítja ezt, akkor biztosan nem RST-t használ. Az nem is igazi tesztelő. (Habár csak azért, hogy valakinek elmagyarázzuk, hogy egy fontos része a tesztelésnek nem jelent dokumentum kötegeket vagy mátrixokat a vezetőség részére, vannak mégis olyan esetek, hogy a vezetők a dokumentumokhoz ragaszkodnak ezzel mérve a tesztelés hatékonyságát. Gyanítom a vezető aki panaszkodik a tesztelő dokumentálási hajlandóságára, vagy a magyarázatára valójában csak megszállottja egy sajátos dokumentálási formának és nem hajlandó elfogadni más életképes megoldást.)

Az RST-ben azt mondjuk, a tesztelés nem lehet automatikus és ezek az eszközök zavart is okoznak. Ez nem azt jelenti, hogy az eszközök ellen vagyok. Nem, én a rossz minőségű tesztelés ellen vagyok. Sajnos nagyon sok eszköz, mint a csillagászati árú HP/Mercury eszköz legtöbbször arra szolgál, hogy automatikusan ellenőrizzen könnyű állításokat, pedig ez megspórolható volna magas minőségű teszteléssel. Igen, az eszközök és a technológiai tapasztalatok nagyon fontos szerepet játszanak a tesztelésben. Az nem automata tesztelés amikor eszközöket használunk, mert a tesztelés mindaz amit a tesztelő csinál és nem az, amit az eszköz. Tehát az a tesztelő, aki nem tanul és nem használ eszközöket, általában nem is tekinthető RST tesztelőnek.

Az RST-ben különbséget teszünk ellenőrzés és tesztelés között. Ez segít abban, hogy felismerjük a mélyen és jól átgondolt teszt folyamatokat, és az (egyedül az ellenőrzésen alapuló) átgondolatlan, felszínes folyamatokat. Amikor a „csak ellenőrzésen alapuló” teszt stratégiát kritizáljuk, az emberek zavarba jönnek, hogy az ellenőrzés fontosságát, vagy a tesztelés hiányát kritizáljuk. Tehát az a tesztelő, aki nem készít és futtat ellenőrzéseket, az egyáltalán nem RST-t használ.

Az RST-ben tiltjuk a tudományosan megalapozatlan, sértő kísérleteket, hogy mérőszámok segítségével kontrollálják a tesztelési folyamatot. Amikor az emberek harcolni és felszólalni látnak minket a tesztesetek megszámlálhatóságát illetően, azt feltételezik, hogy a mérhetőség alapjait kérdőjelezzük meg. Ahelyett hogy a vizsgálat-alapú mérést támogatnánk (amely inkább kérdéseket inspirál, mint döntéseket diktál), inkább a megfigyelések, érvelések és a szociális szakértelem további fejlesztését támogatjuk, amelyek egyelőre a további fejlődés gátjai. Tehát az a tesztelő aki nem használ méréseket, nem használ RST-t sem.

Az emberek hallanak a felfedező tesztelés szabadságáról és ezt összekeverik a felelősségvállalás hiányával, de ez butaság. Vezetés közben áthajthatnál gyalogosokon, nekimehetnél a házaknak, de mégsem teszed, mert felelősséggel tartozol és még törvényellenes is. A szabadság ebben az esetben nem azt jelenti, hogy jogom van bármit csinálni. Tehát az aki a felfedező tesztelésben nem tudja, vagy nem fogja a tesztelést szakszerűen kezelni, az inkompetens vagy beszámíthatatlan.■

Forrás: http://www.satisfice.com/blog/archives/924

Szerző: James Bach

A szerző

James Bach
Szeretem a programozást, ezért is kezdtem programozóként a karrieremet. De megláttam a hiányosságokat a szoftverminőség-biztosításában amely sokkal vonzóbb volt számomra, mint maguk a szoftverek, alkalmazások. Ellenállhatatlan számomra a következő kérdés: „Honnan tudom, hogy jó minőségű a munkám?” Csakugyan, honnan tudom, hogy valami jó? Mit jelent a jó? Ezért tértem át a szoftverminőség-biztosítás oldalára 1987-ben. Manapság különböző csapatoknak és egyéneknek segítek megtervezni a minőségi folyamatokat, tesztelési módszereket, és próbálom átadni a kockázatok kezelésének technikáit. Emellett kockázatelemzéssel, teszttervezéssel és számítógéppel támogatott tesztelés tervezéssel, kialakítással foglalkozom. Tapasztalatimat leginkább a szilikon-völgyi, piac-vezérelt szoftvercégektől - mint Apple Computer, Borland - származnak. A technikák amiket gyűjtöttem és továbbfejlesztettem az alábbi körülmények között voltak használva: sűrített ütemterv, gyakori változtatási kérelmek, moduláris- alapok és szegényes specifikáció.
James blogjában számos érdekes cikket találhatsz. http://www.satisfice. com/blog/
Vissza