Come fai QA e rilascia software velocemente con una squadra numerosa?

È necessario configurare una build continua e automatizzare i test, in modo che tutti i test delle unità e i test di integrazione vengano eseguiti continuamente (idealmente ad ogni revisione del repository se possibile). Se imposti questo tipo di automazione, è abbastanza facile dire che il programma passa di recente QA alla revisione XXX, e quindi non devi più eseguire un QA separato, devi solo sincronizzarti con quella versione e versione.

Ramping troppo veloce rende tutto più lento. Qualcuno della tua squadra ha letto "The Mythical Man Month" di Brooks? Ogni volta che una persona nuova viene a bordo, qualcuno deve trascorrere del tempo per aggiornarle. E ogni decisione richiede più tempo.

Potresti provare agile se i poteri consentiranno. Buona fortuna.

Se non hai test unitari ne hai bisogno. Impediranno un sacco di bug nel normale flusso del tuo programma. Devi anche avere una build giornaliera che è QA da qualcuno. Chi segnala i difetti in anticipo. Se si stanno risolvendo bug durante lo sviluppo, si ottengono risultati migliori, quindi si risolvono i bug alla fine dello sprint.

Sì, come altri test automatici e continui, i test automatici sono una buona cosa, leggi Il Mese di Mythical Man

Forse dovresti provare anche "un ramo per caratteristica e unirmi solo una volta che è stato testato" e dividere in piccoli gruppi.

Ma una cosa che dovresti fare è smettere di crescere finché non sei pronto per questo . Evento se il tuo capo dai capelli a punta pensa che uno scoiattolo cieco abbia maggiori probabilità di trovare un dado se ci sono molti ciechi scoiattoli . Se la situazione è complicata a 20 persone, una cosa è certa: aggiungere più persone non farà che peggiorare la situazione.

E ... quando sei pronto per farlo, cresci lentamente.

Ti suggerisco di riorganizzare:

Avere un Q & Un responsabile responsabile che ha bisogno di rivedere TUTTO il codice andando nel ramo di rilascio, e chi è l'unico che può fondersi in detto codice. Lo stesso ufficiale può rifiutare il codice se è bacato o non è conforme agli standard di codifica. Molto probabilmente questa persona non avrà tempo per la codifica.

Molto probabilmente apprezzerai anche avere un sistema di controllo del codice sorgente abbastanza potente da facilitare questa linea di lavoro, con più persone che lavorano in modo indipendente sullo stesso progetto. So che git can (perché è ciò che Linus usa per), e anche hg e bzr potrebbero esserlo.

Interrompi lo sviluppo ORA , ottieni un rilascio stabile combinato, avvialo questo flusso di lavoro e poi lentamente riprendi a velocizzare. Probabilmente hai troppa inerzia per essere in grado di farlo in volo.

Tu automatizzi i test. Ogni piccola parte. Il team addetto al controllo qualità dovrebbe scrivere test automatici, non scrivere ed eseguire procedure di test manuali. Idealmente dovrebbero scrivere i test prima che il codice sia avviato.

Il test manuale ripetitivo è semplicemente inaccettabile. I test costosi sono la causa principale di quasi tutti gli altri problemi che affliggono i progetti software.

L'ambiente di staging non dovrebbe mai essere bacato. È necessario ottenere un ambiente di costruzione relativamente continuo funzionante. Ho avuto un buon successo con le build orarie. Automaticamente, la creazione e il collaudo quotidiano dell'ambiente di staging dovrebbe aiutare. Automatizza i tuoi test e, se possibile, gli standard di codifica. Assicurati che gli sviluppatori vengano avvisati quando interrompono la compilazione.

La maggior parte dei sistemi di controllo di revisione può eseguire controlli pre-commit che possono fare cose come verificare che il codice segua gli standard. (La produzione rallenterà poiché gli sviluppatori potrebbero aver bisogno di portare i moduli su standard mentre lavorano su di essi.)

Assegna alcuni sviluppatori a rivedere le modifiche man mano che si verificano. Assegna la proprietà di revisione di vari moduli a particolari sviluppatori. (Non dovrebbero essere quelli che cambiano il codice che recensiscono).

Branch sul punto di rilascio. Ciò potrebbe richiedere un ambiente di staging separato se non si desidera che l'ambiente di staging rimbalzi avanti e indietro dallo sviluppo ai flussi di rilascio. Nel flusso di rilascio dovrebbero essere richieste modifiche minime. Tali modifiche dovranno essere replicate in modo appropriato nel flusso di sviluppo. Alcune modifiche possono essere unite, ma altre (soluzioni rapide) richiederanno una rilavorazione sul lato dello sviluppo.

Più persone nella tua squadra, più problemi dovrai affrontare - molte volte dall'enorme quantità di comunicazione necessaria. Quando la squadra era piccola, i piccoli errori che volavano sotto il radar non hanno influenzato tanto quanto quando si ha almeno il doppio del numero di persone - perché gli errori si combinano.

Sembra che tu abbia bisogno di concentrarti sul tuo team di QA per renderlo più agile e gestire la dimensione pura dell'applicazione.

• Concentrati maggiormente sui test automatici e istruisci il tuo personale addetto al controllo qualità a configurarlo. Tutti i criteri di accettazione critici dovrebbero avere un test automatico
• Chiedi al team addetto al controllo qualità di configurare e monitorare i server di integrazione continua
• Scopri dove vanno le cose.

Agile funziona al meglio con team piccoli e concentrati. Potrebbe essere necessario suddividere l'applicazione in sottosistemi e assegnare al team di dimensioni con il quale si è ottenuto il maggior successo con quel sottosistema. Ovviamente, questo significa che i test di integrazione sono ancora più importanti. Se hai una struttura QA su più livelli in cui i team di piccole dimensioni hanno almeno uno o due soggetti QA per assicurarsi che il sistema stia facendo ciò di cui ha bisogno - avrai bisogno di un altro gruppo QA che assicuri che tutto il sistema software nel suo insieme sia ancora facendo ciò di cui ha bisogno.

Attualmente lavoro con un team di sviluppo di ~ 30 persone che rilascia frequentemente una basebase molto ampia di notevole complessità, quindi alcune delle nostre esperienze potrebbero essere di interesse.

Quando è arrivato il momento di impostare il nostro approccio di test, inizialmente abbiamo diviso un team di 4 persone per impostare il "cablaggio", la struttura principale del codice che supporta l'automazione dei nostri test. Tutti i test sono scritti in Cetriolo , e le definizioni dei passi sono relativamente leggere, principalmente facendo un paio di chiamate nell'imbrago che fa il vero lavoro.

Una volta che l'imbracatura era al punto che il team era in grado di scrivere test, circa la metà dell'intero gruppo passava ai test di scrittura. L'esatto equilibrio dipende in anticipo dal livello di test necessario per il proprio progetto. Alcune cose che abbiamo imparato all'inizio:

1. Crea un paio di test e quindi esegui il loopback e armonizzali. Inizia a costruire uno standard in modo che i nuovi test corrispondano allo stile di ciò che è già in atto. Abbiamo finito per farlo più tardi e abbiamo dovuto tornare indietro e standardizzare ciò che era stato scritto finora.
2. File delle funzioni di revisione del codice. Cerca in modo aggressivo la duplicazione della definizione dei passi, quando le persone vanno a testa bassa scrivendo queste cose iniziano a mancare che qualcuno abbia già scritto esattamente la stessa cosa.
3. Assicurati di testare la cosa giusta. Ad esempio, se l'invio di un modulo deve eseguire X, assicurarsi che il test riguardi l'invio del modulo e non il clic su "Invia". La definizione del passo può fare clic sul pulsante, ma il file della funzione non deve essere modificato se il nome di un pulsante lo fa.
4. Se è probabile che un test cambi a causa di un cambiamento nell'implementazione senza un cambiamento di funzionalità, il test probabilmente andrà a rotoli. Questo vale principalmente per 3.

Siamo arrivati al punto che eseguire tutti i nostri test dall'inizio alla fine ha richiesto un tempo osceno. Se pensi di poter arrivare allo stesso punto, pensa presto all'automazione dell'impostazione dell'ambiente di test in modo da poter eseguire facilmente test su più macchine. Siamo in grado di distribuire l'intero sistema di produzione a un host pulito in meno di un minuto, il che ci consente di aumentare facilmente i test in burst.

Ogni volta che ci prepariamo a fare un rilascio, tagliamo una build e poi la eseguiamo attraverso questi test. Esaminiamo eventuali guasti e stabiliamo se devono essere corretti prima della consegna. Se lo fanno, correggi e ripeti. L'intero processo dalla prima generazione alla consegna di solito dura meno di una settimana.

Recentemente siamo arrivati al punto di integrare i nostri team Dev e QA. Ora, qualsiasi funzione che svilupperemo ha un file di funzionalità scritto prima di ogni altra cosa. Quindi sviluppiamo il codice per la funzione. E subito dopo viene eseguito il file delle caratteristiche. Questo diventa possibile solo quando hai abbastanza persone nella tua squadra che capiscono che la BDD / la tua imbracatura può aiutare il resto del team a produrre buoni test.