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

Idő hiánya

2010.04.15. 09:00 | p_jano | Szólj hozzá!

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

Mindig idő hiányában szenvedünk. :) Ez van.

Miből keletkezhet az időhiány?

 

Ha a vezetőség nem fordít megfelelő erőforrást a tesztelésre

Ez általában azért van, mert a vállalaton belül még nem alakultak ki a megfelelő tesztelési folyamatok. Szemléletváltásra van szükség.

 

Ha a becslések nem megfelelőek

A tesztelési időt rosszul becsülték meg. Nem kalkulált feladatokat is el kell végezni, amelyek nem voltak benne a becslésben, vagy csak egyszerűen nem terveztek elég időt az egyes feladatok végrehajtására.

 

Ha nincs tesztvezetés

Egy tesztelői csapatot koordinálni kell, képviselni kell az érdekeit. Ha ez nincs, akkor nagy valószínűséggel fejetlenség fog eluralkodni a teszteken. A tesztvezető segítheti a tesztelési csapat munkáját, amennyiben jól szervezi a feladatokat.

 

Ha a fejlesztés csúszik (már pedig csúszik)

Különböző okoknál fogva csúszik a fejlesztés, ami magával húzza a tesztelés csúszását is. Általában a végső határidőket nem változtatják meg, inkább nagyobb sebességre kapcsolnak, hogy behozzák a lemaradást, vagy csökkentik az átadott funkciók számát.

 

Ha nem várt események történnek

Hosszabb fejlesztési periódus alatt több váratlan esemény is történhet, amely 1-2 napra megállíthatja a fejlesztést. Ez összeadódik és a legvégén tetemes mennyiséget jelenthet, ami miatt időhiányba kerülünk.

 

Ha a feltételek nem megfelelőek, például nincs elég tesztelő, nincs tesztkörnyezet, vagy várni kell annak kialakítására, esetleg nincsenek megfelelő tesztadatok, a specifikációk nem eléggé kidolgozottak.

 

Hogyan lehet védekezni az időhiány ellen?

Először megpróbálhatjuk az egyes okok ellen védekezni, vagyis jobban felmérjük a feladatot és megfelelően becslünk, vagy felkészülünk a tesztelésre és próbáljuk előre kialakítani a tesztkörnyezeteket, tesztadatokat, stb...

 

Ha az egyes okokat már kezeltük és még mindig fenn áll az időhiány, akkor nincs más hátra mint a priorizálás szabályát betartani.

Emberi erőforrás hiánya

2010.04.08. 09:00 | p_jano | Szólj hozzá!

Címkék: tesztelés szoftvertesztelés tesztelési problémák tesztelői erőforrás

 A cím igazából úgy lenne helyes, hogy a "Megfelelő emberi erőforrás hiánya". Sokszor azért nem sikerül rendesen letesztelni az alkalmazásokat, mert nincs megfelelő emberi erőforrás.

A vállalaton belül nincs olyan ember, aki

  • megtervezné a tesztelés lépéseit
  • funkcionálisan letesztelné az alkalmazást
  • integrációs teszteket végezne
  • képes automatikus teszt szkripteket írni
  • összefogná a tesztelési csapatot
  • tesztadatokat gyártana
  • üzleti oldalról segítené a tesztelést

Ha nem csak a szűk tesztelési feladatokat nézzük, hanem a fejlesztési folyamatot, akkor ehhez még hozzájön a megfelelő rendszerszervezők, projektvezetők, fejlesztők, .... hiánya.

 

Igazság az, hogy a jó szakembereket nagyon nehéz megtalálni. Viszont ha már találtunk egyet, akkor azt ne engedjük el. Aranyat érhet.

 

Próbáljuk meg a legjobb embert megtalálni a különböző feladatokra. Tudom nem egyszerű.

Cégen belüli szemléletmód megváltoztatása

2010.04.01. 09:00 | p_jano | 2 komment

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

Először természetesen a vezetőséget kell meggyőzni arról, hogy érdemes erőforrást áldozni a szoftvertesztelésre. Milyen stratégiát válasszunk?

Egyik ismerősöm mondta el a napokban a következő folyamatot. Cégükön belül van egy ember, akinek az a dolga, hogy a megbeszéléseken feltesz pár elgondolkoztató kérdést a teszteléshez kapcsolódóan. Ezeken a megbeszéléseken a vezetőség általában üzleti, vagy fejlesztési oldalról, esetleg az üzemeltetés oldaláról szokta körbejárni a problémákat. Emberünk feladata, hogy a tesztelésre is ráterelje a figyelmet.

 

Például:

  • Elgondolkodtatok már azon, hogyan fogunk megbizonyosodni az alkalmazás helyességéről?
  • Ha ezt és ezt az alkalmazást megváltoztatjuk, akkor a hozzá kapcsolódó alkalmazásokat nem kellene tesztelni? A rendszerek közti kommunikációt nem kellene tesztelni?
  • Ha már tesztelni kell, akkor nem kellene külön tesztkörnyezetet építeni ennek a feladatnak? Vagy már van tesztkörnyezet? Akkor jelenleg ki használja ezt a környezetet? Tudjuk egyszerre több projektre is használni a környezetet?
  • Milyenek a specifikációk? Látta már őket tesztelő? Van már becslés arra, hogy mennyi idő alatt lehet letesztelni?
  • Milyen lesz az új rendszer terhelése? Mit várunk el tőle? Hogyan fogjuk tudni letesztelni? Milyen környezeten, milyen szoftverrel fogjuk végezni a terhelést?
  • ...

Lassú víz partot mos.

A kérdések arra jók, hogy a vezetőség minden egyes megbeszélésen szembesül azzal a problémával, hogy a tesztelést nem tudja megkerülni. A tesztelésbe időt, energiát kell fektetni. A szoftvertesztelést nem elég felületesen megbeszélni, azt át kell gondolni, meg kell tervezni.

Egy idő után a vezetőség fejében nem lesz kérdés, hogy kell-e áldozni a szoftverek tesztelésére, vagy sem.

Miért fontos a tesztmenedzsment eszköz használata? 3. rész

2010.03.25. 09:00 | p_jano | Szólj hozzá!

Címkék: tesztelés szoftvertesztelés dokumentálás teszteszköz

A bejegyzés első része
A bejegyzés második része

Összeköthetjük az entitásokat

Nos, eddig ugyebár felvettünk, létrehoztunk tesztelési követelményeket, teszteket, tesztköröket, hibákat. Az egésznek nem sok értelme lenne, ha nem tudnánk ezeket egymáshoz kötni. Mivel egy átlagos tesztmenedzsment eszköz ezt megteszi, ezért örülhetünk és gyárthatjuk a riportokat. Miért is jó ez? Mert az összekötésnek hála figyelemmel tudjuk követni egy-egy tesztelési követelmény állapotának változását.

 

Grafikonokat, riportokat készíthetünk

 

  • Az entitások rögzítése, és köztük lévő kapcsolat miatt lehetőségünk van különböző riportokat elkészíteni.
  • Hibák eloszlása (súlyosság, állapot, prioritás, terület, funkció, rendszer, verzió, .... szerint)
  • Tesztesetek állapota az egyes verziókban, tesztkörökben (futott-nem futott, sikeres-sikertelen)
  • Követelmények lefedettsége (mely követelményekre mennyi tesztesetet írtunk)
  • Követelmények állapota valamely verzióban (az adott követelményre írt tesztesetek állapotának figyelése, összegzése)
  • ...

Az ilyen grafikonok segítségére lehetnek a vezetőségnek, hogy átfogó képet kapjanak az alkalmazás állapotáról és megfelelő döntést tudjanak hozni.

 

Automatikus eszközöket köthetünk hozzá

 

Némely tesztmenedzsment eszköz képes kezelni automatikus teszteszközök scriptjeit. Azokat tárolja, engedi szerkeszteni, sőt futtathatjuk is őket. A futott scriptek visszajelzéseit rögzíti az eszköz, esetenként a visszajelzett hibákat is el tudja tárolni. Az automatikus scriptek a manuális scriptekkel együtt szerepelhetnek a riportokban. Átfogóbb, pontosabb képet kaphatunk az egyes követelmények állapotáról, vagyis magáról a rendszerről.

 

Amennyiben téged is érdekel, hogy hazánkban hogyan használják a tesztmenedzsment eszközöket, kérlek töltsd ki az alábbi kérdőívet!

 

Köszönöm.

Miért fontos a tesztmenedzsment eszköz használata? 2. rész

2010.03.18. 09:00 | p_jano | Szólj hozzá!

Címkék: tesztelés szoftvertesztelés dokumentálás teszteszköz

A bejegyzés első része

Tesztköröket szervezhetünk

A legyártott tesztesetek közül kiválogathatjuk azokat, amelyeket az adott verzión le szeretnénk futtatni. Ezeket egy tesztelési körbe tudjuk összeszedni. A tesztköröket akár többször is lefuttathatjuk. Egy tesztkört összeállíthatunk úgy, hogy csak egy verzión legyen értelme futtatni, vagy akár úgy is, hogy az összes verzión futtathassuk. A tesztkörökbe szervezett tesztesetekhez felelőst is kijelölhetünk, így mindenkinek kioszthatjuk az adott verzión elvégzendő feladatát. A tesztkörök használatával elérhetjük, hogy a tesztelői csapat pontosan azt hajtsa végre, amit megkövetelünk tőle.

 

Futtatási eredményeket tárolhatunk

 

A futtatási eredményeket eltárolja az eszköz. Nem csak az utolsót, hanem az összes eredményt megnézhetjük. Pontos képet kaphatunk, hogy melyik verzión működött és melyiken nem az adott teszteset.

 

Hibákat vehetünk fel

 

Amennyiben egy teszt hibára fut, úgy lehetőségünk van hozzá csatolni egy hibát. A teszteset futtatása és a hiba között kapcsolat keletkezik, ez később segítségünkre válhat, ha a tesztek futási eredményét nézzük, vagy ha a tesztelési követelmények állapotát elemezzük. A hibák kezelését, karbantartását teljes körűen lefedik. A tesztmenedzsment eszközökben (ugyanúgy mint a hibakezelőkben) általában állíthatunk hiba státusz folyamatot. Alapból van bennük valamilyen státuszkezelés, de ezt a legtöbben felül lehet írni. Olyan folyamatokat lehet bennük definiálni, amely megmondja, hogy melyik felhasználó (felhasználó csoport), a hibák státuszát, melyik állapotból, melyik állapotba állíthatja.

Amennyiben ezt a lehetőséget kihasználjuk, a státuszkezelést pontosan beállítjuk, úgy óriási lépést teszünk egy kontrolált tesztelési folyamat kialakításában!

 

Amennyiben téged is érdekel, hogy hazánkban hogyan használják a tesztmenedzsment eszközöket, kérlek töltsd ki az alábbi kérdőívet!

 

Köszönöm.

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