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 felhasználói élmény tesztelése

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

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

Felgyorsult a világ

Idehaza nem sokan hallottak még arról, hogy manapság a Szilícium-völgyben működő vállaltok között milyen új tesztelési divat ütötte fel a fejét. A rengeteg cég között sokan foglalkoznak kisebb szoftverek, mobilalkalmazások fejlesztésével. Ezeknél az alkalmazásoknál nagy kérdés, hogy milyen a felhasználót érő első élmény. Egy mobiltelefonnál nem installálunk hosszasan egy-egy szoftvert. Általában a szoftverek nem olyan bonyolultak, hogy 2-3 perc alatt ne lehetne a főbb funkciókat kipróbálni. Sokkal jobban előtérbe kerül a felület kezelhetősége, a grafikai elemek kidolgozottsága, a funkciók átgondoltsága, használhatósága. Ezek alapján döntenek a felhasználók, hogy később is használják az alkalmazást, vagy azonnal törlik azt.

A fejlesztőknek az a célja, hogy a terméküket sokan használják. Ezt csakis akkor tudják elérni, ha a felhasználókat meg tudják tartani és új felhasználókat tudnak szerezni. 

A felhasználók hogyan döntenek?

Mobilalkalmazásoknál leginkább az ajánlásokra támaszkodnak. Ha új szoftvert próbálnak ki, akkor pedig az első pár perc alatt ért impulzusok határozzák meg a döntésüket. Ezért is nagyon fontos a fejlesztőknek olyan alkalmazások készítése, amelyet élmény használni.

Visszatérve a Szilícium-völgyre, az ottani cégek elkezdtek kisebb kontroll csoportokat bevonni a fejlesztésükbe. Ha elkészülnek az adott alkalmazás egy verziójával, akkor azt kiadják olyan csoportoknak, akik eddig még nem találkoztak a szoftverrel és megnézik, hogy milyen reakciókat, élményeket vált ki az alkalmazás használata.

Ezáltal a fejlesztésüket úgy állíthatják irányba, hogy az alkalmazás a lehető legtöbb ember igényeinek megfelelő legyen. Így képesek leszek az embereket rábírni, hogy a szoftverüket használják és ajánlják azt másoknak. Ettől lesznek sikeresek. Attól, hogy képesek már a piacra dobás előtt letesztelni, hogy az alkalmazás mennyire ütőképes, mennyire hasznos az annak a csoportnak, akiknek megcsinálták.

Hazai pálya

Hazai szinten 1-2 ilyen szerveződésről/tesztről tudok. Nem ártana a fejlesztőknek elgondolkodni arról, hogy milyen hozadéka lehet/van egy ilyen tesztnek.

Véleményem szerint nem csak mobil eszközökön, hanem bármilyen weboldalnál, nagyobb szoftvernél alkalmazható a felhasználói élmény teszt.

A saját tapasztalatimat egy ilyen teszt megszervezésével, lebonyolításával kapcsolatban majd egy következő bejegyzésben írom le.

Mantis

2013.01.24. 09:01 | p_jano | 2 komment

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

(Az írás megtalálható a Tesztelés a gyakorlatban magazinban.)

Az egyik legismertebb hibakezelő: a Mantis

Az installálással mint eddig most sem volt semmi probléma. Ami engem kicsit mindig is zavart (ez más eszközöknél is így van), hogy az INSTALL fájlt, vagy leírást eldugva valamelyik könyvtárban találja meg az ember, de kis keresgélés után megvan. (Jelenleg a “DOC” könyvtáron belül található.) Csak kövessük a fájl leírását. Megfelelő PHP, Apache és MySql kell, hogy legyen a gépen valamint tudnunk kell a MySql elérését és root jelszavát. Ha ez megvan, akkor a letöltött fájlokat másoljuk be a web szerverünk könyvtárába, indítsuk el a webszerver/mantis/admin/install.php fájlt, és adjuk meg az adatbázishoz kért adatokat. Az installálás befejezése után elindíthatjuk a telepített Mantisunkat a “localhost/mantis” url-lel. Belépni az administrator/root adatokkal tudunk. Ezután kezdődhet az igazi munka. Amennyiben mégsem sikerülne elsőre az installálás úgy az előjövő hibákra általában bő leírást találhatunk a Neten.

Feltelepítettük. Na de mi az a Mantis?

A Mantis egy ingyenes web alapú hibakezelő rendszer, mely Apache, Mysql és PHP alapokon nyugszik. A MySql mellett még PostgreSql és MS SQL adatbázisokon is működik. (http://www.mantisbt.org/)

Az eszköz segítségével menedzselhetjük a különböző fejlesztésekben feltárt hibákat. Egyszerre több projektet lehet kezelni benne, egy időben több felhasználó is tud dolgozni a projekteken.

Alapvető beállítások: a projektek

A telepítés után vár ránk egy kis adminisztráció, mivel létre kell hozni a felhasználókat, projekteket, jogosultságokat, stb. Nézzük is sorba őket. Kezdjük a projektek kialakításával. Az admin jogosultságú felhasználóval való belépés után válasszuk a “Karbantartás” (“Manage”) menüpontot.

A Mantis projekt alapú csoportosítást biztosít, vagyis egyszerre több projektet kezelhetünk. A “Projektek kezelése” (“Manage Projects”) oldalon vehetünk fel új projekteket, módosíthatjuk a meglévőket. Új projektnél adjuk meg a projekt nevét, leírását, hogy milyen státuszban van, hová tölthetjük fel a projekt fájlokat, stb. A projekt adatlapján alprojekteket és verziókat, kategóriákat is beállíthatunk. Amint felhasználókat is rögzítettünk a rendszerben a projekt adatlapján a usereket is hozzárendelhetjük megfelelő jogosultsággal az adott projekthez. A projektek listája alatt találhatunk egy “Globális kategóriák” (“Global Categories”) elnevezésű részt, melyben megadhatjuk a bejelentett hibák kategorizálását (pl.: funkcionális hiba, ergonómiai hiba, stb., vagy kategorizálhatjuk a hibákat helyileg, hogy melyik modulban, funkcióban, menüpontban, találtuk meg). Az itt megadott kategóriák globálisak, vagyis minden egyes projektben használhatóak lesznek. Eddig csak egy esetben fordult elő, hogy sikerült használható globális kategóriákat létrehozni, ezért én inkább a projektekben külön-külön definiálom a privát kategóriákat, melyeket kizárólag csak az adott projektben lehet használni. Egyébként a globális kategorizálás okos dolog, csak minél bonyolultabb a vállalat, annál biztosabb, hogy nem találunk megfelelő csoportosítási szempontokat.

Menedzseljünk felhasználókat

Térjünk át a felhasználók menedzselésére. A “Felhasználók kezelése” (“Manage Users”) oldalon tehetjük meg, hogy az eddig felvett felhasználók adatait szerkesztjük, vagy új felhasználót rögzítsünk. Túl sok személyes adatot nem tárol a rendszer a felhasználókról, csak az email címét (az esetleges értesítések végett), jogosultságát, felhasználói nevét és rendes nevét. Ellenben mikor belépünk egy felhasználó oldalára (a felhasználói listában rákattintunk a nevére), ott már tudjuk állítani a projektjeit, jelszavát és különböző rendszer beállításait (melyik lesz az alapértelmezett projektje, milyen email értesítéseket kapjon, milyen időzónát és nyelvet használ) Minden felhasználónál külön beállíthatjuk az eszköz nyelvét. A Mantis kb. 50 különböző nyelven elérhető, melyek között megtalálható a magyar is. A fordítás nem tökéletes, mert pár helyen angolul jelenik meg a szöveg, de a főbb funkcióknál teljes mértékben használható.

Ha nincs elég mező, gyártsunk egyet

Egyedi mezőket is adhatunk a projektjeinkhez. Beállíthatjuk, hogy milyen típusú legyen a mező, milyen értékeket lehessen beírni, mi legyen az alapértelmezett értéke, kik tudják olvasni és írni, illetve melyik oldalakon jelenjen meg és hogy kötelező-e kitölteni vagy sem. Figyeljünk arra, hogy szét van választva az ügy (hiba) bejelentésekor és módosításakor való megjelenítés. Kis logikai bukfenc van az oldal adatainak megadásainál, mivel ha nem kapcsoljuk be a megjelenítést az ügy (hiba) megadásakor, viszont bekapcsoljuk, hogy kötelező legyen ilyenkor megadni, akkor elméletileg orra kellene állnia a rendszernek. Szerencsére nem így működik, ha bekapcsoljuk a kötelezőséget, akkor automatikusan kiteszi a felületre a mezőt. Hiba lehetőség mégis van a folyamatban, ugyanis ha elfelejtünk megadni választható értékeket a listás mezőnek, akkor a kötelezőség miatt nem fogunk tudni ügyeket (hibákat) felvenni, mert nem engedi üresen hagyni az egyedi kötelező mezőnket.

A “Globális profilok kezelése” oldalon beállíthatunk előre definiált platformokat, operációs rendszereket, melyekkel megkönnyíthetjük a hibarögzítést. Nem kell miden egyes hibafelvételnél a különböző platform adatokat megadni, hanem az előre definiált listából kiválaszthatjuk azt és az értékek automatikusan beíródnak.

Jogosultságkezelés és munkafolyamatok beállítása

Számomra a jogosultságkezelés és a munkafolyamatok beállítása a legérdekesebb terület. Ezeket a “Konfiguráció kezelés” alatt találhatjuk. Kezdjük a “Munkafolyamat határértékei” oldalon. Itt beállíthatjuk, hogy a különböző eseményeket kik végezhetik el, melyik felhasználói csoportnak milyen jogosultsága van. Meg kell jegyeznem, hogy a Mantis egyik hátránya, hogy a felhasználói csoportokat nem lehet megváltoztatni. Magyarosabb lenne, ha tesztelőknek hívnánk és nem bejelentőnek, vagy frissítőnek.

A “Munkafolyamat átmenetei” oldalon két dolgot is meghatározhatunk. Megadhatjuk, hogy melyik státuszból melyik státuszba állítható egy hiba, vagyis felépíthetünk egy hiba életciklust. Ez a rész nagyjából rendben van, mivel táblázatos formában, jelölő négyzetekkel nagyon egyszerűen és átláthatóan lehet meghatározni az átmeneteket. Az oldalon beállíthatjuk, hogy az adott státuszokba melyik jogosultsági csoportba tartozó személyek állíthatják a hibákat. Sajnos itt megint van egy apróbb problémája az eszköznek, mivel a felhasználói csoportokat egymás felé rendezi egy előre definiált, beégetett sorrendben. A fejlesztőt a tesztelő fölé helyezi. Ez akkor okozhat gondot, ha a hibákat csak a tesztelőknek hagyjuk lezárni. Mivel a megadásnál a minimális szintet kell megjelölni (jelen esetben a tesztelő) és az összes többi felette lévő szint is megkapja a jogot. Mivel a fejlesztő magasabb jogokat élvez ezért nem tudjuk ezt a lehetőséget beállítani, hacsak úgy nem, hogy a fejlesztőket nem fejlesztőknek nevezzük J De akkor micsodának?

Spam küldés = NEM MENŐ

Ezeken az apróságokon túllépve lehetőségünk van még az email küldések beállítására az “Email emlékeztetők” oldalon. Mielőtt beállítanánk az email emlékeztetőknél mindent, kérdezzük meg a projekttagokat, hogy miről is szeretnének értesítést kapni!

Az admin felülettel készen is volnánk, a beállításokból már csak a felhasználói lehetőségek maradtak. Minden egyes felhasználó a “Saját beállításaim” oldalon tudja nevét, email címét, jelszavát állítani. Ezen belül még a “Beállítások” oldal lehet érdekes az átlag felhasználónak, mivel itt tudja engedélyezni az emailküldéseket, valamint állítani az alkalmazás nyelvét.

Ennyi adminisztrálás után térjünk rá az eszköz használatára. A Mantis elég könnyen kezelhető, mivel igazából csak egy hibakezelő alapvető funkcióit tartalmazza. A felhasználók amennyiben több projektben szerepelnek, úgy a jobb felső sarokban látható projekt választó gombbal kiválaszthatják az aktuális projektjüket.

A végfelhasználó kezelésbe veszi az eszközt

A hibákat több oldalon is megtekinthetjük, a “Saját nézet”, és az “Ügyek megtekintése” oldalak a hibák listáját adja, az “Összefoglalás” oldalon viszont a felvett hibák alapján többféle szempont szerint rendezve láthatunk grafikonokat, kimutatásokat.

A “Saját nézet” oldalon természetesen csak a bejelentkezett felhasználóhoz valamilyen módon köthető hibákat látjuk.

Ez most hiba, vagy feature?

Ennél az oldalnál lényegesebben többet mutat az “Ügyek megtekintése”. Itt lehetőségünk van szűrőket használni. Amennyiben van jogosultságunk hozzá, el is menthetünk szűrési feltételeket és akár publikussá is tehetjük őket, hogy mások is tudják használni. Sajnos ez a lehetőség nem mindig működött rendesen. Sokszor előfordult, hogy a felhasználó által mentett szűrés hiába publikus azt más felhasználó nem tudta használni. Az “Ügyek megtekintése” oldalon a hibákat listában felsorolva láthatjuk, melyet a táblázat fejlécével nagyon egyszerű rendezni. A táblázat oszlopait sajnos nem tudjuk bővíteni, pedig sokszor jó lenne különböző nézeteket beállítani. A felvett hibákat módosítani könnyen és egyszerűen lehet a nevére vagy az előtte megjelenő ceruza ikonra kattintva. Itt a részletező oldalon szerkeszthetjük a hibák alapadatait, megjegyzéseket írhatunk hozzá, fájlokat csatolhatunk, valamint megnézhetjük a hiba történetét. Egy furcsa működés van, hogy a felvitt megjegyzéseket bárki törölheti. A history-ban nem jelenik meg a megjegyzés tartalma, csak az azonosítója, így csak csínján a törléssel! A fájl feltöltésénél vigyázzunk, mert hiába van kiírva, hogy max. 5,000 k, a feltöltés megkezdése előtt nem végez ellenőrzést rá, így könnyen belefuthatunk egy rendszer elszállásba. Többségük általában hibaüzenettel fejeződik be, de rendszer összeomlást is elő lehet vele idézni.

Van pár olyan hiba az alkalmazásban, amely fejtörést okozhat, például a karbantartás oldalon beállított “ügy törlése” opciónál a bejelentőnek nincs joga törölni, viszont ennek ellenére bejelentő jogosultsággal simán kitörölhetünk hibákat a rendszerből. A másik, hogy megfelelő jogosultsággal lezárt hibához is lehet pluszban megjegyzéseket írni. Van még pár, de mint minden eszköznél itt is meg lehet tanulni és megfelelő használat mellett együtt lehet velük élni.

Van még egy fontos oldal ez az “Összefoglaló”. Itt megtekinthetjük különböző szempontok szerint a felvett hibákat. Grafikonokat készíthetünk, és különböző riportokat generálhatunk belőlük. A menedzsment felé bemutatott statisztikák összeállításához nagyon fontos oldal.

Összefoglaló

Amennyiben a Mantis-t használjuk hibakezelésre, készüljünk fel, hogy egy elég merev keretek között működő, de azért sokféle beállítást nyújtó alkalmazást fogunk használni. Ha az eszköz által felajánlott lehetőségek elegek számunkra, akkor mindenféleképpen jó választásnak bizonyulhat a rendszer. Ám ha több folyamatot, csoportot, jogosultságot szeretnénk kezelni, akkor ne a Mantis-t válasszuk.

A projektjeim kapcsán állandóan belebotlok a Mantis-ba, de az eltelt évek alatt soha nem éreztem úgy, hogy bármilyen szinten is megragadott volna ez az eszköz. Nagyon sokan azért használják, mert tényleg nincs gond a telepítésével, nagyszerű magyar fordítása van, és mind a belső emberek, mind a felhasználók könnyen megtanulják a használatát. Az alapbeállításokkal vígan el lehet éldegélni. Gyakorlatilag a döntés után pár perccel már működő, kész hibakezelő rendszerünk lehet.

Ami szerintem a legnagyobb hátránya az eszköznek, hogy egyrészt csak az előre beépített hibastátuszokat lehet használni, új hibastátuszt nem lehet létrehozni és beépíteni a folyamatba, másrészt a felhasználói csoportok/jogosultságok is előre definiáltak. Lehet, hogy adatbázisból hátulról meg lehet ezeket oldani, de ezt még eddig nem próbáltam.

Értékelés (1-5)

Telepítés: 5

Testre szabhatóság: 3

Használhatóság: 3

Design: 3

Összkép: 3

MantisTouch

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

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

Elsőre azt hittem, hogy találtam valami nagyon jó dolgot. De pár perc elteltével rádöbbentem, hogy mégsem. Egy kis öröm, de nagyobb csalódás a MantisTouch.

A sokak által ismert Mantis issue-kezelőt fejlesztő társaság nemrégiben piacra dobott egy mobilra optimalizált alkalmazást. Érdekes módon nem egy native mobil applikációt fejlesztettek, hanem egy böngészőben futtatható alkalmazással jöttek ki.

A demo verzió kipróbálása vegyes érzelmeket váltott ki.

A verzió stabilan működik, a felülete átlátható és könnyen használható, és valóban mobilra optimalizált. A funkcionalitás viszont csak arra terjed ki, hogy különböző projektekbe issue-kat vehessünk fel és listázhassunk ki. Szerintem pont nem ez lenne a fontos, mivel a hibákat akkor rögzítjük, amikor dolgozunk, tehát valószínűleg van előttünk számítógép (még akkor is ha mobil alkalmazást tesztelünk). És valószínűleg a gépen tízszer gyorsabban gépel az ember, mint a telefonon. Nagyon kevés olyan helyzetet tudok felhozni, amikor a telefonon vesszük fel a hibákat.

Engem jobban érdekelt volna, hogy egy-egy riportot, listát hogyan tudok generálni, de sajnos ilyen funkcionalitás nincs a rendszerben. Az issue-k listás nézetében három opció közül választhatunk:

  • a nyitott hibákat láthatjuk
  • a fontos hibákat láthatjuk
  • vagy mindent látni akarunk

Ennél azért több lehetőséget is fel lehetett volna ajánlani a felhasználóknak. Pláne úgy, hogy az alkalmazás használatáért egyszeri 100 dollárt kérnek el. Vagyis ekkora összegért tudjuk a saját szerverünkre-adatbázisunkra hangolni a szoftvert. A nagyobb funkcionalitással még meg is érné a pénzt, de így nem vagyok benne biztos.

Amennyiben ez egy komolyabb fejlesztés első lépése, úgy üdvözlendő a dolog, de az biztos, hogy nagyon sok fejleszteni valója lesz még a csapatnak.

A tesztelő lusta?

2013.01.17. 11:38 | p_jano | Szólj hozzá!

Címkék: tesztelés szoftvertesztelés

Sokan vannak azon a véleményen, hogy a tesztelők lusták. Akár igazuk is lehet, mivel számos esetben a tesztelőkön semmilyen kontroll nincs. Most biztosan több tesztvezető is azt gondolja, hogy de én igenis irányítom a csapatomat, és számon kérem a napi munkájukat. Ez rendben is van, na de nem egy helyen megfordultam már én is, tehát tudom azt, hogy mivel a tesztvezető több projektet is irányít, az egyes projektek mindennapi történéseibe már nem lát bele. Sokszor az a helyzet, hogy a vezető meetingekre jár, terveket készít, beszámolókat tart, kapcsolatot ápol, míg a tesztelő végzi a projekt tesztelését. Bármikor is kérdezik meg tőle, hogy "Józsikám", hogy állsz a teszteléssel, barátunk azt mond, amit akar. Akkor is, ha van tesztmenedzsment eszköz, ha van hibakezelő eszköz, ha bármilyen módon dokumentálva van az ő munkája, akkor is tud úgy "füllenteni" a főnöknek, hogy az ne vegye észre.

Ha a tesztelő nem talált meg egy hibát és netán felelőségre vonják, akkor jöhetnek a kifogások:

  • a specifikáció nem volt egyértelmű,
  • nem volt tesztadat, 
  • nem volt tesztrendszer, 
  • későn került ki a build, 
  • nem volt elég idő a tesztelésre, 
  • én néztem, de pont akkor, pont ott, pont jó volt, nem is értem a másik rendszeren miért rossz,
  • biztos beállítási probléma,
  • stb..

Tesztvezető legyen a talpán aki az összes kifogást le tudja ellenőrizni.

Nem azt állítom, hogy minden tesztelő ilyen mentalitással dolgozik, de ha belefutunk egy ilyenbe akkor problémáink akadhatnak. 

Ilyen helyzetekben általában segítenek a mérések, mérőszámok.

Szubjektíven mindenki meg tudja mondani, hogy ki a leggyengébb a csapatban. Csak ezt a mérést a feletteseink nem mindig fogadják el. A számomra legkönnyebben használható objektív mérés, amikor a hibák számát hasonlítjuk össze.

Számoljuk össze a tesztelő által elkapott hibákat, és az összes bejelentett hibát. Ezek aránya már lehet egy mérőszám. Ha finomítani akarjuk, akkor a tesztelő által elkapott hibákat az összes olyan hibával hasonlítsuk, melyeket a tesztkörnyezeten is lehet reprodukálni. Ezzel kiszűrhetünk beállítási problémákat. A körülmények figyelembe vételével még tovább szűkíthetjük az összes hibák számát, ha kivesszük belőle azokat, amelyeket a tesztelőnek eleve nem kellett nézni, vagy nem volt hozzá elég ismerete. Pl.: üzleti folyamatok hibái, melyekhez mély üzleti tudás kell, amellyel a tesztcsapat tagjai nem rendelkeznek, tesztadatok hibái, stb.

A képlet finomításával azt lehet elérni végső soron, hogy összeszámoljuk mennyi olyan hiba van, amelyet elkapott és mennyi amelyet - habár meg kellett volna találnia de - nem fedezett fel a tesztelő. Ezek aránya adja meg a tesztelő munkavégzésének hatékonyságát.

Tesztelés a gyakorlatban magazin

2012.12.19. 22:11 | p_jano | Szólj hozzá!

Címkék: média tesztelés szoftvertesztelés

Megjelent a Tesztelés a gyakorlatban magazin legújabb száma.

2012_4.jpg

Az ingyenes online verziót letöltheted a weboldalról: www.tesztelesagyakorlatban.hu

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