Menu

Modello di esempio per rapporto del test di accettazione con esempi

sample template acceptance test report with examples

Prova Il Nostro Strumento Per Eliminare I Problemi

Panoramica del rapporto sul test di accettazione (Parte III):

Tutorial precedente | PROSSIMO Tutorial

Nel nostro precedente tutorial su ' Documentazione sui test di accettazione con scenari in tempo reale 'Abbiamo discusso il piano del test di accettazione.

In questo tutorial, daremo uno sguardo approfondito alla segnalazione dello stato del test di accettazione, del riepilogo del test di accettazione e della firma.

Alcuni modelli generici sono inclusi in questo tutorial per migliorare la tua comprensione in un modo migliore. Passeremo anche il mouse sul concetto di Test di accettazione in Sviluppo Agile e Test di accettazione guidato.

In breve, questo tutorial ti spiegherà il rapporto sullo stato del test di accettazione e il rapporto di riepilogo insieme ad alcuni modelli generici per una chiara comprensione e rispolverà anche il concetto di test di accettazione nello sviluppo Agile e basato sui test in un modo facilmente comprensibile.

Modello di test di accettazione

Cosa imparerai:

Rapporto sullo stato del test di accettazione

Il rapporto sui test di accettazione dovrebbe sempre riassumere i test di accettazione eseguiti insieme ai loro risultati. Dovrebbe essere indirizzato a tutti gli stakeholder identificati che fanno parte della fase di test di accettazione. Una volta iniziata l'esecuzione dei test di accettazione, lo stato di avanzamento dovrebbe essere riportato su base giornaliera.

Modello generico per rapporto sullo stato del test di accettazione:

Data :Data rapporto sullo stato del test di accettazione

Dettagli dell'esecuzione dei test di accettazione odierni:

  • Numero di test superati
  • Numero di test non riusciti
  • Numero di test in corso

Dettagli dell'esecuzione dei test di accettazione fino alla data:

  • Numero totale di test
  • Numero di test superati
  • Numero di test non riusciti
  • Numero di test in corso
  • Numero di test in sospeso

Dettagli sui difetti:

quali sono le migliori app di realtà virtuale
  • Numero di difetti registrati
  • Ogni difetto dovrebbe avere i seguenti dettagli:
    • ID, riepilogo, componente, gravità
  • Il numero totale di difetti registrati fino ad ora (in fase di test di accettazione).

Questo rapporto deve essere rivisto su base giornaliera per garantire che l'esecuzione sia in linea e non vi siano deviazioni dai programmi pianificati.

Rapporto di riepilogo del test di accettazione

Questo è il report che riassume lo stato dell'intera fase di Test di Accettazione. Ciò comporta dettagli come attività di test condotte, riferimenti a criteri soddisfatti, specifiche dei requisiti, regole aziendali, risultati di esecuzione, programmi pianificati, deviazioni, ecc.

Modello generico per rapporto di riepilogo del test di accettazione:

Sommario

Varianze

Varianze

Risultati

Rapporti

Valutazione

Raccomandazione

gravità dei difetti e il tasso di superamento influisce sulla raccomandazione per il prodotto da lanciare sul mercato.>

Sforzi

Sforzi

Rapporto di firma

Una volta che il prodotto ha superato il test di accettazione, si consiglia di andare in diretta. Prima di essere lanciato in produzione, deve essere firmato formalmente.

Modello generico per rapporto di firma:

Nome prodotto, versione release, numero build

Ultimo rapporto

Recensito il

Recensito da

Rivedi commenti

Data di sottoscrizione

Sign-Off By

Commenti di firma

In generale, uno qualsiasi dei rapporti di cui sopra dovrebbe essere rivisto dalle principali parti interessate per il suo modello e deve essere concordato su ciò che deve essere utilizzato come informazione all'interno.

Tutti i dettagli che vengono inseriti nel report dovrebbero essere controllati prima di condividerli con gli stakeholder. Eventuali discrepanze nel rapporto avranno un forte impatto sulla decisione aziendale e potrebbero causare un guasto del prodotto nel mercato.

Pertanto, la segnalazione dovrebbe essere sempre gestita da specialisti o membri senior del team.

Test di accettazione in Agile

Nel Agile , I criteri di accettazione di ciascuna User story sono destinati ai test di accettazione, ovvero i test di accettazione derivano dai criteri di accettazione di una User story. Ciascun criterio di accettazione può avere uno o più test di accettazione per coprire lo scenario.

I test di accettazione sono generalmente progettati da un QA che è l'esperto in materia nell'area. Il test di accettazione in Agile inizia molto presto rispetto agli altri approcci, di solito all'interno degli sprint stessi.

Viene eseguito molto frequentemente poiché ogni sprint avrà nuove storie utente in arrivo e anche miglioramenti / continuazione delle storie precedenti.

Il test di accettazione viene eseguito in due fasi diverse in Agile:

  • Quando la funzione viene creata e nella sua fase iniziale - di base.
  • Quando la funzionalità è integrata e stabilizzata con le altre funzionalità del prodotto.

Ogni user story qui deve essere sottoposta a test di accettazione e deve essere passata per considerazione. Eventuali fallimenti nel Test di accettazione devono essere considerati come una priorità alta e risolti immediatamente, questo, a sua volta, avrà il test di accettazione per eseguirlo.

I punti della storia vengono assegnati a ciascuna storia utente in base al successo dei risultati del test di accettazione per ciascuno dei criteri di accettazione. Il test di accettazione definisce anche il completamento a livello di User Story, affermando che i criteri di accettazione per la storia sono soddisfatti.

Chi esegue il test di accettazione in Agile?

Di solito, i responsabili di prodotto, le competenze in materia (potrebbero essere clienti E / O beta tester) eseguono i test di accettazione in un ambiente Agile. A volte, il QA coinvolge anche in questa attività insieme alle loro normali attività di regressione.

Vantaggi dei test di accettazione in Agile

Ci sono diversi vantaggi dei test di accettazione in Agile.

I vantaggi sono:

  • Collaborazione più stretta tra Product manager e team.
  • Aumenta la fiducia a livello di User Story.
  • Aiuterà a derivare più scenari per coprire ogni criterio di accettazione.
  • Maggiore probabilità di improvvisare le soluzioni al prodotto tramite criteri di accettazione nelle User Story.

Inconvenienti

Sebbene ci siano molti vantaggi, ci sono anche alcuni demeriti.

Gli svantaggi includono:

  • Non tutte le storie possono essere prese in considerazione per i test di accettazione. Solo storie funzionali da coprire: la copertura dal punto di vista della storia potrebbe venire giù.
  • Non tutti i criteri di accettazione possono essere presi in considerazione per i test di accettazione. Devono essere coperti solo i criteri funzionali: la copertura saggia dei Criteri di accettazione all'interno della storia dell'utente potrebbe venire meno.
  • Poiché sono coinvolti stakeholder di background diversi e poiché i test di accettazione in termini di storia vengono eseguiti direttamente, è abbastanza difficile per tutti essere sulla stessa pagina (fondamentalmente nella comprensione del livello della singola User story).
  • Poiché la durata del rilascio è inferiore rispetto ad altri approcci, è abbastanza difficile accogliere i test di accettazione all'interno degli Sprint.

Sviluppo basato su test di accettazione (ATDD)

Questa è una delle pratiche di sviluppo Agile in cui l'intero team discute in modo collaborativo ciascuno dei criteri di accettazione della User Story e costruisce solidi test di accettazione attorno ad essi.

Questo perché prospettive diverse da ciascuno dei membri del team daranno un nuovo modo di pensare per ciascuno dei criteri di accettazione e arriveranno con un buon numero di test di accettazione che coprono più scenari. A volte, ATDD è anche chiamato Story Test Driven Development (STDD).

In realtà, l'ATDD avviene prima dell'inizio dello sviluppo. Quindi, gli sviluppatori, in questo approccio, sapranno cosa ci si aspetta effettivamente e come ottenerlo. L'intero team condividerà una visione comune della funzionalità e di ciò che viene costruito.

Questo descrive come il prodotto viene costruito e, a sua volta, darà una buona idea di come funzionerà effettivamente il prodotto prima di essere consegnato per il test. Quindi è definito come ' Sviluppo guidato dal test di accettazione '.

Conclusione

Il test di accettazione in ogni suo approccio ha l'obiettivo comune di costruire la fiducia e la soddisfazione del cliente sul prodotto sviluppato prima che venga messo in funzione. Ciò si ottiene solo quando non ci sono / meno difetti di bassa gravità nel prodotto che non ostacolano nessuna delle funzionalità.

In poche parole:

  • I test di accettazione sono stati superati.
  • I difetti sono a livelli accettabili.
  • Copertura per flusso / scenario raggiunta.
  • Il prodotto e le sue soluzioni sono accettati.
  • Il cliente è abbastanza sicuro del prodotto.
  • Tutti i documenti del prodotto vengono aggiornati per corrispondere alle funzioni più recenti.
  • Risultato per lo sforzo della squadra.
  • Buono per andare avanti con il lancio della produzione.

Tutorial precedente | PROSSIMO Tutorial

Spero che tu abbia acquisito una conoscenza immensa da questi tutorial sui test di accettazione. Sentiti libero di condividere i tuoi pensieri e di porre le tue domande nella sezione commenti qui sotto.

Lettura consigliata

^