il team addetto al controllo qualità dovrebbe idealmente eseguire i test su un ambiente che corrisponda esattamente al prod env (per ridurre al minimo i bug non rilevati che sorgono a causa dell'impostazione delle differenze).
Se ciò è vero, il team di QA tipicamente esegue nuovamente i test su prod post deployment nei googles e nelle amazzoni là fuori? Se la risposta è sì, sembra ridondante .. ma anche come possono non testare la produzione?
Dipende da cosa stai facendo, ma spesso non puoi testare in produzione perché il sistema è ora collegato a risorse reali. Nel caso di Amazon, faresti un ordine reale con una vera carta di credito e aspetteresti che arrivi il libro? Spesso devi fare attenzione a inserire i dati di test in un sistema di produzione.
Una volta che è andato in diretta, sei dipendente dai tuoi sistemi di monitoraggio per darti degli avvertimenti precoci sui bachi. Calo improvviso degli ordini completati? Meglio ripristinare l'aggiornamento, quindi andare a scavare nei log per scoprire cosa è successo.
(Probabilmente quello che SpaceX ha fatto è "testare in produzione" con il loro sistema di recupero missilistico: non è realmente possibile effettuare lanci fittizi, quindi si lanciano con il vero carico utile e poi vedono se il sistema riesce a far atterrare il razzo.)
Non esegui il test in produzione perché non troverai nulla che non trovi in un ambiente di prova adeguato. Forse una sorta di controllo rapido se la distribuzione è andata bene, ma questa non è una parte importante del testing.
Per prima cosa testate il vostro codice (unit test). Quindi testerai il tuo codice nell'intera applicazione (test di integrazione). Quindi testerai il tuo codice nell'intero panorama del sistema (test di sistema).
Tutti gli altri test sono fatti da persone che non guadagnano nulla dal trovare o segnalare bug, che - quando ci pensi - fa schifo per la qualità del prodotto.
"Testare" non è una cosa sola e non è qualcosa che viene fatto solo una volta. Dal requisito alla distribuzione, il codice dovrebbe passare attraverso molti livelli di test:
Il tutto forma il controllo qualità (QC) attorno a un pezzo di codice. Sostenendo che "il test deve essere eseguito una o due volte", manca la misura in cui il codice viene effettivamente testato (in un buon ambiente).
Oh, per favore non chiamarlo "QA". Il test del software non può mai coprire il 100% di tutte le possibili combinazioni di interazione utente / dati e flusso del programma. Quindi non è possibile offrire garanzie che il codice sia adatto allo scopo. Tutto quello che puoi fare è controllare la qualità attraverso "test di esempio".
Sì, il test dovrebbe essere eseguito due volte negli ambienti di staging e produzione.
Il fattore più importante nel test di staging è assicurarci che le nuove funzionalità funzionino come previsto e che le funzionalità esistenti non siano interrotte. Questo test dovrebbe idealmente essere accurato a livello di unità e di funzionalità e di solito richiede un po 'di tempo per essere eseguito.
Il più grande fattore nel test di produzione è assicurarsi che le funzionalità esistenti non vengano interrotte utilizzando le macchine, le reti, le configurazioni, ecc. che stanno servendo il software. Questi sono spesso test rapidi di "sanità" o "fumo" che possono essere eseguiti molto rapidamente e assicurano che il percorso "felice" funzioni ancora correttamente.
Ho anche imparato che i test negli ambienti di produzione o di produzione sono spesso troppo tardi per aggiungere qualità negli ambienti di oggi, per lo più agili. A quel punto il codice è stato scritto ed è meno malleabile ai cambiamenti (confessione: sono un ex sviluppatore). È meglio concentrarsi sui piani di test e sulla progettazione prima che venga scritto qualsiasi codice e quindi concentrarsi sul codice di test prima che il codice dell'applicazione sia scritto in modo che i test possano guidare il codice in modo TDD / BDD con test eseguiti in ambienti e ci .
Idealmente Sì, il controllo qualità dovrebbe testare il sistema live. Altrimenti, testerai ancora il sistema live, ma i tuoi clienti lo faranno invece.
La vera domanda è come ottenere ciò quando si hanno applicazioni stateful. vale a dire. come posso testare il mio pulsante DeleteAllOrders (esempio estremo), senza effettivamente cancellare tutti gli ordini?
Normalmente questo si ottiene avendo un ambiente di test, ma come avete notato questo è difettoso. Non c'è alcuna garanzia che qualcosa che funziona nel test funzionerà in diretta. Inoltre, inevitabilmente ti ritroverai con dozzine di ambienti di test per tutte le diverse funzioni o team e diventa molto difficile testare se tutto funzionerà bene il giorno.
Un secondo approccio è quello di avere un sottoinsieme di test che si eseguono in diretta, i "smoke test" che consentono di testare le cose facili. "Metti un ordine di prova, ma cancellalo prima che ci venga addebitato", ecc. Ma, ancora una volta, non è perfetto.
Per testare completamente il tuo sistema live, devi programmare il tuo sistema tenendo a mente la testabilità.
Se crei un pulsante Elimina Tutti , devi pensare 'ok come posso testarlo?' forse dovrei aggiungere anche un pulsante UndeleteAllTheOrdersIjustDeleted!
Se alcune funzioni di un sistema vengono eseguite raramente, o difficili da testare, ciò non equivale a che la funzione non sia importante.
La pratica migliore è quella di testare il tuo sistema live tutto il tempo. Se si sviluppa un problema, lo vuoi sapere subito.
Ad esempio, se si dispone di un sito eCommerce, si effettuano costantemente ordini fittizi per assicurarsi che il sito sia attivo e che venda prodotti. Se gli ordini fittizi iniziano a fallire, vuoi sapere subito, non devi aspettare che un cliente chiami il servizio di assistenza.
In base alla mia esperienza, testare in un ambiente organizzato e non eseguire di nuovo test su prod dà spesso bug in rilascio. La mia organizzazione monitora molto da vicino i problemi di produzione che sono il risultato di una recente modifica, e quindi esamina attentamente il processo di rilascio seguito per trovare la disaggregazione.
L'errore umano spesso porta l'ambiente scenico a non essere esattamente lo specchio dell'ambiente prod. Oppure, tutti i sistemi che sono upstream e downstream non vengono replicati anche nello stage. Oppure, l'ambiente dello stage non aveva il volume completo di dati che scorre attraverso il sistema prod.
Non c'è un vecchio detto che dice qualcosa del tipo "nessuno è mai stato licenziato per aver compiuto troppa diligenza, ma molto per non averlo applicato abbastanza?" Se non c'è, dovrebbe esserci.
In realtà, non è possibile testare tutto al 100% che il tuo prodotto non verrà mai rilasciato e capire dove disegnare la linea non è facile.
L'intero punto del QA è assicurarsi che il prodotto finale soddisfi i requisiti del cliente e che l'applicazione sia sufficientemente stabile da implementare. Quindi anche se gli ambienti di QA imitano gli ambienti di produzione, potremmo avere alcuni problemi durante le implementazioni come alcuni piccoli problemi di configurazione o di server mancanti, o anche alcuni nuovi bug dovuti alla mancanza di dati !!
Ho lavorato con diverse aziende che utilizzano diverse strategie di QA, alcune di loro non testano mai la produzione e Altre hanno un team speciale per testare la produzione e assicurare che tutto sia perfetto.
Dalla mia esperienza, non ci sono azioni di controllo qualità "ridondanti" !! dipende sempre dalla visione del manager e dalle dimensioni e dai traguardi del progetto.
Direi di sì. Ma a questo punto sarebbe bene avere automatizzati test di integrazione, funzionali e di performance e averli eseguiti frequentemente. Questo è lo scopo di sistemi come l'integrazione continua in cui il QA può essere trasmesso. A questo punto vorrei cercare su Consegna continua e Test continuo .
L'escenario ideale è quello in cui tutto è stato testato in test , int e pre . Finalmente il QA dice OK / KO al rilascio. Ma il codice è stato sottolineato in tutti gli programmi di gestione temporanea prima di essere eseguito in produzione. Ma sappiamo che gli scenari ideali sono abbastanza rari nella tecnologia del software.
Lo scenario comune per me è quello in cui il software non è il mio (io sono il fornitore), per eseguire qualsiasi operatore in produzione dovrebbe essere perché è stato trattato e appare nel contratto .
Quindi il cliente testerà manualmente il professionista! Ma lo faranno con un piano di test scritto da me o dal mio team di QA (fornitore)
Come vedi, eseguire test in Pro a volte è una decisione politica. In altri scenari dipende dalla tua strategia di gestione delle consegne.
Leggi altre domande sui tag testing deployment production qa build-system