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 ...