Per quanto ne so, i test dovrebbero essere fatti in modo estensivo, il più possibile e il più lontano possibile, tuttavia a volte (sempre) dobbiamo spedire rapidamente.
In caso di progetti in ritardo o eccessivi, esiste una buona pratica in quanto sono sufficienti le prove? o è soggettivo? Ovviamente nessun test sta pianificando di fallire, ma quanto poco è troppo piccolo?
Modifica: questo progetto è per uso interno con un determinato modello di dispositivo.
Per ogni lavoro che svolgi, ci sarà probabilmente uno dei tre vincoli su di esso: tempo, caratteristiche e qualità. È assolutamente impossibile vincolare tutti e tre; nella migliore delle ipotesi puoi sceglierne due.
Nel tuo caso, hai un vincolo di tempo imposto su di te. Quindi una scelta deve essere fatta tra caratteristiche e qualità. Dalla tua domanda e risposta al commento di Telastyn, sembra che anche tu abbia un vincolo di funzionalità imposto anche a te. In tal caso, la qualità deve soffrire. Quindi la risposta alla tua domanda, " Esiste un test minimo richiesto ", la risposta è sì: quel minimo è la quantità di test che può essere raggiunta nel tempo disponibile. Quelli che impostano i vincoli hanno scelto - anche se non erano a conoscenza - spedire con errori.
Questo non è un buon posto per essere. Per il bene dei tuoi clienti, la qualità dovrebbe essere prioritaria rispetto alle funzionalità se c'è una scadenza difficile. Quindi il modo per garantire che si verifichi un test adeguato è quello di testare presto e spesso. Rompere il lavoro in blocchi di funzionalità, implementare una funzione e averla testata correttamente, prima di iniziare con la prossima funzione. In questo modo, quando raggiungi la scadenza, hai un prodotto di qualità superiore pronto per la spedizione.
Ovviamente puoi anche andare avanti di un livello: usa lo sviluppo basato su test (TDD). Iniziare i test prima ancora di scrivere il codice scrivendo un test dell'unità guasto, quindi scrivendo il codice per eseguire il test senza interrompere altri test esistenti. Hai ancora bisogno che i tester eseguano presto i test esplorativi e spesso anche i test unitari non cattureranno tutti i bug, ma ne cattureranno molti. In questo modo, la qualità viene spinta in primo piano. La domanda su quale sia il livello minimo di test diventa quindi discutibile: si sta sempre facendo molto più di un minimo arbitrario.
In case of a delayed or a over-deadline projects, is there a best practice in how much testing is enough?
Diciamo per argomento che il limite inferiore di cui stai parlando esiste. Come lo si quantifica? tutti sanno che devi testare per almeno 6 ore , oppure dovrebbero esserci almeno due test per cento linee di codice ?
Ovviamente, queste misure non hanno alcun senso perché sono arbitrarie. Una decisione su quanto o quanto poco è accettabile il test dipende da una serie di fattori, tra cui:
Questi fattori sono diversi per ogni prodotto, quindi è impossibile dire quanti test dovrebbero essere eseguiti senza conoscere il prodotto in questione.
Leggi altre domande sui tag testing unit-testing deadlines