In che modo il QA / processo di test può essere valutato?

In definitiva, le metriche che scegli dipendono dalle domande specifiche a cui vuoi rispondere sulla qualità del tuo prodotto e dei tuoi processi:

• Se vuoi sapere quanto sono validi i rapporti sui difetti presentati, tieni traccia del numero ritirato o contrassegnato come non riproducibile. Dovresti anche tenere traccia di quale organizzazione (sviluppo, qualità, assistenza clienti, ecc.) L'ha presentata. Si desidera che un'alta percentuale dei report contenga informazioni sufficienti per riprodurre e quindi correggere i problemi.
• Se vuoi sapere quanto è efficace il tuo test, guarda la copertura del test. Se si sta facendo una copertura basata sui requisiti, mappare i casi di test ai requisiti e assicurarsi che tutti i requisiti siano coperti. Se il tuo team di qualità sta scrivendo il codice di test a un'unità e al livello di integrazione, guarda la copertura del codice.
• Guarda le metriche di contenimento dei difetti, come l'efficacia del contenimento dei difetti totali (TDCE). Usa l'equazione TDCE = (pre-release defects found) / (pre-release defects + post-release defects) . Potrebbe essere necessario fare attenzione a ciò che consideri un difetto pre-rilascio / post-rilascio. Se si desidera solo contare l'efficacia delle attività di qualità back-end, i difetti pre-rilascio sono solo i difetti riscontrati dall'organizzazione della qualità ei difetti post-rilascio sono qualsiasi cosa trovata dopo aver terminato il proprio lavoro. Potresti considerare la pre-release come tutti i difetti riscontrati da chiunque prima del rilascio a un cliente e i difetti post-release come quelli trovati dai clienti o in-house dopo il rilascio.
• Numero di difetti trovati per fase. Questo dipende dal tuo processo, ma gli esempi sarebbero requisiti, design, codice e test unitario, test di integrazione, test di accettazione, post-rilascio.

Tuttavia, è importante considerare che i tuoi sviluppatori dovrebbero essere coinvolti nella garanzia della qualità. Dovrebbero esaminare i requisiti per garantire che siano corretti e utilizzabili, i progetti per garantire che possano implementare il software, il codice dovrebbe essere rivisto e testato unitamente. Il QA è più di un processo che ti dà la certezza che il prodotto sia di alta qualità e non un'organizzazione che ispeziona o collauda il prodotto finale.

La gestione della qualità, sia la garanzia che il controllo, è la mitigazione del rischio contro prestazioni e difetti scadenti, entrambi sono probabilistici. Parte dell'esito probabilistico è aleatoria, cioè a causa di variabilità casuale in cui nessuna azione ha alcun effetto reale. Cercare di decifrare quanto bene sta facendo l'attività di QM quando si hanno sia effetti casuali che non casuali sarebbe quasi impossibile. In altre parole, darai credito o biasimo QM su un risultato favorevole e sfavorevole che si sarebbe verificato comunque.

C'è anche qualcosa di strano nel fare un'analisi di qualità sulla funzione che fa analisi di qualità sul resto del team e sui processi e gli output. In un ambiente di progetto, in cui tempo e denaro sono sempre limitati, dubito che ciò produrrebbe alcun valore reale.

Alla fine della giornata, misuri le tue prestazioni e i risultati di tutto il team del progetto, incluso il team di gestione della qualità. Se le prestazioni e le realizzazioni stanno raggiungendo gli obiettivi, allora credo che sia lecito ritenere che la capacità di gestione della qualità sia in parte responsabile. Se gli obiettivi non vengono raggiunti e il team di gestione della qualità sta producendo risultati che richiedono attenzione, sia durante il controllo qualità o il controllo qualità, questo è un altro buon segno che stanno ottenendo. Se gli obiettivi non vengono raggiunti, né QA né QC stanno introducendo risultati, quindi è un buon segno che stanno eseguendo se stessi. Penso che sia facile come questo; non dovrebbe richiedere un'analisi più complessa di questa.

Assunzione di una visione semplicistica ...

I difetti vengono introdotti in un prodotto dall'operazione di sviluppo. Noi (o più spesso il management) potremmo dire "Se ottengo sviluppatori migliori (per gli sviluppatori" migliori "leggo" persone migliori e processi e pratiche migliori) avrò meno difetti ". Questo è innegabilmente vero, ma solo fino a un certo punto - In un punto sconosciuto della curva non sarai in grado di ridurre i difetti assumendo sviluppatori "migliori", ma otterrai comunque dei difetti perché, come tutti sappiamo (ad eccezione del management) è tecnicamente e praticamente impossibile produrre difetti codice gratuito.

Quindi assumi i tester per garantire che a) il prodotto faccia ciò che deve fare in modo che tu venga pagato e b) trovino ogni singolo bug rimasto nel codice ... Tranne che hai una curva simile- Ad un livello, assumere tester migliori significa che troveranno più difetti, ma proprio come non si può garantire una programmazione senza bug, né si può mai fare abbastanza test per garantire di aver trovato tutti i bug. Alcuni rimarranno sempre. Ed è l'I.T. equivalente a Sods Law che, anche se i difetti rimanenti sono così oscuri, la tua copertura di test non li trova, il giorno 1 gli utenti faranno (o circa).

Il trucco è sapere se i tuoi sviluppatori sono sufficientemente bravi ei tuoi tester sono sufficientemente bravi da produrre i migliori output possibili agli utenti, accettando il fatto che ci saranno sempre dei difetti residui dopo test non importa quanto tu faccia.

Ma supponiamo che tu abbia motivo di credere che alcuni elementi dell'operazione di consegna non stiano operando alla massima qualità possibile e che gli utenti vedano più difetti di quanto potrebbero essere. Dove vai da lì?

Bene, misurate la quantità e i tipi di difetti riscontrati nei test di sistema, nei test UAT e poi dopo che il prodotto è diventato attivo. Ora sai quanti difetti "rilevabili" ci sono stati nella tua versione del prodotto. È quindi possibile valutare perché UAT non ha trovato quelli che sono stati segnalati in Live e perché i test di sistema non hanno trovato quelli che sono stati segnalati in UAT. Infine, puoi valutare il motivo per cui i difetti sono usciti dal negozio di sviluppo.

Riceverai una vasta gamma di effetti e risposte, ma quando li avrai puoi escogitare un'analisi costi / benefici per mitigare qualsiasi problema tu possa trovare. Poi, quando hai mitigato quegli effetti al punto in cui spendere più tempo o denaro non ti darebbe alcuna differenza apprezzabile nei tassi di difetti residui hai ottenuto tutto ciò che puoi ottenere e hai la migliore operazione di consegna pratica possibile per te ...

Dopo, i problemi verranno comunque trovati e gli utenti continueranno a essere infastiditi e la direzione chiederà comunque perché è possibile fornire codice con difetti "anche dopo aver speso tutti questi soldi per rendere la consegna il migliore possibile", ma saprai di avere, come organizzazione, fatto il meglio che puoi e di notte starai tranquillo:)

La risposta alla tua domanda è probabilmente in due fasi.

In primo luogo, il controllo qualità ha un ruolo di polizia. Questo può essere misurato in quasi tutti i progetti e si può usare un rapporto metrico piuttosto semplice come i difetti rilevati dal QA rispetto al numero di difetti scoperti (da chiunque) nella produzione. Questo ti mostrerà quanto è buono il tuo team di QA nel catturare i difetti e non è un brutto punto di partenza. Se passano molti difetti, puoi vedere se ci sono tendenze nei tipi di difetti che attraversano o forse i difetti si verificano più spesso quando il QA viene sopraffatto vicino alle scadenze.

Tuttavia, troppe organizzazioni si fermano qui e questo è sia finanziariamente dispendioso che in ultima analisi inefficace. Non è possibile risolvere il problema del difetto con il solo test. Vuoi sfruttare la prospettiva dei tuoi esperti di QA durante tutto il processo. Quando gestivo un team di QA, avremmo incorporato persone in tutti i team agili. Durante la revisione delle storie e delle attività degli utenti, i membri del team del QA farebbero domande su casi d'uso e potenziali rotture che diventerebbero casi di test, ma contribuirebbero maggiormente a inquadrare il lavoro che lo sviluppatore farebbe. Sarebbero presenti anche per discussioni architettoniche e tattiche, oltre a revisioni di codice per creare una prospettiva più ampia nella squadra. Infine, se ai membri del team QA viene chiesto di fare della qualità la loro priorità, possono fornire un controllo contro le pressioni sugli sviluppatori per affrettare le attività che tutti sappiamo possono verificarsi nei progetti.

Sfruttare il team di QA come qualcosa di più di una semplice forza di polizia ridurrà il numero totale di difetti creati nello sviluppo. Ovviamente, la cattura del 95% dei 100 difetti in un progetto è uno scenario molto più appetibile del 95% dei 1000 difetti. Una volta che le cose sono più integrate in questo modo, puoi considerare i difetti generati come misura, ma devi ricordare a quel punto che stai parlando di una misura che riflette l'intera organizzazione, non solo il QA.

Se stai cercando metriche quantitative che mostrino se il QA sta svolgendo il proprio lavoro, eccone un paio in comune:

numero di difetti aperti e # di difetti totali, il rapporto tra i due, la variazione del rapporto durante l'iterazione.

numero di P1, P2. P3. Difetti P4 rilevati nell'ambiente pre-produzione rispetto all'ambiente di produzione

Tempo ciclo difetto medio

Ecco alcune cose più qualitative da considerare che sono forti indicatori di performance:

Quanto è documentato il difetto? Almeno ha una gravità, un risultato reale, un risultato previsto documentato?

Il tuo team di QA scrive codice? Automatizzano i test? Scrivono un test automatico quando viene risolto un difetto?

Il tuo QA scrive casi di test? Quando le scrivono - prima che una storia sia sviluppata o alla fine quando ha bisogno di essere testata?

Eseguono regressioni? Quando? Cosa è regredito in termini di funzionalità business critical? La regressione è automatizzata?

Il tuo QA può giustificare, in termini di valore aziendale, cosa hanno deciso di testare e come?

Durante le retrospettive, il QA fornisce suggerimenti per il miglioramento? La squadra ascolta?

Com'è la comunicazione tra il QA e gli sviluppatori? Cosa dice Dev sul valore aggiunto dal controllo qualità sul team?