Stiamo assumendo un addetto al controllo qualità e dovrei presentare alcune domande per l'intervista. La verità è che non so molto di ciò che un buon ingegnere addetto al controllo qualità dovrebbe sapere, tanto meno di ciò che potrebbero comportare le domande di un buon colloquio. Qualcuno ha suggerimenti?
Alcune informazioni: l'ambiente è due applicazioni Web separate (ma intrecciate) per lo stack Microsoft (ASP.NET, SQL Server, IIS).
Risposte:
A meno che tu non abbia molta esperienza di lavoro con i tester, leggi i primi capitoli del "Testing Computer Software" di Cem Kaner per avere un'idea dei tipi di termini che vuoi sentire: test di confine, test di errore, test di percorsi felici, funzionali, prestazioni, sicurezza, integrazione, ecc. Se non sai parlare la lingua, non sarai in grado di condurre una buona intervista.
Fornisci loro una specifica per un piccolo pezzo del tuo sistema. Chiedi loro di provarlo. Stai cercando l'organizzazione del pensiero e la loro capacità di elaborare test interessanti. Volete vederli spezzare le aree del test in modo ordinato, e quindi approfondire ogni area, inventando casi di test sempre più interessanti. I tester davvero bravi possono farlo per ore con tutti tranne i problemi più banali, quindi potresti aver bisogno di tagliarli e farli passare ad un'altra categoria per avere una buona idea di come pensano.
Descrivi il comportamento causato da un vero bug nel tuo sistema che è stato difficile da capire. Chiedi loro cosa farebbero se vedessero questo errore durante il test. Qui, stai cercando la riduzione dei bug: la capacità di trovare il più semplice insieme di circostanze in grado di riprodurre un bug. Questo rende il debugging molto più semplice per gli sviluppatori, poiché hanno una migliore idea di cosa abbia causato il problema e dimostrano una chiara capacità di risoluzione dei problemi e una chiara comprensione di quali fattori possono interagire per causare bug. Con il tuo prodotto specifico, discutere di una condizione di gara potrebbe essere divertente.
Fornisci loro un semplice programma da riga di comando che hai hackerato insieme (magari seminato con bug) e una semplice specifica, e lasciali sedere al computer e giocare con esso, con l'obiettivo di trovare problemi. Qui stai cercando la creatività e la capacità di affrontare le aree problematiche. Dovrebbero testare cose come input grandi, input piccoli, input strani, input vuoti. Se trovano un bug, chiedi loro di provare a capire esattamente quando si verifica quel bug (di nuovo con la riduzione del bug!).
Chiedi loro cosa farebbero se un SDE rispondesse a un bug con "No Repro" o "Won't Fix", se ritenessero che il bug fosse importante. Qui stai cercando qualcuno che non sarà solo un pushover, ma anche non sarà antagonista. Le risposte ragionevoli includono l'aggiunta di scenari di esempio che dimostrano più chiaramente la gravità del bug e quindi riaprono il ticket, parlando con lo sviluppatore per cercare di capire perché le cose sono state risolte in questo modo prima della chiusura, ecc.
Parla con loro della tua applicazione ad alto livello. Chiedi loro che tipo di test vorrebbero eseguire. Qui stai cercando aree generali di test come test di componenti funzionali, test di integrazione, test delle prestazioni, test di sicurezza.
Se si tratta di un ingegnere SDET / di automazione, dai loro alcune domande di intervista per gli sviluppatori con circa 1/3 della metà della loro esperienza complessiva.
Se questa è la tua prima persona con QA, assicurati che possa avviarsi da sola. Chiedi loro che aspetto hanno la loro prima settimana al mese di lavoro. Dovrebbero dire qualcosa sulla raccolta dei requisiti e sulla configurazione degli strumenti, quindi descrivere un approccio ragionevole per iniziare i test. Stai cercando qualcuno che non ha bisogno di un capo per dire loro come iniziare i test e può autogestirsi. Se hai già personale addetto al controllo qualità, questo è meno importante.
Quello che faccio quando ho intervistato i candidati al QA è chiedere loro di delineare una strategia di test per un'applicazione. Di solito do loro il mio telefono e scelgo un'app con funzionalità limitate, oppure consento loro di scegliere qualcosa con cui hanno più familiarità. Quando elencano una strategia di alto livello (alcuni non possono), potrei chiedere loro di approfondire ed elencare alcuni casi di test.
Una volta fatto, potrei dare loro uno scenario in cui disponiamo di risorse limitate e vedere come hanno la priorità.
Chiedo anche loro quando il software è abbastanza buono da spedire, come gestire le situazioni in cui PM o dev non ritengono che un bug sia importante ma lo fanno. Tipici scenari di sviluppo del prodotto.
Queste sono per posizioni di QA non codificanti. Codifica delle posizioni QA Dò loro un'intervista com / dev / test.
Chiedi loro come progetterebbero i piani di test. Chiedi loro se hanno esperienza nell'uso dei test di regressione e in che modo lo hanno fatto. Chiedi loro come vanno su un'interfaccia utente. Chiedi loro come farebbero per testare le importazioni di dati che non passano attraverso l'interfaccia utente (se fai queste cose). Chiedi loro come avrebbero comunicato i loro problemi agli sviluppatori e come avrebbero verificato la risoluzione del problema. Chiederei loro il bug più interessante (o più difficile da trovare) che hanno trovato e come lo hanno trovato.
Prima di iniziare a intervistare, cerca alcuni dei libri disponibili sui test e analizza un po 'cosa dovrebbe fare una persona di controllo qualità. Ciò ti aiuterà a valutare le loro risposte.
Inoltre stai anche cercando una buona personalità. Non vuoi un addetto al controllo qualità che è un pushover, ma non vuoi nemmeno un bullo o un coglione. Ma vuoi qualcuno che resista al management quando le cose non vanno e non approva tutto perché il management vuole rispettare una scadenza. Volete qualcuno che lavorerà efficacemente con gli sviluppatori e che comprenda i requisiti di ciò che stanno testando. Qualcuno con qualche background nel tipo di applicazione che stai testando potrebbe essere buono. Un tester con esperienza sanitaria saprà di cose per verificare che qualcuno che proviene da un altro campo potrebbe non essere a conoscenza.
Immagino che non ci si possa aspettare che abbiano una seria conoscenza della tecnologia: chiunque abbia probabilmente rifiuterà di lavorare come banale tester.
Il meglio che puoi fare è cercare cose comuni come l'attenzione ai dettagli, la mente curiosa, l'entusiasmo per la sperimentazione e così via.