base di conoscenza
CTRL+F per cercare la tua parola chiave

Test di accettazione

Test di accettazione

In ingegneria e nelle sue varie sottodiscipline, i test di collaudo sono test condotti per determinare se i requisiti di una specifica o di un contratto sono soddisfatti. Può comprendere test chimici, test fisici o test delle prestazioni.

Nell'ingegneria dei sistemi può comportare test in scatola nera eseguiti su un sistema (ad esempio: un pezzo di software, molte parti meccaniche fabbricate o lotti di prodotti chimici) prima della sua consegna.

Nei test software l'ISTQB definisce i test di accettazione come:

Test formali in relazione alle esigenze dell'utente, ai requisiti e ai processi aziendali condotti per determinare se un sistema soddisfa o meno i criteri di accettazione e per consentire all'utente, ai clienti o ad altre entità autorizzate di determinare se accettare o meno il sistema.

- Glossario standard dei termini utilizzati nei test del software: 2

Il test di accettazione è anche noto come test di accettazione dell'utente (UAT), test per l'utente finale, test di accettazione operativa (OAT), test di sviluppo guidato da test di accettazione (ATTD) o test sul campo (accettazione). I criteri di accettazione sono i criteri che un sistema o un componente deve soddisfare per essere accettato da un utente, cliente o altra entità autorizzata.

Un test del fumo può essere utilizzato come test di accettazione prima di introdurre una build di software nel processo di test principale.

Panoramica

Il test è un insieme di attività condotte per facilitare la scoperta e / o la valutazione delle proprietà di uno o più articoli in prova. Ogni singolo test, noto come caso di test, esercita una serie di attività di test predefinite, sviluppate per guidare l'esecuzione dell'elemento di test per raggiungere gli obiettivi del test; tra cui corretta implementazione, identificazione degli errori, verifica della qualità e altri dettagli preziosi. L'ambiente di test è in genere progettato per essere identico o il più vicino possibile all'ambiente di produzione previsto. Include tutte le strutture, hardware, software, firmware, procedure e / o documentazione destinate o utilizzate per eseguire i test del software.

I casi di test UAT e OAT sono derivati ​​idealmente in collaborazione con clienti aziendali, analisti aziendali, tester e sviluppatori. È essenziale che questi test includano sia test di logica aziendale sia condizioni ambientali operative. I clienti aziendali (proprietari di prodotti) sono le principali parti interessate di questi test. Man mano che le condizioni del test raggiungono con successo i propri criteri di accettazione, le parti interessate sono rassicurate sullo sviluppo che procede nella giusta direzione.

  • I criteri del test di accettazione dell'utente (UAT) (nello sviluppo di software agile) sono generalmente creati da clienti commerciali ed espressi in un linguaggio di dominio aziendale. Si tratta di test di alto livello per verificare la completezza di una storia dell'utente o delle storie "riprodotte" durante uno sprint / iterazione.
  • I criteri del test di accettazione operativa (OAT) (indipendentemente dal fatto che si usi lo sviluppo agile, iterativo o sequenziale) sono definiti in termini di requisiti funzionali e non funzionali; che copre gli attributi di qualità chiave di stabilità funzionale, portabilità e affidabilità.

Processi

Potrebbe essere necessario eseguire più volte la suite di test di accettazione, poiché tutti i casi di test potrebbero non essere eseguiti in un'unica iterazione di test.

La suite di test di collaudo viene eseguita utilizzando procedure di collaudo predefinite per indirizzare ai tester quali dati utilizzare, i processi passo-passo da seguire e il risultato previsto dopo l'esecuzione. I risultati effettivi vengono conservati per il confronto con i risultati previsti. Se i risultati effettivi corrispondono ai risultati previsti per ciascun caso di test, si dice che il caso di test passa. Se la quantità di casi di test non passanti non supera la soglia predeterminata del progetto, si dice che la suite di test passi. In tal caso, il sistema può essere rifiutato o accettato alle condizioni precedentemente concordate tra lo sponsor e il produttore.

Il risultato atteso di una corretta esecuzione del test:

  • i casi di test vengono eseguiti utilizzando dati predeterminati
  • i risultati effettivi vengono registrati
  • vengono confrontati i risultati effettivi e previsti e
  • i risultati del test sono determinati.

L'obiettivo è garantire che il prodotto sviluppato soddisfi sia i requisiti funzionali sia quelli non funzionali. Lo scopo di condurre i test di accettazione è che una volta completato, e purché siano soddisfatti i criteri di accettazione, si prevede che gli sponsor sottoscriveranno lo sviluppo / il miglioramento del prodotto in quanto soddisfano i requisiti definiti (precedentemente concordati tra azienda e fornitore / sviluppatore del prodotto) .

Test di accettazione dell'utente

Il test di accettazione dell'utente (UAT) consiste in un processo di verifica del funzionamento di una soluzione per l'utente. Non si tratta di test di sistema (assicurarsi che il software non si arresti in modo anomalo e soddisfi i requisiti documentati), ma piuttosto garantisce che la soluzione funzionerà per l'utente (ovvero, test che l'utente accetta la soluzione); i fornitori di software spesso si riferiscono a questo come "beta testing".

Questo test dovrebbe essere eseguito da un esperto in materia (PMI), preferibilmente il proprietario o il cliente della soluzione in esame, e fornire un riepilogo dei risultati per la conferma di procedere dopo la prova o la revisione. Nello sviluppo del software, l'UAT come una delle fasi finali di un progetto si verifica spesso prima che un cliente o un cliente accetti il ​​nuovo sistema. Gli utenti del sistema eseguono test in linea con quanto accadrebbe in scenari di vita reale.

È importante che i materiali forniti al tester siano simili ai materiali che l'utente finale avrà. Ai tester dovrebbero essere forniti scenari di vita reale come i tre compiti più comuni o difficili che gli utenti che rappresentano intraprenderanno.

L'UAT funge da verifica finale della funzionalità aziendale richiesta e del corretto funzionamento del sistema, emulando le condizioni del mondo reale per conto del cliente pagante o di un cliente specifico di grandi dimensioni. Se il software funziona come richiesto e senza problemi durante il normale utilizzo, si può ragionevolmente estrapolare lo stesso livello di stabilità nella produzione.

I test degli utenti, di solito eseguiti dai clienti o dagli utenti finali, normalmente non si concentrano sull'identificazione di semplici problemi estetici come errori di ortografia, né su difetti di showstopper, come crash del software; tester e sviluppatori identificano e risolvono questi problemi durante le fasi precedenti di unit test, test di integrazione e test di sistema.

UAT deve essere eseguito in base a scenari di test. Gli scenari di test di solito differiscono dai casi di test di sistema o funzionali in quanto rappresentano un percorso "giocatore" o "utente". L'ampia natura dello scenario di test garantisce che l'attenzione sia focalizzata sul viaggio e non sui dettagli tecnici o specifici del sistema, evitando le fasi del test "click-by-click" per consentire una variazione nel comportamento degli utenti. Gli scenari di test possono essere suddivisi in "giorni" logici, che di solito sono dove l'attore (giocatore / cliente / operatore) o il sistema (backoffice, front-end) cambia.

Nell'industria, un UAT comune è un test di accettazione in fabbrica (FAT). Questo test ha luogo prima dell'installazione dell'apparecchiatura. Il più delle volte i tester non solo controllano che l'apparecchiatura soddisfi le specifiche, ma anche che sia perfettamente funzionante. Un FAT di solito comprende un controllo di completezza, una verifica rispetto ai requisiti contrattuali, una prova di funzionalità (mediante simulazione o un test funzionale convenzionale) e un'ispezione finale.

I risultati di questi test danno fiducia ai clienti su come il sistema funzionerà nella produzione. Potrebbero inoltre essere previsti requisiti legali o contrattuali per l'accettazione del sistema.

Test di accettazione operativa

Il test di accettazione operativa (OAT) viene utilizzato per condurre la prontezza operativa (pre-release) di un prodotto, servizio o sistema nell'ambito di un sistema di gestione della qualità. OAT è un tipo comune di test software non funzionale, utilizzato principalmente in progetti di sviluppo e manutenzione del software. Questo tipo di test si concentra sulla prontezza operativa del sistema da supportare e / o diventare parte dell'ambiente di produzione.

Test di accettazione in programmazione estrema

Test di accettazione è un termine usato nelle metodologie di sviluppo software agili, in particolare la programmazione estrema, che si riferisce al test funzionale di una user story da parte del team di sviluppo software durante la fase di implementazione.

Il cliente specifica gli scenari da testare quando una user story è stata implementata correttamente. Una storia può avere uno o più test di accettazione, qualunque cosa serva per garantire che la funzionalità funzioni. I test di accettazione sono test di sistema a scatola nera. Ogni test di accettazione rappresenta alcuni risultati attesi dal sistema. I clienti sono responsabili della verifica della correttezza dei test di accettazione e della revisione dei punteggi dei test per decidere quali test falliti hanno la massima priorità. I test di accettazione vengono utilizzati anche come test di regressione prima di una versione di produzione. Una user story non è considerata completa fino a quando non ha superato i test di accettazione. Ciò significa che devono essere creati nuovi test di accettazione per ogni iterazione o il team di sviluppo segnalerà progressi zero.

Tipi di test di accettazione

I tipi tipici di test di accettazione includono quanto segue

Test di accettazione da parte dell'utente Questo può includere test di accettazione in fabbrica (FAT), vale a dire i test eseguiti da un fornitore prima che il prodotto o il sistema venga spostato nel sito di destinazione, dopo di che i test di accettazione del sito (SAT) possono essere eseguiti dagli utenti sul sito. Test di accettazione operativa Conosciuto anche come test di prontezza operativa, questo si riferisce al controllo effettuato su un sistema per garantire che siano in atto processi e procedure per consentire al sistema di essere utilizzato e mantenuto. Ciò può includere controlli effettuati su strutture di backup, procedure per il ripristino di emergenza, formazione per gli utenti finali, procedure di manutenzione e procedure di sicurezza. Test di accettazione dei contratti e dei regolamenti Nei test di accettazione dei contratti, un sistema viene testato rispetto ai criteri di accettazione come documentato in un contratto, prima che il sistema venga accettato. Nei test di accettazione delle normative, un sistema viene testato per garantire che soddisfi gli standard governativi, legali e di sicurezza. Test di accettazione in fabbrica

Test di accettazione condotti nel sito in cui il prodotto è sviluppato ed eseguito da dipendenti dell'organizzazione fornitore, per determinare se un componente o un sistema soddisfa i requisiti, normalmente inclusi hardware e software.

Test Alpha e beta I test Alpha si svolgono presso i siti degli sviluppatori e prevedono test del sistema operativo da parte del personale interno, prima che vengano rilasciati a clienti esterni. Il beta testing si svolge presso i siti dei clienti e prevede test da parte di un gruppo di clienti che utilizzano il sistema nelle proprie sedi e forniscono feedback, prima che il sistema venga rilasciato ad altri clienti. Quest'ultimo è spesso chiamato "test sul campo".

Elenco dei quadri di collaudo

  • Quadro Concordion, Specification by example (SbE)
    • Concordion.NET, test di accettazione in .NET
  • Cucumber, un framework di test di accettazione dello sviluppo guidato dal comportamento (BDD)
    • Capybara, framework di test di accettazione per applicazioni web Ruby
    • Behat, framework di accettazione BDD per PHP
    • Lattuga, framework di accettazione BDD per Python
  • Fabasoft app.test per test di accettazione automatizzati
  • Framework per test integrato (adattamento)
    • FitNesse, una forcella di Fit
  • iMacros
  • Framework Web Ajax Java nativo con funzionalità di test Web integrate, basate su server e funzionali.
  • Mocha, un popolare framework di test di accettazione web basato su Javascript e Node.js
  • Ranorex
  • Robot Framework
  • Selenio
  • Specifica per esempio (Specs2)
  • Watir
  • Calibro (software)