Come dimostrare alla direzione che i test unitari sono più economici a lungo termine rispetto ai test manuali? [duplicare]

Question

Come dimostrare alla direzione che i test unitari sono più economici a lungo termine rispetto ai test manuali? [duplicare]

#1 da (4 voti)
#2 da (1 voti)
#3 da (1 voti)

0

Nell'azienda in cui lavoro, è necessario che tutto il codice sia coperto da un test di qualsiasi tipo perché vogliono avere il minor numero possibile di difetti segnalati dall'utente.

Con questa idea ho deciso di mettere una politica che il codice dovrebbe essere testato unitamente a C0 (copertura del 100% di ogni riga, non di ciascuna condizione).

Ora altri dicono che questo è più costoso del test manuale.

Intuitivamente direi che questo è sbagliato poiché ogni volta che esegui una modifica devi ripetere tutto manualmente e questo è probabilmente uno sforzo maggiore rispetto all'esecuzione dei test e all'aggiornamento di quelli che devono essere aggiornati ma non li trovo un modo per giustificarmi con numeri, documenti o altre informazioni.

Puoi darmi dei buoni spunti per dimostrare il mio approccio alle persone a cui ti riferisco?

EDIT : grazie a tutto ciò che ha contribuito alla domanda. Vedo che c'erano alcuni punti chiave mancanti:

Questo è un nuovo prodotto che abbiamo iniziato a sviluppare un anno fa con i test in mente, quindi utilizziamo DI ovunque e tutto è pronto per essere testato.
Abbiamo già un prodotto commerciale che ci consente di raggiungere una copertura del 100% poiché possiamo prendere in giro quasi tutto, comprese le classi .Net, così possiamo davvero isolare le classi (JustMock).
Disponiamo di strumenti per calcolare la copertura dei test.
Non stiamo rimuovendo tester e test manuali. Stiamo rimuovendo test manuali fatti dagli sviluppatori. Abbiamo un team SQ separato ma il management vuole che il numero di bug che raggiungono il team SQ sia il più piccolo possibile, così gli sviluppatori devono raggiungere il 100% di copertura con qualsiasi mezzo prima di consegnare il codice al team SQ. Quindi quello che ho fatto è stato sostituire i test manuali degli sviluppatori con test automatici (test di unità e integrazione) ed è ciò che la gestione vuole ripristinare.

La domanda non è la stessa di quella "duplicata" perché ho già un requisito di copertura del 100%.

testing unit-testing test-automation manual-testing

posta Ignacio Soler Garcia 07.05.2014 - 19:00

fonte

3 risposte

Leggi altre domande sui tag testing unit-testing test-automation manual-testing

Modello client / server in cui il server rifiuta le connessioni da * nuovi * client Versione ridotta della libreria JavaScript sotto LGPL utilizzata su un sito senza preavviso di copyright

score 4 · Answer 1

La maggior parte degli specialisti del settore concordano sul fatto che i test unitari aiutano e riducono il tasso di difetti; ci sono stati studi basati su più progetti che mostrano questo. Puoi trovare risultati concreti di questi studi nei libri di ingegneria del software; dai un'occhiata ad esempio nel Codice completo di Steve McConnell nel capitolo 20.3 Efficacia relativa delle tecniche di qualità .

Dal punto di vista critico, stai ipotizzando che potrebbe non essere valido in tutti i casi:

dipende molto dalla tua applicazione, dal tipo di dominio (non riesco a vedere come puoi rilasciare un gioco complesso, ad esempio senza alcun test manuale)
dipende se sei all'inizio con l'applicazione e cambia molte cose o hai già un'applicazione abbastanza stabile.
forse la tua applicazione ha una vita breve e investire molto nei test automatici non vale la pena
dipende dalla forza lavoro; forse le risorse umane nella tua zona in test manuali sono molto più economiche di sviluppatori o tester che sanno come codificare

Avere copertura del codice di prova del 100% non ha senso (nella maggior parte dei casi) perché:

Non garantisce che l'applicazione sia priva di bug; ci sono ancora problemi di integrazione, problemi di prestazioni, problemi di sicurezza ecc. La ragione più importante dei test unitari credo che sia la garanzia del codice di refactoring senza romperlo; non è una sostituzione per altri tipi di problemi.
È estremamente difficile da raggiungere. Fondamentalmente i test unitari dimostrano che hai unità separate, ma le tue applicazioni hanno molte unità interconnesse. La correttezza dell'applicazione dipende anche dal modo in cui queste unità sono interconnesse.
Guarda un argomento molto migliore di Joel Spolsky .

Per riassumere è una buona idea aggiungere test unitari se non ne hai; ma è una cattiva idea sostituire completamente i test manuali con una copertura della linea del 100% nei test unitari.

score 1 · Answer 2

Esegui un po 'indietro la matematica dell'involucro per capire dove si trova il punto di equilibrio.

Se occorrono x ore per un tester manuale che viene pagato $ y / h per eseguire un test manuale e il test manuale deve essere eseguito z volte all'anno, il costo del test manuale è x * y * z per anno. Se occorrono n ore per qualcuno che guadagna $ m / h per automatizzare quel test, questo è un costo una tantum di n * m. Quindi scopri quanto tempo ci vuole per l'investimento una tantum nella costruzione del test automatizzato (n * m) per superare il costo annuale (x * y * z) del test manuale.

La maggior parte delle volte, la creazione del test automatizzato è un gioco da ragazzi. È un po 'più costoso come costo una tantum ma consente di risparmiare i costi ricorrenti dell'esecuzione del test manuale. E questo prima che tu renda conto del fatto che i test manuali sono generalmente meno affidabili dato che gli umani sono fallibili e occasionalmente tralasciano i passaggi. Occasionalmente, tuttavia, troverai test da eseguire occasionalmente difficili da automatizzare e più semplici da eseguire manualmente prima delle versioni principali.

score 1 · Answer 3

Anche se c'è il merito di avere test unitari, la maggior parte delle persone lo prende troppo lontano - in primo luogo provare per il 100% di copertura del test unitario sta cercando di trasformare la tua azienda in questo . Hai bisogno di un approccio più pragmatico, soprattutto perché i test unitari non garantiscono che la tua applicazione sia priva di bug, hai comunque bisogno di molti test di integrazione per dimostrare che tutti i bit isolati funzionano insieme.

I test manuali sono meglio sostituiti con strumenti di test di integrazione automatici. Ce ne sono molti in giro (es. Cucumber o SpecFlow ) che dovrebbero essere riconosciuti molto più facilmente come qualcosa per sostituire il test manuale senza andare in manutenzione incubo del 100% di copertura del test unitario.

Il test dell'unità è spesso abusato, la copertura del 100% del test unitario è sicuramente un cattivo odore.