Test Case di progettazione e la responsabilità di tester, sviluppatori, clienti [chiusa]

Question

Così sembra che un sacco di persone stanno giocando il gioco di colpa in giro dove lavoro, e si porta in primo piano una domanda interessante.

knowns:

Requisiti squadra scrive requisiti per il prodotto. Sviluppatori creano i propri test di unità a seconda delle esigenze. team di testing crea Condizioni di prova, test design e test case in base alle esigenze.

rilasciato prodotto se e solo se X% dei casi di test dal team di test passa.

Dopo la consegna al cliente fa Prove di accettazione -.> Team di risposta cliente ottiene insetti dal campo, e lascia che il team di testing sapere su questi temi

Domanda:

Se il cliente finisce per il deposito di un sacco di difetti, chi è la colpa? E 'la squadra test per non coprire chi? O è la squadra requisiti per non scrivere i requisiti migliori? E come si fa a perfezionare il regime?

Answer 1

L'affermazione "prodotto rilasciato se e solo se X% dei casi di test dal team di test passa" davvero mi dà fastidio. La squadra può prendere in considerazione avere migliori criteri di rilascio che è recintato su più di un semplice tassi superare il test. Ad esempio, sono noti gli scenari, compreso, rappresentato (e testato)? Certamente non tutti i bug saranno risolti, ma sono quelli che sono stati rinviati o meno fisse stati analizzati e suddivisi in modo corretto? Avete raggiunto i vostri obiettivi di performance testing e di stress? Hai minaccia modellato e rappresentano il mitigazioni a potenziali minacce? Avere x quantità di clienti (interno / esterno) schierato build e fornito un feedback prima del rilascio (cioè "dogfood")? Non gli sviluppatori a capire gli insetti provenienti dal campo e il tester per la creazione di unit test di regressione? Il team di requisiti capire questi bug in arrivo per vedere il motivo per cui gli scenari non sono state contabilizzate? Ci sono punti di integrazione fondamentali tra caratteristiche che non sono state valutate in specifiche, lo sviluppo, o test?

Alcuni suggerimenti per la squadra sarebbe quello di fare prima l'autopsia sui problemi riscontrati e capire dove si è rotto, e si sforzano di spingere qualità a monte, per quanto possibile. Assicurarsi che i requisiti di squadra, sviluppatori e tester comunicano frequentemente e bene durante la progettazione, dev, e il ciclo di test per assicurarsi che tutti sono sulla stessa pagina e sa chi fa cosa. Si sarebbe stupito di quanto la qualità del prodotto può essere acquisito quando la gente in realtà parlano tra loro in fase di sviluppo!

Answer 2

I bug possono entrare nel sistema ad entrambe le esigenze e le fasi di sviluppo. Il team di requisiti potrebbe fare qualche errore o di semplificare eccessivamente le assunzioni durante la creazione dei requisiti, e gli sviluppatori potrebbero fraintendere i requisiti o fare le proprie ipotesi.

Per migliorare le cose, il cliente deve firmare i requisiti prima di procedere dello sviluppo, e dovrebbe essere coinvolta, almeno in una certa misura, in fase di sviluppo di monitoraggio per garantire le cose sono sulla strada giusta.

Answer 3

La prima domanda nella mia mente sarebbe, "come fanno i difetti stack contro i requisiti?"

Se il requisito di legge, "OK dovrebbe essere blu" e il difetto è "OK è verde", avrei la colpa sviluppo e test - in modo chiaro, né leggere i requisiti. D'altra parte, se il reclamo è, "pulsante OK non è gialla", chiaramente, c'è stato un problema con la raccolta dei requisiti o il vostro processo di cambiamento di controllo.

Non c'è una risposta semplice a questa domanda. Un sistema può avere un gran numero di difetti con la diffusione delle responsabilità tra tutti i soggetti coinvolti nel processo - dopo tutto, un "difetto" è solo un altro modo di dire "le aspettative dei clienti insoddisfatti". Le aspettative, di per sé, non sono sempre corrette.

Answer 4

"prodotto rilasciato se e solo se X% dei casi di test dal team di testing passa" - è uno dei criteri per il rilascio. In questo caso "Copertura dei test" in TC scritto è molto importante. Ha bisogno di una buona recensione del TC se qualsiasi funzionalità o uno scenario viene saltato o meno. Se qualcosa è mancato in TC ci potrebbe possibilità di trovare bug alcuni dei requisito non è coperto in caso di test.

Ha anche bisogno di alcuni test ad hoc, nonché test esplorativo per trovare scoprire i bug in TC. Ed ha anche bisogno di definire "criteri di uscita" per il test.

Se il cliente / cliente trova qualsiasi bug / difetto è necessario indagare come: i) Che tipo di bug è trovato? ii) C'è qualche caso di prova scritta in merito a tale? iii) Se v'è banco di prova (s) in merito a tale eseguito correttamente? iv) Se è assente in TC perché è stato perso? e così via

Dopo la decisione di accertamento può essere presa che dovrebbe essere incolpato. Se è molto semplice e con gli occhi aperti bug / difetto, sicuramente i tester devono essere biasimati.