Codifica e test nello stesso sprint

Come viene gestito il test all'interno dello stesso sprint della codifica, se tutto o la maggior parte della codifica non viene eseguita fino alla fine dello sprint? (Mi riferisco allo sviluppo e alla sperimentazione "zuppa di noci" di un singolo PBI in uno sprint.)

La maggior parte delle risposte che ho visto online riguardano l'automazione del QA, ma anche questo non è davvero possibile poiché in genere è necessaria un'interfaccia utente funzionale per registrare o creare test automatici. Ho solo storyboard che continuano ad evolversi mentre sviluppo funzionalità e scopro nuovi requisiti.

Nel mio caso, sto sviluppando una nuova applicazione desktop. Le app desktop non si prestano molto bene ai test automatizzati. Ho alcuni test di unità automatizzati, ma non sono i test funzionali / di integrazione manuali che verrebbero eseguiti da un professionista del controllo qualità.

Quindi, dove sono ora è che il mio sprint termina domani, devo ancora scrivere il codice per finire, e i miei addetti al controllo qualità non hanno ancora nulla da testare, e non ho idea di come testare qualsiasi cosa darei senza di me tenendomi per mano.

Sono sicuro di non essere la prima persona ad avere questo dilemma.

In passato, ho realizzato una pipeline: nello sprint corrente il team di test verifica le funzionalità implementate durante lo sprint precedente. Nel mio attuale lavoro, il PM si riferisce a questo approccio come "cascata", e come tale inaccettabile.

Se non testate una User Story (US) e verificate che i criteri di accettazione siano soddisfatti, questa storia non viene eseguita. Se ciò non viene fatto, gli Stati Uniti vanno ovviamente al prossimo sprint. E se tutti gli Stati Uniti sono in questo stato, lo sprint è terminato senza alcun valore aggiunto al progetto. Dal punto di vista del cliente non riesco a distinguerlo dall'intero team di sviluppo che va in vacanza.

Uno dei principi magri (agile non si esaurisce con la mischia) afferma che "la qualità è integrata". Qualcosa viene fatto solo se soddisfa i criteri di qualità definiti. Questo è cruciale per avere un vero processo agile, terminare la primavera con valore zero o test separati dallo sviluppo sono sintomi di un grosso problema.

Ci sono molte cose che puoi fare:

• l'automazione è la chiave del successo. Almeno a livello di unit test e anche altre pratiche come la CI sono importanti. Questo non è abbastanza, ma se fatto bene questi tipi di test generano pochi o nessun bug scoperto nel test manuale (di solito cose minori dell'interfaccia utente). Se disponi di addetti al controllo qualità dedicati, questi possono essere quelli che automatizzano i test di accettazione e parte di questa automazione può iniziare prima di completare uno sprint.

• Guarda le dimensioni delle tue User Story. Se hai un USA che termina i due primi giorni dello sprint il terzo giorno, una persona di controllo qualità può testarlo. A mio avviso, avere piccoli utenti (SMART) nella cronologia rappresenta una delle cose più importanti per il successo nello sviluppo agile e molte persone sembrano non accorgersene.

• La collaborazione tra tester e sviluppatori è un'altra parte fondamentale del successo. Nel mio precedente progetto, quando uno degli Stati Uniti è finito da uno sviluppatore, un addetto al controllo qualità esegue "accoppia test" con lo sviluppatore (può essere manuale, può essere tramite il lancio di alcuni automatizzati o, meglio, entrambi), funziona abbastanza bene.

Il problema essenziale è che hai programmatori che codificano ma non testano e tester che testano ma non codificano.

Risolvi quel problema e non avrai questo problema, e una squadra probabilmente più efficiente.

Un modo che ha funzionato per me in passato è stato quello di suggerire a programmatori e tester di accoppiare storie con il compito esplicito di fornire una storia completamente testata. Insieme a questo ho cancellato tutte le forme di pensiero "sviluppo completo": nessuna colonna "sviluppo completo" sulla scheda scrum / kanban / trello, nessun atteggiamento "sviluppo fatto" dai programmatori.

Quello che è successo è stato:

• Le coppie erano responsabili della consegna delle storie e sarebbero entrambe fallite se una storia non fosse stata completata. Sono stati trattati come professionisti responsabili incaricati della consegna del software e, nella maggior parte dei casi, lo hanno fatto.

• Sono stati eseguiti molti meno test poiché i tester sono stati esposti ai test unitari e di integrazione, quindi non hanno ripetuto lo stesso test manualmente.

• Alcuni test sono stati automatizzati quando gli sviluppatori hanno capito meglio di cosa avevano bisogno i tester.

• Alcune persone si sono arrabbiate.

• Le storie sono state consegnate in media più velocemente perché il ciclo di test del codice di commit-pull è diventato quasi istantaneo

Certo, questa è solo la mia esperienza aneddotica, ma potresti provare tu stesso se puoi.

Nel tuo caso, dato il tuo commento secondo cui tester e sviluppatori sono autorevolmente separati nella tua azienda, il messaggio mi sembra chiaro. Esiste un evidente ostacolo alla comunicazione e alla collaborazione istituito dalle regole aziendali.

Questo è un problema di comunicazione , non un problema agile . L'adozione di una metodologia agile lo sta semplicemente rendendo evidente. I team silos sono un noto anti-schema gestionale , quindi abbracciano la non adattabilità dell'agile in questo caso!

Il ruolo effettivo del QA è vicino ai test di accettazione. Immagino che ciò venga fatto da un team separato, che agisce più come proprietario del prodotto piuttosto che come parte del team di sviluppo.

Esempio: durante uno sprint, è necessario aggiungere una funzione che consente di filtrare i risultati della ricerca in base a criteri diversi. Hai già implementato il tuo meccanismo di ricerca, ma i risultati sono ordinati alfabeticamente.

• Durante lo sprint:

  1. Il team elabora il design della nuova funzionalità e l'impatto sulla base di codice reale.

  2. Gli sviluppatori scrivono unit test che assicurano che l'ordinamento funzioni come previsto e allo stesso tempo scrive il codice effettivo.

  3. La nuova funzionalità è stata accuratamente testata per garantire che non rompa nulla (test di regressione) e che funzioni come previsto (test unitari).

  4. Se possibile e appropriato , il che non è il caso nella maggior parte dei progetti , un proprietario del prodotto (e quindi il tuo team addetto al controllo qualità) può costantemente valutare la nuova funzionalità per evitare che il team vada nella direzione sbagliata. Ciò richiede una continua integrazione con dozzine di build ogni giorno.

• Dopo lo sprint, il proprietario del prodotto valuta la nuova funzionalità per verificare che corrisponda alle esigenze del cliente. Il tuo team di QA è effettivamente qui, dopo che lo sprint è terminato.

Credo che i tuoi problemi reali siano i seguenti:

• Ambito di applicazione . Uno sprint riguarda il tuo team e solo il tuo team, non il tuo vero QA che agisce più come proprietario di un prodotto.

• Test . Il fatto che tu abbia un team di controllo qualità non significa che tutto ciò che devi fare è scrivere codice. Il lavoro del tuo team è quello di fornire una funzionalità che funzioni come previsto, non di gettare il codice per il test degli altri. Se fai affidamento sul team QA per eseguire i test per te, questo aumenterà il costo complessivo, poiché i bug verranno corretti una o due settimane dopo anziché essere risolti quasi istantaneamente.

se tutta o la maggior parte della codifica non viene eseguita fino alla fine dello sprint?

Perché non finisce prima? Questa limitazione chiave è la fonte dei tuoi problemi e ho visto che due approcci hanno successo. Uno si adatta bene all'approccio agile (ma non ad altre pratiche comuni) e l'altro è un po 'agile (ma è più comune).

Il primo è che non devi programmare fino alla fine dello sprint. In realtà la scrittura di codice è una parte relativamente piccola dello sviluppo. Se finisci circa a metà dello sprint, questo fornisce un sacco di tempo per il controllo qualità. Ti lascia anche un sacco di tempo per scrivere documentazione, ripulire il debito tecnico, progettare articoli arretrati ... Tutte le altre cose che devi fare per un prodotto di qualità. L'unico aspetto negativo di questo che ho visto è che è quasi impossibile ottenere rapidamente la funzionalità e i test unitari. Personalmente, penso che sia del tutto corretto fare test unitari dopo aver lasciato che il QA inizi a dare un'occhiata alla funzionalità, ma i sostenitori del TDD (e altri) non saranno d'accordo.

La seconda opzione è fare in modo che il QA gestisca uno sprint dietro lo staff di sviluppo come il tuo PM odia. Anch'io tendo a non gradire questo. Elimina il concetto di "prodotto rilasciabile" alla fine dello sprint, anche se hai un processo di escalation per le tue uscite. Peggio ancora, gli sviluppatori si concentreranno su "nuove" cose quando il QA arriva a loro con domande o bug dai test. È più improbabile che gli sviluppatori risolvano i bug in questa disposizione. Ma l'ho visto produrre software di qualità in tempo.

La Scrum Guide richiede che i team siano interfunzionali. Tutti i membri del team sono considerati sviluppatori, indipendentemente dalla loro specializzazione individuale. Gli individui silos (codificatore, tester, qa, ux, ecc.) Non sono utili in Scrum. I membri del team si aiutano a vicenda ovunque possano. Non esiste il concetto di "passare l'oggetto a qa".

Nella tua situazione, sembra che potresti avere un problema di stima. Quando si valutano gli articoli arretrati del prodotto, è necessario considerare tutte le attività, ad esempio: codifica, test, peer review, distribuzione, integrazione - qualunque sia la definizione delle richieste fatte.

Come regola generale, aspettati di portare tra 5 e 15 articoli arretrati del prodotto in uno sprint. Questo ti dà un'idea di quanto dovrebbe essere grande ogni articolo arretrato del prodotto. Ti dà anche un'eccellente possibilità di "lavorare" all'interno dello sprint.

Infine, il team ha il compito di spostare un elemento di arretrato del prodotto su 'fatto' e quindi passare a quello successivo. A volte, ciò significa che le persone stanno camminando sulle dita dei piedi e quindi ha senso girare più di un backlog di prodotto alla volta. La linea guida, tuttavia, dovrebbe essere quella di ridurre il work in progress (WIP) e spostare gli articoli arretrati del prodotto.

Test e codifica vanno di pari passo. Puoi programmarlo modulo per modulo. Una volta terminato il modulo, è possibile fornirlo ai tester. L'intero scenario dipende anche dalla fase di test a cui stai lavorando. Il modello SDLC a spirale ha un bell'aspetto. In questo, è conveniente test e codifica simultanei. Un altro approccio potrebbe essere modello V .

La mia risposta, che probabilmente all'inizio è piuttosto strana, sarebbe: non trovi il tempo di test perché pensi che i test debbano essere fatti sugli effetti collaterali del codice. E con effetto collaterale intendo il termine informatica :

si dice che una funzione (...) abbia un effetto collaterale se, oltre a restituire un valore, ha anche (...) un'interazione osservabile con (...) il mondo esterno.

Ho sollevato la citazione per enfatizzare la parte "interazione con il mondo esterno": vuoi che i test si verifichino sull'interfaccia utente così come sono stampati sullo schermo ("[per iniziare i test] non è davvero possibile poiché in genere hai bisogno di una funzionalità Interfaccia utente per registrare o creare test automatici da ").

Altre risposte ti hanno detto di automatizzare questo "test di accettazione", in modo che possa avvenire rapidamente. Questo è giusto, ma non risolve completamente il problema originale: cosa succede se non c'è abbastanza tempo per scrivere quei test di accettazione?

Devi lasciare andare la tua visione del test una volta che il codice ha interagito con il mondo esterno, cioè ha stampato qualcosa e si aspetta un input. Il problema con gli effetti collaterali è che sono, in effetti, non verificabili. Mi sono reso conto durante la lettura di un'intervista a Guido van Rossum, in cui ha affermato che una dichiarazione che spegne il computer può essere dimostrata funzionante solo eseguendola.

La soluzione a questa "non testabilità" è capire che, se hai dimostrato una volta che la dichiarazione funziona, puoi usarla ovunque e fare affidamento su di essa per fare il suo lavoro. Isolarlo in una funzione e testare tutto il resto .

Avvicinando l'esempio alla tua domanda, la funzione ora è probabilmente un'intera libreria o framework e, invece di spegnere il computer, stampa qualcosa: un'interfaccia utente. Mantieni le chiamate il più stupide e il più stabili possibile , perché una volta che entri in quella parte della tua applicazione, puoi testare solo attraverso costosi test di accettazione, cioè una sorta di osservazione esterna.

Considerare l'interfaccia utente come "territorio straniero" è in realtà un punto di vista corretto, dal momento che non è necessario testare la logica di una libreria che non è fornita da te, e forse sorprendentemente, è un punto di vista realistico: davvero ti aspetti di provare mai quella chiamata, ad es. MyWidget.draw()fa quello che ti aspetti, al livello di un singolo pixel?

Questo non significa che i test di accettazione non siano importanti o che possano essere saltati. È lì per rimanere e automatizzarlo, come suggeriscono altre risposte, ha enormi vantaggi. Ma se vuoi trovare il tempo per testare e codificare nello stesso sprint, cerca di mantenere il tuo codice il più libero possibile dagli effetti collaterali.