Menü Bezárás

„Manuális” és „automata” tesztelés

A kategóriák, mint „manuális” és „automata” tesztelés (és a még kevésbé jelentősebb „manuális tesztelő” és „automata tesztelő”) vitathatóan jelentéktelenek, de valószínűleg túlélik a szavatossági idejüket.

Kidobhatnánk már az egészet a szemétbe végre? Köszönöm!

Itt egy hosszú és figyelemre méltó példabeszéd Patrick Smith pilótától, aki éveken át próbált megvilágítani egy hasonló kérdést szakemberek véleménye (és gondolata) alapján a „manuális” és „automata” kereskedelmi repülésről.

Nem beszélhetünk manuális tesztelésről, amikor a szoftverekről van szó.

A megbízható otthoni szótáram szerint a manuális „kézi megvalósulást” jelent. A munka kézzel lett elvégezve, melynek ellentéte az automatikus, számítógéppel támogatott. Az biztos, hogy néha használjuk a kezünket a gombok lenyomásához a billentyűzeten, de azt gondolni, hogy ezért ez „manuális tesztelés” olyan, mintha „manuális vezetésnek” hívnánk a kormánykerék kézzel forgatását. Nem azt mondjuk, hogy Itzhak Perlman a kezeit használva „manuális zenész”, még akkor sem ha pont a kezei használatának van az egyik legfontosabb szerepe a zenéjében, ugyanúgy mint a mi kezeinknek a tesztelésben. Amikor egy ilyen összetett értékes feladatról beszélünk, akkor az agy van a középpontban. Az agy végzi a munkát.

Lehet, hogy automatizálunk egy feladatot, vagy néhány funkciót egy szoftveren és automatikusan összehasonlítjuk a kapott eredményeket egy másik szoftverrel vagy folyamattal. Ezt inkább ellenőrzésnek nevezném (mint McCracken, 1957-ben és Alan Turing). De bármit is nevezünk automata folyamatnak, az biztosan unalmas rész. Jó tudni, hogy a számítógép dolgozik, precízen ellenőriz és sokmillió ellenőrzés megy végbe a másodperc ezredrésze alatt, de a kockázat analízis, az ellenőrzés megtervezése, az ellenőrzések programozása, választani a lehetőségekből, hogy mit és hogyan csinálunk, az a kritikus az eredmények szempontjából. Ezek azok a részek, amelyek igazán számítanak, amely részek éppenséggel a tesztelés részei.

És pontosan ezek azok a részek, amelyek nem automaták. A számítógépek bitekkel operálnak, nem végzik el a tesztelést. Az automatikus ellenőrzések felgyorsítják a munkát és kiterjesztik a kapacitásunkat, hogy olyan részein dolgozzunk a tesztelésnek, amelyhez az agyunkra van szükség. A szerkezet lényegtelen, ne engedjük magunkat elkápráztatni. Helyette irányítsuk a figyelmünket arra, hogyan tudjuk fejleszteni az eszközök használatával kapcsolatos képességeinket, amely eszközök jobban elősegítik az eredményességünket.

Ellenkező esetben olyan ez, mintha egy 17 éves suhancnak odaadnánk egy Ferrari kulcsát… Borítékolhatjuk, hogy nem lesz jó vége.

Az emberek általában izgatottak, amikor fejlesztenek vagy összetalálkoznak valamivel, amely bármi módon kiterjeszti a képességeiket. Marshall McLuhan a médiát használta, hogy definiáljon eszközöket és technológiákat – bármit, amit egy humán használhat, hogy eredményesebb legyen – ami mintegy kiterjesztése az embernek, minden olyan, ami emel, kibővít, lehetőséget ad, vagy felgyorsítja a munkamenetet. Hangsúlyozta, hogy a média agnosztikus a képességeinket és a céljainkat illetően. Az eszközök nemcsak felgyorsítják a munkát, hanem meg is erősítenek a hitünkben. Az eszköz a tesztelés természetét is befolyásolja. Az eszközök mesés tesztelési eredmények elérésében támogatnak. Ellenben néhány tesztelési feladat felgyorsításakor az eszközök rossz irányba is elvihetnek minket. Adott esetben rosszabb eredményt hozhat az eszközzel való tesztelés, mint az eszköz nélküli.

Ahogy Cem Kaner nagyszerűen mondja: Amikor tesztelünk, akkor nem arról beszélünk, amit a kezünkkel csinálunk, hanem arról, amit az agyunkkal. Emellett arra is rámutat többek között, hogy igen ritka, amikor nem használunk eszközöket a manuális teszteléshez. Mint a felülvizsgálatnál – és most nem egy termékről, vagy szoftverről beszélünk – követelményeket és forráskódokat keresünk a képernyőn a billentyűzet és az egér segítségével. A számítógépet arra használjuk, hogy segítsen megtalálni és megváltoztatni az információkat, hogy kapcsolatba léphessünk a kollégáinkkal, hogy eszmét cserélhessünk, hogy megoszthassunk információt. Ez egy manuális folyamat?

Jobban szeretem okosságnak nevezni (vagy ahogy barátom Pradeep Soundararajan mondja a „brain” és „manual” szavakból alkotott „brainual”) az olyan feladatokat, amelyeket egy gép nem tud elvégezni és nem támogatja eszköz. Ha ezt manuális tesztelésnek nevezzük, akkor hogy hívjuk azt, amikor automata ellenőrzéseket készítünk? Gondoljuk csak el! Nevezzük írásnak és ne gépelésnek? A makrókon keresztül a számítógép ténylegesen gépel és ezzel időt spórol nekünk, lehetőséget az írásra. Látszik a különbség?

Sok évvel ezelőtt Excelt használtam egy olyan funkcionalitás megvalósítására egy banki applikációnál, amely azonosította, hogy melyik főkönyvi számlán kell jóváírni, vagy terhelni. Ennek az alkalmazásnak az elkészítése (az analízis és a programozás) három hetemet vette igénybe. Ez alatt a munka alatt rengeteget tanultam a rendszerről, a tesztekről, a feltárt problémákról, visszajelzésekről. Rengeteg hibát is találtam. Néhány esetben az általam készített rendszer is segített a hibák feltárásában, tesztelésben. Automata vagy manuális tesztelést végeztem?

Egy másik esetben egy pénzügyi területen dolgozó cégnél a feladat része volt, hogy a funkcionális és integrációs ellenőrzésekre egy táblát kellett létrehozni. A FITnesse eszköz használatával tudtam a funkciókat kiválasztani, az adatokat rendszerezni és ellenőrzéseket elvégezni.

Kockázatokat diagnosztizáltam, ellenőrzéseket készítettem a kockázatok ellenőrzéséhez. Ezeket az ellenőrzéseket manuálisan vettem fel a billentyűzeten gépelve. Az eszköz ezeket az ellenőrzéseket hajtotta végre, bár én manuálisan indítottam minden esetben. A szememmel ellenőriztem az eredményeket, de az eszköz abban segített, hogy a nem várt eredményeket könnyen felismerjem. Ezek alapján gyakran újragondoltam a feltevéseimet, mely ellenőrzések eredményeivel kell foglalkoznom és melyekkel nem. Amikor felfedeztem egy hibát a lefedettségben, akkor egy újabb ellenőrzést vettem fel manuálisan. Automata tesztelést csináltam?
Miért ilyen jelentős kérdés ez nekem? Két nagyon fontos szempont miatt, amelyek kiegészítik egymást.

Amikor „automata tesztelés”-ről beszélünk, akkor az általunk végzett tesztelést szűkítjük le automatikus ellenőrzésre és a tesztelési erőforrásainkat az automata tesztek fejlesztésére és futtatására fordítjuk. Az ellenőrzés nem ördögtől való. A tesztelés jó és fontos dolog, de sokkal több aspektusa van a szoftver minőségében, mint amennyit az ellenőrzések eredményeképpen megkapunk.

Van tapasztalatom abban, hogy mennyire elbűvölő egy végletekig ellenőrzött átfogó és mély automata ellenőrzést végezni, ami maga után vonta, hogy több fontos problémát figyelmen kívül hagytam (köszönet a tesztelő kollégáimnak, akik észrevették, mielőtt az ügyfél tudomást szerzett volna az egészről).

Egy termék minőségi analízise nem csak a bitekről szól. Arról szól, hogy történeteket kell kreálni. A minőségi analízist segíthetik az eszközök, amely most a második fontos szemponthoz vezet minket.

A manuális tesztelés legtöbbször a felfedező típusú manuális tesztelést jelenti.

Ehhez nincsenek eszközök, az eszközök nem képesek felfedező elgondolásban működni. Ez a különbség a felfedezés és az eszközök között. A felfedező típusú tesztelés nem egy eszköztelen folyamat. Amikor a manuális tesztelésre gondolunk, akkor fennáll a veszélye, hogy alulterveztük az eszközök szerepét a termékkel való kapcsolatunkban és a tesztelési erőforrásokban.

Ennek következtében előfordulhat, hogy figyelmen kívül hagyunk számtalan olyan automatizálást, mely segítséget nyújthat, felgyorsíthat, lehetővé tehet mindenféle tesztelési feladatot: adatok összegyűjtése, beállítások, újrakonfigurálás, installálás, loggolás, riportolás, az eredmények vizuális megjelenítése, adatok generálása, véletlenszerű bemenő adatok, ismétlődő feladatok, amelyek nem voltak ellenőrizve, verziók összehasonlítása,… És ez csak a jéghegy csúcsa.

Az a véleményem, hogy a folyamatos keresés, hogy mely eszközök segíthetnek és ezek tudás nélküli használata veszéllyel van a minőségre.

Összegezve a „manuális” és „automata” tesztelés egy hamis kettősség. Olyan, mint a manuális statisztikai kimutatás és automata statisztikai kimutatás, vagy manuális és automata könyvszerkesztés.

Meggyőződésem, hogy sok ember az automata és manuális megközelítésen a bemeneti mechanizmusokat érti. Az emberek az automata tesztelést a manuális tesztelés ellentéteként használják, de úgy, mint tesztelés, nem létezik szimplán csak automata és csak manuális. Kivétel az a típus, amelyet ellenőrzésnek hívunk, amelyhez szignifikáns tesztelési tudás szükséges, hogy megtervezzük, megvalósítsuk, használjuk és analizáljuk.

Az ellenőrzés lehet automatikus – egy számítógép által végezve – de a tesztelés nem automatikus vagy manuális. Aki a tesztelést végzi, ő sem automata vagy manuális tesztelő. Az eszközök sokféle módon segíthetik a tesztelést, de el is torzíthatják azt, ezért kell gyakorolni, fejleszteni a tudásunkat és a megfelelő módon használni azokat.

Ha azt gondolják, hogy ez az egész egy humbug, akkor fogadják meg James Bach kollégám tanácsait:

Ne mondd azt, hogy a fordítás és linkelés automata programozás, és azt se mondd, hogy a programkód írása manuális programozás!

Forrás: http://www.developsense.com/blog/2013/02/manual-and-automated-testing/

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