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

Tesztelő képzés - Hogyan válik valaki tesztelővé? 2. rész

2009.06.10. 21:20 | p_jano | Szólj hozzá!

Címkék: oktatás tesztelés szoftvertesztelés tesztelői erőforrás

Az első részben szó volt arról, hogy gyakorlati oktatást kell adni a tesztelőknek. Hogyan lehet ezt megvalósítani?

Amennyiben van rá lehetőség, akkor próba projekten kell kitapasztalni a tesztelői affinitást. Ez a projekt lehet egy üzleti szempontból kis prioritású alkalmazás, vagy netán egy teljesen belső projekt. Belső projektnek nevezem azt a szoftverfejlesztést, melynek végtermékét vállalaton belül fogjuk használni. Itt is figyelembe kell venni azonban, hogy ne olyan funkció tesztelését adjuk oda a betanítandó munkatársnak, amely kritikus a vállalkozás működését tekintve, hanem inkább a periférián lévő modulok, funkciók ellenőrzését bízzuk rá.

Ha találunk ilyen projektet, akkor nagy szerencsénk van, ugyanis meg van oldva a projekt szimuláció. Amennyiben nincs projekt, viszont az erőforrást be kell tanítanunk, na akkor már egy kicsit nehezebb a helyzetünk.

Mi régebben úgy oldottuk meg, hogy vettünk egy lefutott projektet. Ennek a projektnek a verzióit egy verziókezelő rendszerben tároltuk, amelyből visszafelé elkészítettünk 4-5 buildet. Ezeket a buildeket meghatározott időközönként kitettük a tesztelendő környezetre. Volt egy tesztmenedzser eszközünk, melyben a tanulók felvették az adott verzió hibáit. (Nem találtak olyan hibát, melyet mi azelőtt ne kaptunk volna el.) A hibák a következő verzióban vagy kijavultak, vagy úgyanúgy szerepeltek benne. Az egész szimulációhoz 1 ember kellett, akit mi vezető fejlesztőnek hívtunk. Ő tette ki az új verziókat, buildeket, válaszolt a hibákra, állította a hibák státuszát, stb... Napi 2-3 órás munkájával 4-5 embert tudott folyamatosan oktatni, feladattal ellátni.

Ha a tesztelőket csoportokba szervezzük, akkor a csoportmunkát is megtanulhatják egycsapásra. Feladatok leosztását, egymásra figyelést, csoportos munkavégzést.

Ha minden kötél szakad, akkor ilyennel is lehet próbálkozni. Persze egy komolyabb cég életében szinte kizárt, hogy ne legyen bármilyen belső fejlesztés. Viszont ha nincs, akkor segíthet egy ilyen szimuláció.

Miben jobb a szimuláció egy új fejlesztésnél?

Egy dologban biztosan. Ha össze tudjuk hasonlítani a két hiba adatbázist (az eredetit és a tanulóit), akkor különböző kérdésekre kaphatunk válaszokat.

  • Megtaláltak-e minden hibát az egyes verziókban?
  • Milyen típusú hibák nem kerültek elő?
  • A hibaleírások mennyire hasonlítanak az eredetiekre?

Ezekre a kérdésekre adott válaszok abban segítenek, hogy meglássuk az új generáció hibáit, hátrányait. Esetleg ezeken még az élesbe kerülés előtt javíthassunk. Akár elméleti, akár gyakorlati oktatással.

A bejegyzés trackback címe:

https://teszteles.blog.hu/api/trackback/id/tr661177638

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.