Jaké otázky mám čekat na pohovoru pro inženýra kvality?
Autor: Aaron Cao · Aktualizováno
Očekávejte otázky na strategii testování (testování podle rizik, testovací pyramida, co automatizovat), automatizaci (návrh frameworku, page objecty, API a kontraktní testy, nestabilní testy), pipeline (kontrolní brány CI, prostředí, testovací data) a scénáře, jako je vydání za dva dny při selhávající sadě testů. Tazatelé hodnotí úsudek více než názvy nástrojů.
Jaké otázky na strategii testování otevírají pohovor?
Tazatelé začínají úsudkem, teprve potom nástroji. Počítejte s tím, že budete vysvětlovat, jak se rozhodujete, co testovat u funkce, kterou jste nikdy neviděli: jak čtete požadavky a změny v kódu, určujete nejrizikovější cesty, vybíráte kontroly pro úroveň jednotkových, integračních a end-to-end testů a rozhodujete, co zůstane manuální. Následující otázka bývá téměř vždy opačná: co byste netestovali a proč. Uchazeči, kteří dokážou říct, že nízkoriziková změna konfigurace vyžaduje smoke test, nikoli úplnou regresi, prokazují úsudek, který je pro tuto pozici důležitý.
- Testovací pyramida. Mnoho rychlých jednotkových testů, méně integračních testů a několik end-to-end testů. Doplňující otázka: co se pokazí, když ji tým obrátí?
- Testování podle rizik. Stanovení priorit podle pravděpodobnosti a dopadu selhání a schopnost toto pořadí vysvětlit produktovému manažerovi.
- Techniky návrhu testů. Rozdělení do tříd ekvivalence, hraniční hodnoty, rozhodovací tabulky a přechody stavů; očekávejte, že jednu techniku použijete na konkrétní vstupní pole.
- Nefunkční testování. Základy výkonu, přístupnosti a zabezpečení a znalost toho, kdy každou oblast zahrnout.
- Výstupní kritéria. Jak rozhodujete, zda je vydání připravené, a co uděláte, když termín nastane dříve, než jsou kritéria splněna.
Kdykoli to otázka dovolí, odpovězte konkrétním příkladem z vlastní práce; strategické otázky se hodnotí podle konkrétnosti.
Jak probíhají otázky na automatizaci a frameworky?
Automatizujete každý den a očekáváte, že se tazatel bude ptát na nástroje. Místo toho se bude ptát na strukturu, proto tato část probírá otázky, které odhalí, zda je vaše automatizace systematicky navržená, nebo jen nahromaděná.
- Návrh frameworku. Vrstvy mezi testy a aplikací (ovladače, page objecty nebo modely obrazovek, API klienti), sdílené fixtures, správa testovacích dat, reportování a způsob, jakým nový inženýr přidá test bez kopírování starého.
- Nestabilní testy. Oblíbená otázka. Před opakováním určete příčinu: časování a implicitní čekání, stav sdílený mezi testy, závislost na pořadí, rozdíly prostředí a asynchronní chování. Řekněte, co dáte do karantény, co odstraníte a jak zabráníte tomu, aby tým celou sadu ignoroval.
- API a kontraktní testování. Přímé testování služeb, ověřování schémat a kontrakty řízené spotřebitelem, které zachytí nekompatibilní změny dříve než end-to-end testy.
- Otázky na nástroje. Selenium, Playwright, Cypress nebo mobilní framework; REST klienti; nástroj pro zátěžové testy. Tazatelům záleží méně na tom, který používáte, než na tom, proč jste si ho vybrali a jaké má limity.
- Programování. Očekávejte napsání malého testu nebo pomocného nástroje v jazyce Python, Java, JavaScript či C# a otázku, jak byste otestovali funkci s několika hraničními případy.
Propojte odpovědi: framework s jasnými vrstvami umožňuje diagnostikovat nestabilní testy a kontraktní testy dovolují udržet vrstvu end-to-end testů malou.
Jak vypadají otázky na CI a scénáře vydání?
Ve výběrových řízeních na seniorní pozice dostanete konkrétní situaci. Typický příklad: inženýr kvality ucházející se o seniorní pozici ve společnosti vyvíjející zdravotnický software se dozví, že vydání proběhne za dva dny, sada end-to-end testů je už týden neúspěšná a vývojáři tvrdí, že selhání způsobuje prostředí. Silná odpověď nejprve rozdělí selhání podle příčin a až poté řeší vydání: prozkoumá výsledky, oddělí problémy prostředí od skutečných defektů, ověří, zda neúspěšné testy pokrývají změny v tomto vydání, a manažerovi vydání místo prostého ano či ne předloží vyhodnocení rizik. Tazatel hodnotí třídění problémů a komunikaci.
Další opakující se scénáře: návrh kontrolních bran CI, aby pull request spouštěl jednotkové a kontraktní testy, zatímco pomalejší sady běží podle plánu; správa testovacích prostředí a dat tak, aby testy nezávisely na jediné sdílené databázi; rozhodování, jak testovat změnu integrace se službou třetí strany, kterou nemůžete ovládat; hlášení defektu, který vývojář zpochybňuje; a měření kvality bez toho, aby se pokrytí stalo samoúčelným cílem. V každém případě popište omezení, zvolte mechanismus a uveďte jeho náklady.
Tyto odpovědi se výrazně zlepší, když si je vyslovíte nahlas a projdete doplňující otázky, k čemuž slouží režim simulovaného pohovoru; další sady pro jednotlivé role najdete v části otázky na pohovor podle role a tématu.
Může při pohovoru pomoci AI asistent?
U konverzačních kol ano, v rámci poctivých mezí. Nativní desktopová aplikace SubcueAI pro macOS a Windows zachycuje systémový zvuk i váš mikrofon a zobrazuje stručné návrhy odpovědí v místním překryvném okně. Když se tedy tazatel zeptá, jak byste diagnostikovali nestabilní sadu testů, máte při popisování vlastních zkušeností kontrolní seznam na obrazovce. Rozšíření prohlížeče pokrývá hovory v kartě prohlížeče Chrome a Edge a zachycuje pouze zvuk z karty se schůzkou. K hovoru se nepřipojuje žádný bot a do stránky schůzky se nic nevkládá; postup nastavení najdete na stránce s návodem.
Omezení: domácí úkoly, hlídané programovací úlohy, nahrávané obrazovky a firemně spravované notebooky jsou mimo rozsah použití a živé cvičení, při kterém pod dohledem píšete test, je vaší vlastní prací. Aaron Cao, zakladatel SubcueAI, popisuje produkt jako nápovědu k tomu, co už víte, nikoli jako scénář, a proto vychází z vašeho životopisu a vašeho vlastního způsobu vyjadřování. Nejprve tento životopis nahrajte; profil se nachází v nástroji pro tvorbu životopisu.