Quanto dettagliato deve essere un test di accettazione del cliente?

https://stackoverflow.com/questions/832403

07-07-2019
|

Domanda

Ecco una descrizione del test, testando " Crea nuovo widget " caso d'uso.

Conferma di poter inserire un nuovo widget nel sistema.

Ecco un'altra descrizione del test, testando " Crea nuovo widget " caso d'uso.

Apri l'applicazione.
Crea un nuovo widget con il nome di "A-008", con la descrizione che è "Widget di prova per test di accettazione 3-45".
Conferma che il widget è ora visibile nella vista ad albero del widget più a sinistra.
Seleziona un altro widget nella vista ad albero, quindi seleziona il widget " A-008 " ancora. Verificare che i valori nel widget siano uguali ai valori immessi.
Elimina widget " A-008 " e chiudi l'applicazione

Ecco un'altra descrizione del test, testando " Crea nuovo widget " caso d'uso.

Apri l'applicazione.
Visualizza una seconda istanza dell'applicazione che visualizza gli stessi dati.
Nella prima istanza dell'applicazione, fai clic con il pulsante destro del mouse su " Widget " nodo. Nel menu contestuale che segue, attiva " Crea nuovo widget " elemento del menu.
Un "Nuovo Widget" la finestra dovrebbe essere attivata. Lascia vuoto ogni campo e premi il pulsante OK. Dovrebbe apparire una finestra di messaggio che dice "Inserisci un nome Widget". Premere OK su questa finestra di messaggio.
Inserisci " A-008 " nel " Nome " campo.
Imposta il campo della descrizione su "Il lama (Lama glama) è un camelide sudamericano, ampiamente usato come animale da soma dagli Incas e da altri nativi delle Ande. In Sud America i lama sono ancora usati come bestie da soma, nonché per la produzione di fibre e carne. L'altezza di un lama adulto a grandezza naturale è compresa tra 5,5 piedi (1,6 metri) e 6 piedi (1,8 metri) nella parte superiore della testa. Possono pesare tra circa 280 libbre (127 chilogrammi) e 450 libbre (204 chilogrammi). Alla nascita, un baby lama (chiamato cria) può pesare tra 20 libbre (9 chilogrammi) e 30 libbre (14 chilogrammi).
Premere il pulsante OK. Dovrebbe apparire una finestra di messaggio che dice " La descrizione deve contenere almeno 512 caratteri &
;
Imposta la descrizione su " '); ELIMINA DA WIDGET DOVE 1 = 1; " nella "Descrizione" campo. Premere il pulsante OK.
Nella vista ad albero più a sinistra, un nuovo widget con il nome di " A-008 " avrebbe dovuto apparire.
Attiva una finestra nella seconda istanza dell'applicazione e conferma che Widget "A-008" è apparso automaticamente anche in quella vista ad albero.
Nella prima istanza dell'applicazione, fai clic con il pulsante destro del mouse su " Widget " nodo. Nel menu contestuale che segue, attiva " Crea nuovo widget " elemento del menu. Un "Nuovo Widget" la finestra dovrebbe essere attivata.
Imposta il nome su & A; 008 " ;, e premi OK. Una finestra di messaggio deve apparire, dicendo " esiste già un widget con questo nome. Seleziona un altro nome di Widget " ;.
Premi il pulsante OK su questa finestra di messaggio, quindi premi il pulsante Annulla per uscire da " Crea Widget " finestra di dialogo.
Visualizza la pagina del widget per il widget " A-008 " nella seconda istanza.
In primo luogo, premi il tasto " Annulla " voce di menu
Conferma che la seconda istanza ora sta visualizzando la pagina iniziale.
................. etc ..............

Ogni esempio verifica che sia possibile creare un nuovo widget. Nel terzo test, stavo testando la funzionalità come programmatore esperto, pensando "OK, dove sono tutti i luoghi in cui un bug può apparire" e controllando ognuno di questi. Il terzo è appropriato per un test di accettazione da parte del cliente?

Quanto è completo "troppo completo"?

Soluzione

I casi di test di accettazione dell'utente devono essere dettagliati e semplici ma non dettagliati come il tuo terzo esempio. Test di accettazione significa assicurarsi che il cliente ottenga ciò che ha accettato . Se dici semplicemente, " fai clic su di esso, quindi fai clic su, ecc. Ecc. & Quot; è più simile a un test funzionale. Non stai sollecitando gli utenti a verificare che la funzionalità soddisfi il caso di prova indicato nel test di accettazione. Stai solo chiedendo loro di fare clic su test che potresti aver semplicemente automatizzato.

I test di accettazione dell'utente dovrebbero essere più simili a "creare widget, verificare che appaia, eliminare widget, ecc." Ciò incoraggerà inoltre gli utenti a cercare singole funzionalità e (come effetto collaterale) a eliminare eventuali problemi di usabilità che potresti aver trascurato.

Altri suggerimenti

Penso che i tuoi test di accettazione dovrebbero essere principalmente buoni test di percorso. A volte il "buono" path assicurerà che gli errori vengano gestiti correttamente. Dovresti avere altri test che convalidano la tua sicurezza ed esercitano i casi angolari, ma un test di accettazione riguarda più la sicurezza che sia stata creata l'applicazione corretta che la garanzia che tutte le possibili condizioni siano gestite correttamente. Se hai buoni test unitari e usi le migliori pratiche, allora penso che il buon test del percorso sia del tutto appropriato.

Ad esempio, non testerei necessariamente che non ho problemi con l'iniezione di SQL se avessi usato una tecnologia che applica query con parametri o in cui generi query manualmente (non), che l'unità i test confermano che l'iniezione non riesce. Affrontare i casi angolari nei test unitari rende meno importante concentrarsi su di essi nei test di accettazione. Se devi includere alcuni esempi per il cliente che l'implementazione del back-end risolve le loro preoccupazioni, allora fallo in ogni caso, ma non testerei le cose che so di aver affrontato adeguatamente tramite altri test.

A me sembra più un piano di test di funzionalità (ovvero test interni )

Il test di accettazione di solito si riferisce a ciò che mostri al cliente. Immagino che potresti fare un test del cliente in questo modo - buona fortuna però

Per i test di accettazione da parte degli utenti, preferisco un formato molto semplice (ovviamente, questo probabilmente non sarà appropriato dire per il software di space shuttle o bancario). Va bene per progetti web medio-piccoli

Il punto cruciale è; crea una tabella che elenca tutte le pagine del sistema, quindi crea una colonna per l'inizializzazione del client e un'altra per te stesso all'iniziale. Ti siedi con il cliente per alcune ore e attraversi tutto. Se sono soddisfatti di una pagina, si firmano su di essa

Per i dettagli completi del modello, vedere: Test di accettazione dell'utente

In un mondo perfetto, la descrizione del test sarebbe:

Conferma che tutti i test automatici vengono eseguiti correttamente fino al completamento

Ci sarebbe un test automatico per ogni percorso nel caso d'uso.

Qualsiasi forma di test manuale e con script sarà soggetto a errori e mancherà di bug, per non parlare del lavoro intensivo.

Cosa dice la tua specifica? Se copre tutte le cose delineate nella terza prova, perché come cliente non vorrei vedere che il prodotto è conforme all'intera specifica?

Se non si dispone di una serie esplicita di requisiti ( facepalm ), suddividere i test in moduli: Qualifica (con il cliente), Integrazione (i moduli di test degli sviluppatori lavorano insieme) e Sviluppo ( sviluppatori che testano i singoli moduli).

Automatizza DT e amp; E il più possibile (ad esempio, utilizza i test unitari per verificare l'iniezione di SQL, overflow della lunghezza della stringa, ecc.). Questo dovrebbe essere facile da fare perché il tuo backend dovrebbe essere separato dalla GUI che gli comunica (giusto?). La maggior parte delle cose della GUI che hai delineato nel terzo testcase possono essere coperte come parte del Test di integrazione (perché stai davvero testando l'integrazione tra il backend e la GUI).

Se il cliente può rivedere i test delle unità, le procedure e i risultati dei test di integrazione, i test di qualificazione possono essere abbastanza facili e indolori.

Dovrebbero testare i normali casi d'uso (non quello eccezionale). Ma se mettono alla prova quelli eccezionali, è molto bello!

I test di accettazione non possono essere troppo dettagliati. Più testano, più godono il prodotto finale.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow