Megjelent a Tesztelés a gyakorlatban magazin legújabb száma.
Hogyan lehet ...?
2011.08.18. 09:00 | p_jano | 2 komment
Címkék: tesztelés megtörtént szoftvertesztelés tesztelői erőforrás
Hogyan lehet a legrövidebb idő alatt a legtöbb tesztelőt összegyűjteni?
Még tavaly előtt történt egy ilyen eset, hogy ismerősömet felkeresték azzal teszteljen le egy oldalt egy nagyobb tesztcsapattal. Megkérdezte, hogy pontosan mit kellene tesztelni és mégis hány fővel.
A válaszon eléggé meglepődött.
Egy robusztus weboldalról volt szó, amelyen funkcionális teszteket (vagy nevezzük inkább használhatósági teszteknek) kellett volna futtatni. Dokumentáció nincs, üzleti oldalhoz nem ért, csak a megrendelő csapata. Gyakorlatilag az evidens, alapvető hibák felkutatása lett volna a cél. Hogy hány tesztelővel? Amennyivel csak tudja, de a preferált létszám valahol 500 és 1000 fő között mozgott.
Mindezt 1 hét alatt kellett volna megvalósítania. Természetesen nem sikerült.
Bennem mai napig motoszkál a kérdés:
Hogyan lehet a legrövidebb idő alatt a legtöbb (magyar) "tesztelőt" összegyűjteni? Természetesen nem szakképzett tesztelőkről lenne szó, de mindenképpen értelmes, alapvető informatikai tudással bíró emberekről beszélünk.
Nincs időm a hibákat rögzíteni
2011.08.11. 09:00 | p_jano | Szólj hozzá!
Címkék: tesztelés megtörtént szoftvertesztelés dokumentálás
Nemrégiben beszéltem egy tesztelővel, aki az alábbi szituációt vázolta:
Az adott tesztelési folyamatban több hátráltató tényező is van. Az első, hogy nem megfelelő a projektvezetés, túl sok idő telik el egy hiba felvétele és fejlesztőhöz való delegálása között. Sokszor a projektvezető nem is tudja, hogy kinek kell kiosztania a hibát. Természetesen az idő kevés, a határidők pedig nem változnak, azokat tartani kell. Mindezek mellett nagyon sok emberrel (projektvezető, fejlesztők, üzemeltetők, rendszertervezők, üzleti végfelhasználók) kell tartani folyamatosan a kapcsolatot, hogy hatékonyan el tudja végezni a feladatát.
A tesztelő úgy oldja meg a határidők tartását, hogy sokszor nem dokumentálja a feladatvégzését. Például nem viszi fel a rendszerbe a talált hibákat. Küld egy emailt a megfelelő személyeknek, vagy pedig személyesen megbeszéli velük és együtt pillanatok alatt elhárítják a hibát.
Ha továbbra is így dolgozik és nem fordít időt az adminisztrációra, hamarosan nagy bajba sodorhatja magát. Mivel nem lesz nyomon követhető a munkája, senki nem fogja látni, hogy az adott tesztelés miért tart olyan sokáig. Ne is beszéljünk arról az esetről, ha kienged élesre egy hibát. Egyrészt a saját munkájával nem tud elszámolni, másrészt a menedzsment teljesen fals értékeket fog látni a projektről. Egyik sem jó.
Természetesen a tanács az volt, hogy mindent dokumentáljon le. Ha nem részletesen, de címszavakat, 1-1 mondatot minden hibáról tud írni, és ne csak a hibákat, hanem a futtatásokat is adminisztrálja. Ha nincs más egy laza Excel tábla is megteszi. Csak csinálja.
Ha a Kövspecet a fejlesztő írja
2011.08.04. 09:00 | p_jano | Szólj hozzá!
Címkék: tesztelés szoftvertesztelés dokumentálás
Mi történik, ha a rendszertől elvárt követelmény specifikációt a fejlesztők írják le?
Eddigi tapasztalataim szerint semmi jó.
Tévedés ne essék, nem másokat akarok leszólni. Egyszerűen arról van szó, hogy nem szokott működni ez a fajta munkaleosztás, mint ahogy nem szokott működni az sem, amikor a saját maga programját teszteli le a fejlesztő.
Ilyenkor nincs annyira kidolgozva a specifikáció, a homályos, nem definiált részleteknél a fejlesztő önkényesen dönti el, hogy az hogyan legyen megoldva az alkalmazásban. Ezáltal üzletileg rossz döntéseket hoz, ami természetesen sérti a Megrendelő érdekeit.
Kimondhatjuk, hogy ezekben az esetekben egyértelműen a Megrendelő a hibás. Úgy kellene leosztania a feladatot, hogy a követelmény specifikációt vagy házon belül írják meg hozzáértő emberek, vagy ha ilyen nincs, akkor más céget kellene megbíznia a követelmény specifikáció elkészítésével és a fejlesztéssel.
Kövspec nélkül
2011.07.28. 09:00 | p_jano | Szólj hozzá!
Címkék: tesztelés szoftvertesztelés dokumentálás
Mi van, ha nincs követelmény specifikáció? Vagy éppenséggel elkészült, de nem használható?
Hogyan tudunk mégis megfelelő minőséget építeni az alkalmazásba?
A tesztelésnek egyik alapvető inputja az üzleti követelmény specifikáció, amiben az üzlet leírja, hogy az adott rendszerben milyen funkciókat szeretnének használni. A dokumentumnak részletesen tartalmaznia kell, hogy az új alkalmazással szemben milyen igények merültek fel.
Egy egyszerű weboldalnál is fel kell sorolnunk a menüpontokat, jogosultságokat, kitöltendő mezőket, elvárt értékeket, folyamatokat.
Amennyiben nincs részletesen kidolgozott dokumentum a kezünkben, hogyan fogjuk letesztelni, hogy az alkalmazás megfelelően működik-e?
- Kezdjük el összeszedni és egységesíteni az üzleti igényeket a dokumentációkból.
- Beszéljük át a projekt részleteit a projekttagokkal (projektvezető, rendszerszervező, vezető fejlesztő).
- Józan ésszel gondoljuk végig az alkalmazás működését, hogy mit is kellene ellenőriznünk.
- Nézzük át, vagy emlékezzünk vissza a régebbi projektjeink teszteseteire hátha vannak egybeesések, hasonlóságok a projektek között.
- Próbáljunk meg a megrendelővel egyeztetni. Általában ezt a legnehezebb összeszervezni, de ezáltal pontosíthatjuk legjobban az elvárásokat.
A fenti lista eredményeiből könnyen készíthetünk tesztelési követelményeket. Ne az üzleti specifikációt próbáljuk meg megírni, mert az amúgy sem a mi dolgunk. Koncentráljunk arra, hogy a felkutatott igényeket, elvárásokat milyen tesztekkel tudjuk ellenőrizni.
A tesztelési követelményekre pedig könnyűszerrel írhatunk teszteseteket.
Kommentek