Che cos'è il test di accettazione (una guida completa)

what is acceptance testing

Introduzione al test di accettazione (Parte I):

In questa serie di tutorial imparerai:

1. Che cos'è il test di accettazione
2. Test di accettazione e piano di test
3. Stato dei test di accettazione e rapporti di riepilogo
4. Che cos'è il test di accettazione dell'utente (UAT)

Hai finito con il test del sistema? La maggior parte dei tuoi bug sono stati risolti? I bug sono stati verificati e chiusi? Allora, qual è il prossimo?

Successivamente nell'elenco viene il test di accettazione, che è l'ultima fase del processo di test del software . Questa è la fase in cui decide il cliente GO / NO-GO per il prodotto e deve essere obbligatoriamente seguita prima di rilasciare il prodotto sul mercato. Gli sforzi congiunti dello sviluppo e del team di test saranno premiati dal cliente accettando o rifiutando il Prodotto sviluppato.

Questo tutorial unico sul test di accettazione ti fornirà una panoramica completa del significato, dei tipi, degli usi e di vari altri fattori coinvolti nel test di accettazione in modo semplice e facile per una migliore comprensione.

Cosa imparerai:

• Cos'è il test di accettazione?
• Perché i test di accettazione?
• Tipi
  • # 1) Test di accettazione dell'utente (UAT)
  • # 2) Test di accettazione aziendale (BAT)
  • # 3) Test di accettazione del contratto (CAT)
  • # 4) Regolamenti / Test di accettazione della conformità (RAT)
  • # 5) Test di accettazione operativa (OAT)
  • # 6) Alpha test
  • # 7) Beta test / Test sul campo
• Chi esegue il test di accettazione?
• Qualità dei tester di accettazione
• Uso
• Differenze tra test di sistema, test di accettazione e test di accettazione dell'utente
• Test di accettazione
• Test di accettazione letto
• Criteri di ingresso e di uscita per AT
  • Criteri di ingresso
  • Criteri di uscita
• Processo di test di accettazione
• Fattori di successo per questo test
• Conclusione
• Lettura consigliata

Cos'è il test di accettazione?

Una volta che il file Processo di test del sistema viene completato dal team di test e viene firmato, l'intero Prodotto / applicazione viene consegnato al cliente / pochi utenti di clienti / entrambi, per testarne l'accettabilità, ovvero il Prodotto / applicazione deve essere impeccabile nel soddisfare sia principali requisiti aziendali. Inoltre, i flussi aziendali end-to-end vengono verificati in modo simile allo scenario in tempo reale.

L'ambiente simile alla produzione sarà l'ambiente di test per Accepting Testing (generalmente definito come ambiente di staging, pre-produzione, failover, UAT).

Questo è un tecnica di test black-box dove viene verificata solo la funzionalità per garantire che il prodotto soddisfi i criteri di accettazione specificati (non sono necessarie conoscenze di progettazione / implementazione).

Perché i test di accettazione?

Sebbene il test del sistema sia stato completato con successo, il test di accettazione è richiesto dal cliente. I test condotti qui sono ripetitivi, poiché sarebbero stati trattati nei test di sistema.

Allora, perché questo test viene condotto dai clienti?

Questo è perché:

• Acquisire fiducia nel prodotto che viene immesso sul mercato.
• Per garantire che il prodotto funzioni nel modo in cui deve.
• Per garantire che il prodotto corrisponda agli attuali standard di mercato e sia sufficientemente competitivo con gli altri prodotti simili sul mercato.

Tipi

Esistono diversi tipi di test.

Alcuni di loro sono elencati di seguito:

# 1) Test di accettazione dell'utente (UAT)

UAT è quello di valutare se il prodotto funziona per l'utente, correttamente per l'utilizzo. I requisiti specifici che vengono utilizzati abbastanza spesso dagli utenti finali vengono scelti principalmente per lo scopo del test. Questo è anche definito come End-User Testing.

Il termine 'Utente' qui indica gli utenti finali a cui è destinato il Prodotto / applicazione e, quindi, il test viene eseguito dal punto di vista degli utenti finali e dal loro punto di vista.

=> Inoltre Leggere: Che cos'è il test di accettazione dell'utente (UAT)?

# 2) Test di accettazione aziendale (BAT)

Questo serve per valutare se il Prodotto soddisfa o meno gli obiettivi e gli scopi aziendali.

Le BAT si concentrano principalmente sui vantaggi aziendali (finanze) che sono piuttosto impegnativi a causa delle mutevoli condizioni di mercato / delle tecnologie avanzate, cosicché l'attuale attuazione potrebbe dover subire modifiche che si traducono in budget aggiuntivi.

come creare un nuovo file java in eclipse

Anche il prodotto che supera i requisiti tecnici potrebbe non superare le BAT a causa di questi motivi.

# 3) Test di accettazione del contratto (CAT)

Si tratta di un contratto che specifica che una volta che il Prodotto diventa operativo, entro un periodo predeterminato, deve essere eseguito il test di accettazione e deve superare tutti i casi d'uso di accettazione.

Il contratto firmato qui è definito come Service Level Agreement (SLA), che include i termini in cui il pagamento verrà effettuato solo se i servizi del prodotto sono in linea con tutti i requisiti, il che significa che il contratto è soddisfatto.

A volte, questo contratto può essere stipulato prima che il Prodotto venga pubblicato. In entrambi i casi le modalità di un contratto dovrebbero essere ben definite in termini di periodo di prova, aree di prova, condizioni sui problemi riscontrati nelle fasi successive, pagamenti, ecc.

# 4) Regolamento /ConformitàTest di accettazione (RAT)

Questo serve per valutare se il Prodotto viola le regole e i regolamenti definiti dal governo del paese in cui viene rilasciato. Potrebbe non essere intenzionale, ma avrà un impatto negativo sull'attività.

Di solito, il Prodotto / applicazione sviluppato che è destinato a essere rilasciato in tutto il mondo, deve essere sottoposto a RAT, poiché diversi paesi / regioni hanno regole e regolamenti diversi definiti dai suoi organi di governo.

Se una qualsiasi delle regole e dei regolamenti viene violata per qualsiasi paese, quel paese o la regione specifica in quel paese non sarà autorizzato a utilizzare il prodotto ed è considerato un guasto. I venditori del Prodotto saranno direttamente responsabili se il Prodotto viene rilasciato anche se c'è una violazione.

# 5) Test di accettazione operativa (OAT)

Questo serve per valutare la prontezza operativa del Prodotto ed è un test non funzionale. Include principalmente test di ripristino, compatibilità, manutenibilità, disponibilità del supporto tecnico, affidabilità, failover, localizzazione ecc.

OAT assicura principalmente la stabilità del Prodotto prima di rilasciarlo alla produzione.

# 6) Alpha test

Questo serve per valutare il Prodotto nell'ambiente di sviluppo / test da parte di un team di tester specializzati, solitamente chiamati alpha tester. Qui, il feedback dei tester, i suggerimenti aiutano a migliorare l'utilizzo del prodotto e anche a correggere alcuni bug.

Qui, il test avviene in modo controllato.

=> Leggi anche: Cos'è l'alpha test?

# 7) Beta test / Test sul campo

Questo serve per valutare il prodotto esponendolo ai veri utenti finali, solitamente chiamati beta tester / utenti beta, nel loro ambiente. Il feedback continuo degli utenti viene raccolto e i problemi vengono risolti. Inoltre, questo aiuta a migliorare / migliorare il prodotto per offrire una ricca esperienza utente.

Il test avviene in modo incontrollato, il che significa che un utente non ha restrizioni sul modo in cui il Prodotto viene utilizzato.

=> Leggi anche: Cos'è il beta test?

Tutti questi tipi hanno un obiettivo comune:

• Garantire per acquisire / arricchire la fiducia nel prodotto.
• Assicurati che il prodotto sia pronto per essere utilizzato dagli utenti reali.

Chi esegue il test di accettazione?

Per il tipo Alpha, solo i membri dell'organizzazione (che hanno sviluppato il prodotto) eseguono il test. Questi membri non fanno parte direttamente del progetto (Project manager / lead, sviluppatori, tester). I team di gestione, vendita e supporto di solito eseguono i test e forniscono feedback di conseguenza.

A parte il tipo Alpha, tutti gli altri tipi di accettazione sono generalmente eseguiti da diversi stakeholder. Come i clienti, i clienti del cliente, i tester specializzati dell'organizzazione (non sempre).

È anche utile coinvolgere analisti aziendali e competenze in materia durante l'esecuzione di questo test in base al suo tipo.

Qualità dei tester di accettazione

I tester con le seguenti qualità sono qualificati come tester di accettazione:

• Capacità di pensare in modo logico e analitico.
• Buona conoscenza del dominio.
• In grado di studiare i prodotti competitivi nel mercato e analizzare gli stessi nel prodotto sviluppato.
• Avere la percezione dell'utente finale durante il test.
• Comprendi le esigenze aziendali per ogni requisito e verifica di conseguenza.

Impatto dei problemi rilevati durante questo test

Eventuali problemi riscontrati nella fase del test di accettazione devono essere considerati di alta priorità e risolti immediatamente. Ciò richiede anche che l'analisi delle cause alla radice venga eseguita su ogni problema riscontrato.

Il team di test gioca un ruolo importante nel fornire RCA per i problemi di accettazione. Questi aiutano anche a determinare l'efficacia dei test eseguiti.

Inoltre, i problemi validi nel test di accettazione colpiranno sia i test che gli sforzi del team di sviluppo in termini di impressioni, valutazioni, sondaggi sui clienti, ecc. A volte, se viene rilevata un'ignoranza da parte del team di test sulle convalide, si verifica anche un'escalation.

Uso

Questo test è utile da diversi aspetti.

Pochi dei quali includono:

• Per capire i problemi persi durante la fase di test funzionale.
• Quanto bene è stato sviluppato il prodotto.
• Un prodotto è ciò di cui hanno effettivamente bisogno i clienti.
• Feedback / sondaggi condotti aiutano a migliorare le prestazioni del Prodotto e l'esperienza dell'utente.
• Migliora il processo seguito inserendo gli RCA come input.
• Ridurre al minimo o eliminare i problemi derivanti dal prodotto di produzione.

Differenze tra test di sistema, test di accettazione e test di accettazione dell'utente

Di seguito sono riportate le principali differenze tra questi 3 tipi di test di accettazione.

Test di accettazione

Analogamente ai casi di test del prodotto, abbiamo test di accettazione. I test di accettazione derivano dai criteri di accettazione delle storie degli utenti. Questi sono solitamente gli scenari scritti con dettagli di alto livello su ciò che il prodotto deve fare in condizioni diverse.

Non fornisce un'immagine chiara su come eseguire i test, come nei casi di test. I test di accettazione sono scritti da tester che hanno una presa completa sul prodotto, di solito competenza in materia. Tutti i test scritti vengono esaminati da un cliente e / o da analisti aziendali.

Questi test vengono eseguiti durante il test di accettazione. Insieme ai test di accettazione, deve essere preparato un documento dettagliato su eventuali impostazioni da eseguire. Dovrebbe includere i dettagli di ogni minuto con screenshot appropriati, valori di configurazione, condizioni, ecc.

Test di accettazione letto

Il banco di prova per questo test è simile a un normale banco di prova, ma è separato. La piattaforma con tutto l'hardware, il software, i prodotti operativi, le impostazioni e le configurazioni di rete, le impostazioni e le configurazioni del server, le impostazioni e le configurazioni del database, le licenze, i plug-in, ecc., Devono essere configurate in modo molto simile l'ambiente di produzione.

Il banco di prova di accettazione è una piattaforma / ambiente in cui verranno eseguiti i test di accettazione progettati. Prima di consegnare l'ambiente del test di accettazione al cliente, è buona norma verificare eventuali problemi ambientali e la stabilità del Prodotto.

Se non è impostato un ambiente separato per i test di accettazione, è possibile utilizzare un ambiente di test regolare a tale scopo. Ma qui, sarà disordinato poiché i dati di test dai normali test di sistema ei dati in tempo reale dai test di accettazione vengono mantenuti in un unico ambiente.

Il banco di prova di accettazione viene solitamente installato dal lato del cliente (ovvero in laboratorio) e avrà un accesso limitato ai team di sviluppo e test.

quale non è un esempio di data mining?

Ai team sarà richiesto di accedere a questo ambiente tramite VM / o URL appositamente progettati utilizzando credenziali di accesso speciali e tutti gli accessi a questo verranno monitorati. Niente in questo ambiente deve essere aggiunto / modificato / eliminato senza l'autorizzazione del cliente e dovrebbe essere informato delle modifiche apportate.

Criteri di ingresso e di uscita per AT

Proprio come qualsiasi altra fase dell'STLC, il test di accettazione ha una serie di criteri di ingresso e uscita che devono essere ben definiti nel Piano del test di accettazione (che è trattato nella parte successiva di questo tutorial).

Questa è la fase che inizia subito dopo il test del sistema e termina prima del lancio in produzione. Quindi, i criteri di uscita del test del sistema diventano una parte dei criteri di ingresso per AT. Allo stesso modo, i criteri di uscita di AT diventano una parte dei criteri di ingresso per il lancio di produzione.

Criteri di ingresso

Di seguito sono indicate le condizioni da soddisfare prima di iniziare:

• I requisiti aziendali dovrebbero essere chiari e disponibili.
• La fase di test del sistema e della regressione dovrebbe essere completata.
• Tutti i bug critici, principali e normali dovrebbero essere corretti e chiusi (i bug minori accettati principalmente sono bug cosmetici che non disturbano l'utilizzo del prodotto).
• L'elenco dei problemi noti dovrebbe essere preparato e condiviso con le parti interessate.
• Deve essere installato un banco di prova di accettazione e deve essere eseguito un controllo di alto livello per l'assenza di problemi ambientali.
• La fase di test del sistema deve essere firmata consentendo al prodotto di passare alla fase AT (di solito eseguita tramite comunicazione e-mail).

Criteri di uscita

Ci sono determinate condizioni che AT deve soddisfare per lasciare che il prodotto vada in produzione.

Sono i seguenti:

• I test di accettazione dovrebbero essere eseguiti e tutti i test dovrebbero essere superati.
• Nessun difetto critico / grave lasciato aperto. Tutti i difetti devono essere corretti e verificati immediatamente.
• AT dovrebbe essere firmato da tutti gli stakeholder inclusi con Go / No-Go Decisione sul prodotto.

Processo di test di accettazione

Nel Modello V. , La fase AT è parallela alla fase Requisiti.

Il processo AT effettivo va come mostrato di seguito:

Analisi dei requisiti aziendali

I requisiti aziendali vengono analizzati facendo riferimento a tutti i documenti disponibili all'interno del progetto.

Alcuni dei quali sono:

• Specifiche dei requisiti di sistema
• Documento sui requisiti aziendali
• Casi d'uso
• Diagrammi del flusso di lavoro
• Data matrix progettata

Piano di test di accettazione del progetto

Ci sono alcuni elementi che devono essere documentati nel piano del test di accettazione.

Diamo un'occhiata ad alcuni di loro:

• Strategia e approccio del test di accettazione.
• I criteri di ingresso e di uscita dovrebbero essere ben definiti.
• L'ambito di AT dovrebbe essere ben menzionato e deve coprire solo i requisiti aziendali.
• L'approccio alla progettazione del test di accettazione dovrebbe essere dettagliato in modo che chiunque scriva i test possa facilmente capire il modo in cui deve essere scritto.
• È necessario menzionare la configurazione del banco di prova, il programma / le scadenze dei test effettivi.
• Poiché il test è condotto da diversi stakeholder, i dettagli sulla registrazione dei bug dovrebbero essere menzionati in quanto gli stakeholder potrebbero non essere a conoscenza della procedura seguita.

Progettare e rivedere i test di accettazione

I test di accettazione dovrebbero essere scritti a livello di scenario menzionando ciò che deve essere fatto (non in dettaglio per includere come farlo). Questi dovrebbero essere scritti solo per le aree di ambito identificate per i requisiti aziendali e ogni test deve essere mappato al suo requisito di riferimento.

Tutti i test di accettazione scritti devono essere riesaminati per ottenere un'elevata copertura sui requisiti aziendali.

Questo per assicurarsi che non siano coinvolti altri test oltre all'ambito menzionato, in modo che i test rientrino nelle scadenze programmate.

Configurazione del banco di prova di accettazione

Il banco di prova dovrebbe essere configurato in modo simile a un ambiente di produzione. Sono necessari controlli di livello molto alto per confermare la stabilità e l'utilizzo dell'ambiente. Condividi le credenziali per utilizzare l'ambiente solo con uno stakeholder che sta eseguendo questo test.

Configurazione dei dati del test di accettazione

I dati di produzione devono essere preparati / popolati come dati di prova nei sistemi. Inoltre, dovrebbe esserci un documento dettagliato in modo tale che i dati debbano essere utilizzati per i test.

Non hai i dati di test come TestName1, TestCity1, ecc. Invece hai Albert, Messico, ecc. Ciò offre una ricca esperienza di dati in tempo reale e il test sarà aggiornato.

Esecuzione del test di accettazione

I test di accettazione progettati devono essere eseguiti sull'ambiente in questa fase. Idealmente, tutti i test dovrebbero passare al primo tentativo stesso. Non dovrebbero esserci bug funzionali derivanti dai test di accettazione, se presenti, quindi dovrebbero essere segnalati con una priorità alta per essere risolti.

Anche in questo caso, i bug corretti devono essere verificati e chiusi come attività ad alta priorità. Il rapporto sull'esecuzione del test deve essere condiviso su base giornaliera.

I bug registrati in questa fase dovrebbero essere discussi in una riunione di valutazione dei bug e devono essere sottoposti alla procedura di analisi della causa principale. Questo è l'unico punto in cui i test di accettazione valutano se tutti i requisiti aziendali sono effettivamente soddisfatti dal prodotto o meno.

Decisione aziendale

Viene fuori un file Go / No-Go decisione per il prodotto da lanciare in produzione. Partire decisione porterà il prodotto avanti per essere rilasciato sul mercato. No-Go decisione contrassegna il prodotto come guasto.

Pochi fattori di decisione No-Go:

• Scarsa qualità del prodotto.
• Troppi bug funzionali aperti.
• Deviazione dai requisiti aziendali.
• Non all'altezza degli standard di mercato e necessita di miglioramenti per soddisfare gli attuali standard di mercato.

Fattori di successo per questo test

Una volta pianificato questo test, prepara una lista di controllo che ne aumenti il ​​tasso di successo. Ci sono alcune azioni che devono essere seguite prima che inizi il test di accettazione.

Sono:

• Avere un ambito ben definito e assicurarsi che vi sia una necessità aziendale per l'ambito identificato per questo test.
• Eseguire almeno una volta i test di accettazione nella fase di test del sistema.
• Eseguire ampio test ad hoc per ciascuno degli scenari del test di accettazione.

Conclusione

In poche parole, i test di accettazione aiutano a capire l'efficienza dei team di sviluppo e test.

Ci sono diversi strumenti per condurre questa attività, ma di solito si preferisce che venga eseguita manualmente in quanto vi è un coinvolgimento degli utenti reali e di diversi stakeholder che non hanno un background tecnico e potrebbe non essere fattibile per loro.

Qual è il prossimo?

Nel nostro prossimo tutorial, passeremo il mouse sugli argomenti seguenti:

• Esempi di criteri per test di accettazione.
• Come scrivere un piano di test di accettazione.
• Un modello adatto per la scrittura dei test di accettazione.
• Come scrivere Test di accettazione con esempi.
• Identificazione degli scenari del test di accettazione.
• Rapporti sui test di accettazione.
• Test di accettazione nello sviluppo Agile e basato sui test.

PROSSIMO Tutorial n. 2: Piano del test di accettazione

Hai eseguito test di accettazione? Saremmo lieti di ascoltare le tue esperienze !!

Lettura consigliata

• Alpha test e beta test (una guida completa)
• Che cos'è il test di accettazione dell'utente (UAT): una guida completa
• Guida completa al test di verifica della costruzione (test BVT)
• Test funzionale vs test non funzionale
• Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
• Tipi di test del software: diversi tipi di test con dettagli
• Esercitazione sul test del data warehouse di test ETL (una guida completa)
• Guida al test di sicurezza delle applicazioni Web