QA e rami di funzionalità nello sviluppo Web

1

Sto cercando di presentare al mio team un modello di branching più sofisticato di "commit to master and push".

Siamo una piccola squadra composta da due analisti, tre sviluppatori e un tester. Al momento, uno sviluppatore impegna le sue modifiche su master , quindi crea il ramo master sul nostro ambiente di test. Quindi notificano al tester che le modifiche sono disponibili per testare.

Il mio flusso di lavoro proposto è basato su questo , con GitHub che abilita la revisione del codice tramite pull- richieste sulla fusione di rami di caratteristiche. Ogni caratteristica o bug ha il proprio ramo creato, sul quale viene eseguito il lavoro. Quando lo sviluppatore ha finito, richiede un'unione e il suo codice viene esaminato e quindi unito al ramo dev .

La mia domanda è questa: a che punto del nuovo processo è opportuno chiedere al tester di testare la funzionalità? Per come la vedo io, le opzioni sono:

  • Il tester verifica la funzionalità dopo che il codice è stato esaminato e il ramo è stato unito in dev
    • Pro : la recensione si spera che abbia rilevato alcuni bug e abbia salvato il tester dal rifiuto del lavoro
    • Con - il team deve attendere fino a quando qualcuno esegue la revisione prima che il tester possa firmarlo
  • Oppure, il tester verifica la funzionalità prima che il codice sia stato revisionato
    • Pro : il tester è in grado di testare e firmare il lavoro prima che il codice venga esaminato
    • Con : se vengono suggerite modifiche, il tester dovrà riesaminare il codice modificato

C'è anche la domanda su come il tester sarebbe in grado di accedere al ramo della funzione prima che venga unito. Utilizziamo TeamCity come strumento di distribuzione e possiamo specificare il nome di un ramo da costruire, ma temo che non sia chiaro quale ramo di funzione è attualmente 'attivo' sul nostro server di prova.

Quindi in realtà questo si riduce a: quando il tester deve eseguire i test e se è prima che il ramo sia stato unito, come deve essere gestita la situazione?

    
posta AlexFoxGill 27.11.2014 - 18:30
fonte

3 risposte

4

Se credi davvero nelle revisioni del codice, la codifica non è terminata finché non si chiude il ciclo di revisione-revisione-ripetizione. Fino ad allora, il codice è in una sequenza di forme preliminari, non nella sua forma finale. Il tuo tester potrebbe testare una o più versioni preliminari del codice, ma i test dovrebbero essere ripetuti dall'inizio sul codice finale. Una buona pratica di test non consentirebbe certamente l'approvazione di un codice che doveva ancora essere rivisto.

    
risposta data 27.11.2014 - 19:34
fonte
2

Con altri 3 anni di esperienza nello sviluppo, risponderò al mio passato con il suggerimento che test e revisione del codice possono accadere contemporaneamente, in modo iterativo. Due cose aiuteranno:

  1. Test automatici. Il lavoro per scriverli deve avvenire solo una volta, a differenza del lavoro di un tester manuale che è richiesto su ogni iterazione. Proteggono anche dalle regressioni molto tempo dopo che ti sei allontanato dal codice (e forse dalla squadra / società). Sono anche molto più veloci da eseguire rispetto a un tester manuale, quindi il tuo ciclo di feedback diventa più stretto. Non limitarti a testare a un solo livello: i test di integrazione e i test di unità hanno entrambi un ruolo da svolgere.
  2. Analizza le modifiche nelle unità più piccole possibili. Meno cambi significano meno possibilità di rompere le funzionalità e una più rapida revisione del codice (normalmente con commenti di recensioni di qualità superiore come bonus). Se hai bisogno di refactoring prima di scrivere il codice, scrivilo come una richiesta di modifica separata e falla firmare prima di aggiungere la nuova funzione: puoi farlo mentre l'attività di refactoring è in corso di revisione. L'asincronicità è la chiave della produttività quando ci sono diverse persone / ruoli coinvolti nell'ottenere una funzionalità in produzione.
risposta data 06.04.2018 - 13:02
fonte
1

At what point during the new process is it appropriate to ask the tester to test the functionality?

Il tester dovrebbe iniziare il processo di test il primo giorno, nello stesso ramo dello sviluppatore. C'è molto lavoro da fare. Possono lavorare con gli sviluppatori per assicurarsi che il codice sia facile da testare (ad es. Aggiungere id a elementi web, ecc.). Possono iniziare a creare i dati di test necessari per testare il software. Possono iniziare a scrivere piani di test e test di accettazione automatici, in modo che quando il codice è pronto per il test, i test siano già pronti e in attesa.

I test devono essere eseguiti prima della revisione finale, poiché non c'è molto motivo di rivedere il codice se non funziona. I test devono essere eseguiti dopo la revisione per verificare che le modifiche apportate alla revisione siano state testate correttamente.

In breve, il test dovrebbe essere un processo continuo, non solo qualcosa che viene attaccato alla fine.

    
risposta data 03.04.2018 - 14:19
fonte

Leggi altre domande sui tag