Dove posso trovare statistiche / cifre su quanto tempo il test dovrebbe / potrebbe prendere? [duplicare]

Non credo che il test possa essere misurato in% del tempo totale speso. Se si sta utilizzando una fase di test, è sempre possibile definire quella fase come 10%, ma non ha senso poiché il test alla fine è destinato a trovare un sacco di problemi che devono essere corretti e quindi è necessario riavviare la fase di test ancora una volta.

Un modo migliore per avvicinarsi a questo è indicare il fatto che trovare i bug in anticipo è molto più conveniente quindi trovarli in ritardo. Leggi l'articolo Rothmans a riguardo. Ecco una tabella che fornisce ulteriori informazioni:

A mio avviso, il testing è una parte integrante dello sviluppo, così come il design, la codifica e l'integrazione. Forse è più facile convincerli a iniziare a lavorare di più con i test automatici e integrare maggiormente i test nel processo di sviluppo?

Some smaller shops don't have budgets for testers and phbs automatically assume the developer will spend a few minutes after every build "testing" and deliver a perfectly functional system.

Se sei uno sviluppatore, è meglio prendersi un po 'di tempo per testarlo. Chiunque non dovrebbe pensare di trovare un'altra carriera.

Testing should be XX% of your total man hour count , etc etc?

Non esiste un modo semplice per prevedere le ore X QA in base allo sviluppo. Ci sono troppe variabili. La qualità degli sviluppatori, dei tester, ecc. Devi anche tener conto della complessità del codice e del suo scopo (dovresti mettere un limite al numero di ore di test dire il codice 911 usato per tracciare le emergenze).

La cosa migliore da fare è chiedere alla gente della QA quanto tempo ci vorrà in base a ciò che si sta sviluppando. Stanno per avere la migliore stima, come sono quelli che hanno fatto il lavoro prima. Se la direzione non li ascolterà, avrai dei problemi reali. Quello che devono decidere è ciò che è più importante per loro. Tempo trascorso o qualità. Questo è ciò che si riduce a.

Quello che puoi fare è fare alcune brevi "prove". Fare in modo che lo sviluppo passi un po 'di tempo a sviluppare un pezzo e inviarlo al QA. Scopri quanto tempo impiega e inizia a usarlo come base per la previsione. (Pensa alla velocità in Agile).

Se ti stai riferendo alle tue attività di test, includi solo il tempo di test nelle stime dei tempi di sviluppo.

Questo dovrebbe essere compreso da tutti, poiché ci vuole tempo per sviluppare test unitari e test di integrazione. Se la gestione non è gradita a questo punto di vista, spiega semplicemente che ogni volta che vengono eseguiti test automatici per una build, vengono salvate un numero infinito di ore di lavoro che sarebbero state spese per il test manuale.

Se sei uno sviluppatore, quanto tempo la gestione spende per i test di controllo qualità non è davvero un tuo problema. Se non spendono abbastanza tempo, significa solo che hai bisogno di più tempo per assicurarti che i tuoi test siano solidi.

Tutto ciò che è stato detto, non è raro passare tanto (o più) tempo nello sforzo di test che il tempo trascorso a fare la vera codifica.

Il fatto che stiano chiedendo questo tipo di metrica separatamente dalle loro figure storiche dimostra che qualunque risposta tu darai sarà sbagliata.

Quanto tempo è necessario dedicare dipende interamente da ciò che vale la pena catturare i bug. Ho lavorato in luoghi in cui tutte le basi degli utenti potevano passare a piacere tra la versione corrente e quella beta e il loro lavoro consisteva in transazioni atomiche abbastanza veloci. Quel prodotto non aveva quasi alcun valore nel test del QA oltre alla convalida che i dati inseriti erano archiviati come inseriti. Ho anche, nello stesso posto, lavorato su cose che potrebbero costare centinaia di dollari al minuto se fossero rotte, così l'abbiamo testato fino a quando non abbiamo potuto pensare a nient'altro da buttare.

Senza il contesto di quale sia il rischio e quale sia la complessità, non hai alcuna idea di come siano i tuoi test e se non sai come saranno i tuoi test non puoi venire con una metrica ragionevole per la durata.

Comprendo che stai solo provando a stilare una stima del personale, ma un numero generico che non tiene conto dei tipi di prodotti e delle loro complessità ti farà più male che un buon IMHO.