Szoftvertesztelés

Hírek, újdonságok, tapasztalatok és elmélkedések a szoftvertesztelés világából!

Kommentek

  • blash: Én csak pár képet hiányolok, ami persze nagymeló, de sokat hozzá tud tenni a cikkekhez. (2013.02.10. 17:17) Mantis
  • szlj: A sorok között benne van, de mivel a személyes tapasztalatommal is megegyezik, ezért ideírom. Aki ... (2013.01.24. 22:20) Mantis
  • p_jano: @B9: Az egyik lehetőség a tanácsadói, szolgáltatói cégeknél elhelyezkedni. Itt azért negyedévente,... (2012.07.03. 22:16) Tanulni szeretnék ...
  • B9: Sziasztok! Mit javasolnál annak, aki olyan munkahelyet keres, ahol a legszéleskörűbb tapasztalato... (2012.06.18. 10:29) Tanulni szeretnék ...
  • Eaven: Csakis egy adatbázisból. Kell egy web oldal ahol regisztrálhatja magát az ember ilyen munkára. In... (2011.10.25. 17:24) Hogyan lehet ...?
  • Utolsó 20

A specifikáció és az abban bekövetkezett változások dokumentálásának hiánya

2008.10.01. 15:56 | p_jano | Szólj hozzá!

Címkék: tesztelés tervezés szoftvertesztelés tesztelési problémák

Egyik ismerősöm folyamatosan azzal a kérdéssel "zaklat", hogy hogyan tudnám a szoftvertesztelést rendbe hozni a cégükön belül. Régóta figyelemmel követem a céget, így tisztában vagyok azzal, hogyan is dolgoznak. A szakmai tudásukkal nincs gond, a projektvezetési-, fejlesztési- folyamatok is rendben vannak. A teszteléssel sem lenne semmi komolyabb probléma, mivel van megfelelő szaktudású tesztelőjük, tesztvezetőjük. Definiálva vannak a tesztelési folyamatok, használnak tesztmenedzsment eszközt, léteznek tesztkörnyezetek, tesztadatok.

A baj a tesztelés tervezésénél jön állandóan elő!

Soha nem tudják a tesztelés hatókörét megfelelően belőni. Nem lehetséges a feladat pontos meghatározása, mivel egyáltalán nem készül dokumentáció!

Az ügyféllel telefonon, e-mailben és személyes megbeszéléseken keresztül történik a kommunikáció. Írásos dokumentáció leginkább e-mail formájában születik, de nem egyszer fordul elő az sem, hogy csakis a kapcsolattartó fejében van meg az információ.

A tesztelők a projekt során összehívott megbeszéléseken tájékozódnak az elkészítendő szoftver tulajdonságairól. Sokszor menet közben derül ki, hogy egy funkció kimarad, vagy éppen beépül az adott szoftverbe! Amennyiben a tesztelő nincs bevonva a kommunikációba, úgy az alkalmazást nem tudja megfelelő módon letesztelni. 

A cégnél sokan azt gondolják, hogy pótolhatatlanok. Igazuk is van!

A kulcsemberek kilépése tönkretenné a vállalkozást. Ha bárki aki a szoftver tervezésében részt vett, elmegy a cégtől, az összes dokumentálatlan információhalmazt magával viszi.

- o - 

Másik jellegzetes hiba a cégeknél, hogy a dokumentációk a projekt elején elkészülnek, de a munka előrehaladtával a változásokat nem jegyzik fel bennük. Így a végén a specifikációktól teljesen eltérő szoftvert alkot a fejlesztő cég. Egy ilyen szoftvert, a fejlesztés vége felé már képtelenség tesztelni.

 

Az ismerősömnek is azt ajánlottam, a legelső dolog az legyen, hogy alkalmaznak egy üzleti elemzőt, rendszerszervezőt, aki dokumentálja az üzleti igényeket, követelményeket.

Projektvezetés, fejlesztés és tesztelés szempontjából is kulcsfontosságú, hogy megfelelően dokumentált igényekkel tudjanak az emberek dolgozni. Amennyiben az üzleti követelményeket és az abban bekövetkezett változásokat rögzítik, úgy sokkal hatékonyabb projektvezetést, tervezést, fejlesztést, tesztelést lehet végezni a cégben.

Cégen belüli szemlélet hiánya

2008.09.30. 14:59 | p_jano | 1 komment

Címkék: tesztelés tervezés szoftvertesztelés tesztelési problémák

A cégvezetők, projektvezetők gyakran nem ismerik fel a tesztelés fontosságát. Számukra a hirtelen felmerülő problémák megoldása és a napi munkafolyamatok rutinszerű elvégzése fontosabb, így a szoftver(ek) minőségének javítása háttérbe szorul.

Sok olyan vállalkozás létezik, ahol a legfontosabb az ügyfél megszerzése. Nem számít a minőség, csakis a mennyiség, az üzlet a mértékadó. Ezt nagyon sokáig lehet csinálni, pláne, ha a fejlesztő cég komoly értékesítői hálózattal rendelkezik.

Általában ezeknél a cégeknél a fejlesztésre és az azt követő supportra tevődik a hangsúly. Ha minőségi problémák merülnek fel, azt a fejlesztés javításával próbálják megoldani, kevesen gondolják úgy, hogy a tesztelés és minőségbiztosítás területén kellene fejlődniük. A tesztelés a fejlesztési folyamatból teljesen ki van zárva, vagy csak a fejlesztés után kezdődik el.

Sokszor hallani olyat is, hogy azért nem akar a cég minőségi szoftvereket gyártani, mert akkor a support-ból nem lenne bevétele. Természetesen ez is egyfajta hozzáállás, amit lehet követni. De minőségi szoftvereket ezektől a vállalkozásoktól ne várjunk.

A szemléletváltozást leginkább belülről lehet elősegíteni. Amennyiben van a cégen belül egy olyan ember, aki zászlajára tudja tűzni a minőségi szolgáltatás nyújtást, minőségi termék előállítását, úgy van esély a javulásra. Azt kell megértetni a vezetőséggel, hogy a tesztelést időben - még a tervezés fázisában - kell elkezdeni, integrálni a fejlesztési folyamatba.

Mindannyian tudjuk: Minél hamarabb derül ki egy hiba, annál kevesebb veszteséget okoz a cégnek!

Tesztelési problémák a gyakorlatban

2008.09.29. 13:09 | p_jano | 1 komment

Címkék: tesztelés szoftvertesztelés tesztelési problémák

Meggyőződésem, hogy az országban sok helyen végeznek megfelelő minőségű szoftvertesztelést. De ennél sokkal több azon vállalkozások száma, ahol nem ez a helyzet. Sokszor alapvető hozzávalók hiányoznak, melyek nélkül az eddig rosszul teljesítő tesztelők továbbra is rossz eredményt érnek el. Nem is említve azokat a vállalkozásokat, ahol nincs, vagy „csak“ szoftverfejlesztői oldalról látják el a tesztelést. Úgy gondolom professzionális munkát csakis megfelelő körülmények között lehet végezni.

Nézzük végig, mik azok a problémák, amelyek leginkább akadályozzák a profi tesztelés működését:

  • Cégen belüli szemlélet hiánya
  • Specifikációk hiánya
  • Változások követésének hiánya
  • Tesztelési módszertan hiánya
  • Emberi erőforrás hiánya
  • Idő hiánya
  • Tesztkörnyezet hiánya
  • Tesztadat hiánya
  • Teszteszköz hiánya
  • Teszt konfiguráció hiánya
  • Automatizált tesztelés hiánya / túlzott használata
  • Tesztvezetés hiánya

Hogyan lehet ezeket a problémákat megoldani?

A következő napokban ezeket fogom kivesézni.

Tesztelés helye a fejlesztési folyamatokban

2007.07.12. 16:39 | p_jano | 1 komment

Címkék: tesztelés tervezés szoftvertesztelés tesztelési módszertan

Ahány cég, annyi szokás. Mégis abban talán mindenki egyetért, hogy a lehető leghamarabb kell a tesztelést elkezdeni. Ha a munka első fázisaiban kapjuk el a hibát, az kevesebb költséggel jár, mintha a legvégén jönnénk rá, hogy a tervezésnél elrontottunk valamit.

Szeretnénk egy családi házat felépíteni. Vannak különböző igényeink a házzal kapcsolatban, hogy hány szoba legyen, hogyan helyezkedjenek el, mekkora négyzetméterrel, stb. Az építész megtervezi a házat a különböző szakmai szempontoknak és a mi elvárásainknak megfelelően. A kész tervet ezután átnézzük és szóvá tesszük kifogásainkat. Ha ugyanis valamelyik fal nem jó helyen van, akkor azt papíron egyszerűbb módosítani, mint később, amikor már áll a ház.

A szoftverekkel is ugyanez a helyzet. Ha már a tervezés szintjén észrevesszük a logikai bukfenceket, akkor azokat sokkal könnyebben és olcsóbban javíthatjuk ki a tervben, mint a kész programban. Ugyanúgy figyelni kell a rendszerszervező munkáját, mint ahogyan a lakás tulajdonos figyeli az építész munkáját.

De nem csak a tervezők, hanem a kivitelezők tevékenységét is figyelni kell. Ha már van egy jó tervünk, olyan amilyet a megrendelő szeretne, akkor a terv mentén haladva állítsuk elő a terméket. (Nagyon kevés projekt fut le úgy, hogy a tervtől nem térnek el menet közben. Ez elsősorban a tervezés, az üzlettel való kapcsolattartás és a felhasználókkal, megrendelővel való kommunikációs nehézségek számára írható elő.)

Legyen az ház, vagy szoftver a munkák rendszeres és folyamatos ellenőrzése elengedhetetlen. Egyszerűbb egy kapcsolót áthelyezni, egy vezetéket áthúzni amikor a villanyszerelők dolgoznak, mint amikor a festő befejezte a munkáját. A szoftvereknél is könnyebb egy rutint átírni az elkészítése után, mint mikor már beépítették a többi modul közé és 30-an hivatkoznak rá különböző helyekről. Persze ekkor sem lehetetlen, csak éppen sokkal több munkával jár, mint kellene.

Ahogyan a házat, úgy a szoftvert is az átadásig tesztelni kell. Egészen addig, amíg a megrendelő el nem fogadja a termék állapotát.

Nem elég csak a kész programot tesztelni, vagy a fejlesztés legvégén elkezdeni a minőség ellenőrzését. Már jóval a kódolás előtt a tervezési szinten el kell kezdődnie a tesztelésnek, majd az egész projekt ideje alatt a fejlesztés mellett haladva kell ellenőrizni a terméket a jobb minőség elérése és a költségek csökkentése érdekében.

Hogyan javíthatunk a tesztelés minőségén?

2007.06.13. 14:15 | p_jano | Szólj hozzá!

Címkék: tesztelés tervezés szoftvertesztelés tesztelési módszertan

Az első és legfontosabb lépés, hogy a tesztet meg kell tervezni! Először a tesztelés lépéseit, illetve azt, hogy milyen típusú teszteket érdemes futtatni.

  • Hol tart a fejlesztés?
  • Milyen a termék minősége?
  • Mikor lehet bevezetni, eladni a terméket?

Ezekre a kérdésekre egy folyamatban lévő tervezett tesztelés alatt MINDIG pontos választ lehet adni!

Ezzel szemben „ad hoc” tesztelésnél NEM állapítható meg, hogy hányszor nézték meg a tesztelők az egyes programrészeket illetve, az sem, hogy azok korábban tartalmaztak-e bármilyen jellegű hibát? Továbbá kérdéses marad, hogy mely modulokat, funkciókat ellenőriztek többször és melyek maradtak ki?

Az „ad hoc” tesztelés csak akkor kapcsolódik be a munkafolyamatokba, ha már a fejlesztés egy bizonyos szintet elért. Ekkor kezdik a tesztelők megismerni a funkciókat, ami már önmagában időveszteséget jelent. Másrészt: mivel terv nélkül tesztelnek, kimaradhat a vizsgálat alól olyan modul, amely fontos az adott alkalmazáson belül. Harmadrészt: senki nem lesz képes megmondani, hogy a tesztelés egy adott pillanatban hol áll; így lehetetlen a munka ellenőrzése. Ebben az esetben megállapíthatatlan, hogy mikor válik elfogadható állapotúvá a program. Csak a hibák számának csökkenéséből lehet az alkalmazás minőségére következtetni, ami önmagában kevés fogódzó.

Ha a cégen belül tervezett tesztelés folyik, a fenti kérdésekre folyamatosan naprakész adatok állnak a vezetők rendelkezésére. Miért?

Mert egy tervezett tesztelés alatt a követelményeket feljegyezik, folyamatosan karbantartják, definiálják: melyek a fontosak (core) és melyek perifériálisak. A tervezés során meghatározzák, mikor mondható az alkalmazásra, hogy működőképes. Például: a core 100%-ban működik, a periférián lévő követelmények 70%-ban teljesültek. Tudható, hogy mely tesztek futottak és melyek nem, illetve ezek futási eredménye is lekönyvelt, amelyből ezt követően megfelelő elemzések készítésére nyílik lehetőség.

A terv tartalmazza: milyen tesztelést mikor kell végrehajtani, hogy mikor kerül előtérbe a funkcionális, integrációs, regressziós, terheléses, (...) teszt. De nem csak azt határozza meg, hogy mikor szükséges a teszteket elvégezni, hanem hogy ezeket mely modulokon, funkciókon kell alkalmazni.

Továbbá a tesztelő már az alkalmazás működése előtt megismeri a funkciókat, megtervezi a tesztelést, képes az alkalmazás üzleti oldalát megérteni, a főbb folyamatokat áttekinteni. Ez jelentős időnyereséget és magasabb precizitást jelent a munkában, mivel a már tesztelhető programmal korábban megismerkedett.

Arról sem szabad megfeledkezni, hogy egy-egy hiba felfedése fényt deríthet az alkalmazás tervezése alatt elkövetett tévedésekre. Eredményesebb a hibát minél hamarabb megtalálni. Az „ad hoc” tesztelésnél a tervezési defektusok már csak a kódolás után kerülnek elő. Ezzel szemben az előre megtervezett tesztelésnél még a kódolás előtt, a tesztesetek írásánál, a követelmények összeállításánál és a program tervezésénél fellelhető az ilyen jellegű hibák nagy része. A fentiekből jól látható, hogy miért érdemes a tesztelést már a fejlesztés elején elkezdeni. Minél hamarabb derül ki egy hiba, annál kevesebb veszteséget okoz a cégnek!

 

süti beállítások módosítása