Ruolo della garanzia della qualità (non testare!) in Agile

Penso che esista un ruolo per garanzia della qualità in un'organizzazione agile, in particolare quella che deve aderire a un sistema di gestione della qualità come ISO9001 , ISO13485 per il settore dei dispositivi medici o AS9000 nel settore aerospaziale , allo scopo di soddisfare i requisiti dei clienti, i regolamenti o i mandati aziendali.

Ci sono due cose importanti da tenere a mente. Innanzitutto, l'assicurazione della qualità non è solo interessata alla qualità del prodotto finale, ma a tutti i prodotti di lavoro intermedi. È possibile visualizzare lo sviluppo del software come una scatola nera che accetta in qualche modo i requisiti del cliente e il software di output (e forse il supporto per quel software). Tuttavia, durante questo processo, il team di sviluppo fa cose - trasformazioni di tali requisiti in qualcosa di usabile per progettare e costruire software, creazione di progetti, prototipi e simulazioni, codice di produzione, codice di test, script di supporto, procedure manuali (per test, implementazione. ..), documentazione per l'utente e altro - ognuno dei quali può presentare difetti che potrebbero avere un impatto sulle attività a valle che si basano su tali informazioni. La garanzia della qualità riguarda non solo i difetti riscontrati in questi prodotti di lavoro, ma anche il modo in cui tali difetti vengono prevenuti. In secondo luogo, l'assicurazione della qualità è anche interessata alla qualità dei processi: quanto bene stiamo facendo il lavoro. Anche se la cosa ovvia qui è la qualità dei prodotti di lavoro, è anche quanto tempo ci vuole per fare il lavoro (tra le altre cose).

Due dei principi di Agile sono di favorire "gli individui e le interazioni su processi e strumenti" e di favorire "software funzionante su una documentazione completa". Tuttavia, nessuno di questi dice che non si dovrebbe avere un processo o che non è necessario alcun tipo di documentazione. Se stai cercando di implementare un sistema di gestione della qualità, è probabile che ti venga richiesto un livello di documentazione che possa essere paragonato al lavoro effettivamente svolto durante il controllo. Penso che questi ideali Agili siano meglio espressi in alcuni dei concetti di sviluppo del software snello - eliminare gli sprechi rimuovendo i ritardi il processo, riducendo la burocrazia e migliorando la comunicazione interna, amplificando l'apprendimento e responsabilizzando il team nel prendere decisioni su come raggiungere al meglio gli obiettivi.

Oltre ad essere responsabile dell'auditing interno, un'organizzazione di QA può anche aiutare a supportare l'agilità o lo sviluppo del software snello essendo responsabile di aiutare a rilevare gli sprechi, trovare ritardi e garantire che ciò che è documentato dia ad ogni team di sviluppo un margine di manovra sufficiente per implementare requisiti di processo (riscossi da clienti, agenzie di regolamentazione, mandati aziendali, ecc.) nel modo migliore per il singolo progetto ma con un certo livello di coerenza all'interno dell'organizzazione per consentire alle persone di passare da un progetto all'altro senza dover reimparare un intero nuovo set di processi e metodi in cima alla curva di apprendimento tecnico.

Tuttavia, sulla base di alcuni dei tuoi commenti, sembra che la direzione in cui questo sta andando non sia agile o snella. È una linea sottile camminare su come dettagliato per rendere la documentazione del processo. Se è troppo vago, offre a ogni team room del progetto l'implementazione di tutto ciò che desidera, determinando ampie variazioni nelle implementazioni dei processi (e quindi nella qualità del processo e nella probabile qualità del prodotto) all'interno dell'organizzazione. Se è troppo specifico e dettagliato, è probabile che aggiunga burocrazia e una documentazione completa interferisca con le interazioni e il software di lavoro. Ci deve essere equilibrio tra agilità e capacità di ottenere informazioni sulla qualità del processo (attraverso misurazioni e un certo livello di coerenza).

Vedi anche:

• Can Agile e ISO 9001 interagiscono bene?
• Come convalidare la necessità di documentazione?

Non sono sicuro di capire la differenza (o il modo in cui è rilevante) tra "testing" e "quality assurance". Alla fine, per fare QA, devi fare test.

Il QA, come lo definisci, suona un po 'contro il valore del manifesto di Software di lavoro su una documentazione completa . Hai davvero bisogno di tutto ciò che documenta il processo? Stai cercando di spremere un processo esistente in uno Agile. Se hai davvero bisogno della documentazione, dovresti aggiungerla alla tua definizione di fatto.

Le metodologie agili preferiscono gli "specialisti generalizzanti" che fanno fette verticali. Ciò significa che qualsiasi membro del team dovrebbe essere in grado di completare qualsiasi storia. Gli sviluppatori dovrebbero testare, il controllo qualità dovrebbe testare e tutti dovrebbero lavorare per migliorare la qualità.

I team agili utilizzano le retrospettive come punto in cui migliorano il loro processo.

Nei team in cui ho lavorato in tutti è responsabile della qualità. In genere c'è un ritardo tra qualcosa verificabile in una iterazione / sprint pronto per un tester. Con questo tempo, puoi svolgere le tue attività di QA appena in tempo per testare le storie. Fai attenzione a questa introduzione dello scope creep all'interno di un'iterazione.

Molti processi Agile non sono prescrittivi su quel livello di dettaglio e sono lasciati alla squadra a decidere. Un team di auto-organizzazione potrebbe chiedere uno specialista di QA?

Se leggi le pubblicazioni dei fondatori del movimento per la qualità (Shewart, Demming, Juran) ti renderai presto conto che la qualità è un problema economico. La mancanza di qualità significa che ci sono molti rifiuti. Il miglioramento della qualità è il processo di riduzione degli sprechi dal processo. Shewart, Demming e Juran si occupavano di produzione ma la stessa idea si applica allo sviluppo del software. Nello sviluppo del software, la fonte primaria di rifiuti è la rielaborazione (correzione degli errori, ripetizione del test, ridistribuzione) sempre assumendo che i requisiti funzionali dei clienti fossero soddisfatti. Il prossimo problema più costoso non è produrre qualcosa che il cliente vuole acquistare. La qualità del software coinvolge anche l'utente. Design scadente o mancanza di affidabilità possono aumentare il costo di utilizzo del software.

Il ruolo di Quality Assurance non è quello di testare il prodotto, anche se i dati di test sono utili se registrati correttamente. Il ruolo dell'assicurazione della qualità consiste nell'indagare possibili modi per ridurre il numero di problemi introdotti e ridurre il costo della correzione. Questo non è limitato ai difetti del codice.

Uno dei peggiori processi per la conduzione di qualsiasi sviluppo ingegneristico è quello di rendere i progettisti / sviluppatori responsabili delle funzionalità. I problemi sorgono quando più di uno sviluppatore o team deve modificare lo stesso componente per fornire la funzionalità desiderata. Il risultato sono difetti che non vengono scoperti fino a dopo l'integrazione (cioè nel test a livello di sistema). Nella situazione ideale, i test di sistema non dovrebbero trovare alcun difetto. Se viene rilevato un numero significativo, significa che il prodotto presenta un numero enorme di difetti anche dopo aver eseguito tutti i test. Ciò si traduce in un prodotto inaffidabile.

La risposta a questo problema è lo sviluppo basato su componenti o sottosistemi in cui solo uno sviluppatore o un team può modificare qualsiasi componente del sottosistema. In un negozio orientato alle funzionalità, il ruolo delle persone di controllo qualità sarebbe di aiutare i team a passare a un processo orientato al sottosistema.

In qualsiasi altra impresa, le metriche sono raccolte e utilizzate per prevedere il futuro. In molti negozi di software la metrica chiave è che i difetti sono stati trovati o che i difetti sono aperti. Ma questa è una metrica inutile per il miglioramento. La metrica chiave è il numero di difetti ancora presenti nei prodotti di lavoro. I difetti dei requisiti (supponendo che ci siano dei requisiti) finiscono nel design insieme agli errori commessi nel produrre il disegno. I difetti di progettazione (supponendo che ci sia un disegno) finiscono nel codice insieme agli errori di codifica. La garanzia della qualità dovrebbe aiutare a trovare modi per ridurre al minimo il numero di difetti riportati dai precedenti prodotti di lavoro utilizzando le metriche raccolte quando questi articoli sono prodotti e verificati.

Quality Assurance non è responsabile per la qualità dei prodotti. Le persone che li producono sono responsabili. La garanzia della qualità è responsabile della scoperta dei pasticci fatti lungo il percorso e li indirizza verso la direzione in modo che possano essere affrontati prima che diventino problemi seri e costosi.