Tesztelés a Gyakorlatban - A szakértő tesztelők lapja
Hogyan mérjük a tesztelők hatékonyságát?

Hogyan mérjük a tesztelők hatékonyságát?

Az biztos, hogy képletekben nincs hiány ezen a szakterületen sem. De biztosan mindent képletekkel, számokkal és mutatókkal kell kifejeznünk? Milyen következtetéseket tudunk levonni ezekből a mérésekből? Amikor túlságosan belefeledkezünk a mátrixokba, számokba és mérésekbe akkor kell az érem másik oldalán az embert meglátnunk. Az emberekkel való munka türelmet igényel. Értsd meg őket is, ne csak a számokat!

Erre a kérdésre azzal a kérdéssel válaszolok, hogy „Miért akarod mérni a tesztelők hatékonyságát a csapatodban?”

Meg akarom érteni, hogy mi a kérdés mögötti motiváció. Miért fontos az személyek hatékonyságának mérése a vezetők számára? (mert ez egy tipi-kus vezetőktől jövő kérdés)

Természetesen fontos tudni, hogyan teljesít valaki a munkájában, hogyan látja el a feladatait, de emögött a kérdés mögött általában nem ez áll. A kérdés leginkább arra szokott vonatkozni, hogyan tudom fejleszteni trénin-gekkel az embereket, vagy csak szimplán anyagi szempontok miatt érde-kes.

Ne érts félre, szeretem a méréseket. Minden apró dolgot mérünk mi is, amit csak tudunk, de óvatosan bánunk a következtetésekkel, amiket a mérések alapján vonunk le.

A vezetők (különösen a tesztvezetők) tipikus válasza szokott lenni a fenti kérdésre, hogy próbálják igazolni a tesztelők hozzáadott értékét a projekt-hez és/vagy a csapathoz.

Gyakran csak két dolgot próbálnak mérni. (Habár sok minden mást is mér-hetnek/mérhetnének, de általában abba a csapdába esnek, hogy egy-egy kiragadott szám alapján hozzák meg a döntéseiket.)

Először is, vajon Teszter Feri és Teszter Fanni ugyanolyan hozzáadott ér-téket jelentenek a projekt számára? Ki tudjuk őket cserélni, ha a projekt azt kívánja? Jobb az egyik, mint a másik?

Másodszor, egyáltalán Teszter Feri vagy Teszter Fanni adnak-e hozzá bármit is a projekthez? (mi történne, ha levennénk őket a preojektről?)

Ez általában agyatlan mérőszámok kitalálásával végződik, mint mennyi tesztesetet futtatott, mennyi hibát talált. Ezzel mérik a tesztelők hatékony-ságát.

Amilyen őrültség, annyira általános, hogy ilyen egyszerű mátrixok segítsé-gével hoznak döntéseket az egyéneken.

Tudom, hogy miért. Tudok egy pofon egyszerű indokot, miért uralkodik ez a gyakorlatban. Mert az emberek kezelése nagyon nehéz feladat.

Az embereket külön-külön kezelni és megérteni, valamint feltárni, hogy mi a projekthez hozzáadott értékük, időbe telik és tipikusan a szoftverfejlesztés-ben nem mérhető egyszerű számokkal. (annak ellenére, hogy néhány me-nedzser mégis így gondolja)

Az emberekkel való munka nagy türelmet igényel. Minden a kapcsolatokról szól. A visszajelzéseket elfogadni magadról, néha fájdalmas.

Ezért a menedzserek a mátrixokban keresik a munkatársak hatékonyságá-nak a pontos értékét. Egy számot értékelni sokkal egyszerűbb, mint sok-sok számot értékelni. Vagy akár több csapattag véleményét értékelni a saját tapasztalatok és a többiek véleménye alapján. A leggyakoribb, amit a tesztmenedzserektől hallok, a hiba felderítési szám.


1. ábra A csapat vagy az egyén hatékonysága

Önmagában nagyon érdekes ez a mérőszám – érdekes, úgy mint „mond ez bármit is a folyamat minőségéről és a tesztelésről?”

Különösképpen érdekes, amikor ezzel kezdjük el mérni ténylegesen a mun-katársunk hatékonyságát. Vajon egy tesztelőnek mekkora kontrollja van azon, hogy egy szoftverben mennyi hiba van? És vajon meg tudja határoz-ni, hogy kik fogják majd ezeket a hibákat kijavítani?

Egyszer kaptam egy levelet egy hölgytől egy masszív kalkulációra vonatko-zóan, ahogyan ő méri a kollégáit. A kalkuláció a teszteset futtatások és a megtalált hibák számán alapult. A periódus, amikor a hibát találta, a hiba kijavításának a sebessége és az elkészítet tesztesetek mennyisége és ezen adatok kombinációja. Mondhatni bizarr! Nagyon bonyolult volt a kalku-láció és tele volt hibalehetőségekkel, félreértelmezési lehetőségekkel, pon-tatlanságokkal. Milyen meglepő volna, ha a munkatársak jövője, előrehala-dása egy ilyen rossz kalkuláción alapulna, de mégis vannak vállalatok, ahol ilyen mátrixokra támaszkodnak.

Van egy történet egy tesztelőről (és a jövőjéről) aki szintén hibaszámok és tesztesetek futtatásának a száma alapján volt kontrollálva. Ezek a mérő-számok végül egy olyan belső rendszerbe kerültek, ami önmagában sem volt igazán tesztelve. Így kétséges, hogy a rendszer egyáltalán kielégíti-e az elvárt üzleti célokat.

  • És mi a helyzet a csapat eredményességével?
  • Valamint mi van a szoftver hozzáadott értékével?
  • Mi a helyzet az árbevétellel?
  • Mi van a csapat felkészültségével, amikor egy problémát kell megol-daniuk?
  • Mi van a munkamenettel, a feladatokkal?
  • Mi van az egyéniséggel, aki fejlődni és növekedni akar?
  • Mi van az érzésekkel, a munkahelyi hangulattal az ügyfelektől érkező visszajelzésekkel?
  • Az emóciókkal a munkatársak között?

Ezeket nagyon nehéz mérni, és magukban nem is adnak semmire sem vá-laszt. Az összeset együtt vizsgálva kaphatunk korrekt eredményt, de mint mondtam, ez nagyon nehéz.

Tehát így állunk.

Most mutatok egy kalkulációt, ami minden kalkuláció alapja. Egy kalkuláci-ót, amiből az összes többi csapat vagy egyéni hatékonysági kalkuláció kiin-dul.

Higgy nekem – használd ezt és kapni fogsz egy számot.

Ez a szám lesz a megfelelő szám. A legfontosabb szám az életedben. Az egyetlen szám, amire szükséged van. A legösszetettebb szám, ami csak létezik.

Képhez: A csapat vagy az egyén hatékonysága = (1 sprintben megtalált hibák száma * A kódban lévő összes hiba száma / A fejlesztő csapat életko-rának összege * A tollak darabszáma egy 24-es csomagban)

Ezt még kiegészítésként:
KÉRLEK ne használd ezt arra, hogy döntést hozz valaki karrierjén, vagy jövőjén ez alapján.

Inkább csináld a dolgod helyette, építsd a kapcsolatokat, értsd meg az em-bereket. Kezeld az embereket is, ne csak a számokat!

Te már kiszámoltad a számod? Írd le magadnak valahová!

Szerző:
Rob Lambert

<< Vissza