Penso che il "test di accelerazione" sia più di un obiettivo secondario che di un obiettivo. L'obiettivo reale di tutti i test è mitigare il rischio .
Per mitigare i rischi, è necessario sapere quali sono questi rischi. Quindi il primo passo è un processo di valutazione del rischio, che di solito si traduce in una matrice di rischio. Vorrei riunire un gruppo di stakeholder chiave e personale tecnico esperto e fare un brainstorming su quali potrebbero essere questi rischi, in parte sulla base della cronologia con il software e di quanto bene sono stati rilasciati.
Per ogni rischio, l'azienda deciderà l'impatto (ad esempio il rischio di uno scenario di "sistema inattivo" potrebbe essere la perdita finanziaria o di reputazione) e assegnare un punteggio (in genere 1-5). Nel frattempo, la squadra tecnica deciderà la probabilità, anch'essa segnata da 1-5. Quindi si moltiplicano questi due fattori e si ordinano in base al prodotto per ottenere un ordinamento forzato del rango (vale a dire la priorità) dei rischi.
Quindi per ogni rischio devi avere una strategia di mitigazione. Molti dei rischi saranno attenuati da un determinato tipo di test: test funzionali, test delle prestazioni, test in modalità guasto, test di integrazione, test di migrazione dei dati, test di penetrazione, ecc. Il team deve quindi sviluppare un piano di test che fornisca fiducia agli stakeholder che il rischio è mitigato.
Uno dei rischi principali è solitamente "Il software è di bassa qualità" o qualcosa di simile. Questo rischio specifico è mitigato dalla garanzia della qualità.
Per un controllo di qualità ordinato, devi sviluppare parametri di qualità. Se stai partendo da zero, ti suggerisco di raccogliere i dati dal codice base esistente e dal sistema di tracciamento dei difetti, in modo da poter stabilire una linea di base; per esempio, nelle ultime cinque uscite potresti trovare una media di un sev1 di difetto e di 10 di 2. Quindi puoi impostare un obiettivo per zero sev1 e meno di 5 sev2, quel genere di cose. I team di sviluppo e controllo qualità dovranno quindi elaborare un piano per raggiungere questo obiettivo.
Il team di sviluppo può migliorare la qualità con revisioni del codice, test unitari automatizzati, test unitari manuali, codifica in coppia e altre tecniche. Per ognuno di questi, gli obiettivi possono essere impostati, ad es. per i test di unità automatizzate è possibile decidere che l'80% di copertura del codice è richiesto entro una certa data. Il team addetto al controllo qualità può utilizzare test automatici e manuali di fumo e funzionalità. Potresti avere risorse specializzate che stabiliscono prestazioni e stress test. Il QA e i lead di sviluppo dovrebbero creare un processo per test, misurazioni e report continui.
Questi approcci di prova sono standard? Una specie di. La terminologia e le tecniche generali di ogni tipo di test saranno più o meno coerenti. Tuttavia, la definizione delle priorità per ciascun tipo di test varia a seconda di dove sono le aree a rischio e in che modo sono state classificate. Alcuni software salteranno alcuni test in modo completo, ad esempio non è possibile eseguire determinati test di sicurezza su un'applicazione interna, mentre altri test potrebbero richiedere priorità più alte, test per la stabilità del sistema su un'applicazione 24/7 ad alte prestazioni, per esempio. Tali scelte e decisioni saranno specifiche per il business e per il prodotto e, come tutte le decisioni aziendali, sono limitate dalla disponibilità delle risorse, dal budget e dai vincoli temporali. Una taglia non va bene per tutti.