Miglioramento del processo di test (TPI) utilizzando il modello PDCA

Che cos'è il miglioramento del processo di test?

Miglioramento del processo di test Si tratta della pratica di misurare le prestazioni di un processo di test, identificarne i punti deboli e applicare modifiche controllate in modo che il progetto successivo offra una qualità superiore a un costo inferiore e in tempi più brevi. Considera il testing come un processo misurabile e ottimizzabile, anziché come un'attività ripetuta sempre allo stesso modo ad ogni rilascio.

Immagina il GuruIl progetto per la 99 Bank è appena stato completato. Il consiglio di amministrazione apprezza il tuo lavoro e il cliente è soddisfatto. Ciononostante, il tuo capo ha ancora delle domande da farti.

I manager spesso descrivono test del software come un processo problematico e incontrollabile. Ripensando al GuruNel progetto 99 Bank, avete riscontrato qualcuno dei seguenti problemi?

Si tratta di problematiche comuni a quasi tutti i progetti di test. Molte organizzazioni si rendono conto che migliorare il processo di test è l'unico modo duraturo per risolverle, perché imparare dagli errori passati è ciò che impedisce che gli stessi errori si ripetano nel ciclo di rilascio successivo.

Perché testare il miglioramento del processo?

Il seguente scenario mostra perché il miglioramento del processo di test è importante. GuruIl progetto 99 Bank è stato completato, la qualità dei test è stata ottima e avete ricevuto un feedback positivo dal cliente.

Qual è la lezione appresa da questo scenario? È semplicemente "Cerca sempre di fare meglio"Anche quando credi di aver fatto un buon lavoro, ci sono sempre altri che lo fanno meglio, perché hanno trovato idee e soluzioni migliori delle tue.

Ogni azienda desidera che il progetto venga completato con il massimo qualità, al minore costo e nel più breve tempi di consegna. Il miglioramento del processo di test è ciò che aiuta un team di test a raggiungere tutti e tre gli obiettivi contemporaneamente.

Come implementare il miglioramento del processo di test?

Per implementare il miglioramento del processo di test sul GuruProgetto 99 Bank, il Test Manager può seguire il PDCA Modello. Il PDCA (Plan-Do-Check-Act) è un metodo di gestione in quattro fasi utilizzato in ambito aziendale per il controllo e il miglioramento continuo di un processo. Ogni passaggio attraverso il ciclo rappresenta un singolo ciclo di miglioramento e l'output della fase Act diventa l'input della fase Plan successiva.

Passaggio 1) Pianificare

La fase di pianificazione è quella in cui viene progettato il miglioramento. È suddivisa in tre fasi più piccole.

Passaggio 1.1) Identificare il problema

La prima attività di un processo di miglioramento dei test è identificazione i problemi che si sono verificati nel progetto attuale. I problemi in questo progetto potrebbero ripresentarsi in altri progetti. Risolvere i problemi e scoprire le soluzioni per evitarli in futuro è l'obiettivo primario del Test Improvement.

Ora torniamo al progetto. GuruSul sito web di 99 Bank, hai riscontrato problemi o suggerimenti per miglioramenti? Seleziona qui sotto

Passaggio 1.2) Determinare l'obiettivo

Comprendere il problema e le criticità emerse nel progetto è fondamentale. In questo modo si individuano i punti di miglioramento e le fasi di test che meritano attenzione prioritaria.

Supponiamo di aver identificato che è durata anche la fase di esecuzione del test molti tempo e costi di completamento. È possibile rendere i test più veloci ed economici? Questa domanda diventa l'obiettivo del ciclo. Un obiettivo utile è espresso con un numero e una scadenza, ad esempio "ridurre del 30% lo sforzo necessario per l'esecuzione dei test di regressione prima della prossima release".

Passo 1.3) Definire le azioni di miglioramento

In base all'obiettivo concordato, vengono definite le azioni di miglioramento. Tali azioni dovrebbero essere graduali e introdotte un passo alla volta, poiché non è realistico pensare di cambiare tutto in una volta sola.

Ad esempio, per rendere i test più rapidi ed economici, si possono prendere in considerazione le seguenti azioni.

Nell'esempio precedente, le opzioni A e B rendono i test più veloci ed economici. L'opzione C renderebbe i test più rapidi, ma costerebbe di più, perché un tester più esperto percepisce uno stipendio più elevato. Questo compromesso è esattamente il motivo per cui ogni azione di un candidato deve essere valutata in base all'obiettivo, non in base all'intuito.

Passaggio 2) Fare

Avete già individuato i punti di miglioramento. Ora è il momento di elaborare un piano per metterli in pratica. Questo piano deve rispondere alle seguenti domande.

• Quali punti di miglioramento devono essere implementati e in quale ordine?
• Entro quando deve essere completato il piano?
• Quali passaggi devono essere completati per realizzare il piano?
• A chi è affidata ciascuna fase e come verrà confermato il completamento?

Eseguire azioni di miglioramento

Una volta stabilito il piano, è necessario implementarlo. Le attività di miglioramento possono interferire con il lavoro di test già in corso, quindi un responsabile dei test deve prestare attenzione. attenzione a loro per evitare gli indesiderati conseguenze.

Consideriamo il seguente scenario. Sul GuruProgetto 99 Bank, per rendere i test più veloci ed economici, hai deciso di utilizzare test di automazione al posto di un grande blocco di test di regressione manuali. Dopo l'applicazione dell'azione, la produttività è aumentata in modo significativo.

Passaggio 3) Controlla

Nella fase di verifica si eseguono tre operazioni.

• Valuta il efficienza delle azioni di miglioramento del test
• Misura come efficace la soluzione era
• Analizzare se potrebbe essere migliorata ulteriormente

L'obiettivo di questa fase è confermare che le azioni di miglioramento siano state implementate con successo e valutare se l'obiettivo prefissato nel Piano sia stato effettivamente raggiunto.

Il modo migliore per eseguire tale valutazione è con metricaLe metriche sono essenziali per una gestione organizzativa di successo. Il responsabile dei test raccoglie dati e li utilizza per misurare parametri quali produttività, qualità e costi.

Ad esempio, prima che l'automazione venisse applicata al progetto, la produttività dei test era 10 casi di test per ora-uomoDopo l'applicazione dell'automazione, la produttività è stata misurata a 20 casi di test per ora-uomo.

Ma insieme a questo vantaggio è emerso un problema indesiderato.

In questo caso, applicando l'automazione è aumentato la produttività dei test, ma la qualità dei test diminuitaUn'azione di miglioramento può quindi causare gravi conseguenze conseguenze altrove. In tale scenario lo strumento di test deve essere selezionato con molta più attenzione e la suite automatizzata deve essere esaminata con lo stesso rigore del codice di produzione. Una valutazione strutturata degli strumenti candidati, come quella descritta nel Selenium lezioneimpedisce che uno strumento venga adottato solo perché è popolare.

Consideriamo di nuovo lo stesso scenario. Il Guru99 il costo del progetto era superare perché i membri del team hanno preso troppo molto tempo per eseguire i casi di test. Utilizzando lo strumento di test automatizzato, hai risparmiato 30 per cento del costo del progetto. È un buon miglioramento, ma il tuo capo si aspetta di più.

È quindi necessario essere sempre alla ricerca di soluzioni più innovative che migliorino ulteriormente il processo di test. In questo scenario, altre opzioni possono consentire di risparmiare ulteriori costi di progetto.

• Gestisci le tue risorse umane in modo efficace, in modo che i tester qualificati vengano impiegati dove possono apportare maggior valore.
• Negozia condizioni commerciali migliori con i tuoi fornitori di strumenti e personale.
• Invece di automatizzare i casi di test duplicati o di scarso valore, è preferibile eliminarli.

Passaggio 4) Agire

Una volta implementate con successo le azioni di miglioramento e raggiunto l'obiettivo, il responsabile dei test dovrà completare il ciclo con le seguenti attività.

• Review le attività di miglioramento e agire in base alle lezioni apprese
• Standardizzare il punto di miglioramento all'interno del processo di gestione dei test
• Aggiornanento i documenti di policy, i modelli di piano di test e i documenti di processo standard
• Determinare quando e dove queste modifiche verranno applicate nel prossimo progetto

Se l'obiettivo non è stato raggiunto, il ciclo non si interrompe. L'obiettivo non raggiunto viene riportato in una nuova fase di pianificazione insieme a tutto ciò che la fase di verifica ha rivelato in merito alle ragioni del mancato raggiungimento degli obiettivi.

Confronto tra TPI NEXT, TMMi e CMMI

Il ciclo PDCA è il motore del miglioramento, ma un modello di riferimento indica come si presenta un risultato "migliore". Esistono tre modelli comunemente utilizzati, che vengono spesso confusi tra loro.

TPI NEXT È un modello di riferimento specifico per i test, pubblicato da Sogeti. Valuta 16 aree chiave, organizzate in tre gruppi, rispetto a quattro livelli di maturità: Iniziale, Controllato, Efficiente e Ottimizzato. Poiché la valutazione avviene area chiave per area chiave, un team può essere Efficiente in un'area pur rimanendo Controllato in un'altra.

TMMi, gestito dal TMMi Foundation, è un modello di maturità a fasi con cinque livelli: Iniziale, Gestito, Definito, Misurato e Ottimizzato. Un'organizzazione raggiunge un livello solo dopo aver soddisfatto le aree di processo di quel livello.

CMMI Non si tratta affatto di un modello di test. Copre l'intera organizzazione di sviluppo e la sua rappresentazione a fasi prevede cinque livelli di maturità: Iniziale, Gestito, Definito, Gestito Quantitativamente e Ottimizzato. TMMi è stato progettato per integrare CMMI, non per sostituirlo.

Metriche che dimostrano il miglioramento del processo di test

La fase di verifica si risolve senza l'utilizzo di numeri. È sufficiente un insieme di metriche piccolo e stabile, raccolto prima e dopo ogni ciclo, e le stesse definizioni devono essere utilizzate su entrambi i lati del confronto.

• produttività dell'esecuzione dei test — casi di test eseguiti per ora-uomo
• Percentuale di rilevamento dei difetti (DDP) — difetti riscontrati durante i test in percentuale rispetto al totale dei difetti riscontrati, inclusi quelli segnalati dopo il rilascio
• Costo per caso di test eseguito — costo totale dello sforzo di test diviso per i casi di test eseguiti
• Copertura dei requisiti — requisiti con almeno un collegamento caso di prova
• Tempi di risoluzione del difetto — età media di un difetto nel corso del ciclo di vita del difetto

Usando il GuruSecondo i dati di 99 Bank, dove 180 difetti sono stati riscontrati durante i test e 20 sono stati segnalati dal cliente dopo la consegna, il calcolo è semplice.

# Defect Detection Percentage and improvement deltas
def ddp(found_in_test, found_after_release):
    return found_in_test / (found_in_test + found_after_release) * 100

def delta(before, after):
    return (after - before) / before * 100

print("Defect Detection Percentage: %.1f%%" % ddp(180, 20))
print("Productivity gain: %.1f%%" % delta(10, 20))
print("Test cost change: %.1f%%" % delta(50000, 35000))

Produzione:

Defect Detection Percentage: 90.0%
Productivity gain: 100.0%
Test cost change: -30.0%

Un DDP del 90% significa che un difetto su dieci è comunque giunto al cliente, quindi l'obiettivo di qualità non è stato pienamente raggiunto, nonostante la produttività sia raddoppiata e i costi siano diminuiti del 30%. È proprio questa visione d'insieme che impedisce a un team di dichiarare vittoria troppo presto.

Errori comuni nel miglioramento del processo di test

La maggior parte dei programmi di miglioramento fallisce per ragioni organizzative piuttosto che tecniche. I seguenti errori sono responsabili della maggior parte delle iniziative abbandonate.

• Migliorare senza un punto di riferimento iniziale. Se nessuno ha misurato il processo prima del cambiamento, nessuno può dimostrare che il cambiamento abbia apportato benefici. È fondamentale rilevare i dati di riferimento durante la fase di pianificazione, non successivamente.
• Inseguire un livello di maturità anziché un fattore trainante per il business. Un certificato che non riduce i costi, i difetti o i tempi di consegna rappresenta una spesa, non un miglioramento.
• Cambiare troppe cose contemporaneamente. Quando cinque azioni vengono eseguite nella stessa release, non è possibile effettuare una regressione. trace a uno qualsiasi di loro.
• Automatizzare un processo difettoso. L'automazione moltiplica qualsiasi processo a cui venga applicata, inclusi test di progettazione deboli e criteri di accesso poco chiari.
• Saltareping la fase di azione. Un miglioramento che non è mai scritto nella politica di test e il Ciclo di vita del test del software Un documento muore con il team di progetto che lo ha creato.
• Esclusi i collaudatori. Le persone che non sono state consultate in merito a un cambiamento trovano quasi sempre il modo di aggirarlo.

Per approfondire queste idee, rivediamo le fasi del Ciclo di vita del test del software, stringi il tuo caso di prova progettare, formalizzare il processo di gestione dei difetti, valutare dove test di automazione offre un ritorno reale e guarda come uno strumento come HP ALM può contenere le metriche da cui dipende la fase di verifica.

DOMANDE FREQUENTI