Qual è una buona misura del test / efficienza del tester?

11

Sto per partecipare a una discussione con la direzione per quanto riguarda la misurazione della nostra efficienza di test come organizzazione della qualità. La ragione principale alla base di questo è che metà del nostro team è sotto contratto e la nostra azienda vorrebbe fornire alcune metriche su quanto siamo efficienti / efficienti, in modo da avere i dati di base su cui negoziare i parametri del contratto con il contratto di servizio dei nostri appaltatori .

Ho cercato un po 'e la maggior parte dell'opinione che ho trovato su questo argomento ruota intorno all'efficienza dello sviluppatore: linee di codice, punti narrativi consegnati, difetti introdotti, ecc.

Ma per quanto riguarda i tester? I nostri test sono per lo più basati su requisiti e su una combinazione di test manuali, semi-automatici e automatizzati (non perché non siamo riusciti ad automatizzare tutto, ma perché alcune cose non sono automatizzate nel nostro sistema di test).

    
posta Randy 08.02.2013 - 16:55
fonte

5 risposte

8

Il numero di test scritti è inutile e un numero elevato di bug rilevati 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 maggior aiuto allo sviluppo (come sviluppatore, saprò se rompo qualcosa per caso) rispetto ai clienti (voglio fallo e non funziona).

Poiché la qualità è buona se i clienti non incontrano problemi, quindi una buona misura dell'efficacia (non dell'efficienza) di un team e di un processo di garanzia della qualità è la misura dei bug riscontrati dai clienti che non sono stati trovati di QA .

Il problema principale di tale metrica è che può esserci un considerevole ritardo tra il lavoro svolto e quando inizi a avere numeri significativi.

    
risposta data 08.02.2013 - 18:48
fonte
6

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

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

Alla fine, il lavoro del tuo team di QA è trovare i bug prima che escano allo stato selvatico. Le loro metriche dovrebbero basarsi sul raggiungimento effettivo di quell'obiettivo. Se c'è una bassa copertura dei casi di test, una quantità minima di test automatici e un alto tasso di bug in produzione, allora non stanno facendo un buon lavoro. Tuttavia, se hanno un buon track record di trovare i bug molto prima che colpiscano prod, le loro metriche dovrebbero essere piuttosto alte.

    
risposta data 08.02.2013 - 17:07
fonte
3

Il QA dovrebbe essere misurato da due parametri principali: quanti bug superano il QA da trovare sul campo? Quali sono la loro gravità?

Potresti essere in grado di eseguire il QA per trovare bug gravi più vicini al rilascio rispetto a dev-complete. Potresti essere in grado di eseguire il QA per non aver completato i test in base alla data di completamento stimata (per funzionalità).

Anche se alla fine, temo che spenderai più soldi cercando di misurare l'efficacia del tuo personale contrattuale rispetto ai risparmi ottenuti usando uno staff di contrattisti ...

    
risposta data 08.02.2013 - 17:02
fonte
0

La società che lavoro utilizza una serie di metriche 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. Si tratta di utile come LOC al giorno.

    
risposta data 08.02.2013 - 16:59
fonte
-1

Molti modi per misurare le prestazioni nelle fasi di sviluppo e test durante l'esecuzione del progetto. Abbiamo usato misure inferiori ai nostri progetti. Performance di sviluppo misurata da 4 metriche popolari del codice (indice di manutenibilità, complessità ciclometrica, profondità dell'ereditarietà, accoppiamenti di classe). Per C # lo otterrà in Microsoft Visual Studio. Per la copertura di test Ncover / Ndepend è molto utile. Test delle prestazioni misurato dal numero di bug di sviluppo: il roll-over degli ultimi 4 sprint Bug di testing del sistema che si stanno verificando negli ultimi 4 sprint. Numero di test di automazione superato in particolare versione / Funzionalità erogate.

    
risposta data 20.03.2013 - 07:30
fonte

Leggi altre domande sui tag