Introduzione

La vita di un tester QA sarà considerata incompleta se i termini “Test del fumo”, “Test di sanità mentale” e “Test di regressione” non sono infusi in esso. Anche se questi sono alcuni termini usati regolarmente, ci sono alcune idee sbagliate comuni intorno a loro troppo.

Prima di iniziare nei dettagli di fumo, sanità mentale e test di regressione e che cosa significano in realtà, lascia passare attraverso alcune idee sbagliate comuni e miti intorno a loro:

1. Il test del fumo e il test della sanità mentale sono gli stessi e possono essere usati in modo intercambiabile : questo non è vero e non dovrebbe mai essere fatto, perché? ne discuteremo in questo articolo.
2. Il test di integrità è equivalente al test di accettazione: il test di accettazione viene eseguito per garantire che la build soddisfi tutti i requisiti specificati dal client prima del rilascio, mentre il test di integrità viene eseguito per garantire che il prodotto sia sano di mente, razionale per test più dettagliati. Questi non sono e non devono essere usati in modo intercambiabile.
3. Se sto facendo fumo Test, posso saltare test di sanità mentale: Il test del fumo è un test di livello molto alto, come in, questo test è fatto per garantire che questa build sia adatta per iniziare qualsiasi altro tipo di test. Ad esempio, questo potrebbe essere solo un test per garantire l’installazione della build e quindi il test di integrità può iniziare. Anche se a volte, i casi di test del fumo vengono eseguiti insieme ai casi di test di sanità mentale, questi non dovrebbero essere confusi per essere l’unica e la stessa cosa.
4. Il test di regressione non è correlato al test del fumo o al test di sanità mentale: in teoria, il test di sanità mentale è un sottoinsieme del test di regressione. Alcuni casi di test di regressione ad alta priorità costituiscono di solito un test di sanità mentale.
5. Se intendo eseguire la suite di test di regressione completa – non ho bisogno di eseguire alcun test di fumo o test di sanità mentale: Anche se questo può essere vero in alcuni casi, poiché il test di sanità mentale è comunque un sottoinsieme di test di regressione, è comunque consigliabile eseguire prima i casi di test di sanità mentale e poi seguirli con il

In questo articolo, cercheremo di cancellare le confusioni sopra per una volta per tutte.

Nel caso in cui volessi leggere di più sui test manuali, fai riferimento al link qui.

Nota: Poiché useremo il termine ‘Software Build’ molte volte nell’articolo, definiamolo qui. ‘Software Build’ è un processo di conversione del codice sorgente, in un’applicazione utente, dopo più revisioni e modifiche al codice e la creazione di build software coinvolge più processi come “Controllo versione, Qualità del codice & Compilazione ” e la build del software è anche il risultato di questo processo di costruzione. In questo articolo, una build verrà indicata come una versione testabile del software.

Smoke Testing

Smoke testing è un approccio che di solito viene eseguito durante le fasi iniziali di sviluppo del Software Development Life Cycle(SDLC) per assicurarsi che le funzionalità principali di un programma funzionino correttamente senza problemi. Viene eseguito prima che vengano eseguiti test funzionali dettagliati sul software.

L’intento principale del test del fumo non è quello di eseguire test approfonditi ma di verificare che le funzionalità principali o principali del programma o del software funzionino correttamente. Smoke test mira a rifiutare una build malamente rotta nella fase iniziale in modo che il team di test non perda tempo nell’installazione di & testando l’applicazione software.

Il test del fumo è anche chiamato Test di verifica della compilazione.

Vediamo un semplice esempio in cui ti viene data un’applicazione di posta elettronica da testare. Le funzioni importanti sarebbero l’accesso all’applicazione di posta elettronica, la composizione di un’e-mail e l’invio, giusto? E, nel caso in cui l’e-mail non venga inviata, ha senso testare altre funzionalità come bozze, messaggi cancellati, archivi, ecc.? Ciò significa che dovrai abbandonare la build senza ulteriori convalide. Questo è chiamato test del fumo.

L’obiettivo principale del test del fumo è quello di testare le aree critiche e non l’applicazione completa.

Quando eseguire il test del fumo

• Quando gli sviluppatori forniscono una nuova build al team QA. Una nuova build qui significa quando la build ha nuove modifiche apportate dagli sviluppatori.
• Quando un nuovo modulo viene aggiunto alla funzionalità esistente.

Automazione & Prova del fumo:

Di solito questo è il tipo di test che viene eseguito prima che i casi di test di automazione effettivi possano essere eseguiti. Per le organizzazioni che dispongono di test continui integrati, il test del fumo equivale all’installazione corretta della build per l’esecuzione di casi di test o l’esecuzione del primo caso di test. Quindi, questo non è un tipo di test deliberatamente automatizzato, ma se l’automazione dei test viene messa in atto, l’automazione dei test può essere eseguita con successo solo una volta che il software ha superato i test del fumo. O altrimenti, il primo caso di test che viene eseguito potrebbe non riuscire.

Sanity Testing

Sanity testing è un tipo di test eseguito per verificare se un prodotto software funziona correttamente quando un nuovo modulo o funzionalità viene implementato in un prodotto esistente. Test di sanità mentale è una tecnica di test del software che fa una rapida valutazione della qualità del rilascio del software per determinare se è idoneo per ulteriori cicli di test o meno.

Il test di integrità viene solitamente eseguito dopo aver ricevuto una build software abbastanza stabile o talvolta quando una build software potrebbe aver subito modifiche minori nel codice o nella funzionalità. Decide se il test end to end di un prodotto software deve essere effettuato ulteriormente o meno.

Il test di integrità è anche un test di livello superficiale che aiuta a decidere se la build del software è abbastanza buona da passarla al livello successivo di test.

Perché eseguire test di sanità mentale

• Per verificare e convalidare la conformità delle funzionalità e delle funzionalità appena aggiunte nel codice esistente.
• Per garantire che le modifiche introdotte non influenzino altre funzionalità esistenti del prodotto.
• Per decidere ulteriori test possono essere portati avanti o meno.

Quando eseguire test di integrità

• La build viene ricevuta dopo molte regressioni o se c’è una piccola modifica nel codice.
• La build viene ricevuta dopo la correzione di bug.
• Poco prima della distribuzione in produzione.

Automazione& Test di integrità:

Considerando che il test di integrità è considerato come un sottoinsieme di test di regressione, questi sono i casi di test che possono essere automatizzati. Un approccio consigliato è quello di eseguire questi casi di test prima di eseguire la suite di test di regressione completa. Il vantaggio è che se ci sono errori nei casi di test di sanità mentale, gli errori possono essere segnalati prima piuttosto che dopo.

Test di regressione

Il test di regressione è la verifica di “correzioni di bug o eventuali modifiche nel requisito” e assicurandosi che non stiano influenzando altre funzionalità dell’applicazione. Il test di regressione è efficace sull’automazione e di solito viene eseguito dopo che sono state apportate alcune modifiche nella build del software dopo le modifiche ai requisiti o le correzioni di bug.

Una volta completato il test di integrità della funzionalità modificata, tutte le funzionalità interessate dell’applicazione richiedono test completi. Questo è chiamato test di regressione.

Ogni volta che le correzioni di bug sono fatte nel software esistente, alcuni scenari di test devono essere eseguiti, per verificare le correzioni di bug. Oltre a questi, il team QA deve anche controllare le aree interessate, in base alle modifiche al codice. Nel test di regressione, tutti quegli scenari di test dovranno essere eseguiti, per prendersi cura delle funzionalità correlate.

Quando eseguire il Test di Regressione

• Dopo la modifica del Codice, secondo le modifiche richieste
• Dopo alcune sono state aggiunte nuove funzioni all’applicazione
• Dopo alcune correzioni di bug sono incorporati nella compilazione

Automazione & Test di Regressione:

test di Regressione casi sono in realtà l’ideale di casi di test per automa. Di solito, quando un’organizzazione avvia l’automazione, questi sono i casi di test che vengono automatizzati per primi. Se il test di regressione è un’attività che richiede molto tempo per i tester e gli stessi casi di test vengono ripetuti più volte, è ora di iniziare a pensare anche all’automazione.

Se stai cercando uno strumento che possa aiutarti a iniziare il tuo percorso di automazione, devi anche assicurarti di scegliere lo strumento giusto. Uno strumento che può anche fornire ROI sugli sforzi investiti. Abbiamo la guida che può aiutarti lì:

10 Points to Help You Choose the Right Test Automation Tool

Differences Between Smoke vs Sanity vs Regression Testing

Punti Chiave

• Fumo e la Sanità mentale test di aiutare il team QA salvare velocemente i test per verificare se un’applicazione sta funzionando correttamente. Inoltre, garantisce che il prodotto sia idoneo per ulteriori test. Mentre il test di regressione aiuta a migliorare la fiducia sulla qualità del software dopo un particolare cambiamento. In particolare, che le modifiche al codice non influenzano le aree correlate.

• Il test del fumo viene eseguito sia dal team di sviluppo che dal team QA e può essere preso come un sottoinsieme di test rigorosi. Mentre entrambi i test di regressione di Sanity & vengono eseguiti solo dal team QA. Inoltre, il test di sanità mentale può essere considerato come un sottoinsieme di test di accettazione.

• Il test del fumo viene eseguito nella fase iniziale di SDLC, per verificare le funzionalità principali di un’applicazione. Mentre Sanity & I test di regressione vengono eseguiti nella fase finale di SDLC, per verificare le principali funzionalità di un’applicazione.

• Secondo il requisito di testare& disponibilità di tempo, il team QA potrebbe dover eseguire test di integrità, Fumo& Test di regressione sulla loro build software. In questi casi, i test del fumo vengono eseguiti per primi, seguiti da Test di sanità mentale & quindi in base alla disponibilità di tempo viene pianificato il test di regressione.

In pratica, tutti i team QA devono eseguire test di fumo, sanità mentale e regressione. Tutti questi tipi di test hanno un numero predefinito di casi di test che vengono eseguiti più volte. Questa esecuzione ripetitiva li rende anche un candidato ideale per l’automazione dei test. Quando si cerca l’automazione, si consiglia di utilizzare uno strumento che fornisce il ROI sull’automazione fin dalle fasi iniziali. Testsigma è uno di questi strumenti.