Interjúkérdések 3. rész: Mit tennél, ha tudod, hogy a kért tesztelés (tesztesetek futtatása) nem végezhető el időben?

Bevezetés a bevezető elé

A cikksorozat régen megvolt a Passed.hu-n, de az oldal újra dizájnolása közben a cikksorozat eltűnt egy digitális fekete lyukban. Szerencsére az internet nem felejt és az internet-archivból (https://archive.org/) vissza tudtuk keresni ezeket a cikkeket. Mivel a cikkek nem vesztették el az aktualitásukat, ezért némi leporolás után újra közöljük ezeket.

Bevezető

Az interjúkérdések cikksorozat olyan várt, vagy váratlan kérdésekkel foglalkozik, amik tesztelői állásokra jelentkezve szembe jöhetnek egy interjún. Ebben a részben azon a kérdésen fogunk elgondolkodni, hogy mit tegyünk, ha látjuk, hogy egy kiadott feladatra túl kevés időnk van.
A sorozat eddigi részei:

Mire kíváncsi a kérdés?

Na, erre mi is kíváncsiak vagyunk! Derítsük ki! 🙂

Mire lehet kíváncsi egy ilyen kérdés? Tudjuk-e, hogy kötelességünk erről szólni? Vagy arra kíváncsi, hogy tudjuk-e, hogy szakmailag mi a teendő ilyen esetben? Vagy arra kíváncsi, hogy szakmailag tudunk‑e feladatot priorizálni?

Kérdezzünk, nyomozzunk, hogy be tudjuk lőni, milyen válasszal lesznek megelégedve. Járjuk körbe a témát:

  • Kik dolgoznak az adott projekten az adott feladattal, milyen szereplői vannak a projektnek?
  • Ki szabja meg, hogy mi az elvégzendő feladat?
  • Mi az oka, hogy ilyen kevés idő van és mi az oka, hogy túl sok a feladat?
  • Van-e céges vagy projekt szinten kialakított előírás, ami az ilyen helyzetekre vonatkozik? (Módszertan, Tesztterv, Stratégia…)
  • Ki a közvetlen felettes?
  • Van, akit bevonhatsz még a feladat elvégzésébe? Tud segíteni a tesztelésben a csapat, amiben dolgozol?

Megeshet, hogy a fenti kérdésekre nem kapsz válaszokat vagy a kapott válaszok nem visznek közelebb a megoldáshoz. Ne ess pánikba! (És persze mindenképpen legyen nálad egy törülköző.)

Legyél módszeres!

  1. Ha van valamilyen kialakított előírás, ami az adott helyzetre is vonatkozik, akkor azt kell betartani. (Módszertan, Tesztterv, Stratégia…)
  2. Ha nincs előírás, akkor mindenképpen jelezni kell a közvetlen felettesnek! Eszkalálj, ne te dönts!
  3. Ha az előző két válasz nem elég, akkor nem arra voltak kíváncsiak, hogy eszkalálsz-e, hanem valószínűleg valami másra kíváncsiak (csak rosszul kérdeztek :), de ezt nem áruljuk el nekik!).
  4. Nézzük mit mond a csapat ebben a helyzetben. Volt már ilyen? Akkor mi volt a megoldás?
  5. A csapatnak mi a tapasztalata, véleménye az adott feladatokkal kapcsolatban?  
  6. Nincs segítség, nincs előzetes tapasztalat, nincs csapatmódszer. Oké, szóval neked kell megoldani. Fel kell mérni a kockázatokat.
  7. Milyen kockázatokkal jár, ha nem lesz teljesen végrehajtva a tesztelés? Például nem mindegy, hogy egy élesbe állás elött vagyunk, vagy a tesztrendszeren egy apró hibajavítás után.
  8. Ha a kockázatokba nem fér bele a nem teljes tesztelés, akkor lehet az a döntés, hogy mivel részedről nem végezhető el a tesztelés, ezért nem támogatod a tesztelendő verzió kitelepítését.
  9. Ha a kockázatokba belefér a nem teljes tesztelés, akkor priorizálni kell. Többféleképpen is lehet priorizálni. Ilyen esetekben a következőket lehet megtenni:
    • Kockázatok alapján történő priorizálás. Ha a követelményekhez tartoznak kockázatok, akkor ezeket lehet sorba rendezni a legnagyobbtól a legkisebb kockázatig. Ezek mentén történhet a tesztelés
    • Lehetséges, hogy a tesztesetek vannak már priorizálva fontosság szerint, akkor ez a sorrend is használható
    • Ha nincs meglévő szempont a priorizáláshoz, akkor szokták azt csinálni, hogy előbbre veszik a pozitív utas eseteket és későbbre a negatív utas eseteket.
    • Az is szempont lehet, hogy előbb azokat a követelményeket vizsgáljuk, amik meghibásodása blokkolhatja a további működést. (Még ezen belül is lehet sorrendet felállítani, mert pl. egy bejelentkezési hiba több-mindent blokkol, mint egy alfunkció hibája.)

A teszt végén a jegyzőkönyvnek tartalmaznia kell, hogy mely tesztesetek nem lettek futtatva.

Összefoglalás

Igen, összefoglalás. 🙂 Ez szerintem fontos. Mármint az összefoglalás egy gondolkodtató kérdés végén. Amikor hangosan gondolkozol, nem biztos, hogy módszeresen a rendezett válasz jut kapásból az eszedbe. Ezért amikor már kigondolkodtad magad hangosan és nincs más, ami eszedbe jut, próbáld rendezetten összefoglalni a kimondott gondolatokat.

Találkozunk még.

Addig is: Hajrá! 🙂

Megosztás

Kérsz értesítést a legújabb cikkekről?

Kapcsolódó cikkek

20 év szoftvertesztelés után ezt látjuk minden sikeres szoftverprojektben

Húsz év és több száz projekt után az ember már nem az egyedi eseteket jegyzi meg, hanem az ismétlődő mintákat. A legérdekesebb felismerés az, hogy a sikeres szoftverprojektek mennyire hasonlítanak egymásra. Más az iparág, más a technológia, más a csapat, mégis ugyanazok az elvek térnek vissza bennük, újra és újra. A kudarcok ezzel szemben mind

T&M vagy fix projekt? Melyik tesztelési modell mikor működik jobban?

Amikor egy cég külső tesztelési partnert von be, az egyik legkorábbi kérdés nem szakmai, hanem pénzügyi: milyen konstrukcióban dolgozzunk együtt? A válasz sokszor a beszerzési reflexből születik: „adjatok egy fix árat, hogy tudjam, mennyibe kerül”. Érthető igény, de nem mindig a legjobb döntés. A fix ár és a másik klasszikus modell, a T&M (Time and

Scroll to Top

Elérhető tesztelőink

Nézze meg szakértőink profiljait, tapasztalatát és kompetenciáit, és találja meg a projektjéhez illő szakembert.

Töltse le tesztelőink szakmai profilját

Adja meg elérhetőségét egyszer és férjen hozzá valamennyi elérhető profilhoz.