Condivisione dei casi di test di sviluppo (unità e integrazione dello sviluppo) con il team QA (test)?

Quando il tuo team di sviluppo e il tuo team di QA non parlano tra loro, c'è il rischio che alcuni test vengano eseguiti inutilmente due volte e altri vengano dimenticati. Uno scenario peggiore si verifica quando il tuo team di sviluppo ha implementato alcuni test di integrazione automatica, eseguiti in pochi minuti o ore, e le persone addette al QA verificano le stesse cose manualmente, impiegando giorni o settimane per tale attività. Un altro brutto scenario è quando entrambi i gruppi pensano che l'altro gruppo sia responsabile di alcuni tipi di test, e quindi tali test vengono omessi.

Quindi, supponendo che entrambi i gruppi lavorino come una squadra e non uno contro l'altro, è logico informarsi a vicenda in merito ai test effettuati da quale gruppo, e lasciare che i due gruppi coordinino le attività lì.

Testing team (the so called QA team in some organization) insists that the dev team should share their (Dev team's) test cases with them.

Certo, il controllo qualità dovrebbe avere una visione generale di ciò che è coperto dai test di unità / integrazione, e cosa non lo è.

Their arguments are Dev test cases are the starting point for the QA testing.

... anche se il loro ragionamento è difettoso. Il mantra numero 1 di una persona con QA è non si fida degli sviluppatori . "Non ti preoccupare! Ho controllato bene!" è il primo passo verso un enorme problema di produzione.

Come dice Doc Brown, non è bene spendere un sacco di tempo per il controllo di qualità su qualcosa che è ben coperto da test automatici. Ma è sconsiderato passare il tempo no a qualcosa che è ben coperto da test automatici. Ed è uno spreco sprecare un sacco di tempo a documentare i tuoi test unitari in dettaglio quando il QA non dovrebbe davvero fidarsi di loro comunque (e perché quel livello di documentazione spinge gli sviluppatori a fare test unitari meno / cattivi).

In una moderna architettura software l'intento è che i test non solo testano il codice ma lo fanno in un modo che documenta la loro funzionalità.

Questa documentazione di ciò che fa il codice (oltre a ciò che è inteso fare nelle specifiche) è utile per i QA'er per capire meglio l'intento del codice e anche se corrisponde i requisiti. È anche un'informazione utile quando i QA'er stanno scrivendo dei casi di test e questo aiuterà a dare loro un senso di ciò che, in teoria, è già stato testato. Alcune delle aree sottoposte a test potrebbero trarre vantaggio da ulteriori casi e altre potrebbero essere esposte in quanto prive di test.

I dettagli effettivi di questa esposizione dipenderanno in gran parte dall'assetto organizzativo e in particolare dalla profondità tecnica dei tester (ad esempio, leggendo il codice sorgente).

Essere un po 'controcanti ... Spesso mi piace ignorare i test degli sviluppatori e venire fuori con i miei test (io sono un membro di un grande team di QE). Ho scoperto che ignorare i test degli sviluppatori aiuta a evitare la mentalità di guardare il problema / problema / funzionalità solo dal punto di vista degli sviluppatori.

Il mio motto QE è: QE dovrebbe essere aggiungere valore testando il prodotto. "Unisci ed esegui test di unità" da solo è un QA insufficiente!

La mia prima reazione di questa domanda è "dipende".

Dipende da cosa intendi per "casi di test del team di sviluppo".

• Se hai solo test unitari (test white-box ); Il team QA (integrazione e test di sistema) non ha potuto sfruttare i casi di test. I test unitari sono lì solo per verificare la tua unità, che non soddisfa solo un requisito (soprattutto). Il test white-box non dovrebbe essere la via per l'integrazione o per i test di sistema.

• Se hai test comportamentali; Il team QA può utilizzarli per ricavare alcuni scenari di integrazione.

• Se utilizzi TDD ; come per definizione, i test sono documenti eseguibili dei requisiti, dell'architettura e del design dell'applicazione. Il team di QA avrebbe sicuramente bisogno di questi casi di test.
• Alcuni metodi di test design come il test gray-box richiedono informazioni progettuali dettagliate per isolare o simulare soggetti di test come componenti o sottosistemi (test di integrazione). È inoltre necessario condividere la progettazione dettagliata con il team di QA.
• I test di sistema non si preoccupano mai del design dettagliato. Si concentrano sugli scenari utente. Pertanto i test di sviluppo (white-box) non saranno utilizzati per loro.

La mia umile raccomandazione per il tuo caso è una valutazione di approcci agili come avere tester (QA) all'interno del team di sviluppo e test di progettazione (funzionalità, integrazione, sistema) insieme in anticipo.

Non c'è motivo per cui non dovresti condividere ciò che hai testato con il team addetto al QA, tuttavia dovrebbero duplicare i tuoi test che ritengono importanti per la corretta verifica dell'applicazione.

1) Sono responsabili per testare il codice / l'applicazione / qualunque cosa. Duplicando i test dove appropriato, verificano che il test sia stato eseguito correttamente.

2) Come sviluppatore, sei responsabile dell'unità che verifica il tuo codice (in genere, tuttavia, alcune organizzazioni hanno iniziato a testare anche il codice di sviluppo). Questo è un approccio diverso e in genere si concentra maggiormente sulla copertura dei punti decisionali in un metodo.

3) Come hai detto, è importante che il tuo team di test condivida i casi di test con te per aiutarti a pensare a casi che potresti non aver inizialmente preso in considerazione.

4) Qualcuno ha detto che è responsabilità del team di test verificare i requisiti, e mentre questo è vero, anche la progettazione dettagliata è molto utile. Avendo il design, il team di test non solo può assicurarsi di soddisfare i requisiti, ma li aiuta a comprendere alcune delle decisioni di progettazione e li aiuterà a creare casi di test migliori.