Come si misura

Direi che si sta sicuramente facendo la cosa giusta sostenendo la testabilità all'inizio dell'SDLC.

"spingilo e dimentica di testarlo"
Ahi. Un altro modo per leggere questo è "spingerlo e dimenticare tutti i rischi per i clienti di cui avremmo potuto essere a conoscenza e possibilmente fare qualcosa prima che fosse troppo tardi".
I tempi di rilascio sono importanti, ma fintanto che l'azienda conosce il rischio di spingere senza alcun test (ad esempio, non sapremo nulla del prodotto o quali problemi potrebbero sorgere), Allora hai fatto il tuo lavoro di tester.

In termini di metriche, la velocità è facile da misurare come il tempo impiegato per il rilascio, che può essere misurato in ore, giorni o settimane.

Per quanto riguarda la qualità del prodotto, mi limiterei a testarlo, a scoprire i rischi e le minacce al valore e a comunicarli agli stakeholder sotto forma di informazioni (non di dati). Dire davvero Cosa c'è di sbagliato nel prodotto piuttosto che cercare di consolidarlo in una sorta di numeri su un grafico.

Lo stesso vale anche per la testabilità: valuta, valuta e descrivi come la testabilità sta migliorando nel tempo, quanto è più facile rendere il tuo lavoro di test e come stai diventando più soddisfatto del risultato.

I manager amano le metriche economiche e facili, purtroppo, ma non dipingono un buon quadro della qualità, comprese cose come la testabilità. Non c'è da stupirsi che tu stia lottando, perché non credo che nessuno al mondo abbia trovato una misurazione affidabile della qualità e non sono sicuro che qualcuno lo farà mai. È molto più efficace fornire informazioni sotto forma di una storia: chi può subire danni e a quale costo?

Le metriche surrogate possono essere utilizzate per supportare la storia della qualità in un modo che potrebbe essere importante. L'esempio classico è quello delle prestazioni, in cui i dati sui tempi di risposta e sui tempi di caricamento possono essere utilizzati per supportare una valutazione. Cose Tuttavia, diventa un po' più complicato quando si cerca di identificare i dati per supportare la funzionalità o la qualità dell'usabilità. Potrebbe essere necessario essere più specifici su quali aspetti della qualità si desidera misurare.

La testabilità è un po' più specifica, quindi posso trovare alcuni esempi possibili, ma è comunque necessario identificare ciò che si desidera misurare esattamente.
Volete misurare quanta testabilità viene sostenuta all'inizio dell'SDLC? Quanto viene preso sul serio dagli sviluppatori? Quanto viene implementato? Quanto risulta testabile il prodotto?
Potresti considerare cose come: Per ogni riunione di sviluppatori per discutere requisiti o progetti, quante volte è stata discussa la testabilità? Quante volte non se ne è parlato? Quante volte è stata menzionata una funzione di testabilità? Quante volte è stato implementato o ignorato?
Per i test in generale: quanti progetti sono stati spediti senza alcun test? Per quanto tempo è stato Test eseguiti in percentuale dell'intero progetto? Quante volte lo sviluppo ha superato la scadenza per i test? Ancora
una volta, però, nessuna di queste metriche ti darà una misura della qualità, ma potrebbero essere sufficienti per darti una sorta di visione di come stanno andando le cose che possono essere monitorate nel tempo.

Scusa per il lungo post, ma c'è un altro (ancora più lungo) post sul blog di James Bach che potrebbe interessarti (ma che vale la pena leggere): Valutare la qualità, non misurarla - Satisfice, Inc.