Hat dolog, ami rontja a teszteléssel kapcsolatos megbeszéléseket

A szoftver tesztelésével kapcsolatos beszélgetés nem könnyu. Nem természetes! A tesztelés “meta” tevékenység. Ez nem csak egy feladat, ez a feladat, amely új feladatokat generál (hibák megtalálásával, amelyeket meg kell határozni, vagy új kockázatokat kell megvizsgálni). Ez egy olyan feladat, amelyet soha nem lehet “befejezni”, de eredményül “kész”-t kell kapnunk.

A tesztelés körüli zavarok kevésbé hatékony beszélgetésekhez vezetnek, amelyek lényegtelen kérdésekre összpontosítanak, figyelmen kívül hagyva az igazán fontos dolgokat. Íme néhány olyan konkrét példa, amikor a tesztelési megbeszélések garantáltan sikertelenek:

Amikor az emberek azzal törődnek, hogy hány teszteset van, ahelyett, hogy azzal törődnének, valójában mit vizsgálnak

A vizsgálati esetek száma (például 500, 257, 39345) nem ad választ a “mennyi tesztet” kell csinálni kérdésére. A fejlesztők sem büszkék arra, hogy hány fájlt hoztak létre ma termékük fejlesztése során, hiszen mindenki tudja, hogy ostobaság számszerűsíteni a fájlokat, billentyűleütéseket vagy ilyesmit. Ugyanezen okok miatt ostobaság számolni a vizsgálati eseteket is. Ugyanaz a vizsgálati tevékenységet lehet bemutatni egy vagy egymillió vizsgálati esettel. Mi van akkor, ha egy tesztelő olyan szoftvert ír, amely automatikusan 100 000 variációt hoz létre egyetlen vizsgálatnál? Ez valóban 100 000 teszteset lesz, vagy egy nagy teszteset, vagy nem is lesz belőle vizsgálati eset? Ha a következő alkalommal, amikor valaki ad egy tesztszámot, akkor erre a helyes válasz az, hogy “ez egyáltalán nem mond nekem semmit.” Tegyünk fel egy kérdéseket a tesztek valódi tartalmáról: Mit fednek le? Milyen hibákat észlelnek? Milyen kockázatok indokolják meglétüket?

Amikor az emberek tárgyként beszélnek a tesztről, nem pedig eseményként

A teszt nem fizikai tárgy, bár a fizikai dolgok, mint például a dokumentáció, az adatok vagy a kód is része lehet a teszteknek. A teszt egy tevékenység, valami, amit csinálsz. Mikor a tesztelésről, mint tárgyról, nem pedig végrehajtásról beszélnek, akkor átsiklanak a teszt legfontosabb része, a tesztelő figyelme, motivációja, teljességre való törekvése és tesztelői jártassága felett. Két tesztelő nem hajtja végre „ugyanazt a tesztet” “ugyanolyan módon”. Technikailag nem adhatunk oda valaki másnak egy tesztesetet, anélkül, hogy valamilyen módon meg ne változtatná azt (mint ahogy, nincs hátvéd vagy baseball játékos sem, aki ugyanazt a játékot kétszer ugyanúgy játssza), bár ezek a változások nem feltétlenül számítanak.

Amikor az emberek nem tudják leírni saját tesztstratégiájukat

A tesztstratégia olyan ötletek készlete, amelyek irányítják a döntéseket, hogy milyen teszteket tervezzünk és milyen teszteket végezzünk el az adott helyzetben. A tesztstratégiát az egyes tesztekből álló cselekvések mögött álló érvelésnek is nevezhetjük. A tesztstratégia olyan kérdésekre ad választ, mint például “Miért érdemes ezeket a teszteket csinálni?”, “Miért nem csinálunk más teszteket helyettük?”, “Mit változtathatnánk, ha mélyebben akarnánk megvizsgálni?”, “Mit változtatnánk, ha gyorsabb tesztelést szeretnénk?”, “Miért ilyen módon tesztelünk?”. Helyes volna, ha ezek a kérdések nem csak a tesztelés után merülnének fel, hanem már a folyamat kezdetén. A tesztstratégia megtervezésének és megvitatásának képessége a szakmai tesztelés egyik legfontosabb eleme. Ellenkező esetben a tesztelés csak szokás és intuíció dolga lenne.

Amikor úgy beszélnek az automatizálásról, mintha az az emberek helyett tesztelne

Ha a fejlesztők a fejlesztésről úgy beszéltek volna, mint ahogy oly sokan beszélnek ma a tesztelésről, akkor azt mondanák, hogy a fordítóprogramjuk hozta létre a termékeiket, és az egész csak annyi, hogy a fordító működik. Azt mondanák, hogy a termék “automatikusan” jött létre, nem pedig azon személyek munkája által, akik keményen és célirányosan dolgoztak a kód megírásán. Így a menedzsment megszállottja lenne a “fejlesztés automatizálásának”, egyre jobb eszközöket szerezne be ahelyett, hogy kiváló fejlesztőket bérelne vagy képezne ki. A helyes az, ha ugyanúgy beszélünk a tesztelésről, mint a fejlesztésről.: ez valami, amit emberek csinálnak, nem pedig eszközök. Az eszközök segítenek, de nem végzik el maguktól a tesztelést. Nincs olyan, hogy automatizált teszt. A legtöbb eszköz képes működtetni a terméket, miközben a script speciális outputokat ellenőriz. Ez így tények „csekkolása” és nem valódi tesztelés. Az eszközök erre nagyon jók, de a tesztelés több, mint tényfeltárás, mert a tesztelőknek technikai megítélést és leleményességet kell alkalmazniuk az ellenőrzések létrehozása és értékelése céljából, valamint fenntartani és javítani azokat. A tesztelés tehát teljes (eszközökkel támogatott) emberi folyamat. Ha az “automatizált tesztekre” koncentrálnak, akkor általában elfeledkeznek a készségekről, ítélőképességről, problémamegoldásról, motivációról. Így magáról a tesztelés minőségének az ellenőrzéséről feledkeznek meg.

Amikor az emberek úgy beszélnek, mintha csak egyfajta tesztlefedettség lenne

Számos módon lefedheti a terméket teszteléskor. A lefedettség értékelésének minden módja eltérő, és saját dinamikája van. Senki sem állíthatja, hogy egyféle (pl. kódlefedettség) elegendő lesz a történethez. Például, ha olyan oldalt tesztelünk, amely keresési eredményeket ad meg egy lekérdezéshez, akkor a lekérdezés típusával lefedjük azt a funkciót, amelyet az aktuális lekérdezés (funkció lefedettség) képvisel, és az egyes elemek aktuális adatkészletével lefedjük az adatokat (adatlefedettség). Ha megváltoztatja a lekérdezést egy másik típusú keresésre, akkor új funkcionális lefedettséget kap. Ha módosítja az adatkészletet, új adatlefedettséget kap. Mindkét esetben az új lefedettséggel új hibát találhat. A funkciók kölcsönhatásba lépnek az adatokkal; ezért a jó tesztelés magában foglalja nemcsak az egyik vagy másik, de különböző kombinációkban mindkettőt együttesen.

Amikor az emberek úgy beszélnek, mintha a tesztelés egy statikus feladat lenne, amely könnyen formalizálható

A tesztelés tanulási feladat; alapvetően a tanulásról szól. Ha azt mondjuk, hogy tesztel, de közben nem tanul semmit, akkor valójában egyáltalán nem tesztel. Bármely valódi tanulás természete az, hogy nem tudhatja, mit fog felfedezni legközelebb –  ez egy felderítés. Ugyanígy vagyunk sok dologgal, amit az életben végzünk, az autó vezetéstől a cégvezetésig. Valóban vannak olyan dolgok, amelyeket előre megjósolhatunk, és olyan mintákat is alkalmazhatunk, amelyek megszervezik akcióinkat, de ezek közül egyik sem azt jelenti, hogy alvajáróként kell követi az előre megírt szkripteket. A tesztelés folyamatosan megkérdőjelezi, mit csinálunk és mit látunk. A szakmai tesztelés folyamata nem csak annyi, hogy vannak a tervezési tesztesetek majd azokat követik a vizsgálati esetek. A felelős tesztelő nem így működik. A felelős tesztelés folyamatosan felülvizsgál és kísérletezik. Ez magában foglalhatja olyan eljárások és automatizmusok tervezését is, amelyek szisztematikusan gyűjtenek adatokat a termékről, de mindezt azzal a hozzáállással tegyük, hogy közben folyamatosan reagálunk az előttünk kialakuló helyzetre. Sokszor eltérünk az általunk létrehozott eljárásoktól, mivel a szoftver bonyolult és meglepő; a szervezeti igények is változnak; és közben jobb tesztelési módszereket ismerünk meg.

A fentieken és más hibákon keresztül, az emberek továbbra is abban a meggyőződésben élnek, hogy a jó tesztelés kulcsa az egyre több “teszteset” megírása (függetlenül attól, hogy ezek mit csinálnak); automatizálása (függetlenül attól, hogy mit nem lehet automatizálni); átadása egyik gyakorlatlan tesztelőnek a másik után; miközben fetisizálják magukat a fájlokat és a szkripteket; ehelyett inkább arra figyelhetnének, mit tesznek velük a tesztelők nap mint nap.

Forrás: http://www.satisfice.com/blog/archives/1728 
Szerző: James Bach