Quali sono i buoni requisiti per un ingegnere di qualità? [chiuso]

A meno che tu non abbia molta esperienza di lavoro con i tester, leggi i primi capitoli di "Testing Computer Software" di Cem Kaner per avere un'idea del tipo di termini che vuoi ascoltare: test al contorno, test degli errori, test del percorso felice , funzionale, prestazioni, sicurezza, integrazione, ecc. Se non riesci a parlare la lingua, non sarai in grado di condurre un buon colloquio.

Fornisci loro una specifica per un piccolo pezzo del tuo sistema. Chiedi loro di provarlo. Stai cercando un'organizzazione di pensiero e la loro capacità di elaborare test interessanti. Volete vederli separare le aree di test in modo ordinato, e poi approfondire in ogni area, escogitando casi di test sempre più interessanti. I tester davvero bravi possono farlo per ore con tutti, tranne i problemi più banali, quindi potresti doverli tagliare e farli passare a un'altra categoria per avere un'idea del loro modo di pensare.

Descrivi il comportamento causato da un bug reale nel tuo sistema che era piuttosto difficile da capire. Chiedi loro cosa farebbero se vedessero questo bug 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 debug molto più facile per gli sviluppatori, dal momento che hanno una migliore ipotesi su ciò che ha causato il problema e dimostra 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.

Offri loro un semplice programma a riga di comando che hai violato (magari inseminato con bug) e una semplice specifica, e permetti loro di sedersi al computer e giocare con esso, con l'obiettivo di trovare problemi. Qui stai cercando la creatività e la capacità di indirizzare le aree problematiche. Dovrebbero testare cose come grandi input, piccoli input, strani input, input vuoti. Se trovano un bug, chiedi loro di provare a capire esattamente quando si verifica l'errore (di nuovo con la riduzione del bug!).

Chiedi loro cosa farebbero se un SDE rispondesse a un bug con "No Repro" o "Will Not Fix", se pensavano che il bug fosse importante. Qui stai cercando qualcuno che non sarà solo un pushover, ma non sarà nemmeno antagonista. Le risposte ragionevoli includono l'aggiunta di scenari di esempio che dimostrano più chiaramente la gravità del bug e poi 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 loro della tua applicazione ad alto livello. Chiedi loro quali tipi di test vorremmo eseguire. Qui siete alla ricerca di aree generali di test come test dei componenti funzionali, test di integrazione, test delle prestazioni, test di sicurezza.

Se questo è un SDET / ingegnere dell'automazione, dai loro alcune domande di intervista per gli sviluppatori con circa 1/3 della metà dei loro anni di esperienza.

Se questa è la tua prima persona di QA, assicurati che possa auto-avviarsi. Chiedi loro come immaginano la loro prima settimana al mese di lavoro. Dovrebbero dire qualcosa su come raccogliere i requisiti e impostare gli strumenti, quindi descrivere un approccio ragionevole per iniziare a testare. Stai cercando qualcuno che non abbia bisogno di un capo per dirgli come iniziare a testare e può autogestirsi. Se hai già uno staff di controllo qualità, questo è meno importante.

Quello che faccio quando ho intervistato i candidati del QA è chiedere loro di delineare una strategia di test per un'applicazione. Di solito gli do il mio telefono e scelgo un'app con funzioni limitate, o lascia che scelgano 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 vediamo in che modo hanno la priorità.

Chiedo anche a loro quando il software è abbastanza buono da essere spedito, come gestire le situazioni in cui PM o dev non ritiene che un bug sia importante, ma lo fanno. Scenari di sviluppo del prodotto tipici.

Queste sono per le posizioni di QA non codificanti. Codifica le posizioni QA Fornisco loro un'intervista combo di sviluppo / test.

Chiedi loro come progetterebbero i piani di test. Chiedete loro se hanno esperienza nell'uso dei test di regressione e come l'hanno fatto in questo caso. Chiedete loro come vanno a testare un'interfaccia utente. Chiedete loro come farebbero per testare le importazioni di dati che non passano attraverso l'interfaccia utente (se fate così). 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) trovato e come l'hanno trovato.

Prima di iniziare l'intervista, cerca alcuni dei libri là fuori sui test e abbassa un po 'su cosa dovrebbe fare una persona del QA. Ciò ti aiuterà a valutare le loro risposte.

Inoltre, stai cercando anche una buona personalità. Non vuoi una persona di controllo qualità che è un pushover, ma non vuoi neanche un bullo o uno stronzo. Ma tu vuoi qualcuno che si faccia da padrone quando le cose vanno male e non solo approva tutto perché la direzione vuole rispettare una scadenza. Vuoi qualcuno che lavori 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 di assistenza sanitaria saprà delle cose per testare che qualcuno proveniente da un altro campo potrebbe non essere a conoscenza.

Immagino che non ci si possa aspettare che abbiano una conoscenza seria della tecnologia - chiunque probabilmente si rifiuterà di lavorare come un 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.