Gli sviluppatori dovrebbero essere coinvolti nelle fasi di test?

stiamo usando un classico processo di sviluppo a forma di V. Abbiamo quindi requisiti, architettura, progettazione, implementazione, test di integrazione, test di sistema e accettazione.
I tester stanno preparando casi di test durante le prime fasi del progetto. Il problema è che, a causa di problemi di risorse (*), le fasi del test sono troppo lunghe e spesso accorciate a causa di vincoli di tempo (conosci i project manager ...;)). Gli sviluppatori stanno facendo i test unitari come dovrebbero.

Quindi la mia domanda è semplice: gli sviluppatori dovrebbero essere coinvolti nelle fasi dei test e non è troppo "pericoloso"? Temo che darà ai responsabili del progetto una falsa sensazione di migliore qualità poiché il lavoro è stato svolto, ma i giorni lavorativi aggiunti avrebbero valore? Non sono molto fiducioso che gli sviluppatori facciano dei test (senza offesa, ma sappiamo tutti che è abbastanza difficile rompere in pochi clic ciò che hai fatto in giorni diversi).

Grazie per aver condiviso i vostri pensieri.

(*) Per ragioni oscure, aumentare il numero di tester non è un'opzione ad oggi.

(Solo in anticipo, non è un duplicato di Dovrebbero i programmatori aiutare i tester nella progettazione di test? Che parla della preparazione del test e non dell'esecuzione del test, dove evitiamo le implicazioni degli sviluppatori)

Esaminare la tua domanda molto letteralmente ("coinvolto in") La mia unica risposta è assolutamente inequivocabile

SÌ

Gli sviluppatori non dovrebbero mai avere l'ultima parola sul proprio codice.

Ma gli sviluppatori dovrebbero essere coinvolti nel testare il lavoro di altri sviluppatori. Fa due cose:

1. Fornisce ai test un'idea di uno sviluppatore. Ciò è dovuto sia al caso generale di sapere semplicemente quali API vengono probabilmente utilizzate in un determinato momento, quali eccezioni possono derivare da tali API e come dovrebbero essere gestite. Aiuta anche su un progetto specifico perché gli sviluppatori ottengono molta più esposizione alle varie discussioni sul perché qualcosa viene fatto rispetto al normale QA, il che significa che potrebbero individuare casi limite che il QA non farebbe. È anche probabile che i bug individuati da uno sviluppatore siano più economici da correggere perché di solito uno sviluppatore fornirà più informazioni e maggiori informazioni su come risolverlo immediatamente.
2. Fornisce allo sviluppatore un'esposizione a parti dell'applicazione a cui altrimenti non potrebbe ottenere esposizione. Questo li renderà gli sviluppatori migliori per quell'app nel lungo periodo. Quando so come viene consumata la mia API, sono molto più bravo ad anticipare la prossima cosa che dovrei fare rispetto a quando sto solo guidando fuori da una specifica. Ancora più importante, posso dire quando le specifiche sono sbagliate prima di iniziare a programmare se conosco l'applicazione e il suo utilizzo.

Infine, perché non dovresti usare il maggior numero di occhi possibile? Raramente puoi permetterti di passare attraverso il processo di assunzione e di imbarco per coinvolgere altre persone addette al controllo qualità per un periodo di crisi. Quindi, dove trovi gli occhi extra di cui hai bisogno? O provi a superare il tempo di crisi con lo stesso numero di QA che hai avuto da sempre? Anche se gli sviluppatori impiegano il 20% del loro tempo a testare e l'80% a correggere qualsiasi bug si presenti, sono ancora più occhi sull'app di quelli che avevi prima. I test automatici offrono solo un certo livello di sicurezza e non saranno mai al 100%.

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29

Per tutto tranne che per i test unitari, assolutamente no. Gli sviluppatori sanno troppo sull'app e su come "dovrebbe" funzionare per diventare tester oggettivi.

La differenza fondamentale nel testare le filosofie tra sviluppatori e Qs è questa: il programmatore in genere verifica il suo programma per dimostrare che il suo codice funziona (test "positivi"). Il QA può e lo fa, ma ha anche un'ulteriore attenzione a scoprire cosa non funziona cercando di rompere il software (usando test "negativi").

Nella misura in cui il personale addetto al controllo qualità potrebbe potenzialmente essere danneggiato dai test dei programmatori che "dimostrano" che il software funziona, dovrebbe esserci un isolamento tra il test degli sviluppatori e il test QA. Lo sviluppatore può sicuramente aiutare i test di qualità dimostrando ciò che funziona, ma spetta al QA verificare in modo indipendente che il software non si rompa.

La cosa migliore che il programmatore può fare per aiutare lo sforzo di test è fornire una suite di test unitaria completa, di alta qualità e verificabile, contenente test che si allineano ai requisiti individuali nel documento dei requisiti.

Bene in termini di test, ci sono 3 tipi.

Scatola nera, scatola grigia e scatola bianca.

La scatola nera si riferisce agli utenti che testano il prodotto, senza sapere come funziona il prodotto internamente.

La casella grigia si riferisce agli utenti esperti che hanno conoscenze sulla programmazione del computer, ma non fanno parte del team di sviluppo. Queste persone verificheranno se il prodotto presenta perdite di memoria, problemi relativi ai requisiti di sistema e così via.

Ecco la parte principale: la casella bianca si riferisce ai test degli sviluppatori sul prodotto a livello di codice. Ciò significa che eseguono test di unità, debug, ecc.

Pertanto è positivo che gli utenti e il team di sviluppo siano tutti coinvolti nella fase di test, ma ciascuno dei test richiede un livello di impegno adeguato da parte degli utenti e del team di sviluppo, a seconda di ciò che viene testato.

UNIT TESTING è un must per tutti gli sviluppatori

Per informazioni su come questo potrebbe essere usato a tuo vantaggio, leggi i seguenti link se sei nello sviluppo di C ++:

• Una rapida introduzione a Google C ++ Testing Framework
• Strumenti di test di unità C / C ++ open source, Parte 1: Scopri il framework di test di unità Boost
• Strumenti di test di unità C / C ++ open source, Parte 3: Conoscere CppTest

NON ESISTE UN MODO CHE UNA PERSONA QA PU DO EFFETTUARE QUESTE PROVE. NON C'È MODO.

Supponendo che il progetto abbia un numero significativo di sviluppatori, quindi gli sviluppatori devono lavorare sui test. Un avvertimento sarebbe che gli sviluppatori non lavorano sui test (questo non include i test unitari) per il proprio codice.

Preferirei vedere il personale amministrativo (o i potenziali utenti effettivi) fare i test di controllo qualità rispetto agli sviluppatori. Qualcuno che non sa come il prodotto è stato progettato per funzionare, deve provare a usarlo. Gli sviluppatori tendono ad essere molto limitati nel modo in cui affrontano i test e francamente sono troppo costosi all'ora per essere utilizzati anche per i test di controllo qualità.

Scrivi:

Il problema è che, a causa di problemi di risorse (*), le fasi del test sono troppo lunghe e spesso accorciate a causa di vincoli di tempo Questo perché gli sviluppatori non le stanno eseguendo. Una delle più grandi società Internet che offrono i migliori prodotti più stabili non usa affatto i tester. Usano solo test automatici, tutti eseguiti dagli stessi sviluppatori. I risultati sono x10 prodotti migliori rispetto a quando lo sviluppatore lascia i test ai "tester".

È come se i muratori costruissero la tua casa, ma fai in modo che un team diverso si assicuri che l'edificio effettivamente si trovi, le porte si aprano e si chiudano, l'aria condizionata funzioni ecc ... Probabilmente ci vorranno x10 per costruire edifici, e la maggior parte finirà essere inaffidabili.