Cos'è il test del fumo?

Cos'è il test del fumo?

Test del fumo è un processo di test del software che determina se la build del software distribuito è stabile o meno. Il test del fumo è una conferma per il team QA di procedere con ulteriori test del software. Consiste in una serie minima di test eseguiti su ciascuna build per testare le funzionalità del software. Il test del fumo è noto anche come “test di verifica della costruzione” o “test di fiducia”.

In parole semplici, il smoke testing consiste nel verificare che le funzionalità principali funzionino correttamente e che non vi siano problemi bloccanti nella build in fase di test. Si tratta di un mini e rapido test di regressione delle funzionalità principali. Questo aiuta a determinare se la build presenta dei difetti, rendendo così ulteriori test uno spreco di tempo e risorse.

Confronta Test sul fumo contro la sanità mentale

Perché eseguiamo il test del fumo?

Il smoke testing riveste un ruolo importante nello sviluppo del software, in quanto garantisce la correttezza del sistema nelle fasi iniziali. In questo modo, possiamo risparmiare tempo e risorse di test. Solo dopo aver completato il smoke testing si può procedere con i test funzionali.

• Tutti i punti critici della costruzione verranno identificati tramite test di base.
• Con l'aiuto del test del fumo, la maggior parte dei difetti vengono identificati nelle fasi iniziali lo sviluppo del software.
• Con il test del fumo semplifichiamo il rilevamento e la correzione dei difetti principali.
• Mediante il test del fumo, il team QA può individuare difetti nella funzionalità dell'applicazione che potrebbero essere emersi dal nuovo codice.
• Il test del fumo rileva i principali difetti di gravità.

Esempio 1: Finestra di registrazione: è possibile passare alla finestra successiva con nome utente e password validi facendo clic sul pulsante di invio.

Esempio 2: L'utente non è in grado di uscire dalla pagina Web.

Quando si effettua il test di fumo?

Questi vantaggi si concretizzano solo se il controllo viene attivato al momento giusto. Il test di fumo (smoke testing) viene eseguito ogni volta che nuove funzionalità del software vengono sviluppate e integrate in una build esistente distribuita nell'ambiente di QA/staging. Garantisce che tutte le funzionalità critiche funzionino correttamente. Il diagramma seguente mostra come una build raggiunge l'ambiente di QA prima dell'inizio del test di fumo.

In questo metodo di test, il team di sviluppo distribuisce la build nell'ambiente di QA. Un sottoinsieme di casi di test viene selezionato ed eseguito dai tester sulle funzionalità critiche della build. Questa serie di casi di test è progettata per individuare gli errori presenti nella build. Se questi test vengono superati, il team di QA continua con Test di funzionalità.

Qualsiasi errore indica la necessità di restituire il sistema al team di sviluppo. Ogni volta che si verifica una modifica nella costruzione, eseguiamo il test del fumo per garantirne la stabilità.

Esempio: -Nuovo pulsante di registrazione viene aggiunto nella finestra di accesso e la build viene distribuita con il nuovo codice. Eseguiamo test del fumo su una nuova costruzione.

I test di fumo qualificano la build per ulteriori test formali e sono progettati per dimostrare la stabilità del sistema e la conformità ai requisiti. L'obiettivo principale è individuare tempestivamente i problemi più importanti. Una build include tutti i file di dati, le librerie, i moduli riutilizzabili e i componenti ingegnerizzati necessari per implementare una o più funzioni del prodotto.

Cosa succede se non eseguiamo il test di fumo?

Se non eseguiamo test di fumo nelle fasi iniziali, i difetti potrebbero essere riscontrati nelle fasi successive, con conseguenti costi elevati. Difetto I problemi riscontrati nelle fasi successive possono rappresentare un ostacolo insormontabile che compromette il rilascio dei risultati.

Chi effettuerà il test di fumo?

Dopo aver rilasciato la build nell'ambiente QA, il test del fumo viene eseguito dagli ingegneri/responsabile QA. Ogni volta che viene creata una nuova build, il team di QA determina le principali funzionalità dell'applicazione per eseguire test del fumo. Il team di QA verifica la presenza di ostacoli nell'applicazione in fase di test.

Come si esegue il test del fumo?

Il test del fumo viene solitamente eseguito manualmente, sebbene esista la possibilità di eseguire lo stesso tramite l'automazione. Può variare da organizzazione a organizzazione.

Test manuale del fumo

Vengono effettuati test di fumo per garantire che la navigazione dei percorsi critici avvenga come previsto e non comprometta la funzionalità. Vengono selezionati e testati i casi di test funzionali ad alta priorità per individuare i difetti critici del sistema. Se il test ha esito positivo, si procede con i test funzionali. In caso di esito negativo, la build viene rifiutata e restituita al team di sviluppo per la correzione.

Il team QA riprende i test di base con una nuova versione di build. I test di base vengono eseguiti sulla nuova build e saranno integrati con le build precedenti per garantire la correttezza del sistema. Prima di eseguire i test di base, il team QA deve verificare la correttezza delle versioni di build.

Test di fumo automatizzati

Test di automazione è usato per Test di regressioneTuttavia, possiamo anche utilizzare una serie di casi di test automatizzati da eseguire con Smoke Test. Grazie ai test automatizzati, gli sviluppatori possono verificare immediatamente la build, non appena è disponibile una nuova build per la distribuzione.

Invece di ripetere manualmente i test ogni volta che viene distribuita la nuova build del software, i casi di test del fumo registrati vengono eseguiti sulla build. Verifica se le funzionalità principali funzionano ancora correttamente. Se il test fallisce, possono correggere la build e ridistribuirla immediatamente. In questo modo, possiamo risparmiare tempo e garantire una creazione di qualità per l'ambiente di controllo qualità.

Utilizzando uno strumento automatizzato, l'ingegnere di test registra tutti i passaggi manuali eseguiti nella creazione del software.

Ciclo di prova del fumo

Il diagramma di flusso sottostante mostra come viene eseguito lo smoke test. Una volta che la build è stata distribuita nell'ambiente di QA e gli smoke test sono stati superati, si procede con i test funzionali. Se lo smoke test fallisce, si interrompe la fase di test fino a quando il problema nella build non viene risolto.

Migliori pratiche per la progettazione di casi di smoke test

Conoscere il ciclo è una cosa; mantieniping La suite che la rende affidabile è un'altra cosa. Una suite di test con fumo si guadagna il suo posto solo se rimane compatta, veloce e ripetibile.

• Innanzitutto, mappa i percorsi critici: Elenca i flussi di lavoro che rendono il prodotto commercialmente utilizzabile, come l'accesso, la ricerca, l'inserimento dei dati, il pagamento e la disconnessione. Se uno di questi non funziona, la build non ha alcun valore per un tester.
• Mantieni la suite poco profonda ma ampia: Esamina ogni modulo principale una sola volta, invece di esplorare un singolo modulo in dettaglio. I valori limite, i dati negativi e la formulazione dei messaggi di errore appartengono ai test funzionali, non a questo contesto.
• Limita il tempo di esecuzione: La maggior parte delle squadre mantiene la corsa tra i dieci e i quindici minuti e limita la suite a circa venti o trenta casi testUna corsa che dura un'ora smette di essere un ostacolo e diventa un collo di bottiglia.
• Eseguire gli stessi casi su ogni build: La coerenza consente di attribuire un errore al codice anziché a una modifica nella selezione dei test.
• Elimina i casi instabili e con molte dipendenze: Un caso che passa e fallisce senza alcuna modifica al codice distrugge la fiducia nel gate. Stub o mock di servizi di terze parti instabili dove il framework di automazione dei test permette.
• Registra un verdetto inequivocabile: Ogni caso richiede un unico risultato atteso affinché la build possa essere accettata o rifiutata senza discussioni.
• Versione della suite con la build: Archivia i casi di test di base nello stesso repository del codice dell'applicazione, in modo che il gate corrisponda sempre alla release in fase di test.

RevEsamina la suite a ogni rilascio: ritira i casi relativi a funzionalità non più rilevanti e aggiungi i flussi di lavoro di nuova importanza.

Test di fumo nelle pipeline CI/CD

Una suite progettata in questo modo è abbastanza economica da poter essere eseguita ad ogni commit, che è ciò che la distribuzione moderna richiede. integrazione continua server come Jenkins Il programma compila il codice, lo distribuisce in un ambiente di staging e quindi avvia la smoke suite come prima fase automatizzata. Un'esecuzione con esito positivo (verde) promuove l'artefatto alle fasi funzionali e di regressione, mentre un'esecuzione con esito negativo (rosso) segnala un errore nella pipeline e notifica lo sviluppatore che ha effettuato il commit entro pochi minuti.

Sono comuni due tipi di esecuzione. Un'esecuzione pre-merge protegge il ramo principale convalidando ogni pull request, mentre un'esecuzione post-deployment conferma che l'ambiente distribuito sia raggiungibile e configurato correttamente. I team che adottano la continuous deployment spesso aggiungono una terza esecuzione, più breve, sull'ambiente di produzione subito dopo il rilascio.

Poiché la pipeline esegue la suite più volte al giorno, i casi devono essere non interattivi, autopulenti e indipendenti. Qualsiasi caso che attenda una decisione umana o che lasci dati di test bloccherà la pipeline.

Vantaggi del test del fumo

Ecco alcuni vantaggi elencati per il test del fumo.

• Facile da eseguire e veloce
• Gli errori e i difetti critici sono facili da individuare e correggere nelle fasi iniziali.
• Migliora la qualità del sistema
• Riduce il rischio
• È più facile valutare i progressi.
• Risparmia tempo e fatica nei test
• Riduce al minimo i rischi di integrazione

⚠ Limitazione da notare: Un test di fumo superato indica solo che la build è testabile. Verifica le funzionalità principali in modo superficiale, quindi difetti minori, casi limite e funzionalità usate raramente rimangono nascosti fino all'esecuzione dei test funzionali e di regressione. Non bisogna mai considerare un risultato positivo al test di fumo come un segno che la build sia priva di difetti.

Test di fumo vs test di sanità mentale vs test di regressione

Tutte e tre vengono eseguite dopo una modifica del codice, motivo per cui vengono spesso confuse. Differiscono per ambito, profondità e per la domanda a cui ciascuna risponde.

Il test di verifica (sanity testing) viene eseguito in un ambiente di sviluppo sul codice per garantire la correttezza dell'applicazione prima del rilascio della build al team di QA. Si tratta di un processo che verifica che l'applicazione in fase di sviluppo soddisfi i requisiti funzionali di base.

I test di integrità determinano il completamento della fase di sviluppo e prendono la decisione se superare o meno il prodotto software per un'ulteriore fase di test.

BASE	TEST DEL FUMO	TEST DI SANITÀ	TEST DI REGRESSIONE
Obbiettivo	Ampio e poco profondo	Stretto e profondo	Ampio e profondo
Domanda con risposta	Questa build è sufficientemente stabile per essere testata?	Questa soluzione specifica funziona?	Si è rotto qualcosa che prima funzionava?
Sequenza	Innanzitutto, su ogni build	Dopo aver superato il test del fumo	Dopo il test di sanità mentale
Durata tipica	10 a 15 minuti	30 a 60 minuti	Hours a giorni
Automazione adatta	Molto alto	Moderato, spesso manuale	Molto alto

In pratica, vengono eseguiti in sequenza: smoke testing per accettare la build, sanity testing per verificare la modifica apportata e regression testing quando la pianificazione lo consente.

Esempio di casi di test del fumo campione

La tabella seguente documenta una breve simulazione di fumo, una riga per ogni percorso critico.

T.ID	SCENARI DI PROVA	DESCRIZIONE	FASE DI PROVA	RISULTATO ATTESO	RISULTATO ATTUALE	STATUS
1	Credenziali di accesso valide	Testare la funzionalità di accesso dell'applicazione web per garantire che un utente registrato possa accedere con nome utente e password	1.Avviare l'applicazione 2.Navigare nella pagina di accesso 3.Inserisci un nome utente valido 4.Inserire una password valida 5.Fare clic sul pulsante di accesso	L'accesso dovrebbe avere esito positivo	come previsto	Passare
2	Aggiunta della funzionalità dell'articolo	Possibilità di aggiungere l'articolo al carrello	1.Seleziona l'elenco delle categorie 2.Aggiungi l'articolo al carrello	L'articolo dovrebbe essere aggiunto al carrello	L'articolo non viene aggiunto al carrello	Fallire
3	Funzionalità di disconnessione	Controlla la funzionalità di disconnessione	1. seleziona il pulsante di disconnessione	L'utente dovrebbe essere in grado di disconnettersi.	L'utente non è in grado di disconnettersi	Fallire

DOMANDE FREQUENTI