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

A tesztpiramis: a stabil és kifizetődő tesztautomatizálás alapköve

Bevezető A szoftverfejlesztés világában az automatizálás gyakran úgy indul, mint egy lelkes fellángolás: „Minden manuális tesztet váltsunk ki automata scriptekkel!” A kezdeti eufória után azonban sok projektvezető és fejlesztő szembesül a kőkemény valósággal. A tesztek lassúak, gyakran ok nélkül elbuknak, a karbantartásuk pedig több időt emészt fel, mint amennyit maga a fejlesztés. Ilyenkor merül fel

Tesztautomatizálás: mikor érdemes belevágni, és mikor várjunk még?

Bevezető A szoftverfejlesztési projektek egyik legvitatottabb kérdése nem az, hogy kell-e automatizálni a tesztelést, hanem az, hogy mikor. „Már az első naptól írjunk automata teszteket, vagy ráérünk, ha már kész a funkciók nagy része?” – hangzik el a kérdés szinte minden projektindító megbeszélésen. A válasz azonban nem egy egyszerű dátum vagy verziószám. A tesztautomatizálás ugyanis

Tesztautomatizálás útmutató: mikor, hogyan és miért érdemes bevezetni?

Szoftvert fejleszteni ma már nem csak kódolást jelent. Egy termék sikere legalább annyira múlik azon, hogy a kiadás pillanatában stabilan, hibamentesen és megbízhatóan működjön, mint magán az ötleten. Ahogy az IT projektek egyre komplexebbé válnak, a hagyományos, tisztán manuális tesztelés egyre kevésbé tud lépést tartani a fejlesztés tempójával. Eljön a pont, amikor a tesztelés már

Scroll to Top