Come valutare la qualità di un prodotto software

Question

Ho un prodotto, X, che consegniamo a un cliente, C ogni mese, comprese correzioni di bug, miglioramenti, nuovi sviluppi ecc.) Ogni mese mi viene chiesto di sbagliare "garantire" la qualità del prodotto.

Per questo utilizziamo una serie di statistiche raccolte dai test che eseguiamo, come ad esempio:

• tasso di riapertura (numero di bug riaperti/numero di bug corretti testati)
• tasso di nuovi bug (numero di nuovi, incluse regressioni, bug rilevati durante il test/numero di bug corretti testati)
• per ogni nuovo miglioramento, il nuovo tasso di bug (il numero di bug trovati per questo miglioramento/numero di giorni)

e varie altre figure.

È impossibile, per ragioni che non spiegheremo, testare tutto ogni volta.

Quindi, la mia domanda è:

Come posso stimare il numero e il tipo di bug che rimangono nel mio software?Quali strategie di test devo seguire per assicurarmi che il prodotto sia buono?

So che questa è una domanda un po' aperta, ma ehi, so anche che non esistono soluzioni semplici.

Grazie.

Answer 1

Non penso che tu possa mai davvero stimare il numero di bug nella tua app.A meno che non si utilizzi un linguaggio e un processo che consenta prove formali, non si potrà mai essere veramente sicuri.Probabilmente è meglio spendere il tuo tempo impostando processi per ridurre al minimo i bug piuttosto che provare a stimarne quanti ne hai.

Una delle cose più importanti che puoi fare è avere un buon team di QA e un buon monitoraggio degli elementi di lavoro.Potresti non essere in grado di eseguire test di regressione completi ogni volta, ma se disponi di un elenco delle modifiche apportate all'app dall'ultima versione, gli addetti al QA (o la persona) possono concentrare i test sulle parti di l'app che si prevede sarà interessata.

Un'altra cosa che sarebbe utile sono i test unitari.Maggiore è la quantità di codice che hai coperto, più sicuro puoi essere che i cambiamenti in un'area non abbiano inavvertitamente influenzato un'altra area.L'ho trovato abbastanza utile, poiché a volte cambio qualcosa e dimentico che ciò influenzerebbe un'altra parte dell'app, e i test unitari hanno mostrato subito il problema.Il superamento dei test unitari non garantisce che non si sia rotto nulla, ma può aiutare ad aumentare la fiducia che le modifiche apportate funzionino.

Inoltre, questo è un po' ridondante e ovvio, ma assicurati di avere un buon software di tracciamento dei bug.:)

Answer 2

La domanda è: chi ti richiede di fornire le statistiche?

Se si tratta di persone non tecniche, falsifica le statistiche.Per "falso" intendo "fornire numeri inevitabilmente privi di significato, ma reali" del tipo che hai menzionato.

Se si tratta di tecnici senza esperienza in informatica, bisognerebbe informarli del problema dell'arresto, che è indecidibile ed è più semplice che contare e classificare i bug rimanenti.

Esistono molti parametri e strumenti relativi alla qualità del software (copertura del codice, complessità ciclomatica, linee guida per la codifica e strumenti che li applicano, ecc.).In pratica, ciò che funziona è automatizzare il maggior numero possibile di test, facendo eseguire a tester umani il maggior numero possibile di test che non erano automatizzati, e poi pregare.

Answer 3

Penso che mantenerlo semplice sia la strada migliore da percorrere.Classifica i tuoi bug in base alla gravità e affrontali in ordine decrescente di gravità.

In questo modo puoi consegnare la build della massima qualità possibile (il numero di bug significativi rimanenti è il modo in cui valuterei la qualità del prodotto, al contrario di alcune statistiche complesse).

Answer 4

La maggior parte delle metodologie agili affronta questo dilemma in modo abbastanza chiaro.Non puoi testare tutto.Né puoi testarlo un numero infinito di volte prima di rilasciarlo.Quindi la procedura consiste nel fare affidamento sul rischio e sulla probabilità del bug.Sia il rischio che la probabilità sono valori numerici.Il prodotto di entrambi ti dà un numero RPN.Se il numero è inferiore a 15 spedisci una beta.Se riesci a ridurlo a meno di 10, spedisci il prodotto e invii il bug affinché venga corretto in una versione futura.

Come calcolare il rischio?

Se si tratta di un crash, allora è un 5 Se si tratta di un arresto anomalo ma è possibile fornire una soluzione alternativa, è un numero inferiore a 5.Se il bug riduce la funzionalità, allora è un 4

Come calcolare la probabilità?

puoi riprodurlo ogni volta che corri, è un 5.Se la soluzione fornita causa ancora l'arresto anomalo, meno di 5

Bene, sono curioso di sapere se qualcun altro utilizza questo schema e desideroso di conoscere il chilometraggio su questo.

Answer 5

Quanto è lungo un pezzo di corda?In definitiva, cosa rende un prodotto di qualità?I bug danno qualche indicazione sì, ma sono coinvolti molti altri fattori, la copertura del test unitario è un fattore chiave nell'IMO.Ma secondo la mia esperienza, il fattore principale che determina se un prodotto può essere considerato di qualità o meno, è una buona comprensione del problema che si sta risolvendo.Spesso ciò che accade è che il "problema" che il prodotto intende risolvere non viene compreso correttamente e gli sviluppatori finiscono per inventare la soluzione a un problema che hanno ben delineato nella loro testa, e non al problema reale, creando così dei "bug". .Sono un forte sostenitore dell'iteratività Agile sviluppo, in questo modo il prodotto è costantemente in grado di affrontare il "problema" e il prodotto non si allontana troppo dal suo obiettivo.

Answer 6

Le domande che ho sentito erano: come posso stimare i bug nel mio software?e quali tecniche utilizzo per garantire che la qualità sia buona?

Invece di seguire un corso completo, ecco un paio di approcci.

Come posso stimare i bug nel mio software?

Inizia con la cronologia, sai quanti ne hai trovati durante i test (si spera) e sai quanti sono stati trovati dopo il fatto.Puoi usarlo per stimare la tua efficienza nel trovare bug (DDR - Tasso di rilevamento difetti è un nome per questo).Se riesci a dimostrare che per un periodo di tempo costante, il tuo DDR è coerente (o in miglioramento), puoi fornire alcune informazioni sulla qualità del rilascio indovinando il numero di difetti post-rilascio che verranno rilevati una volta rilasciato il prodotto.

Quali tecniche utilizzo per garantire che la qualità sia buona?

L'analisi delle cause principali dei tuoi bug ti indicherà componenti specifici che presentano bug, sviluppatori specifici che creano codice buggato, il fatto che la mancanza di requisiti completi comporta un'implementazione non corrispondente alle aspettative, ecc.

Riunioni di revisione del progetto per identificare rapidamente ciò che era buono, in modo che quelle cose possano essere ripetute e ciò che era negativo e trovare un modo per non ripeterli.

Speriamo che questi ti diano un buon inizio.Buona fortuna!

Answer 7

Sembra che il consenso sia che l'enfasi dovrebbe essere posta sui test unitari.Il tracciamento dei bug è un buon indicatore della qualità del prodotto, ma è accurato solo come il tuo team di test.Se utilizzi il test unitario, ti fornisce una metrica misurabile della copertura del codice e fornisce test di regressione in modo da poter essere certo di non aver rotto nulla dal mese scorso.

La mia azienda fa affidamento sui test a livello di sistema/integrazione.Vedo che vengono introdotti molti difetti perché mancano i test di regressione.Penso che i "bug" in cui l'implementazione dei requisiti da parte dello sviluppatore si discosta dalla visione dell'utente siano una sorta di problema separato che, come affermato da Dan e rptony, è meglio affrontabile dalle metodologie Agile.