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

Teszteszközök adminisztrálása II.

2010.08.12. 09:00 | p_jano | 6 komment

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

Az úgynevezett időtálló paraméterek (workflow, jogosultság csoportok, stb.) beállítása után foglalkozzunk egy kicsit az eszközök folyamatos adminisztálásával. Ez miből állhat? 

Ideális esetben ez kimerül a projektek és felhasználók karbantartásával. Viszont amennyiben olyan eszközünk van, amelyben nem lehet tisztességesen beállítani a folyamatokat, akkor gyakran fognak kérni tőlünk különböző hibákkal, tesztesetekkel összefüggő karbantartási feladatokat. (Például XY kéri, hogy állítsuk át a hiba státuszát valami másra, mert azt ő nem tudja megtenni a jogosultságából kifolyólag.) Lehetőleg arra törekedjünk minél kevesebb ilyen feladatunk legyen.

 

Térjünk vissza a projektekre és felhasználókra.

Feladatunk lesz a projektek felvétele, módosítása, netán törlése(!) (természetesen szigorúan csak logikai), valamint ugyanezen munkák a felhasználói oldalon is. Általában azzal nem is szokott gond lenni, hogy létrehozzuk a projekteket és a felhasználókat, mivel ez a mi érdekünk is. (Mármint az emberek tudjanak dolgozni egy-egy projektben.) 

 

Viszont meg sem tudom számolni, hogy hányszor találkoztam olyannal, hogy az adott projektbe még a befejezés után évekkel is be tudott lépni a tesztelő. Vagy olyan projekttag, akinek egy időben rá kellett látni a rendszerre de utána semmi köze nem volt a projekthez. Az illető a  feladat elvégzése után is bármikor beléphetett, megnézhette, hogy mi történik a projekten.

 

Tudom ez már inkább biztonsági probléma (de a mi hatáskörünkben van), de ne csak a létrehozást csináljuk rutinszerűen, hanem az eltávolítást, törlést, vagy tiltást is. Mindig csak azok az emberek érhessék el a projekt tesztelési információit, akik éppen ezzel foglalkoznak, szükségük van rá.

 

A legdurvább, ha a cég elhagyása után is nyugodtan használhatja a rendszert, mert senki nem tiltotta le őt.

 

További napi feladatokat generálhat az olyan eszköz, amelybe beragadnak felhasználók ezáltal foglalva a licencek számát, vagy amelyik hektikusan, vagy furcsán működik. Lehetőségünk szerint próbáljuk kerülni ezeket a helyzeteket, ha nem tudjuk, akkor sajnos ezekkel a feladatokkal és a rájuk fordított idővel is számolnunk kell.

 

A bejegyzés trackback címe:

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

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.

szlj 2010.08.12. 11:00:08

"Lehetőleg arra törekedjünk minél kevesebb ilyen feladatunk legyen." Admin jogot mindenkinek! Vagy lehet ezt másként is?
"...az adott projektbe még a befejezés után évekkel is be tudott lépni a tesztelő." Ez baj? Végül is történelmet írunk, nem? Szerintem akkor baj, ha módosítani is tud. Abból nem származhat probléma, ha valaki lapozgatja az elmúlt munkáinak az eredményeit. Sőt! Időnként azt tapasztalhatja, hogy két éve már megoldott egy olyan problémát, ami most megint előjött valahol máshol.
"az olyan eszköz,... amelyik hektikusan, vagy furcsán működik" minél hamarabb kidobandó. Persze, csak ha lehetséges. Nálunk azért nem állt át JIRA-ra a hibakezelés, mert a vezetés ragaszkodik a régi "jól bevált" eszközhöz.

Nem a tárgyhoz:
Elnézést, hogy hosszan hallgattam. Valamiért nem ismert fel az index. Végül mi lett a tesztelő csapatok munkájának összehasonlításával? Szívesen olvasnék erről, ha publikus.

p_jano 2010.08.13. 11:48:17

@szlj: Azzal lesz kevesebb feladatunk egy eszköz karbantartásánál, ha az eszközt összehangoljuk a tesztelési folyamattal és fordítva. Pontosan az időtálló, statikus paramétereket kell jól megcsinálnunk, kialakítanunk (workflow, csoportok, jogosultságok, beviteli mezők, előre definiált szűrések, előre definiált riportok, ...), hogy ne kelljen naponta ilyen feladatokkal bajlódnunk. Legfőképpen természetesen a jogosultságokon és a workflow-n van a hangsúly, ezekből szoktak generálódni azok a hibák, melyeket kizárólag az "admin" közreműködésével lehet kiküszöbölni. Ha helyesen van lemodellezve az eszközben a tesztelési folyamat, kevés ilyen feladat fog generálódni.

Igaz attól, hogy belép még nincs probléma. Általában a belépéssel együtt már módosítani is tud az illető. Helyesen úgy kellett volna írnom, hogy a módosítási jogát tiltsuk le. Ellenben ha már így kettévesszük a megtekintés és módosítás jogot, jobban kell figyelnünk a felhasználók jogosultságaira. Nagyobb a hibalehetőség, hogy egy olyan felhasználó marad bent a rendszerben, aki már nem jogosult a rendszer használatára, a projektek megtekintésére. Éppen ezért szokták pofonegyszerűen letiltani az összes lezárt projektről az embereket.

p_jano 2010.08.13. 11:54:47

@szlj: A tesztelők munkájának objektív összehasonlításából mai napig nem valósult meg semmi. Szubjektív vélemények vannak, de objektív nézőpontokat, pontozási rendszert, alkalmas mérőszámokat, még nem találtak ki az erre kijelölt személyek.
Szkeptikus vagyok ezzel kapcsolatban, nem hiszem hogy lenne megoldása a problémának. Pontosan ezért vetettem fel itt a blogon is, hátha valaki irányt tud mutatni.

szlj 2010.08.14. 22:13:45

Abban egyetértek, hogy egy jól definiált (és betartott/betarttatott!) workflow szárnyakat tud adni a munkának. Cserébe ugyanúgy tönkre is teheti a projektet. Kedves példám erre az a vasutas tiltakozó megmozdulás, amiben semmi mást nem tettek, csak mindent pontosan az utasítások szerint hajtottak végre. Részt vettem benne: állt minden.

Még egy szempont jutott eszembe, amikor elgondolkodtam a fentebb írtakon. Egy-egy ilyen beállítás, hangolás, adminisztráció, és lezárás (amikor pl. a projektből kilépőktől elvesszük a jogosultságokat) mennyi időre szól?
Arra gondolok, hogy az egy hetes lefutású ("villám")projektért, vagy akár a hat hónaposért is érdemes-e mindezzel vesződni? A ráfordított időért mit kapunk cserébe, amit egy verziókezelt dokumentum (word, vagy excel) nem tud adni?

p_jano 2010.08.18. 21:07:42

@szlj: Ha jól értem a kérdést, akkor azt találod problémásnak, hogy egy 1 hetes projekttel sokat kell vesződni, érdemes lenne inkább a sok adminisztráció helyett egy excel/word doksit létrehozni és azt szerkesztenie a projekttagoknak. Igaz?

Csak ismételni tudom magam, amennyiben a workflow és a jogosultság rendesen be van állítva, úgy kizárólag a projektet kell létrehozni, majd a felhasználókat hozzárendelni a projekthez és megadni a projekten lévő jogosultságukat. A projekt létrehozása egy meglévő alapján kb 5 perc. A mezők értékkészletének feltöltése kb 10 perc. A felhasználók és jogosultságaik beállítása kb 5 perc. Az esetleges új felhasználók adminisztrálása fejenként 2-3 perc. A törlés/kitiltás meg fejenként egy kattintás. (Az egész ha több mint fél óra, akkor nem jó eszközt használunk, vagy nincs megfelelően beállítva.)
Az 1 hetes projektnél valószínűleg nem 30 felhasználót fogunk felvenni és kezelni a projektben, így nem kell horribilis adminisztrációs idővel számolni. A lényeg, hogy pár perc alatt elkészíthetjük a kontrollált kereteket és elkezdődhet a munka.

Ha lehet választani, hogy egy kontrollált eszközben menjen a munka, vagy egy bárki által szerkeszthető excel/word fájlban, akkor én az elsőre szavazok. Pláne ha az csak pár perces időráfordítást igényel.

Ahol több mint 1 ember dolgozik, több mint 1 napig és mindenki a saját feje után megy, abból nem lesz semmi. Én személy szerint minden egyes miniprojektnél kötelezővé szoktam tenni egy menedzsment eszköz (de minimum egy hibakezelő) használatát.

De lehet már annyit beszéltünk róla, hogy egy új bejegyzést is kezdhetek belőle. :) Valami olyasmi címmel, hogy mi a különbség egy verziókezelt doksi és egy hibakezelő/tesztmenedzsment eszköz között. :)

szlj 2010.08.19. 10:43:21

@p_jano: Támogatom!
Félreértés ne essék: nem vagyok az excel táblák apostola, de olyan emberekkel dolgozom/dolgoztam, akik igen. Most csak érveket gyűjtök, hogy többé ilyen szégyen ne fordulhasson elő velem. :)
süti beállítások módosítása