Qual è una buona misura dell'efficienza dei test / tester?

Sto per partecipare a una discussione con il management per quanto riguarda la misurazione della nostra efficienza di test come organizzazione QA. Il motivo principale alla base di ciò è che metà del nostro team è contratta e la nostra azienda vorrebbe fornire alcune metriche di quanto siamo efficaci / efficienti, in modo da disporre di dati di base su cui negoziare i parametri del contratto con l'accordo di servizio dei nostri appaltatori .

Ho esaminato un po 'e la maggior parte dell'opinione che ho trovato su questo argomento ruota intorno all'efficienza degli sviluppatori: linee di codice, punti della trama consegnati, difetti introdotti, ecc.

Ma per quanto riguarda i tester? I nostri test sono principalmente basati sui requisiti e un mix di test manuali, semi-automatizzati e automatizzati (non perché non siamo riusciti ad automatizzare tutto, ma perché alcune cose non sono automatizzabili nel nostro sistema di test).

Il numero di test scritti è inutile e un numero elevato di bug trovati può essere una misura di scarso sviluppo piuttosto che un efficiente QA.

Le misure di automazione (copertura del codice, copertura delle funzionalità ...) possono essere buone, ma penso che siano di maggiore aiuto allo sviluppo (come sviluppatore, saprò se rompo qualcosa per errore) rispetto ai clienti (voglio farlo e non funziona).

Poiché la qualità è buona se i clienti non riscontrano problemi, una buona misura dell'efficacia (non dell'efficienza) di un team e di un processo di controllo qualità è la misura dei bug rilevati dai clienti che non sono stati rilevati dal controllo qualità .

Il problema principale con quella metrica è che può esserci un notevole ritardo tra il lavoro svolto e quando si iniziano ad avere numeri significativi.

Ci sono alcune metriche che abbiamo usato nel mio ultimo lavoro per valutare il QA:

• Numero di bug trovati. Odio questo. È come "Numero di righe di codice scritto" per uno sviluppatore.
• Numero di casi di test automatizzati prodotti.
• Percentuale dell'applicazione totale coperta dai test funzionali.
• Numero di bug trovati nella stadiazione rispetto alla produzione.

Alla fine, il lavoro del tuo team QA è quello di trovare i bug prima che escano in libertà. Le loro metriche dovrebbero basarsi sul raggiungimento di tale obiettivo. Se c'è una bassa copertura dei casi di test, una quantità minima di test automatizzati e un alto tasso di bug nella produzione, allora non stanno facendo un buon lavoro. Tuttavia, se hanno una buona esperienza nel trovare i bug molto prima che colpiscano il prod, le loro metriche dovrebbero essere piuttosto alte.

Il QA dovrebbe essere misurato in base a due parametri principali: quanti bug superano il QA nel campo? Qual è la loro gravità?

Potresti essere in grado di eseguire il QA per trovare bug gravi più vicini al rilascio che dev-complete. Potrebbe essere possibile eseguire il QA per non aver completato i test entro la data di completamento stimata (per funzione).

Sebbene alla fine, temo che spenderai più soldi nel tentativo di misurare l'efficacia del tuo personale di contratto rispetto ai risparmi ottenuti usando un personale di contratto ...

L'azienda che lavoro utilizza una serie di parametri di controllo qualità.

Quello che ritengo più rilevante è la copertura del codice. Uno strumento come EMMA funziona alla grande mentre scrive test automatici approfonditi oltre ai test manuali.

Qualunque cosa tu faccia, non concentrarti sul numero di test. È utile quanto LOC al giorno.

Molti modi per misurare le prestazioni nelle fasi di sviluppo e test durante l'esecuzione del progetto. Abbiamo utilizzato le misure seguenti nei nostri progetti. Performance di sviluppo misurata da 4 metriche di codice popolari (indice di manutenibilità, complessità ciclometrica, profondità dell'eredità, accoppiamenti di classe). Per C # lo otterrà in Microsoft Visual Studio. Per la copertura dei test Ncover / Ndepend è molto utile. Test delle prestazioni misurate in base al numero di bug di sviluppo - registrazione degli ultimi 4 sprint Il sistema verifica i bug che si verificano negli ultimi 4 sprint. Numero di test di automazione superato in particolare release / Funzionalità fornite.