Az igények ura: a szoftvertesztelő

Rend – Káosz – Rend

Réges-régen, egy messzi-messzi galaxisban, a Föld nevű bolygón. 1936-ban Konrad Zuse megalkotta az első programozható elektromechanikus számológépet, a Z1-et, aztán 1939-ben a Z2-t. Ezután ezeket továbbfejlesztve 1941-ben Z3 néven megalkotta az első szabadon programozható, teljesen programvezérelt számítógépet. Akik ezekben az időkben az első számítógépekre képesek voltak programokat készíteni, mérnökök voltak. A mérnökök maguk végezték a tervezést, a programozást, a program futtatását, a program futás kiértékelését, a hibakeresést… A mérnökök a „számítógépezés” polihisztorai és egyeduralkodói voltak. Ők tartottak rendet a galaxisban, a programok között.
Az egyre kisebb, egyre gyorsabb, egyre komplexebb számítógépek elhozták a „káoszt”. A mérnökök kevesen voltak és kicsúszott a kezükből az irányítás. Új szakmák születtek meg a káoszból. A mérnöki munka egy-egy területére specializálódott szakmai területek jöttek létre. Például:

  • Lettek olyan szakmák, amik a mérnöki tervezés részfeladatait vették át. Például üzleti elemző (Business Analyst), rendszerszervező (Systems Analyst) vagy architect.
  • A fejlesztők, akik lyukkártyák tervezése, készítése, futtatása helyett a gépbe bepötyögött utasítások segítségével készítik el a programokat.
  • A rendszergazdák, akik a fejlesztéshez biztosítják a környezetet
  • Szoftvertesztelők, akik a kész terméket vizsgálják meg, abból a szempontból, hogy megfelel-e az ügyféligényeknek.

A szakmák átvették a mérnöki munkák összes részfeladatát, így jól megválasztott szakemberek csoportja képes úgy működni, mint anno a mérnökök. A káosz nem szűnt meg teljesen, de ez a káosz már egy rendezett káosz. Shakespeare is megmondta: „Őrült beszéd, őrült beszéd: de van benne rendszer.” (Shakespeare: Hamlet, dán királyfi. II. szín, 2. jelenet. Ford. Arany János.
URL: Hamlet, dán királyfi Hamlet [2016.02.18.])
A komplexebb számítógépek komplexebb működtetést igényeltek, ezért a szakmai területek folyamatokat, módszereket, technikákat, eszközöket fejlesztettek a saját munkaterületük hatékonyabbá tételére. Így lett a fejlesztő, az architect, a rendszergazda és cikkünk főszereplője a tesztelő is különálló szakma képviselője. Ahhoz, hogy szoftvertermékek szülessenek, egyik szakmai terület sem hagyható ki. Együtt képesek csak uralni a káoszt.

A szoftvertesztelő

Az előző fejezetben láttuk, hogy a szoftvertesztelő része a fejlesztésnek, most kicsit vizsgáljuk meg közelebbről is, hogy mi a feladata. Biztos azt gondolod, hogy a szoftvertesztelő feladata a hibák megtalálása. Nemegészen. (Helyesen hibajelenségek, de ennek a stilisztikai különbségnek a rejtelmeibe nem ez a cikk fog beavatni.)
Ahhoz, hogy megértsük a szoftvertesztelő feladatát, hátrébb kell lépnünk és meg kell vizsgálni ismét, hogy mi is történt anno, amikor a mérnök volt az egyedüli ura a számítástechnikának. Ült a mérnök a hatalmas gép előtt és törte a fejét. – Mit tudnék kezdeni ezzel? – Tette fel gondolatban a kérdést. Nyilván eszébe jutott, hogy valamilyen játékra használja fel. 1962-ben így jött létre az első, Spacewars nevű játék: https://pcforum.hu/hirek/13565/50-szuletesnapjat-unnepli-a-vilag-elso-videojateka
Jelen cikkben a játékkészítés egy mellékszál. A lényeg, hogy a mérnök kitalált olyan dolgokat, amikben a hatalmas gép a segítségére lehetet. A lényeg, hogy a mérnök talált ki dolgokat. A mérnök volt az, aki megalkotta az igényt. Így nem volt nehéz dolga, hogy meg is értse azt.
Az igény, azaz, hogy mit is kéne a mai nem túl nagy számítógépeken megvalósítani, már nem azok feladata, aki elkészítik a programot. Így az igény megértése már külön tudomány. Arról nem is beszélve, hogy a mai igények már nem csak egy szűkebb közösség igényei, hanem számtalan szakma igényel magának programokat, amik segítik a munkájukat. Ezek a segítségek gyakran komplett szakmai folyamatokat segítenek, nem csak részeredményeket szolgáltatnak. Számtalan szakma komplex igényei. Ez az oka, hogy szükség van egy szerepkörre, ami a fejlesztés alatt folyamatosan biztosítja, hogy az igény és az elkészült termék nem két különböző dolog. Ez a feladat, amit a szoftvertesztelők végeznek rendíthetetlenül.

  • A szoftvertesztelő vizsgálja, hogy a fejlesztés jól értette meg az igényt.
  • A szoftvertesztelő auditálja, hogy a fejlesztés kiszolgálja az igényt.
  • A szoftvertesztelő ellenőrzi, hogy a fejlesztés által előállított termék megfelel-e az igénynek, azaz agy ügyfélnek.

A tesztelői szupererő

Igen, ennek része a hibajelenségek keresése, hiszen a hibajelenség azt jelzi, hogy a termék nem felel meg az igénynek, de a fentiekből látható, hogy a hibajelenség keresés csak részfeladat. A tesztelői szupererő ehhez képest jelentős többletet biztosít minden projekten (ahol alkalmaznak dedikált tesztelőt J). Ez a jelentős többlet egy nagyon hasznos szupererő. A tesztelő szuperereje a beleérző képesség, aminek segítségével megérti, átérzi, átlátja, hogy az ügyfélnek miért van szüksége egy programra, hogy az ügyfél mire akarja használni a programot és hogy az ügyfél hogyan akarja használni a programot.

Együtt erősebbek vagyunk

Az egész több, mint a részeinek az összege. A fejlesztő csapat, aminek része a tesztelő szuperereje, minőségi terméket képes szállítani, ha együtt dolgoznak a közös célért (közös cél: az igény megvalósítása). A csapatnak szüksége van az összes benne szereplő szaktudásra, de a csapatmunka teszi értékké a csapat tagjainak a szaktudását. A csapatból nem vehetsz el szaktudást, mert akkor a csapat nem tudja teljesíteni a célját. A csapatnak minden építő szaktudásra szüksége van, így a szoftvertesztelőre is, aki biztosítja, hogy a termék az igényeknek feleljen meg.

Jó tesztet!

Hajrá!

Megosztás

Kérsz értesítést a legújabb cikkekről?

Kapcsolódó cikkek

20 év szoftvertesztelés után ezt látjuk minden sikeres szoftverprojektben

Húsz év és több száz projekt után az ember már nem az egyedi eseteket jegyzi meg, hanem az ismétlődő mintákat. A legérdekesebb felismerés az, hogy a sikeres szoftverprojektek mennyire hasonlítanak egymásra. Más az iparág, más a technológia, más a csapat, mégis ugyanazok az elvek térnek vissza bennük, újra és újra. A kudarcok ezzel szemben mind

T&M vagy fix projekt? Melyik tesztelési modell mikor működik jobban?

Amikor egy cég külső tesztelési partnert von be, az egyik legkorábbi kérdés nem szakmai, hanem pénzügyi: milyen konstrukcióban dolgozzunk együtt? A válasz sokszor a beszerzési reflexből születik: „adjatok egy fix árat, hogy tudjam, mennyibe kerül”. Érthető igény, de nem mindig a legjobb döntés. A fix ár és a másik klasszikus modell, a T&M (Time and

Scroll to Top

Elérhető tesztelőink

Nézze meg szakértőink profiljait, tapasztalatát és kompetenciáit, és találja meg a projektjéhez illő szakembert.

Töltse le tesztelőink szakmai profilját

Adja meg elérhetőségét egyszer és férjen hozzá valamennyi elérhető profilhoz.