30 Novembre 2021
Expand search form

Come si scrive un buon test di accettazione?

Stiamo integrando un processo di test nel nostro processo SCRUM. Il mio nuovo ruolo è quello di scrivere test di accettazione delle nostre applicazioni web per automatizzarle in seguito. Ho letto molto su come i casi di test dovrebbero essere scritti, ma nessuno mi ha dato consigli pratici per scrivere casi di test per applicazioni web complesse, e invece hanno lanciato principi contrastanti che ho trovato difficili da applicare:

I casi di test dovrebbero essere brevi: Prendiamo l’esempio di un CMS. I casi di test brevi sono facili da mantenere e da identificare gli input e gli output. Ma cosa succede se voglio testare una lunga serie di operazioni (es. aggiungere un documento, inviare una notifica ad un altro utente, l’altro utente risponde, il documento cambia stato, l’utente riceve una notifica). Mi sembra piuttosto che i casi di test debbano rappresentare scenari completi. Ma posso capire come questo possa produrre documenti di test troppo complessi.

I test dovrebbero identificare input e output:: Cosa succede se ho un modulo lungo con molti campi che interagiscono, con diversi comportamenti. Scrivo un test per tutto o uno per ciascuno?

I casi di test dovrebbero essere indipendenti: Ma come posso applicarlo se il test dell’operazione di upload richiede che l’operazione di connessione abbia successo? E come si applica alla scrittura dei casi di test? Dovrei scrivere un test per ogni operazione, ma ogni test dichiara le sue dipendenze, o dovrei riscrivere l’intero scenario per ogni test?

I casi di test dovrebbero essere leggermente documentati: Questo principio è specifico dei progetti Agile. Quindi hai qualche consiglio su come implementare questo principio?

Anche se pensavo che scrivere casi di test di accettazione sarebbe stato semplice, mi sono trovato sopraffatto da ogni decisione che dovevo prendere (FYI: sono uno sviluppatore e non un tester professionista). Quindi la mia domanda principale è: quali passi o consigli avete per scrivere casi di test di accettazione mantenibili per applicazioni complesse. Grazie.

Modifica: Per chiarire la mia domanda: Sono consapevole che il test di accettazione dovrebbe partire dal requisito e considerare l’intera applicazione come una scatola nera. La mia domanda riguarda i passi pratici per scrivere il documento di test, identificare i casi di test, affrontare le dipendenze tra i test. per applicazioni web complesse

4 Risposte 4

Nelle mie suite di accettazione sono rimasto lontano dall’uso di controlli specifici della tecnologia, cioè per le applicazioni web non usare css non usare elementi html se hai bisogno di compilare un modulo fai le specifiche nei passaggi per impostare il SUT non i test di accettazione effettivi

Io uso cucumber per la mia accettazione e ho il seguente

Questo esempio è sostenuto da un’applicazione web, ma posso ancora utilizzare il test per testare contro un’applicazione desktop in quanto i passi sono utilizzati per impostare il SUT non i test di accettazione

questo test si trova alla fine di un acquisto che va

Generate -> Confirm -> Payment -> Print Receipt

il test di cui sopra è per il passo di pagamento gli altri passi sono impostati in altri test a causa dell’applicazione che è in grado di impostare in questi stati con dati o azioni http in questo caso il pagamento ha un dato che fa i passi di conferma e la conferma fa i passi di generazione quindi sono un po’ fragili al minuto

Per prima cosa è necessario definire Test di accettazione.

Quello che sembra descrivere è il test di integrazione o di sistema.

Quindi, anche se non sono d’accordo al 100% con le definizioni su wikipedia, sono ancora ampiamente valide.

Fondamentalmente lo scopo del test di accettazione è quello di verificare che i processi ‘business’ che fanno uso del pezzo di software che hai costruito funzionino effettivamente come previsto e siano adatti allo scopo – con dati reali. Quindi come tale non si costruiscono casi di test come si fanno i test unitari o il resto. Non si suppone che sia ingegnerizzato allo stesso modo.

La domanda da porsi è “come viene usato il sistema? Quindi testiamolo nel modo in cui dovrebbe essere usato. Naturalmente ora rimettete il vostro cappello da ingegnere e passate religiosamente in rassegna i requisiti di business per ricavare i vostri casi di test. Questo presuppone che tu abbia dei requisiti di business ben scritti.

Se non li hai, non è troppo tardi, devi sederti con gli utenti o i loro rappresentanti (e con l’analista di business e la persona che si occupa della progettazione tecnica) e scrivere cosa si aspettano che il software fornisca in termini di business (con l’ovvia avvertenza che questo è troppo poco e troppo tardi, ma è meglio iniziare tardi che mai – e naturalmente non introdurre nuove funzionalità). Questo è ciò che saranno i vostri casi di test.

Un altro modo di procedere (sempre se avete un tale documento) è quello di passare attraverso il manuale utente. Anche se questo è un passo rimosso dai reali requisiti di business, quindi da usare solo se tutto il resto fallisce.

Potresti anche essere interessato agli argomenti

Come si scrive un test di accettazione?

Piano di test di accettazioneDovrebbe essere dettagliato e specifico. … Dovrebbe essere chiaro e conciso. … Ogni componente del documento dovrebbe essere scritto tenendo a mente solo i requisiti di business.Affidabile e adattabile – Dovrebbe essere aggiornabile come richiesto nelle versioni future.Altri articoli…-Aug 26, 2021

Cosa rende un buon test di accettazione?

Per essere efficaci come specifiche dal vivo, i test di accettazione devono essere scritti in un modo che permetta agli altri di prenderli mesi o anche anni dopo e capire facilmente cosa fanno, perché sono lì e cosa descrivono.

Come si scrive un buon criterio di accettazione?

7 consigli su come scrivere buoni criteri di accettazioneDocumentare i criteri prima che inizi il processo di sviluppo. … Non fare criteri di accettazione troppo ristretti. … Mantenete i vostri criteri raggiungibili. … Evitare criteri di accettazione troppo ampi. … Evitare dettagli tecnici. … Raggiungere il consenso. … Scrivere criteri di accettazione testabili.31 agosto 2020

Come posso migliorare il mio test di accettazione?

Ora che abbiamo capito la portata e lo scopo del piano di test di accettazione dell’utente, rivolgiamo la nostra attenzione a ciò che dobbiamo fare per renderlo di successo.Iniziare a pianificare presto.Sfruttare l’UAT per migliorare la gestione del cambiamento.Strutturare i test e il monitoraggio.Automatizzare i test ripetitivi.Nov 28, 2016

Cos’è un rapporto di test di accettazione?

Per Acceptance Test Report si intende il rapporto del CLIENTE che stabilisce se i Deliverables in fase di test hanno soddisfatto o meno i criteri di accettazione.

Come si crea un documento UAT?

Processo UATSi prepara la lista dei processi di business da testare.Definire i criteri di accettazione.Selezionare il team di test.Preparare i dati di test. I dati di test dovrebbero coprire tutti gli scenari funzionali del software nell’uso reale.Preparare un piano di test UAT. Il piano di test UAT viene preparato per l’esecuzione del test.Feb 2, 2021

Qual è l’abilità meno richiesta di un tester?

Least required skill of Tester – Roles in Software Testing – Good…a. Good Programmer.b. Reliable.c. Attention to details.d. Being diplomatic.13 Aug 2015

Quali sono i requisiti di accettazione che un sistema dovrebbe soddisfare?

I criteri di accettazione (AC) sono le condizioni che un prodotto software deve soddisfare per essere accettato da un utente, un cliente o altri sistemi. Sono unici per ogni storia utente e definiscono il comportamento della caratteristica dalla prospettiva dell’utente finale.

Cosa sono le 3 C nelle storie utente?

Che tu sia un principiante o un veterano, le 3 C delle User Stories aiutano a mantenere lo scopo della user story in prospettiva.La prima C è la user story nella sua forma grezza, la Card. … La seconda C è la conversazione. … La terza C è la Conferma.Aug 11, 2017

Come si scrivono i criteri di accettazione di Gherkin?

Gherkin è un linguaggio specifico del dominio per scrivere criteri di accettazione che ha cinque dichiarazioni principali:Scenario – un’etichetta per il comportamento che si sta per descrivere.Dato – lo stato iniziale dello scenario.Quando – un’azione specifica che l’utente intraprende.Poi – un risultato testabile, di solito causato dall’azione in Quando.Altri elementi…-Nov 21, 2017

Come posso aumentare l’accettazione dell’utente?

Ottenere una maggiore accettazione da parte dell’utente nel processo di implementazione di un nuovo softwareSegnalare un piano di implementazione. … Organizzare sessioni di formazione degli amministratori. … Delineare tutti i casi d’uso del software all’interno della vostra azienda. … Configurare tutte le impostazioni. … Importare i dati. … Delineare un chiaro disegno del processo. … Costruire integrazioni con app di terze parti. … Impostare i diritti di accesso degli utenti.Altri articoli…

C’è l’UAT in agile?

Il test di accettazione dell’utente (UAT) è una parte del test di accettazione nello sviluppo agile. Ma il test di accettazione potrebbe anche includere test non-UAT come i tradizionali test funzionali o di sistema creati dal team.

Chi possiede l’UAT?

Per molti, l’UAT appartiene alle mani dei business analyst e dei corrispondenti business owner. Questi individui collaborano per creare i piani di test e i casi di test e poi determinano come implementare e tracciare i loro progressi, il tutto integrando le competenze degli esperti tecnici e di un team di garanzia della qualità.

Chi farà i test di accettazione?

Il test di accettazione dell’utente (UAT) è un tipo di test che viene fatto dal cliente prima di accettare il prodotto finale. Generalmente, l’UAT è fatto dal cliente (esperto di dominio) per la sua soddisfazione, e controllare se l’applicazione funziona secondo gli scenari di business dati, scenari in tempo reale.

Chi dovrebbe scrivere i casi di test UAT?

I casi di test dovrebbero essere scritti da membri del team di progetto che hanno una buona conoscenza delle funzionalità del sistema e dei processi di business del cliente. Quindi, a seconda della struttura del tuo team di progetto, questo potrebbe essere un Business Analyst o un Functional Lead (o anche uno sviluppatore su piccoli progetti, anche se questo è meno comune).

Articolo precedente

Qual è un esempio di segnalazione autocrina?

Articolo successivo

Quali parole puoi ricavare dall’invito?

You might be interested in …