Scrivere casi di test di accettazione

Stiamo integrando un processo di test nel nostro processo SCRUM. Il mio nuovo ruolo è scrivere test di accettazione delle nostre applicazioni Web per automatizzarle in un secondo momento. Ho letto molto su come scrivere i casi di test, 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 difficile da applicare:

• I casi di test devono essere brevi: prendere l'esempio di un CMS. I casi di test brevi sono facili da mantenere e identificare gli ingressi e le uscite. E se volessi testare una lunga serie di operazioni (ad es. Aggiungere un documento, inviare una notifica a un altro utente, l'altro utente risponde, il documento cambia stato, l'utente riceve un avviso). Mi sembra piuttosto che i casi di test debbano rappresentare scenari completi. Ma posso vedere come questo produrrà documenti di prova apertamente complessi.

• I test dovrebbero identificare input e output:: Cosa succede se ho una forma lunga con molti campi interagenti, con comportamenti diversi. 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 esito positivo? E come si applica alla scrittura di casi di test? Devo scrivere un test per ogni operazione, ma ogni test dichiara le sue dipendenze o devo riscrivere l'intero scenario per ogni test?

• I casi di test devono essere leggermente documentati: questi principi sono specifici per i progetti Agile. Quindi hai qualche consiglio su come attuare questo principio?

Sebbene pensassi 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 professionale). Quindi la mia domanda principale è: quali passi o consigli hai per scrivere casi di test di accettazione sostenibili per applicazioni complesse. Grazie.

Modifica : per chiarire la mia domanda: sono consapevole che il test di accettazione dovrebbe iniziare dal requisito e considerare l'intera applicazione come una scatola nera. La mia domanda riguarda i passaggi pratici per scrivere il documento di prova, identificare i casi di prova, gestire le dipendenze tra i test ... per applicazioni Web complesse

Nelle mie suite di accettazione sono stato lontano dall'uso di controlli specifici per la tecnologia, ad esempio per le applicazioni Web non utilizzare CSS non usare elementi HTML se è necessario compilare un modulo, fare le specifiche nei passaggi per impostare il SUT, non i test di accettazione effettivi

Uso il cetriolo per la mia accettazione e ho i seguenti

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

questo esempio è tornato da un'applicazione Web, ma posso ancora utilizzare il test per eseguire il test con un'applicazione desktop poiché i passaggi vengono utilizzati per impostare il SUT e non i test di accettazione

questo test si trova alla fine di un acquisto che va

Genera -> Conferma -> Pagamento -> Stampa ricevuta

il test sopra è per la fase di pagamento, le altre fasi sono impostate in altre prove a causa dell'applicazione che è in grado di configurare in questi stati con azioni di dati o http in questo caso il pagamento ha un dato che conferma le fasi e la conferma fa il generare passaggi in modo che siano un po 'fragili al momento

Per prima cosa devi definire il test di accettazione .

Quello che sembra descrivere è l' integrazione o i test di sistema .

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

Fondamentalmente lo scopo dei test di accettazione è verificare che i processi "aziendali" che fanno uso del software creato funzionino effettivamente come previsto e siano idonei allo scopo, con dati reali. Quindi, in quanto tale, non costruisci casi di test come fai per i test unitari o per il resto. Non dovrebbe essere progettato allo stesso modo.

La domanda da porsi è "come viene utilizzato il sistema?". Quindi, testalo nel modo in cui dovrebbe essere usato. Ovviamente ora rimetti il ​​cappello di ingegneria e rispondi religiosamente ai requisiti aziendali per ricavare i casi di test. Ciò presuppone che tu abbia requisiti aziendali ben scritti.

In caso contrario, non è troppo tardi, è necessario sedersi con l'utente (i) o i loro rappresentanti (e l'analista aziendale e la persona di progettazione tecnica) e scrivere ciò che si aspettano che il software consegni in termini commerciali ( con l'evidente avvertimento che questo è troppo poco troppo tardi, ma è meglio iniziare in ritardo che mai - e ovviamente non introdurre nuove funzionalità). Ecco come saranno i casi di test.

Un altro modo di procedere (di nuovo se si dispone di un documento del genere) è quello di consultare il manuale dell'utente. Anche se questo è un passo rimosso dai reali requisiti aziendali, quindi può essere utilizzato solo se tutto il resto fallisce.

Quando vai a comprare un'auto, generalmente non vai molto in profondità sotto il cofano (a meno che tu non sia un meccanico di auto che è). Ti siedi semplicemente al volante e controlli comfort, usabilità, aspetto, suoni ... vale a dire le cose generali. Di solito ti fidi che se l'auto deve essere in mano in primo luogo (almeno per una nuova auto), è generalmente sicura e ben costruita (c'è una garanzia, hai fatto il tuo lavoro a casa e guardato le specifiche ...). Quindi ora controlli se questa è l'auto che vorrai guidare per i prossimi anni.

Lo stesso con il software.

Le informazioni in conflitto possono essere frustranti e difficili da generalizzare e applicare alla situazione specifica. Ergo, potresti dover fare ciò che funziona meglio nel tuo contesto.

Non sono un grande fan dei lunghi documenti di prova e ho usato la grafica in modo abbastanza efficace per alcuni progetti più piccoli. Prova questo? Come un diagramma di flusso (o qualsiasi altro diagramma UML come un diagramma di stato, ecc.) Invece di usare solo il testo? Indicare input, output, condizioni, loop, corsie, stati, interazioni con altri componenti ecc., Quindi indicare se hanno esito positivo, non sono riusciti, trasferiti, altri (?) In base ai criteri.

Potrebbe essere un po 'di lavoro all'inizio, ma può aiutarti a mantenerti sano nel lungo periodo. Qualunque metodo tu scelga, più ci lavori, meglio ci riuscirai.

HTH, e buona fortuna!

KM

Penso che tu abbia già definito alcuni buoni criteri. Il tuo secondo punto è un buon modo per definire gli ambiti per i tuoi test, e suggerisco anche di verificare condizioni di errore e correzioni (sostengo che ogni correzione di bug viene fornita con almeno un nuovo test unitario). Ora può sembrare travolgente, ma semplicemente immergersi e, dopo aver acquisito un po 'di esperienza, riconoscere ciò che rende buoni test diventerà più facile.