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: http://mek.oszk.hu/00400/00486.htm [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

Nincs elég tesztelő? Ez az 5 fájdalmas következmény a projektre

Bevezető „Spóroljunk a tesztelésen, majd a fejlesztők megnézik egymás kódját.” Hányszor hallottuk már ezt a mondatot projektindító megbeszéléseken? Logikusnak tűnhet: a fejlesztő ért a legjobban a kódhoz, miért fizetnénk külön embert arra, hogy „kattintgasson”? Ez a gondolkodásmód azonban olyan, mintha a könyvelőt kérnénk meg, hogy auditálja a saját mérlegét. Papíron minden rendben lesz, de a

Miért nem skálázódik QA nélkül egy IT projekt?

Bevezető A szoftverfejlesztés világában létezik egy visszatérő, fájdalmas forgatókönyv, amit szinte minden startup alapító és technológiai vezető átél legalább egyszer. Ez a történet mindig ugyanúgy kezdődik: eufóriával. A projekt elején minden olajozottan működik. A csapat kicsi, agilis, és mindenki mindent tud a rendszerről. A fejlesztők reggel megírják a kódot, délben tesztelik a saját gépükön, délután

QA staffing: hogyan lehet gyorsan és biztonságosan kapacitást bővíteni?

Bevezetés Előző cikkünkben (itt olvasható) arról írtunk, hogy mikor érdemes külsős tesztelőt bevonni, és mikor intő jel, ha csak tűzoltásra használnánk őket. Most, hogy már tudjuk a „mikor”-t, evezzünk gyakorlatiasabb vizekre, és nézzük meg a „hogyan”-t. Hogyan lehet úgy bővíteni a csapatot, hogy az ne a káoszt növelje, hanem a megoldást hozza el? (Megjegyzés: A szakmában gyakran

Scroll to Top
Passed
Adatvédelmi áttekintés

Ez a weboldal sütiket használ, hogy a lehető legjobb felhasználói élményt nyújthassuk. A cookie-k információit tárolja a böngészőjében, és olyan funkciókat lát el, mint a felismerés, amikor visszatér a weboldalunkra, és segítjük a csapatunkat abban, hogy megértsék, hogy a weboldal mely részei érdekesek és hasznosak. Adatkezelési tájékoztató