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 legtöbb tesztstratégia már a projekt elején elbukik

Amikor egy projekt a végén minőségi gondokkal küzd, a reflex szinte mindig ugyanaz: a tesztelést okoljuk. „Nem teszteltek eleget”, „átcsúszott egy hiba”, „a QA nem fogta meg”. Kényelmes magyarázat, mert a folyamat legvégére mutat, oda, ahol a baj láthatóvá vált. Pedig a valódi ok gyakran nem a tesztelésben rejlik. Maga a tesztstratégia dönti el jó

AI rendszerek tesztelése: miért teljesen más, mint egy hagyományos szoftveré?

Egyre több cég épít AI funkciót a termékébe: chatbotot az ügyfélszolgálatra, ajánlórendszert a webshopba, dokumentumfeldolgozót a háttérfolyamatokba, döntéstámogatót a szakértői munkába. A vezetők jó része ilyenkor ugyanúgy áll a teszteléshez, mint bármely más szoftvernél: „írjuk meg a teszteseteket, nézzük meg, átmegy-e”. Csakhogy egy AI rendszer másképp működik, és ami fontosabb: másképp is hibázik. Ezért másképp

AI által generált kód = új QA kihívások

Az AI asszisztensek (a GitHub Copilottól a különféle nagy nyelvi modellekig) néhány év alatt a szoftverfejlesztés mindennapi eszközévé váltak. Egy funkció, amelynek megírása korábban órákba telt, ma percek alatt elkészül. A fejlesztői produktivitás növekedése valós és mérhető. Csakhogy a sebesség önmagában megtévesztő mutató. A kód gyorsabb megírása ugyanis nem jelenti azt, hogy a kód jobb

Scroll to Top

Töltse le tesztelőink szakmai profilját

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