Cosa viene catturato in un piano di garanzia della qualità del software se si utilizzano metodi di sviluppo / agili basati su test?

Il TDD viene di solito praticato insieme a metodologie agili, che di solito non hanno tutti i documenti "Plan" associati alle metodologie più pesanti. Detto questo, se il tuo cliente richiede i piani, devi fornirli.

È importante rendersi conto che TDD non è sufficiente da solo per garantire la qualità. Tuttavia, fornisce una buona base per un sistema ben testato. Nel tuo SQAP, ti consigliamo di comunicare il mezzo con cui intendi mostrare la qualità che dovrebbe includere sezioni almeno su quanto segue:

• Test unitario: metodo per testare unità isolate di codice
• Test di integrazione: metodo per testare le interazioni di codice
• Test di accettazione: metodo per testare la correttezza in base alle specifiche

Un piano definisce come si utilizzano i diversi tipi di test e quando si definiscono i contenuti dei test. È importante che l'unica parte dell'immagine che è più formale sia il test di accettazione.

Per questo, potresti voler guardare "BDD" ( Sviluppo guidato dal comportamento ) o Test delle specifiche. Esistono alcuni strumenti che consentono di scrivere i test delle specifiche utilizzando un linguaggio comprensibile al cliente, con gli hook creati dagli sviluppatori per garantire che il test possa essere automatizzato. Sono definiti usando un costrutto di dato un certo stato, quando succede qualcosa, allora l'applicazione risponde. Gli strumenti BDD possono anche generare la documentazione delle specifiche, insieme alla matrice di test tracciabile su ciò che è passato o fallito.

Mentre l'ordine di stabilire se un test è scritto prima o dopo che il codice non veramente è importante, la correttezza di quel codice lo fa. L'utilizzo di una buona struttura degli strumenti ti aiuterà solo a scrivere il tuo SQAP una sola volta, con i test e le verifiche effettive fatti dal tuo strumento.

Quando penso a un piano di garanzia della qualità del software, penso a un documento che risponde a domande come:

• Nel progetto, quali sono i ruoli e le responsabilità degli individui rispetto alla garanzia della qualità del software?
• Quali risultati finali produrrà l'organizzazione di qualità del software e quando saranno disponibili questi deliverable in diversi stati (bozza, baseline, revisioni eseguite)?
• In che modo viene garantita la qualità dei requisiti? Considera come vengono catturati i requisiti, come vengono esaminati e approvati, come vengono tracciati ai test.
• Come è garantita la qualità del codice? Esistono guide di stile di codifica o strumenti di analisi utilizzati?
• Come è assicurata la qualità del prodotto? Considera la tracciabilità delle modifiche ai requisiti o ai rapporti sui difetti, processo di revisione tra pari. Considerare anche vari livelli di test: unità, integrazione, sistema, accettazione. Chi possiede questi test? Come viene determinata la copertura appropriata?
• Come viene garantita la qualità dei documenti? Considera quando vengono creati i documenti, dove sono memorizzati, quando saranno redatti, pubblicati e revisionati.
• In che modo vengono identificati e tracciati i difetti? Considerare sia i difetti rilevati internamente sia i difetti rilevati esternamente.
• Ogni progetto ha un processo definito. Il processo verrà verificato per garantire che venga seguito? Se sì, quanto spesso? Chi eseguirà gli audit? Come vengono risolti i risultati?

Tutte queste domande sono valide tanto in un approccio agile quanto in un approccio pianificato all'esecuzione del progetto. L'unica differenza potrebbe essere nelle risposte. Per esempio. ognuno di questi può accadere in determinate parti dell'iterazione anziché una volta in una determinata data storica.

Inoltre, a favore di "individui e interazioni su processi e strumenti" e "software operativo su documentazione completa", molte di queste risposte possono essere acquisite in un formato più leggero. Forse un wiki controllato invece di documenti cartacei con cancellazioni formali.

Una buona regola: documenta cosa fai e poi fai ciò che è documentato. Se non sono sincronizzati, ripristinali in sincronizzazione.

I test hanno molte parti. I test scritti durante TDD sono solo una parte. Il tuo piano deve includere tutte le altre parti.

Ad esempio, i test TDD tipicamente testano solo una singola piccola funzionalità, e possibilmente in un solo ambiente. Hai un piano per i test di integrazione per assicurarti che tutte le funzionalità funzionino bene insieme? Il tuo piano include test in un ambiente di staging (rispetto alla macchina dello sviluppatore)?

Che ne pensi di un piano per il test finale di accettazione? Stai per scrivere test automatici end-to-end? Che dire dei test esplorativi? È necessario pianificare per quello. Che dire dei test dopo la distribuzione? Presumibilmente la maggior parte dei test è su box di sviluppo locale o su server di staging. Avete un piano per testare una volta che il software è su server di produzione? In genere non è possibile eseguire una serie completa di test poiché è necessario conservare i dati di produzione esistenti.

Che ne pensi di test che comprendano l'aspetto grafico? Hai un piano per fare qualsiasi tipo di test per assicurarti che i colori appaiano nel modo in cui sono stati progettati per apparire e che le immagini siano tutte corrette, immagini non segnaposto? Se stai creando un'app Web, i test includono tutti i diversi browser utilizzati dagli utenti?

Che cosa succede quando i bug vengono scoperti e risolti? Avete un piano per tenere conto delle correzioni dei bug e delle nuove funzionalità aggiunte?

Che ne pensi delle metriche di test? Avete un piano per tenere traccia delle metriche di test comuni come il codice o la copertura delle filiali?

... e così via.