Test di accettazione eseguiti per primi ... come può essere realizzato?

8

L'essenza della maggior parte dei metodi Agile è che una funzionalità non viene "completata" finché non è stata sviluppata, testata e in molti casi rilasciata. Questo dovrebbe accadere in brevi blocchi di tempo come "Sprint" nel processo Scrum.

Una parte comune di Agile è anche TDD, che afferma che i test vengono eseguiti per primi.

Il mio team lavora su un programma della GUI che fa un sacco di disegni specifici e così via. Per fornire test, il team di test deve essere in grado di lavorare con qualcosa che almeno cerchi di eseguire le cose che stanno cercando di testare. Non abbiamo trovato alcun modo per aggirare questo problema.

Posso vedere molto da dove vengono, perché se stavo cercando di scrivere software mirato ad un'interfaccia fondamentalmente misteriosa, avrei avuto un periodo molto difficile. Anche se abbiamo un comportamento abbastanza ben specificato, l'esatto processo di interazione con vari elementi dell'interfaccia utente quando si tratta di automazione sembra essere troppo unico per una funzionalità per consentire ai tester di scrivere script automatici per guidare qualcosa che non esiste. Anche se potessimo, un sacco di cose finiranno col presentarsi in seguito come mancanti dalle specifiche.

Una cosa che abbiamo preso in considerazione è che i tester scrivono "script" di test che sono più come una serie di passaggi che devono essere eseguiti, come descritto da una prospettiva caso d'uso, in modo che possano essere "automatizzati" da un essere. Questo può essere quindi eseguito dagli sviluppatori che scrivono la funzione e / o verificati da qualcun altro. Quando in seguito i tester ottengono un'opportunità, automatizzano principalmente lo "script" ai fini della regressione. Questo però non ha finito col prendere piede in squadra.

La parte di test del team è in realtà in ritardo rispetto a noi. Questo è uno dei motivi per cui il tempo apparentemente extra di sviluppare una "sceneggiatura" per un essere umano da eseguire non è mai accaduto ... sono sotto una crisi per stare al passo con noi sviluppatori. Se li avessimo aspettati, non avremmo fatto nulla. Non è colpa loro, sono un collo di bottiglia, ma stanno facendo quello che dovrebbero essere e lavorando il più velocemente possibile. Il processo stesso sembra essere impostato contro di loro.

Molto spesso finiamo per dover tornare indietro di un mese o più in quello che abbiamo fatto per correggere i bug che i tester hanno finalmente controllato. È una brutta verità su cui mi piacerebbe fare qualcosa.

Quindi cosa fanno gli altri team per risolvere questo fallimento a cascata? Come possiamo avere i tester davanti a noi e come possiamo farlo in modo che ci sia davvero il tempo per loro di scrivere test per le funzionalità che facciamo in uno sprint senza farci sedere e prendere le dita nel frattempo? Al momento, per ottenere una funzionalità "completata", utilizzando definizioni agili, gli sviluppatori dovrebbero lavorare per 1 settimana, quindi i tester lavorano la seconda settimana e gli sviluppatori sperano di riuscire a risolvere tutti i bug che hanno scoperto negli ultimi due giorni. Questo non succederà, anche se ho concordato che era una soluzione ragionevole. Ho bisogno di idee migliori ...

    
posta Crazy Eddie 20.06.2011 - 04:26
fonte

7 risposte

7

in primo luogo, sbarazzarsi della divisione tra "tester" e "sviluppatori". Tutti i test

secondo, in TDD, gli sviluppatori codificano i test prima codificano la funzione / storia

Quello che hai descritto non è TDD [potrebbe essere Scrum però; Scrum è una metodologia di gestione del progetto indipendente dalla metodologia di sviluppo; Scrum non è rilevante per il tuo problema]

Scenari in cui è impossibile eseguire test automatici sono rari eccessivamente . Gli scenari in cui i test automatici sono difficili, costosi o inopportuni sono molto più comuni, ma sono proprio questi gli scenari in cui è più necessario eseguire test automatici.

Dalla vaga descrizione, presumo che il software stia disegnando qualcosa sullo schermo. Se ciò che viene disegnato è determinato da dati, formule o passaggi funzionali, allora almeno scrivi test automatici che verifichino il livello dei dati / formule / fasi funzionali. Se l'output dello schermo è deterministico (gli stessi passaggi generano sempre lo stesso output di disegno), testare manualmente una volta, acquisire uno screenshot e lasciare che test futuri confrontino l'output con lo screenshot verificato. Se l'output dello schermo è non deterministico e non è governato da dati, formule o passaggi funzionali, allora ti troverai in quella zona rara in cui i test automatici potrebbero essere impossibili. Ma ne dubito.

Suppongo che l'unica ragione per cui i test non siano stati automatizzati finora è che gli sviluppatori non si preoccupano di questo . In TDD, gli sviluppatori eseguono i test, quindi sentono il dolore della noiosa ripetizione di testare lo stesso processo in 62 passaggi cento volte finché tutti i bug non sono spariti. Nulla otterrà una soluzione di test automatizzata sviluppata più velocemente di quanto non facciano gli sviluppatori a fare il test.

    
risposta data 20.06.2011 - 04:38
fonte
4

I miei team hanno scoperto che TDD non era adeguato per la progettazione dei test della GUI. Tutti i framework di test di livello GUI automatizzati abbiamo usato il codice richiesto per essere scritto prima del test. Così siamo passati a Sviluppo guidato dal comportamento . Certo, i test non sono automatizzati, ma ci hanno dato un modo per misurare se l'interfaccia utente è stata "completata" dall'inizio.

    
risposta data 20.06.2011 - 14:44
fonte
3

Troviamo ATDD per la GUI difficile / costoso.

Di solito facciamo prima il front-end. Dal momento che scriviamo webapps è solitamente in HTML / CSS / JS, e quindi otteniamo il sign-off su look, flow, ecc. Questi alla fine verranno tradotti in template con le parti appropriate sostituite con bit dinamici.

Una volta completato il mockup dell'interfaccia utente, scriviamo test che simulano una richiesta web. XPath è usato per affermare che i dati esistono nei tag HTML corretti.

Riteniamo che questo stile di test ci dia un buon valore per il tempo che trascorriamo. Continuiamo ad affermare che i dati vengono restituiti e una struttura generale riguardo l'html. Dal momento che abbiamo già elaborato il look in anticipo attraverso la fase di mockup, non ci preoccupiamo di provare ad affermare il posizionamento dei pixel. Diamo un'occhiata alla pagina mentre sviluppiamo sia come parte dello sviluppo sia come un doppio controllo.

Per gli sviluppatori non Web della GUI probabilmente proverei ad aggiungere alcuni hook per rendere il front-end scriptable. Probabilmente sarei anche in grado di simulare l'interfaccia utente, anche se sulla carta.

    
risposta data 20.06.2011 - 16:02
fonte
1
 > Acceptance tests done first…how can this be accomplished?

Preferisco uno stile di sviluppo bdd-tdd come descritto in questo articolo: Sviluppo basato sul comportamento con SpecFlow e WatiN .

L'esempio utilizza .net per lo sviluppo con SpecFlow + NUnit + WaitN. Se stai sviluppando con (j) ruby / java puoi provare cetriolo + junit + waitr

    
risposta data 20.06.2011 - 15:13
fonte
1

One thing we considered doing was having the testers write test "scripts" that are more like a set of steps that must be performed, as described from a use-case perspective, so that they can be "automated" by a human being. This can then be performed by the developer(s) writing the feature and/or verified by someone else. When the testers later get an opportunity they automate the "script" for regression purposes mainly. This didn't end up catching on in the team though.

Questo è più o meno ciò che facciamo. Ogni funzionalità è sviluppata in parallelo con il caso di test (script) e nessuna funzione viene "completata" finché non vengono eseguiti tutti e tre i passaggi: sviluppo, test case e test. Tutti i casi di test sono scritti dai requisiti dei tester e controllati con gli sviluppatori, quindi abbiamo tutti una comprensione comune del problema. Come il tuo suggerimento 'ogni due settimane', eccetto che quando gli sviluppatori stanno lavorando sulla funzione che i tester stanno lavorando su casi di test e quando i tester stanno testando, gli sviluppatori stanno studiando la funzione successiva.

Penso che il problema più grosso che hai sia

[t]he testing part of the team is actually falling behind us by quite a margin. [...] If we waited for them, we'd get nothing done

Dato che il team di test è così indietro che penso che dovresti aspettarli. Sono sicuro che ci sia qualcosa di produttivo che potresti fare, come sviluppare alcune funzionalità facili da testare ma che impiegano molto tempo per svilupparsi. Può anche aiutare a prendere in considerazione il tempo del test quando si pianifica uno sprint, né gli sviluppatori né i tester dovrebbero essere oberati di lavoro o inutilizzati.

    
risposta data 20.06.2011 - 16:44
fonte
1

Lo sviluppo basato su test di accettazione (distinto da, ma complementare allo sviluppo basato sui test) è un ottimo modo per assicurarsi di avere i requisiti inchiodati prima di iniziare la codifica.

Nel mio team noi (proprietario del prodotto, analisti e sviluppatori del controllo qualità) ci sediamo e usiamo FitNesse due test di accettazione della scrittura. Queste sessioni sono solitamente guidate dal QA ma tutti noi partecipiamo. Questi non verranno eseguiti immediatamente poiché sono necessari alcuni sforzi di sviluppo per aggiungere le fixtures (la colla tra le pagine wiki e il codice di produzione). Questi test costituiscono i criteri di accettazione per una storia . FitNesse è progettato per interagire con il livello sotto l'interfaccia utente.

Come sviluppatori lavoriamo quindi per far passare questi test di accettazione. Utilizziamo TDD per questo, ma TDD non deve essere confuso con ATDD.

Una volta che le pagine di FitNesse diventano verdi, siamo quasi che abbiamo ancora del lavoro da fare (test esplorativi, di solito guidati dal QA e così via).

    
risposta data 23.10.2011 - 12:56
fonte
0

Forse scrivere test dell'interfaccia utente codificati può aiutarti. Se stai lavorando con Visual Studio 2010, puoi utilizzare un componente aggiuntivo chiamato "test dell'interfaccia utente codificato" per la registrazione e la codifica di uno script molto specifico per l'interazione con l'interfaccia utente della tua app. La registrazione di un'interazione in uno script introduce un ulteriore livello di astrazione che ti protegge dalle piccole modifiche nell'interfaccia utente. Tuttavia, l'introduzione di questa forma di test introduce anche l'onere di mantenere i test.

    
risposta data 23.10.2011 - 12:29
fonte

Leggi altre domande sui tag