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

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

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

Non ha molto senso provare a testare formalmente nuove funzionalità mentre lo sviluppo continua, perché è probabile che le prossime 10 funzionalità tocchino la stessa funzionalità e richiedano di testarle nuovamente.

Possono continuare a testare in modo informale i rilasci interni intermedi durante lo sviluppo e ritagliare il design dei test (si spera che riescano a catturare la maggior parte degli errori in quelle nuove funzionalità), ma alla fine dello sviluppo avranno bisogno di un ulteriore periodo per test formali di nuovi caratteristiche e test di regressione.

Quando stimano 5 giorni richiesti per testare le 10 nuove funzionalità, ciò 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 di iterare se vengono trovati bug). Durante questo periodo la versione del cliente può essere sostituita per il test e lo sviluppo di nuove funzionalità può continuare per la prossima versione.

Usiamo un approccio ibrido. Per la versione del cliente, abbiamo sicuramente una sua filiale che è strettamente riservata solo a correzioni di errori critici.

Lo sviluppo regolare continua su più versioni del software. Ad esempio, diciamo che l'ultima versione della versione stabile è la 2.0. Tutte le funzionalità rischiose verranno aggiunte al ramo 3.0. Solo correzioni di bug vanno in 2.0 rami. I test eseguiti dal team di controllo qualità dedicato vengono eseguiti solo su filiali stabili. Le versioni dei clienti sono ovviamente realizzate da un'altra filiale basata su 2.0. Funzionalità a lungo termine come lo sviluppo della piattaforma next gen saranno fatte in 4.0 e persino in 3.0.

Tutto ciò 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 da essere rilasciato ai clienti. Ciò significa che il team del 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 funzionalità. Naturalmente, per una versione del cliente, viene eseguita la suite di regressione completa.

Questo dipende in realtà dall'abbinamento delle nuove funzionalità con le porzioni che richiedono correzioni di bug. Per esempio. se aggiungi nuove funzionalità di trascinamento e rilascio su 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) che i tester vogliano testare le correzioni "Ceteris paribus" (a parità di tutte le altre cose).

Potrebbero esserci altri problemi con le modalità di rilascio e le aspettative degli utenti finali. Per esempio. potrebbe essere necessario rilasciare solo dopo un'iterazione di correzioni di bug + test e altre nuove funzionalità + test perché gli utenti vogliono SOLO la reinstallazione o l'aggiornamento quando ci sono nuove funzionalità. Alcuni potrebbero richiedere correzioni come priorità assoluta al più presto.

Puoi risolvere questo problema (comune) unendo unire entrambi i team.

I tester all'interno del team di sviluppo, testati come funzionalità, possono aiutare la maggior parte dei team a migliorare la qualità dell'output.

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

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

Enjoy.

Il team di test ha sicuramente una preoccupazione valida, ma metterei in dubbio la necessità di più iterazioni di test per ogni release. Perché passare attraverso 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à, allora la loro richiesta è ragionevole, giustificata e dovresti fare i salti mortali per consegnarla.

Se questo è solo per aiutare nei loro "processi" durante le normali fasi di sviluppo, e assicurando che l'elenco degli errori non stia andando fuori controllo, senza averne un problema, chiedi al capo di test se questo vincolo può essere rilassato un po 'finché non ci avviciniamo al punto di rilascio.

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

"Puoi concordare se questo è un principio di test comune.

Yes

La preoccupazione del team di test è valida

Yes

L'hai incontrato in pratica nel tuo progetto. "

Yes

and Yes Merging is the downside of it 

Non hai chiesto chi è la responsabilità, ma è responsabilità del Gestore della configurazione. Questa strategia di streaming dovrebbe essere nel suo CMP. Altrimenti licenziatelo. Penso che la risposta di Pierre 303 sia anche molto buona, naturalmente dove possibile tecnicamente (ad esempio pensando a una versione di Siebel ...) e organizzativamente.

Il problema è che se testano i bug su un ramo hanno ancora bisogno di ripetere il test e la regressione li test sul tronco una volta che sono stati uniti (a meno che non si fida molto dei buoni tester). Questo non sta facendo più lavoro agli sviluppatori, sta facendo più lavoro ai tester.

Non c'è una risposta giusta qui, ma alcune cose che dovresti prendere in considerazione:

• Potrebbero mai arrivare a questi bug release (senza la nuova funzionalità)? Se è così allora sì, deve essere ramificato e testato e tutti devono accettarlo come un sovraccarico.

• È possibile dividere la nuova funzionalità in modo tale che esista in aree completamente separate dell'applicazione ai blocchi precedenti su cui sono state lavorate? Se è così, questo ti dà delle opzioni - i tester possono eseguire le ripetizioni dei bug e le parti del test di regressione dell'applicazione. Non è l'ideale, ma è un compromesso che potrebbe funzionare e dare loro qualcosa di quello che vogliono.

• Quanto lavoro è davvero necessario per dirigerli? Generalmente è un dolore, ma la quantità effettiva di lavoro normalmente non è così bella. Ovviamente avresti bisogno di loro per confermare che non è solo più lavoro per loro (vedi la primissima cosa che dico) ma ho visto che i luoghi fanno funzionare questo.

• C'è un modo migliore per usare il controllo della versione qui? Qualcosa come Mercurial (vedi link - leggerlo, è buono) o un altro sistema di controllo della versione distribuito si dirama e si fonde in un modo diverso e potrebbe 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, ricorda 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 solo di prendere qualcosa dallo scaffale e credi di dover aderire al 100%.

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

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

Se risolvi i bug prima, avrai una base più solida per ogni nuova funzionalità che aggiungi.

Certamente, ci sono momenti in cui forze esterne ti spingono ad andare contro il tuo giudizio migliore. Cerca di aiutare i responsabili decisionali a prendere una decisione informata in cui sono a conoscenza delle conseguenze di entrambe le azioni (ad esempio difetti non risolti rispetto alle date di consegna delle caratteristiche mancanti) e consentono loro di esercitare il proprio giudizio. A volte ci sono motivi legali e finanziari in cui è necessaria una linea d'azione, anche se non preferibile.

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

Dove lavoro gestiamo questo scenario in cui ogni versione prevista per la produzione ha il proprio 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 avrebbe ottenuto il proprio ramo e tutte le funzionalità sarebbero state aggiunte e inviate al QA. A questo punto inizieremo a lavorare sull'uscita di luglio e si dirameranno dalla filiale di giugno. Quando il QA trova i bug li aggiustiamo nel ramo di giugno e una volta che le correzioni sono state trasferite al QA, vengono unite nel ramo di rilascio di luglio. Ciò aggiunge un po 'di overhead per gestire queste fusioni, ma in genere le unioni sono abbastanza indolori. Di tanto in tanto è un grande dolore sapere cosa, ma ciò si verifica solo quando vengono apportate modifiche all'ingrosso e quelle non dovrebbero accadere durante il ciclo di QA (ma accadono, più di quanto mi piacerebbe ammettere). Ma con una buona serie di test (unità e integrazione), copertura del codice e tutte le altre parole d'ordine TDD, i rischi sono attenuati un po '. Per dare una mano, in genere abbiamo una sola persona che gestisce le unioni per ogni progetto.