È corretto correggere i bug senza aggiungere nuove funzionalità quando si rilascia il software per i test di sistema?

Questa domanda è per tester esperti o puntali. Questo è uno scenario di un progetto software:

Supponiamo che il team di sviluppo abbia completato la prima iterazione di 10 funzionalità e l'abbia rilasciata ai test di sistema. Il team di test ha creato casi di test per queste 10 funzioni e ha stimato 5 giorni per i test. Il team di sviluppo ovviamente non può rimanere inattivo per 5 giorni e iniziano a creare 10 nuove funzionalità per la prossima iterazione. Durante questo periodo il team di test ha riscontrato difetti e ha sollevato alcuni bug. I bug hanno la priorità e alcuni di essi devono essere corretti prima della prossima iterazione. Il problema è che non accetterebbero la nuova versione con nuove funzionalità o modifiche alle funzionalità esistenti fino a quando tutti questi bug non fossero stati corretti. Il team di test afferma che è così che possiamo garantire una versione stabile per i test se introduciamo anche nuove funzionalità insieme alla correzione dei bug. Inoltre, non possono eseguire test di regressione di tutti i loro casi di test per ogni iterazione.

Ciò significa che il team di sviluppo deve creare un ramo di codice esclusivamente per la correzione di bug e un altro ramo in cui continuano lo sviluppo. Vi è un maggior sovraccarico di fusione specialmente con refactoring e modifiche architettoniche.

Sei d'accordo se questo è un principio di test comune. La preoccupazione del team di test è valida? Hai riscontrato questo in pratica nel tuo progetto.

Direi invece che ogni versione di nuove funzionalità dovrebbe essere su un ramo separato. Ciò consente di disaccoppiare sviluppo e versioni.

Come funziona la tua versione per gli utenti finali in questo processo? Il team di test del sistema dovrebbe essere meno interessato al programma di sviluppo e concentrarsi invece sul programma di rilascio del cliente.

È inutile tentare di testare formalmente nuove funzionalità mentre lo sviluppo continua, perché è probabile che le prossime 10 funzionalità tocchino le stesse funzionalità e richiedano loro di testarle nuovamente.

Possono continuare a testare in modo informale rilasci interni provvisori durante lo sviluppo e perfezionare il loro progetto di test (sperando di catturare la maggior parte dei bug in quelle nuove funzionalità), ma avranno bisogno di un periodo aggiuntivo alla fine dello sviluppo per test formali di nuove funzionalità e regressione test.

Quando stimano i 5 giorni richiesti per testare le tue 10 nuove funzionalità, quello che dovrebbero considerare è che hanno bisogno di 5 giorni alla fine del ciclo di sviluppo, prima del rilascio ai clienti, per convalidare le nuove funzionalità (e probabilmente più tempo per iterare se vengono trovati dei bug). Durante questo periodo, la versione del cliente può essere ramificata per i test e lo sviluppo di nuove funzionalità può continuare per la versione successiva.

Usiamo un approccio ibrido. Per il rilascio dei clienti, abbiamo sicuramente una propria filiale che è strettamente riservata alle correzioni di bug critici.

Lo sviluppo regolare continua su più versioni del software. Ad esempio, supponiamo che l'ultima versione stabile sia la 2.0. Tutte le funzionalità rischiose verranno aggiunte al ramo 3.0. Solo le correzioni di bug vanno nei rami 2.0. I test da parte di un team addetto al controllo qualità vengono eseguiti solo su filiali stabili. Le versioni dei clienti sono ovviamente fatte da un'altra filiale basata su 2.0. Funzionalità di lunga durata come lo sviluppo della piattaforma di prossima generazione verranno eseguite in 4.0 e nemmeno in 3.0.

Tutto questo sembra buono sulla carta. Ma se un cliente desidera una funzionalità specifica, deve essere aggiunto al ramo 2.0 stesso poiché 3.0 non è abbastanza stabile per essere rilasciato ai clienti. Ciò significa che il team addetto al QA dovrà rieseguire l'intera suite di regressione.

Una cosa che facciamo è fare la copertura del codice di ogni caso di test di regressione. Vengono eseguiti solo i casi di test di regressione che saranno interessati dalle modifiche al codice per la funzione. Naturalmente, per un rilascio del cliente, viene eseguita la suite di regressione completa.

Dipende molto da quanto strettamente sono accoppiate le nuove funzionalità con le parti che richiedono correzioni di bug. Ad esempio, se si aggiunge una nuova funzionalità di trascinamento della selezione a una piccola porzione dell'interfaccia utente, "non dovrebbe" influire sul bug correlato all'analisi del file caricato dall'utente.

Detto questo, è comprensibile (non necessariamente giustificato) per i tester voler testare le correzioni "Ceteris paribus" (tutte le "altre" cose sono uguali).

Potrebbero esserci altre preoccupazioni riguardo alle modalità di rilascio e alle aspettative degli utenti finali. Ad esempio, potrebbe essere necessario rilasciare solo dopo un'iterazione di correzioni di bug + test e un'altra nuova funzionalità + test perché gli utenti desiderano SOLO reinstallare o aggiornare quando sono disponibili nuove funzionalità. Alcuni potrebbero richiedere correzioni al più presto possibile.

Puoi risolvere questo problema (comune) unendo le due squadre.

I tester all'interno del team di sviluppo, testando le funzionalità prodotte, possono aiutare la maggior parte dei team ad aumentare la qualità dell'output.

Ti consiglio di leggere questo eccellente post sul blog di Henrik Kniberg che spiega Kaban . Troverai molte idee nel processo Scrum (un libro gratuito anche di Henrik Kniberg ).

Ha anche scritto un eccellente articolo Kanban VS Scrum sul suo blog.

Godere.

Il team di test ha sicuramente una preoccupazione valida, ma metterei in dubbio la necessità di più iterazioni di test per ogni versione. Perché passare un intero ciclo di test su una versione di codice che gli utenti non vedranno mai?

Se i tester stanno tentando di ottenere un rilascio definito per un cliente, che non si aspetta le nuove funzionalità, la loro richiesta è ragionevole, giustificata e dovresti piegarti all'indietro per consegnarla.

Se questo serve solo per aiutare nei loro "processi" durante le normali fasi di sviluppo, e assicurando che l'elenco dei bug non stia esaurendo il controllo, senza crearne un problema, chiedi al responsabile del test se questa limitazione può essere rilassata un po 'fino a quando ci avviciniamo al punto di rilascio.

Valuta di cambiare il tuo sistema di controllo del codice sorgente in un prodotto distribuito. Ciò renderà molto più facile consegnare tale rilascio.

"Sei d'accordo se questo è un principio di test comune.

Yes

La preoccupazione del team di test è valida?

Yes

Hai riscontrato questo in pratica nel tuo progetto ".

Yes

:

and Yes Merging is the downside of it 

Non hai chiesto chi è la responsabilità ma è la responsabilità del Configuration Manager. Questa strategia di flusso dovrebbe essere nel suo CMP. Altrimenti licenziatelo. Penso che anche la risposta di Pierre 303 sia molto buona, ma ovviamente dove possibile tecnicamente (es. Pensando a una versione di Siebel ...) e organizzativa.

Il problema è che se testano i bug su un ramo devono ancora ripetere il test e la regressione li testano sul trunk una volta che sono stati riuniti nuovamente (a meno che non si fidino molto di quelli che raramente sono bravi tester). Questo non sta solo facendo più lavoro per gli sviluppatori, ma sta facendo più lavoro per i tester.

Non c'è una risposta giusta qui, ma alcune cose che dovresti considerare:

• Queste versioni di bug (senza la nuova funzionalità) potrebbero mai andare agli utenti? In tal caso, sì, deve essere ramificato e testato e tutti devono accettarlo come un overhead.

• È possibile dividere la nuova funzionalità in modo tale che esista in aree completamente separate dell'applicazione con i blocchi precedenti su cui si è lavorato? In tal caso, ciò offre opzioni: i tester possono eseguire i test degli errori e le parti del test di regressione dell'applicazione. Non è l'ideale ma è un compromesso che potrebbe funzionare e dare loro quello che vogliono.

• Quanto lavoro è davvero per dirottare loro una versione? Generalmente è un dolore, ma la quantità effettiva di lavoro non è normalmente così grande. Ovviamente avresti bisogno di loro per confermare che non è solo più lavoro anche per loro (vedi la prima cosa che dico) ma ho visto posti che fanno funzionare questo.

• Esiste un modo migliore per utilizzare il controllo versione qui? Qualcosa come Mercurial (vedi http://hginit.com/ - leggilo, va bene) o un altro sistema di controllo della versione distribuita si dirama e si fonde in un modo diverso e può consentire di aggirare il problema. Davvero, dai un'occhiata perché penso che potrebbe essere la risposta al tuo problema.

Ma buona fortuna, è un dolore. Soprattutto ricordati che il modo migliore per andare avanti dipenderà molto dalla tua azienda, dal tuo prodotto e dalla tua situazione, quindi assicurati di pensarci e non limitarti a ritirare qualcosa dallo scaffale e credere che devi aderire al 100%.

Se i bug che descrivi sono difetti reali e non ottimizzazioni di progettazione , allora sì, dovresti davvero provare a risolverli prima di iniziare a lavorare su nuove funzionalità.

Se costruisci nuove funzionalità in cima a bug noti, stai creando un castello di carte. Probabilmente potresti sviluppare software fragile e imprevedibile. A seconda del livello di isolamento tra il codice errato e le nuove funzionalità, anche i bug potrebbero influire sulle nuove funzionalità. In tal caso, come faresti a sapere se le tue nuove funzionalità funzionano correttamente?

Se correggi prima i tuoi bug, avrai una base più solida per tutte le nuove funzionalità che aggiungi.

Certamente, ci sono momenti in cui forze esterne ti spingono ad andare contro il tuo miglior giudizio. Cerca di aiutare i responsabili delle decisioni a prendere una decisione informata laddove siano a conoscenza delle conseguenze di entrambe le linee di azione (ovvero i difetti irrisolti rispetto alle date di consegna mancanti) e consenti loro di esercitare il loro giudizio. A volte ci sono ragioni legali e finanziarie in cui è necessario un corso d'azione, sebbene non preferibile.

Cerca sempre di correggere i bug prima di aggiungere nuove funzionalità!

Dove lavoro, gestiamo questo scenario in cui ogni versione prevista della produzione ha il suo ramo. Ad esempio, supponiamo per un secondo che ci sarà un rilascio alla fine di giugno e un altro alla fine di luglio. La versione di giugno otterrebbe il suo ramo e tutte le funzionalità sarebbero state aggiunte lì e inviate al QA. A questo punto inizieremmo a lavorare sull'uscita di luglio e alla filiale di giugno. Quando il QA rileva dei bug, li risolviamo nel ramo di giugno e una volta che i fix sono stati trasferiti al QA, vengono uniti nel ramo di rilascio di luglio. Questo aggiunge un po 'di sovraccarico per gestire queste fusioni, ma in genere le fusioni sono abbastanza indolori. Di tanto in tanto è molto doloroso sapere cosa succede, ma ciò si verifica solo quando vengono apportate modifiche all'ingrosso e queste non dovrebbero accadere durante il ciclo di QA (ma accadono più di quello che mi piace ammettere). Ma con una buona suite di test (unità e integrazione), la copertura del codice e tutte le altre parole d'ordine TDD, i rischi sono mitigati un po '. Per dare una mano, in genere abbiamo una persona che gestisce le fusioni per ciascun progetto.