Quali tipi di documenti potrebbero essere utilizzati per descrivere l'automazione del test del software (in qualsiasi fase, pianificazione dell'automazione, progettazione del test, implementazione, reporting)? Esistono tipi standard di documenti? Se qualcuno potesse fornire esempi e modelli per diversi tipi di documenti? Qual è la differenza tra la documentazione del test manuale e quella automatizzata?
Ecco cosa vorrei proporre:
1. Test del documento strategico:
Questo descrive gli obiettivi di tutti i test, quali obiettivi di test esistono e come verrà eseguito il test completo collegando tutti i livelli da test unitario, test dei componenti, test di sistema e test di integrazione. Questo non è uno standard o qualcosa del genere - ma può essere qualcosa di questo tipo .
2. Tuta di prova:
Questa è la raccolta di casi di test e condizioni su quando e come ogni caso deve essere eseguito. Ogni insieme di input, procedure e comportamento di output previsto rispetto a ciascun elemento. Ci sono momenti in cui si notano molto più del successo e dei fallimenti, in modo che ulteriori analisi vengano fatte su questo.
3. Ambiente di test / configurazione e procedure
Se si sta automatizzando completamente o parzialmente il processo di test, vale la pena documentare in che modo i test (vari elementi di) verranno eseguiti. Dovrebbe essere discusso e convalidato se il test eseguito qui è corretto o meno. Lo sviluppatore e il QA associati dovrebbero sapere come utilizzare il set di strumenti e quali procedure seguire.
4. Matrice di tracciabilità:
Questa è una matrice ben definita che identifica quale serie di casi di test sono rilevanti per garantire che ogni punto di funzionalità sia garantito stabile. Leggi di più qui o questo wiki .
Ogni volta che viene scoperto un nuovo bug o viene richiesta una nuova funzionalità, la matrice di tracciabilità deve essere aggiornata per acquisire queste modifiche.
5. Risultati dei test
Sia che vengano generati automaticamente o eseguiti manualmente, i risultati (dettagliati e estati) devono essere acquisiti in un foglio di esecuzione del test. La cosa più importante da annotare è quella
un. l'osservazione originale (come i registri, la produzione effettiva dell'applicazione) dovrebbe essere acquisita come pertinente in modo da poter validare le conclusioni.
b. il documento deve catturare la build su cui sono stati eseguiti questi test; build differenti potrebbero non produrre lo stesso comportamento rispetto allo stesso test.
La procedura e i formati possono essere sviluppati secondo necessità. La cosa più importante, dalla mia esperienza personale, è che invece di rendere la conformità all'acqua in qualche formato, permette alle persone di documentare questo come un diario in esecuzione rendendo solo alcune cose obbligatorie e lasciando che le persone riversino liberamente più informazioni. I test non sono mai statici (almeno per qualsiasi progetto ragionevolmente complesso), quindi nel tempo tutti questi template devono evolversi in continuazione - molto spesso ogni passo successivo potrebbe essere una partenza importante dall'ultima. Se i modelli sono obsoleti o se le persone non lo seguono perché sono troppo rigidi, alla fine gran parte delle conoscenze pertinenti attraverso la procedura di test non si rifletteranno correttamente.
La risposta dipende molto da cosa il software fa, da come è progettato e persino dall'industria in cui verrà utilizzato il software. Alcune industrie hanno requisiti normativi molto estesi per la documentazione di test & validazione, ad esempio FDA CFR 21 Parte 11 nelle industrie Pharma e Biotech.
Inoltre, considera che anche se la tua organizzazione seguisse religiosamente tutti gli standard IEEE pertinenti per la documentazione di test, come ad esempio:
ci sono una miriade di documenti e standard direttamente e indirettamente che dovresti definire e usare, come:
Se tutti quegli standard IE3 sembrano insormontabili, in particolare per le organizzazioni e i team più piccoli, dai un'occhiata al ente di ingegneria del software di Conoscenza che è meno "scientifica" e più concisa.
Infine, in una certa misura, utilizzando gli strumenti ALM che mantengono i record elettronici dei test invece dei documenti formali è perfettamente alternativa valida fintanto che esistono procedure che definiscono un uso standardizzato.
Hai guardato IEEE 829-1998, Standard per la documentazione di test del software ? So che nella mia azienda vengono utilizzati i documenti di test in questo standard per descrivere l'intera strategia di test. Ad esempio, il Master Test Plan includerà effettivamente le informazioni sull'automazione dei test nella sezione di approccio.
Nel mio progetto, i test di automazione sono essenzialmente documentati usando gli stessi mezzi dei test manuali. Oltre a tutte le altre informazioni, segnaliamo anche il caso di test nel codice.
Manteniamo una suite di automazione che l'intero team sa come eseguire. Con entrambe queste informazioni, ogni membro del team è in grado di identificare il caso di test e di eseguirlo.
Inoltre, come il nostro codice di produzione, abbiamo anche la versione e la revisione dei casi di test automatizzati. Questi servono come documentazione vivente per la rappresentazione del codice del test.
Quindi in un certo senso, stiamo riutilizzando i nostri modi di documentazione per test manuali e codice di produzione per test automatizzati.
Leggi altre domande sui tag testing documentation automation qa