Il costo di un ritardo maggiore tra sviluppo e QA

Nella mia attuale posizione, il QA è diventato un collo di bottiglia. Abbiamo avuto lo sfortunato verificarsi di caratteristiche che sono state escluse dall'attuale build in modo che il QA potesse terminare i test. Ciò significa che le funzionalità che vengono sviluppate potrebbero non essere testate per 2-3 settimane dopo che lo sviluppatore è già passato. Con lo sviluppo più rapido del QA, questo intervallo di tempo non farà che aumentare.

Continuo a sfogliare la mia copia di Code Complete, alla ricerca di uno snippet "Hard Data" che mostri che il costo della correzione dei difetti cresce esponenzialmente più a lungo esiste. Qualcuno può indicarmi alcuni studi che supportano questo concetto? Sto cercando di convincere i poteri che il collo di bottiglia del QA è molto più costoso di quanto pensino.

Non hai bisogno di riferimenti, IMHO. Ecco cosa potresti (piuttosto dovresti ) fare:

Quantificare il costo del ritardo! Supponiamo che occorra 1 settimana per testare le funzionalità. Un ritardo di 2-3 settimane implica che la funzione non sarà disponibile almeno fino alla quarta settimana. E anche questo presupponendo il 100% di successo. Aggiungi un tempo di fissaggio di un'altra settimana in modo che siano circa 5 settimane di ritardo.

Ora, se possibile, accedi alla scadenza prevista del progetto / funzionalità. Entro quando il cliente se lo aspetta? Scivolerà? In caso contrario, altri scivoleranno di conseguenza? Quindi di quanto sarà ritardata la "liberazione"?

Qual è il "costo per l'azienda" per quella versione, ovvero quanto si aspetta che il cliente tragga profitto da quella versione? Se si aspettano un profitto di $ 5200 / anno da quella versione, ogni settimana è sceso costa $ 100 in entrate perse. Questa è la vista del cliente. È possibile o meno avere accesso a questi dati, ma vale la pena prendere in considerazione e dichiarare come il ritardo può influire sulla relazione.

Ora, qual è la perdita per gli sviluppatori? Una volta che lo sviluppatore passa ad altre funzionalità, gli chiedi di interrompere il ciclo e di "correggere" la funzionalità precedente. Qual è la perdita di tempo / fatica? Converti il ​​costo in azienda utilizzando lo stipendio come multiplo per ogni ora sprecata di conseguenza. Puoi usarlo per dire la quantità di "profitti / entrate" che i rifiuti "consumano".

Ciò su cui ti sei imbattuto può essere comodamente quantificato utilizzando "Costo del ritardo" - sostenuto da Don Reinerstein in Principi di flusso di sviluppo del prodotto e anche da Dean Leffingwell in Requisiti software agili. Dovreste essere in grado di eseguire ogni tale rivendicazione da fattori economici per convincere i 'poteri superiori' la cui lingua principale è $$ - si deve parlare la loro lingua per convincerli :)

Bestia della fortuna! (gioco di parole :)

Non credo davvero che Code Complete sia la risorsa giusta per te qui. Questo non è un problema di codice, è un problema di processo e forse un problema di gestione.

Se una parte del tuo processo è particolarmente debole, allora è il momento di svelare la teoria dei vincoli :

1. Identificare il vincolo.

   Ciò significa trovare la parte più lenta o più inefficiente del processo complessivo. Nel tuo caso, sta testando. Ma quale parte del test? È:

   • Preparare l'ambiente di test?
   • Determinare cosa testare?
   • Test funzionali (di accettazione)?
   • Test di regressione?
   • Test esplorativi?
   • Segnalazione di bug / difetti dai test?
   • Determinare i passaggi per riprodurre un bug?
   • Ricevi chiarimenti da sviluppatori o project manager?
   • Risolvi i problemi riscontrati nella fase QA?

   Questi sono tutti problemi molto diversi e richiedono soluzioni diverse. Devi decidere qual è il più costoso / importante. Giustificarlo al management non dovrebbe essere difficile, poiché tutte le attività sopra menzionate costano tempo (denaro dell'AKA) e solo un paio di loro sono tempo a valore aggiunto.

2. Sfruttare il vincolo.

   In altre parole, ottimizzare intorno il processo vincolante. Non lasciare mai che i tester siano inattivi. Ciò equivale essenzialmente a:

   • Mettere i tester all'interno dei team di sviluppo, se non lo sono già, quindi c'è un ciclo di feedback continuo con gli sviluppatori.
   • Avere distribuzioni di test frequenti, quindi c'è sempre qualcosa di nuovo / fisso da testare.
   • Rendere la comunicazione più veloce e più frequente. Ad esempio, favorire la messaggistica istantanea sui thread di posta elettronica.
   • Garantire che i tester dispongano dei migliori strumenti disponibili (macchine veloci, monitor multipli, tracciamento dei bug ottimizzato, ecc.)

   Questa fase non riguarda l'ottimizzazione del processo di test stesso (ancora), si tratta piuttosto di ridurre le spese generali. Non perdere tempo con i tester. Eliminare il tempo che è veramente sprecato dovrebbe anche essere una vendita facile al management.

3. Subordinare altre attività al vincolo.

   A questo punto, i tester sono produttivi quanto possono essere da soli, quindi dobbiamo iniziare a prendere in prestito la produttività da altre aree:

   • Chiedi agli sviluppatori e al personale operativo di dare la priorità ai tester, indipendentemente da cosa stanno lavorando.
   • Se non si dispone di team interfunzionali, prenotare una sala riunioni ogni giorno a un'ora prestabilita in modo che i tester non debbano mai perdere tempo nel tentativo di prenotarne uno.
   • Deviare una maggiore percentuale di tempo degli sviluppatori (e possibilmente operazioni) lontano dal lavoro delle funzioni; ad esempio, concentrarsi su correzioni di errori, debito / refactoring tecnico, revisione del codice e test delle unità.
   • Prova in modo continuo e incrementale: non sviluppare per 3 settimane e poi dai un calcio ai tester. Chiedi agli sviluppatori di lavorare per rendere immediatamente testabile il loro codice, ad esempio con scaffolding o prototipi di interfacce utente.

4. Elevare il vincolo.

   Se i tester lavorano a piena capacità, sia in termini di produttività che di costi generali minimi, e non sono ancora abbastanza veloci, è necessario iniziare a investire di più nei test.

   • Se si fa affidamento su distribuzioni di test manuali, automatizzarlo mediante l'uso di script di gestione della configurazione e integrazione continua.
   • Se la creazione di piani di test richiede molto tempo, lavorare per ottenere criteri di accettazione migliori (ad es. INVEST ). La maggior parte delle organizzazioni inizialmente è molto cattiva in questo.
   • Se i test di accettazione impiegano troppo tempo, inizia ad automatizzarli. Utilizzare uno strumento come Cucumber o FitNesse o scrivere test di tipo xUnit se è necessario. C'è anche Selenium, Watij e altri strumenti di automazione del browser se il test dell'interfaccia utente richiede molto tempo.
   • Se i test di regressione richiedono troppo tempo, automatizzare anche quello. Se non può essere automatizzato, concentrati sul miglioramento della qualità out of the gate, vale a dire con un'enfasi ancora maggiore sulla revisione del codice, sui test delle unità, sugli strumenti di analisi statica, ecc. Gli sviluppatori dovrebbero essere abbastanza sicuri che ci siano pochissimi bug reali prima di superarli al QA (i difetti del prodotto sono una storia diversa).
   • Se i test esplorativi rappresentano il collo di bottiglia, è possibile rimandarne alcuni fino a dopo il rilascio o rivolgersi a una società di test per eseguire attività altamente parallelizzabili come testare lo stesso flusso di lavoro in più browser.
   • Se i tester non sono in grado di riproporre molti bug, prendere in considerazione la creazione di un ambiente di test di capacità per poter avviare la riproduzione di errori intermittenti. Oppure, prova a eseguire i test di accettazione automatizzati in parallelo e continuamente, per tutto il giorno, mantenendo registri dettagliati.
   • Se impiega troppo tempo a correggere i bug, inizia a partizionare i tuoi progetti e / o considera seriamente la ricerca di soluzioni. Oppure, in alternativa, non risolverne alcuni; non tutti i bug sono critici, dovresti essere in grado di assegnarli alle priorità insieme alle funzionalità.
   • Se tutto il resto fallisce, assumere più tester.

5. Torna al passaggio 1.

Vorrei dire che questo è tutto buon senso, ma sfortunatamente non lo è, almeno non nella maggior parte delle organizzazioni. Se stai ricevendo molta resistenza dalla direzione, una tecnica inestimabile è Value Stream Mapping (una tecnica dalla lean manufacturing), che puoi usare per mostrare quanto tempo e quindi il denaro viene effettivamente sprecato ogni giorno da un candidato al rilascio che non è in grado per passare alla fase successiva. Il costo delle opportunità è difficile da capire, ma questo è uno dei modi migliori che ho trovato per visualizzarlo e dimostrarlo.

E se nulla di tutto ciò funziona ... allora forse sei in una compagnia disfunzionale, esci prima che sia troppo tardi!

Ma non risolverai questo problema semplicemente facendo cadere alcuni fogli sulla scrivania del manager e chiedendo loro di buttare soldi al problema, perché presumeranno (correttamente) che lanciare soldi potrebbe non risolverlo effettivamente, e potrebbe persino fare peggio. Devi fornire soluzioni , e questa è la risposta. Se introduci il problema come "ecco un elenco di modi in cui possiamo iniziare a risolvere questo problema, in ordine decrescente di costo / beneficio" anziché "abbiamo bisogno di più tester", allora avrai molto più successo.

Le pagine 29 e 30 potrebbero avere i dati che stai cercando, anche se potrebbe essere necessario un follow-up.

Vorrei esaminare la ricerca menzionata in questa frase a pagina 30:

Dozzine di aziende hanno scoperto che concentrarsi semplicemente sulla correzione dei difetti prima piuttosto che dopo in un progetto può ridurre i costi e i programmi di sviluppo per fattori di due o più (McConnell 2004).

A proposito, è stata la tua domanda che mi ha fatto ritirare il libro per aggiornarlo :-)

Quello che stai descrivendo è un collo di bottiglia in un processo. La teoria magra afferma che ci sarà sempre un collo di bottiglia in un processo, ma la sua gravità può variare ampiamente. Se il QA ne assumesse uno in più, lo sviluppo potrebbe diventare il collo di bottiglia.

Per capire il costo, immagina la seguente situazione. Hai scelto uno degli sviluppatori. Il suo lavoro non sarebbe mai garantito dalla qualità, ma sarebbe sempre in coda indefinitamente. Immagina che ciò significherebbe che il QA potrebbe assicurare la qualità del lavoro degli altri sviluppatori in modo tempestivo e che non ci sarebbero costi di ritardo.

In quello scenario, il costo del ritardo è il costo dello stipendio dello sviluppatore, perché il suo lavoro sarebbe sprecato.

Il motivo per cui discuto in termini di costi e non del valore creato dal processo, è semplicemente perché è più difficile documentare il valore di un processo, anche se è molto meglio.

Continuo a sfogliare la mia copia di Code Complete, alla ricerca di uno snippet "Hard Data" che mostri che il costo della correzione dei difetti cresce esponenzialmente più a lungo esiste. Qualcuno può indicarmi alcuni studi che supportano questo concetto?

Il costo esponenziale della ricerca di un bug sembra essere basato su uno studio NIST . Lo studio è stato un sondaggio presuppone fasi distinte a cascata:

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

( tabella qui da qui )

Uno degli obiettivi delle metodologie di sviluppo del software Agile è rimuovere queste fasi distinte e ridurre questi costi. Le cifre non si applicano quando si utilizzano altre metodologie per la cascata.

Il tuo problema non è con il QA, infatti, se il tuo QA sta facendo Test, i ritardi sono praticamente il minimo delle tue preoccupazioni. Per favore, lasciatemi expalin (di nuovo, poiché è un'idea sbagliata comune nel settore della programmazione) ... QA assicura la qualità del prodotto supervisionando l'intero SDLC, dai Requisiti (forse prima), attraverso lo sviluppo, la verifica, il rilascio e il supporto. I test assicurano che non esistano difetti evidenti nel codice. C'è una differenza molto grande e importante. Se avessi un vero QA, verrebbero dappertutto nel dipartimento Test / V&V chiedendoti perché costassero i tempi di lavoro (e quindi i soldi) ritardando le versioni, o in tutto il project management, facendo sì che gestissero correttamente la pianificazione del progetto, o facessero tutto il management certo c'erano abbastanza tester per il codice prodotto ecc ...

Quindi assumendo per QA intendi davvero Test, tornando alla domanda originale. Il codice completo ha funzionato correttamente: il costo di un difetto è il tempo impiegato dall'inserimento alla correzione. La rilevazione precoce è utile solo se la correggi anche in anticipo, ma l'interpretazione della maggior parte delle persone è sbagliata.

(Nota: sto giocando a Devils Advocate qui, non prenderò tutto questo alla lettera perché non so nulla della tua situazione) Il ritardo causato dal tuo dipartimento Test è un costo, assolutamente, tuttavia, devo chiedere, se lo sei aspettando che trovino i tuoi difetti, cosa stai facendo - non dovresti trovare i tuoi difetti? Forse se avessero meno lavoro (attraverso input di qualità superiore con meno difetti da te), il ritardo non sarebbe così significativo e il costo inferiore - come manager ti chiederei come pensi di ridurre i difetti nel codice a cui consegnerai test, poiché (in base alla tua argomentazione) quei difetti costano di più se rilevati dal test, quindi da solo.

Inoltre, come manager, potrei affermare che non è compito dei test trovare i tuoi difetti, il loro compito è quello di scoprire che non ci sono difetti - se ti aspetti che trovino difetti, forse non hai fatto abbastanza bene il tuo lavoro.

Fai attenzione a come ti avvicini a questo. Se non si dispone di una soluzione al problema, è probabile che si verifichi il secondo migliore.