In uno sviluppo agile, chi dovrebbe scrivere casi di test? [chiuso]

https://stackoverflow.com/questions/194790

10-07-2019
|

Domanda

Il nostro team ha un sistema di attività in cui pubblichiamo piccole attività incrementali assegnate a ciascun sviluppatore.

Ogni attività viene sviluppata nel proprio ramo, quindi ogni ramo viene testato prima di essere unito al trunk.

La mia domanda è: una volta terminata l'attività, chi dovrebbe definire i casi di test che dovrebbero essere svolti su questa attività?

Idealmente penso che lo sviluppatore dell'attività stessa sia il più adatto per il lavoro, ma ho avuto molta resistenza da parte degli sviluppatori che pensano che sia una perdita di tempo o che semplicemente non gli piace farlo.

Il motivo per cui non mi piace che i miei addetti al QA lo facciano, è perché non mi piace l'idea che creino il proprio lavoro. Ad esempio, potrebbero tralasciare cose che sono semplicemente troppo lavoro da testare e potrebbero non conoscere i dettagli tecnici necessari.

Ma allo stesso modo, la parte negativa degli sviluppatori che eseguono i casi di test è che possono tralasciare cose che pensano possano rompersi. (anche inconsciamente forse)

Come responsabile del progetto, ho finito per scrivere i casi di test per ogni attività, ma il mio tempo è tassato e voglio cambiarlo.

Suggerimenti?

MODIFICA: per casi di test intendo la descrizione delle singole attività di controllo qualità che devono essere eseguite nella succursale prima che vengano unite al trunk. (Scatola nera)

Soluzione

Il team.

Se un difetto arriva a un cliente, è colpa del team , quindi il team dovrebbe essere scrivere test case per assicurare che i difetti non raggiungano il cliente.

Il Project Manager (PM) dovrebbe comprendere il dominio meglio di chiunque altro nel team. La loro conoscenza del dominio è vitale per avere casi di test che abbiano senso rispetto al dominio. Dovranno fornire input di esempio e rispondere a domande sulle aspettative su input non validi. Devono fornire almeno il caso di prova "percorso felice".
Gli sviluppatori conosceranno il codice. Suggerisci che lo sviluppatore potrebbe essere il migliore per l'attività, ma che stai cercando casi di test in scatola nera. Tutti i test che viene fornito da uno sviluppatore sono test in white box. Questo è il vantaggio di avere sviluppatori che creano casi di test: sanno dove sono le giunture nel codice.

Buoni sviluppatori arriveranno anche al PM con domande "Cosa dovrebbe succedere quando ...?" - ognuno di questi è un caso di prova. Se la risposta è complessa " Se a quindi x , ma se b quindi y , tranne il giovedì " - ci sono più casi di test.
I tester (QA) sanno come testare il software. È probabile che i tester presentino casi di test a cui il PM e gli sviluppatori non avrebbero pensato: ecco perché hai tester.

Altri suggerimenti

Penso che il Project Manager o il Business Analyst dovrebbero scrivere quei casi di test.
Dovrebbero quindi consegnarli alla persona di controllo qualità per perfezionare e testare.

In questo modo non si garantiscono spazi mancanti tra le specifiche e ciò che è effettivamente testato e consegnato.

Lo sviluppatore non dovrebbe assolutamente farlo, poiché testeranno i test unitari. Quindi è una perdita di tempo.

Inoltre, questi test troveranno errori che lo sviluppatore non troverà mai poiché sono probabilmente dovuti a un malinteso nelle specifiche, o una funzionalità o un percorso attraverso il codice che non è stato pensato e implementato correttamente.

Se scopri di non avere abbastanza tempo per questo, assumi qualcun altro o promuovi qualcuno in questo ruolo, poiché è la chiave per offrire un prodotto eccellente.

Abbiamo sperimentato un accoppiamento dello sviluppatore con un addetto al controllo qualità con risultati piuttosto buoni. In genere si "mantenevano reciprocamente onesti" e poiché lo sviluppatore aveva test unitari per gestire il codice, era già abbastanza intimo con le modifiche. La persona addetta al controllo qualità non lo era, ma è arrivata dal lato della scatola nera. Entrambi furono ritenuti responsabili della completezza. Parte del processo di revisione in corso ha aiutato a rilevare le carenze dei test unitari e quindi non c'erano troppi incidenti di cui ero a conoscenza di dove qualcuno stava volutamente evitando di scrivere X test perché probabilmente avrebbe dimostrato che c'era un problema.

Mi piace l'idea di accoppiamento in alcuni casi e penso che abbia funzionato abbastanza bene. Potrebbe non funzionare sempre, ma l'interazione di quei giocatori di diverse aree ha contribuito a evitare la mentalità "buttalo oltre il muro" che spesso accade.

In ogni caso, spero che ti sia utile in qualche modo.

Dall'esperienza passata, abbiamo avuto abbastanza fortuna nel definire test a diversi livelli per testare cose leggermente diverse:

1 ° livello: a livello di codice / classe, gli sviluppatori dovrebbero scrivere test di unità atomiche. Lo scopo è testare classi e metodi individuali il più possibile. Questi test dovrebbero essere eseguiti dagli sviluppatori mentre codificano, presumibilmente prima dell'archiviazione del codice nel controllo del codice sorgente e da un server a integrazione continua (automatizzato) se ne viene utilizzato uno.

2 ° livello: a livello di integrazione dei componenti, gli sviluppatori devono creare nuovamente unit test, ma testano l'integrazione tra i componenti. Lo scopo non è testare singole classi e componenti, ma testare il modo in cui interagiscono tra loro. Questi test dovrebbero essere eseguiti manualmente da un ingegnere dell'integrazione o automatizzati da un server di integrazione continua, se ne viene utilizzato uno

3 ° livello: a livello di applicazione, chiedi al team addetto al controllo qualità di eseguire i test di sistema. Questi casi di test dovrebbero basarsi sulle ipotesi aziendali o sui documenti relativi ai requisiti forniti da un product manager. Fondamentalmente, prova come se fossi un utente finale, facendo ciò che gli utenti finali dovrebbero essere in grado di fare, come documentato nei requisiti. Questi casi di test dovrebbero essere scritti dal team addetto al controllo qualità e dai responsabili del prodotto che (presumibilmente) sanno cosa vogliono i clienti e come devono utilizzare l'applicazione.

Ritengo che questo offra un livello di copertura abbastanza buono. Naturalmente, i livelli 1 e 2 sopra dovrebbero idealmente essere eseguiti prima di inviare un'applicazione costruita al team QA. Ovviamente, puoi adattarlo a qualsiasi modello di business, ma nel mio ultimo lavoro ha funzionato abbastanza bene. Il nostro server di integrazione continua darebbe un'e-mail al team di sviluppo se uno dei test unitari fallisse anche durante il processo di compilazione / integrazione, nel caso qualcuno dimenticasse di eseguire i test e impegnava il codice non funzionante nell'archivio sorgente.

" sviluppatori che pensano che sia una perdita di tempo o che semplicemente non gli piace farlo " Quindi ricompensali per questo. Quale ingegneria sociale è necessaria per farli creare casi di test?

Il QA può esaminare il codice e testare i casi e pronunciare "Non abbastanza copertura - Hai bisogno di più casi". In tal caso, il programmatore che ha "abbastanza" la copertura sarà subito il Big Kahuna.

Quindi, la mia domanda è: una volta terminato il compito, chi dovrebbe definire l'obiettivo di "abbastanza" casi di test per questa attività? Una volta che conosci "abbastanza", puoi rendere i programmatori responsabili della compilazione di "abbastanza". e QA responsabili di assicurare che "abbastanza" il test è terminato.

Troppo difficile da definire "abbastanza"? Interessante. Probabilmente questa è la causa principale del conflitto con i programmatori in primo luogo. Potrebbero pensare che sia una perdita di tempo perché hanno già fatto "abbastanza". e ora qualcuno sta dicendo che non è "abbastanza".

le persone addette al controllo qualità, insieme al "cliente", devono definire i casi di test per ogni attività [stiamo davvero mescolando la terminologia qui] e lo sviluppatore dovrebbe scriverli. prima!

Il motivo per cui non mi piace che i miei addetti al QA lo facciano, è perché non mi piace l'idea che creino il proprio lavoro. Ad esempio, potrebbero tralasciare cose che sono semplicemente troppo lavoro da testare e potrebbero non conoscere i dettagli tecnici necessari.

Sì, devi avere più fiducia nel tuo dipartimento di controllo qualità o in uno migliore. Voglio dire, immagina di aver detto che "non mi piace che i miei sviluppatori sviluppino software. Non mi piace l'idea che creino il proprio lavoro. & Quot;

Come sviluppatore, so che ci sono rischi nello scrivere i miei test. Questo non vuol dire che non lo faccio (lo faccio, specialmente se sto facendo TDD) ma non ho illusioni sulla copertura del test. Gli sviluppatori scriveranno test che dimostrano che il loro codice fa quello che pensano che faccia. Non troppi scriveranno test che si applicano al caso aziendale attuale.

Il test è un'abilità e, si spera, il tuo dipartimento di controllo qualità, o almeno, i leader di quel dipartimento, sono esperti di tale abilità.

Selezionare (non solo selezionare casualmente) uno o due tester e lasciare che scrivano i casi di test. Revisione. Potrebbe anche essere utile se uno sviluppatore che lavora con un'attività esamina i casi di test dell'attività. Incoraggia i tester a suggerire miglioramenti e aggiunte ai set di test - a volte le persone hanno paura di risolvere ciò che il capo ha fatto. In questo modo potresti trovare qualcuno che è bravo nella progettazione del test.

Informa i tester sui dettagli tecnici: penso che tutti i membri di un team agile dovrebbero avere accesso in lettura al codice e qualunque documentazione sia disponibile. La maggior parte dei tester che conosco sono in grado di leggere (e scrivere) il codice, quindi potrebbero trovare utili i test unitari, eventualmente anche estenderli. Assicurati che i progettisti del test ottengano risposte utili dagli sviluppatori, se hanno bisogno di sapere qualcosa.

Il mio suggerimento sarebbe di far esaminare qualcun altro ai casi di test prima che il codice venga unito per garantire la qualità. Concesso ciò può significare che uno sviluppatore sta trascurando il lavoro di un altro sviluppatore, ma quella seconda serie di occhi potrebbe catturare qualcosa che inizialmente non è stato catturato. I casi di test iniziali possono essere eseguiti da qualsiasi sviluppatore, analista o manager, non da un tester.

Il QA non dovrebbe scrivere i casi di test in quanto potrebbero essere situazioni in cui il risultato atteso non è stato definito e, a questo punto, potrebbe essere difficile avere un arbitro tra QA e sviluppo se ciascuna parte pensa che la sua interpretazione sia la il giusto. È qualcosa che ho visto molte volte e vorrei che non accadesse così spesso.

Analizzo liberamente i miei test in " sviluppatore " test e "cliente" test, quest'ultimo dei quali sarebbe "test di accettazione". I primi sono i test che gli sviluppatori scrivono per verificare che il loro codice funzioni correttamente. Successivamente sono test che qualcuno diverso dagli sviluppatori scrive per assicurarsi che il comportamento corrisponda alle specifiche. Gli sviluppatori devono non mai scrivere i test di accettazione perché la loro creazione del software che stanno testando presuppone che abbiano fatto la cosa giusta. Pertanto, i loro test di accettazione probabilmente affermeranno ciò che lo sviluppatore già sapeva essere vero.

I test di accettazione dovrebbero essere guidati dalle specifiche e se sono scritti dallo sviluppatore, saranno guidati dal codice e quindi dal comportamento corrente, non dal comportamento desiderato.

Il Canone Agile è che dovresti avere (almeno) due livelli di test: test degli sviluppatori e test dei clienti.

Test per sviluppatori sono scritti dalle stesse persone che scrivono il codice di produzione, preferibilmente usando sviluppo guidato dai test . Aiutano a creare un design ben disaccoppiato e assicurano che il codice stia facendo quello che gli sviluppatori pensano che stia facendo, anche dopo un refactoring.

Test dei clienti sono specificati dal cliente o dal proxy del cliente. Sono, infatti, le specifiche del sistema e dovrebbero essere scritte in modo da essere entrambi eseguibili (completamente automatizzate) e comprensibili dagli uomini d'affari. Abbastanza spesso, i team trovano il modo in cui il cliente può persino scriverli , con l'aiuto del personale addetto al controllo qualità. Questo dovrebbe accadere mentre - o anche prima - la funzionalità viene sviluppata.

Idealmente, le uniche attività che il QA deve svolgere appena prima dell'unione, è premere un pulsante per eseguire tutti i test automatizzati ed eseguire ulteriori test esplorativi (= non programmati). Ti consigliamo di eseguire nuovamente questi test dopo l'unione, per assicurarti che l'integrazione delle modifiche non abbia interrotto qualcosa.

Un test case inizia per primo nella trama.

Lo scopo del test è quello di guidare i difetti a sinistra (all'inizio del processo di sviluppo del software quando sono più economici e più veloci da riparare).

Ogni carta storia deve includere criteri di accettazione. Il Product Owner si accoppia con l'analista della soluzione per definire i criteri di accettazione per ciascuna storia. Questo criterio viene utilizzato per determinare se lo scopo di una trama è stato raggiunto.

I criteri di accettazione della trama determineranno quali test di unità automatizzati devono essere codificati dagli sviluppatori mentre eseguono Test Driven Development. Condurrà anche il test funzionale automatizzato implementato dai tester autoamted (e forse con il supporto degli sviluppatori se si utilizzano strumenti come FIT).

Altrettanto importante, i criteri di accettazione guideranno i test di prestazione automatizzati e possono essere utilizzati durante l'analisi del profilo dell'applicazione da parte degli sviluppatori.

Infine, il test di accettazione dell'utente sarà determinato in base ai criteri di accettazione nelle carte trama e dovrebbe essere progettato dal partner commerciale o dagli utenti. Segui questo processo e probabilmente rilascerai con zero difetti.

Raramente ho sentito parlare o visto Project Manager scrivere casi di test, tranne nei team più piccoli. In qualsiasi applicazione software complessa e di grandi dimensioni è necessario disporre di un analista che realmente conosca l'applicazione. Ho lavorato in una società ipotecaria come PM - dovevo capire i prestiti subprime, i tassi di interesse e così via? Forse a un livello superficiale, ma i veri esperti dovevano assicurarsi che quelle cose funzionassero. Il mio compito era quello di mantenere la squadra in salute, proteggere i principi agili e cercare nuove opportunità di lavoro per la mia squadra.

L'analista di sistema dovrebbe esaminare tutti i casi di test e la sua corretta relazione con i casi d'uso. Inoltre l'analista dovrebbe eseguire l'UAT finale, che potrebbe basarsi anche su casi di test. Quindi l'analista e il ragazzo di qualità stanno facendo una sorta di peer-review.

La qualità sta rivedendo i casi d'uso mentre sta costruendo casi di test e l'analista sta rivedendo i casi di test dopo che sono stati scritti e mentre esegue UAT.

Naturalmente BA è l'esperto di dominio, non dal punto di vista tecnico. BA comprende i requisiti e i casi di test devono essere mappati ai requisiti. Gli sviluppatori non dovrebbero essere le persone che scrivono i casi di test per verificare il loro codice. Il QA può scrivere passaggi di test dettagliati per requisito. Ma la persona che scrive il requisito dovrebbe dettare ciò che deve essere testato. Chi scrive effettivamente i casi di test, non mi interessa troppo finché i casi di test possono essere ricondotti ai requisiti. Penso che abbia senso che BA guidi la direzione o l'ambito dei test e che il QA scriva i piani di test granulari.

Dobbiamo evolvere dalla " ecco come è stata o dovrebbe essere fatta la mentalità " sta fallendo e fallendo continuamente. Il modo migliore per risolvere il problema del piano di test / scrittura dei casi è che i casi di test debbano essere scritti sul documento dei requisiti in cascata o sulla user story in modo agile mentre vengono scritti quei reqs / user story. In questo modo non ci sono dubbi su cosa debba essere testato e i team addetti al controllo qualità e UAT possono eseguire i casi di test e concentrare i tempi sui test effettivi e sulla risoluzione dei difetti.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow