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

A tesztpiramis: a stabil és kifizetődő tesztautomatizálás alapköve

Bevezető A szoftverfejlesztés világában az automatizálás gyakran úgy indul, mint egy lelkes fellángolás: „Minden manuális tesztet váltsunk ki automata scriptekkel!” A kezdeti eufória után azonban sok projektvezető és fejlesztő szembesül a kőkemény valósággal. A tesztek lassúak, gyakran ok nélkül elbuknak, a karbantartásuk pedig több időt emészt fel, mint amennyit maga a fejlesztés. Ilyenkor merül fel

Tesztautomatizálás: mikor érdemes belevágni, és mikor várjunk még?

Bevezető A szoftverfejlesztési projektek egyik legvitatottabb kérdése nem az, hogy kell-e automatizálni a tesztelést, hanem az, hogy mikor. „Már az első naptól írjunk automata teszteket, vagy ráérünk, ha már kész a funkciók nagy része?” – hangzik el a kérdés szinte minden projektindító megbeszélésen. A válasz azonban nem egy egyszerű dátum vagy verziószám. A tesztautomatizálás ugyanis

Tesztautomatizálás útmutató: mikor, hogyan és miért érdemes bevezetni?

Szoftvert fejleszteni ma már nem csak kódolást jelent. Egy termék sikere legalább annyira múlik azon, hogy a kiadás pillanatában stabilan, hibamentesen és megbízhatóan működjön, mint magán az ötleten. Ahogy az IT projektek egyre komplexebbé válnak, a hagyományos, tisztán manuális tesztelés egyre kevésbé tud lépést tartani a fejlesztés tempójával. Eljön a pont, amikor a tesztelés már

Scroll to Top