Test manuale nella pipeline di distribuzione

Non riesco a darti una risposta in qualsiasi contesto di "chi è la colpa sarebbe se sorgessero problemi nella produzione", poiché esiste solo una best practice per minimizzare gli errori e sarebbe semplicemente un nuovo test di tutto ciò.

Le aree di test "probabilmente" interessate dalla correzione dei bug rappresentano un ragionevole compromesso, sebbene solo la persona che ha apportato la correzione del bug possa sapere quali aree sono interessate. È possibile associare i tag a ciascun test e quindi dire, testare tutto ciò che contiene i tag "dao" e "ordini". Ciò ti darebbe un po 'di flessibilità nel fatto che puoi dipartimentalizzare il tuo programma e quindi i tuoi test in modo da poter testare rapidamente e in modo abbastanza accurato queste aree interessate quando viene effettuata una correzione di bug. Potrebbe valere il tuo tempo per creare un documento tecnico per i tuoi colleghi sviluppatori per chiarire quali aree del programma corrispondono a quali tag.

Spero che ti aiuti!

Il primo passo dovrebbe essere quello di implementare un server CI, come Jenkins. Potrebbe esserci qualche lavoro sul lato dello sviluppo per migliorare questo: avere una buona strategia di ramificazione e indirizzare il proprio server CI nelle filiali appropriate, automatizzare il processo di costruzione, incorporare eventuali test automatici che si hanno nella pipeline CI.

Una delle cose che molti (se non tutti) server CI ti permettono di fare è avere un processo di promozione manuale. Con la configurazione e gli script appropriati, è possibile incorporare entrambi i passaggi automatizzati (test automatici, analisi statiche) e l'approvazione manuale. Se esegui regolarmente test automatici, puoi identificare tutte le build riuscite. Quindi, con l'autorizzazione appropriata, è possibile consentire a utenti specifici di utilizzare l'interfaccia Web per taggare e distribuire a vari livelli di integrazione e ambienti di test. Alla fine, puoi persino esportare build di produzione del tuo software da persone che promuovono build che superano ogni gate.

La cosa di cui non sono sicuro è l'utilizzo dello strumento per far rispettare i casi di test. Potrebbero esserci plugin appropriati, ma potrebbe trattarsi di un processo manuale. Se si utilizza uno strumento di gestione dei test, il proprio server CI può collegarsi e consentire la promozione solo se una specifica suite di test è stata contrassegnata come passata da persone in uno strumento. Non è necessariamente infallibile: le persone potrebbero segnare il passaggio senza eseguire effettivamente i test. Ma penso che tu abbia bisogno di fidarti della tua gente alla fine della giornata per fare la cosa giusta.

In generale, penso che la tua strategia di scegliere i casi di test da eseguire in base alle modifiche al codice sia la cosa giusta da fare. Tuttavia, prenderei in considerazione anche il tentativo di investire nel miglioramento di alcuni livelli di test automatici per cercare di trovare i problemi prima che vengano eseguiti test manuali, ma questo dovrebbe essere un investimento a lungo termine e potrebbe richiedere sia di formare nuove competenze o assumere persone con determinate abilità.

Vorrei provare a semplificarlo un po ', invece di creare un elenco di test da eseguire ...

Prova a creare una "linea di base" di test da eseguire dopo una build e una distribuzione. Questo può essere un misto di test manuali e automatizzati. Dovrebbe includere un "Smoke Test" di base per convalidare tutte le principali parti operative dell'applicazione. Esegui la linea di base e, se passa, esegui i test specifici sui difetti. Se quelli passano, il difetto può essere chiuso.

A un intervallo impostato, eseguire un test di regressione, forse 1x settimana, 1x mese, ecc. per rilevare eventuali problemi causati indirettamente da correzioni di errori. La regressione manuale è costosa, quindi non possiamo farlo ogni volta che viene eseguita una compilazione, ma è necessario per garantire che eventuali aggiornamenti non interrompano le funzionalità esistenti che a volte possono accadere.

Più test sono automatizzati, più velocemente è possibile convalidare le modifiche e più rapidamente è possibile rilevare eventuali fallout. Se tutto è automatizzato, è possibile apportare modifiche e convalidarle molto rapidamente senza un grande sforzo manuale, in modo che la velocità e l'agilità del software aumentino notevolmente.

La linea di base può essere modificata secondo necessità. I test di riferimento dovrebbero richiedere poco tempo per convalidare se corretto, come < 1 giorno, se fossero automatizzati forse solo pochi minuti al massimo. La linea di base dovrebbe includere le funzionalità principali ma non coprire tutto.