Stavo ascoltando questo podcast su Continuous Delivery e Jez Humble ha brevemente parlato del ruolo di QA, ma non ho avuto un'idea del "grande quadro" di quello che stanno facendo giorno per giorno. Come viene modificata la descrizione del loro lavoro quando un'azienda pratica la consegna continua?
Ci sono alcune cose che un ambiente CI non può controllare in modo efficace. O cose che sono proibitive da implementare in un processo di compilazione di elementi di configurazione.
Ad esempio, lavoro con sistemi embedded che funzionano su tutti i tipi di macchine fisiche. È incredibilmente difficile e francamente impossibile modellare virtualmente l'intera macchina fisica per tutte le possibilità.
Le combinazioni hardware specifiche causano solo problemi. Le connessioni fisiche tra diversi componenti possono causare problemi. La velocità di scrittura del disco su sistemi "virtuali" rispetto al sistema di distribuzione potrebbe cambiare, con conseguenti diversi errori.
CI può fare un ottimo lavoro testando singoli pezzi di un grande sistema per verificare che funzionino correttamente. Ma scrivere in alcuni casi un simulatore / emulatore completo "replichi perfettamente il tuo prodotto in un ambiente di test CI" non è possibile in alcuni casi.
Quindi un dipartimento QA può aggiungere molto valore in situazioni come questa.
Se è possibile sviluppare un sistema di CI per testare in modo completo e completo tutti i processi, è possibile trarre vantaggio dallo spostamento di tutti i test in CI e una minore necessità di controllo qualità. Ma in molte applicazioni questo non è affatto banale.
Idealmente, la responsabilità principale del team di QA è nel mantenere i test di accettazione pertinenti. Ciò significa che passano la maggior parte del loro tempo a inventare modi intelligenti per rompere l'applicazione, codificare quei casi e sfoltire periodicamente casi obsoleti o meno utili.
Oltre a ciò, ci sono cose che una suite automatizzata non può testare, che richiedono un QA esperto e / o un occhio editoriale e / o UX:
Oltre a ciò, può essere difficile codificare una singolare suite di test automatizzata per funzionalità che attraversano i limiti dell'applicazione o della piattaforma. Ad esempio, un test runner può essere progettato per automatizzare le interazioni con il browser, ma non con le applicazioni native. In tal caso, se le relative applicazioni native sono piuttosto snelle in termini di funzionalità, potrebbe essere più semplice far trascorrere una persona di QA per 10 o 20 minuti per garantire che l'integrazione funzioni ancora.
Leggi altre domande sui tag continuous-delivery qa