Test del fumo vs test di sanità mentale: differenza con gli esempi

smoke testing vs sanity testing

Esplora in dettaglio le differenze tra il test del fumo e il test di sanità mentale con esempi:

In questo tutorial, impareremo cos'è il test di sanità mentale e il test del fumo nel test del software. Impareremo anche le principali differenze tra Sanity e Smoke test con semplici esempi.

La maggior parte delle volte ci confondiamo tra il significato di Sanity Testing e Smoke Testing. Prima di tutto, questi due test sono molto ' diverso 'E vengono eseguiti durante le diverse fasi di un ciclo di test.

Cosa imparerai:

• Test di sanità mentale
• La mia esperienza
• Test di sanità mentale vs test di regressione
• Strategia per il test delle app mobili
• Misure precauzionali
• Test del fumo
• Esempi di test sul fumo
  • # 1) Test di accettazione
  • # 2) Test di integrazione
  • # 3) Test di sistema
• Importanza nella metodologia SCRUM
• Smoke Test Vs Build Test di accettazione
• Ciclo di prova del fumo
• Chi dovrebbe eseguire il test del fumo?
• Perché dovremmo automatizzare i test sul fumo?
• Vantaggi e svantaggi
• Differenza tra fumo e test di sanità mentale
  • TEST DI FUMO
  • TEST DI SANITÀ
• Lettura consigliata

Test di sanità mentale

Sanity Testing viene eseguito quando come QA non abbiamo tempo sufficiente per eseguire tutti i casi di test, sia esso Test funzionali , UI, OS o test del browser.

Quindi, definirei,

'Sanity Testing come esecuzione di test che viene eseguita per toccare ogni implementazione e il suo impatto ma non in modo completo o approfondito, può includere test funzionali, dell'interfaccia utente, della versione, ecc. A seconda dell'implementazione e del suo impatto.'

Non cadiamo tutti in una situazione in cui dobbiamo firmare in un giorno o due ma la build per i test non viene ancora rilasciata?

team foundation server gestione agile dei progetti

Ah si, scommetto che anche tu devi aver affrontato questa situazione almeno una volta nella tua esperienza di Software Testing. Beh, l'ho affrontato molto perché i miei progetti erano per lo più agili ea volte ci è stato chiesto di consegnarli lo stesso giorno. Ops, come potrei testare e rilasciare la build entro poche ore?

A volte impazzivo perché, anche se si trattava di una piccola funzionalità, l'implicazione poteva essere enorme. E come ciliegina sulla torta, i clienti a volte si rifiutano semplicemente di dedicare tempo extra. Come potrei completare l'intero test in poche ore, verificare ogni funzionalità, Bug e rilasciarlo?

La risposta a tutti questi problemi era molto semplice, cioè nient'altro che usare Strategia di test di sanità mentale.

Quando eseguiamo questo test per un modulo o una funzionalità o un sistema completo, il file Casi di test per l'esecuzione sono selezionati in modo tale che tocchino tutti i pezzi importanti dello stesso vale a dire test ampi ma poco profondi.

A volte il test viene eseguito anche in modo casuale senza casi di test. Ma ricorda, Il test di sanità mentale dovrebbe essere eseguito solo quando hai poco tempo, non usarlo mai per i tuoi rilasci regolari. Teoricamente, questo test è un sottoinsieme di Test di regressione .

La mia esperienza

In oltre 8 anni di carriera nel test del software, ho lavorato per 3 anni Metodologia agile e quello era il momento in cui usavo principalmente un test di sanità mentale.

Tutti i grandi rilasci sono stati pianificati ed eseguiti in modo sistematico, ma a volte è stato chiesto di consegnare i piccoli rilasci il prima possibile. Non abbiamo avuto molto tempo per documentare i casi di test, eseguire, fare la documentazione dei bug, fare la regressione e seguire l'intero processo.

Quindi i seguenti sono alcuni dei puntatori chiave che ho usato per seguire in tali situazioni:

# 1) Siediti con il manager e il team di sviluppo quando discutono dell'implementazione perché devono lavorare velocemente e quindi non possiamo aspettarci che ci spieghino separatamente.

Questo ti aiuterebbe anche a farti un'idea di cosa stanno per implementare, quale area interesserà ecc., Questa è una cosa molto importante da fare perché a volte semplicemente non ci rendiamo conto delle implicazioni e delle eventuali funzionalità esistenti sarà ostacolato (nel peggiore dei casi).

#Due) Dato che hai poco tempo, quando il team di sviluppo sta lavorando all'implementazione, puoi annotare i casi di test più o meno in strumenti come Evernote, ecc. Ma assicurati di scriverli da qualche parte in modo da poterli aggiungere in seguito a lo strumento del caso di test.

# 3) Tieni pronto il tuo banco di prova secondo l'implementazione e se ritieni che ci siano segnali d'allarme come la creazione di dati specifici se un banco di prova richiederà tempo (ed è un test importante per il rilascio), quindi alza immediatamente quei flag e informa il tuo manager o PO sul blocco stradale.

Solo perché il cliente vuole il prima possibile, non significa che un QA verrà rilasciato anche se è stato testato a metà.

# 4) Fai un accordo con il tuo team e il tuo manager che a causa della stretta di tempo comunicherai i bug solo al team di sviluppo e il processo formale di aggiunta, contrassegnando i bug per le diverse fasi nello strumento di tracciamento dei bug verrà eseguito in seguito per risparmiare tempo .

# 5) Quando il team di sviluppo sta testando alla fine, prova ad accoppiarli (chiamato accoppiamento dev-QA) e fare un giro di base sulla loro configurazione stessa, questo aiuterà ad evitare il avanti e indietro della build se l'implementazione di base fallisce .

# 6) Ora che hai la build, prova prima le regole aziendali e tutti i casi d'uso. Puoi conservare test come la convalida di un campo, la navigazione, ecc. Per dopo.

# 7) Qualunque bug trovi, prendi nota di tutti e prova a segnalarli insieme agli sviluppatori piuttosto che segnalarli individualmente perché sarà facile per loro lavorare su un gruppo.

# 8) Se hai un requisito per il complessivo Test delle prestazioni o Stress o Load Testing, quindi assicurati di disporre di un framework di automazione adeguato per lo stesso. Perché è quasi impossibile testarli manualmente con un test di sanità mentale.

# 9) Questa è la parte più importante, e in effetti l'ultimo passo della tua strategia di test di sanità mentale - 'Quando scrivi l'email di rilascio o il documento, menziona tutti i casi di test che hai eseguito, i bug trovati con un indicatore di stato e se è stato lasciato qualcosa non testato menzionarlo con le ragioni ' Prova a scrivere una storia nitida sui tuoi test che trasmetta a tutti ciò che è stato testato, verificato e ciò che non lo è stato.

L'ho seguito religiosamente quando stavo usando questo test.

Lasciami condividere la mia esperienza:

# 1) Stavamo lavorando su un sito Web e utilizzava gli annunci popup in base alle parole chiave. Gli inserzionisti erano soliti fare offerte per determinate parole chiave che avevano uno schermo progettato per le stesse. Il valore dell'offerta predefinita era indicato come $ 0,25, che l'offerente poteva persino modificare.

C'era un altro posto in cui questa offerta predefinita veniva mostrata e poteva essere modificata anche con un altro valore. Il cliente ha chiesto di modificare il valore predefinito da $ 0,25 a $ 0,5, ma ha menzionato solo la schermata ovvia.

Durante la nostra discussione di brainstorming, ci siamo dimenticati (?) Di questo altro schermo perché non era molto utilizzato per quello scopo. Ma durante il test quando ho eseguito il caso di base dell'offerta di $ 0,5 e ho controllato dall'inizio alla fine, ho scoperto che il cronjob per lo stesso non funzionava perché in un punto stava trovando $ 0,25.

L'ho segnalato al mio team e abbiamo apportato la modifica e l'abbiamo consegnata con successo lo stesso giorno stesso.

#Due) Nello stesso progetto (menzionato sopra), ci è stato chiesto di aggiungere un piccolo campo di testo per note / commenti per le offerte. È stata un'implementazione molto semplice e ci siamo impegnati a consegnarla lo stesso giorno.

Quindi, come accennato in precedenza, ho testato tutte le regole aziendali e i casi d'uso attorno ad esso e quando ho eseguito alcuni test di convalida, ho scoperto che quando ho inserito una combinazione di caratteri speciali come, la pagina si è bloccata.

Ci abbiamo riflettuto e abbiamo capito che gli effettivi offerenti non useranno comunque tali combinazioni. Quindi, l'abbiamo rilasciato con una nota ben redatta sulla questione. Il client lo ha accettato come un bug, ma ha accettato di implementarlo in seguito perché si trattava di un bug grave ma non precedente.

# 3) Di recente, stavo lavorando a un progetto di app mobile e avevamo la necessità di aggiornare l'ora di consegna mostrata nell'app in base al fuso orario. Non doveva essere testato solo nell'app, ma anche per il servizio web.

Mentre il team di sviluppo lavorava all'implementazione, ho creato gli script di automazione per il test del servizio Web e gli script DB per la modifica del fuso orario dell'elemento di consegna. Ciò ha risparmiato i miei sforzi e abbiamo potuto ottenere risultati migliori in breve tempo.

Test di sanità mentale vs test di regressione

Di seguito sono riportate alcune differenze tra i due:

Strategia per il test delle app mobili

Ti starai chiedendo perché sto menzionando specificamente le app mobili qui?

Il motivo è che la versione del sistema operativo e del browser per le app Web o desktop non variano molto e soprattutto le dimensioni dello schermo sono standard. Ma con le app mobili, le dimensioni dello schermo, la rete mobile, le versioni del sistema operativo, ecc. Influenzano la stabilità, l'aspetto e, in breve, il successo della tua app mobile.

Quindi una formulazione di strategia diventa fondamentale quando esegui questo test su un'app mobile perché un errore può portarti in grossi guai. Il test deve essere eseguito in modo intelligente e anche con cautela.

Di seguito sono riportati alcuni suggerimenti per aiutarti a eseguire correttamente questo test su un ''app mobile':

# 1) Prima di tutto, analizza con il tuo team l'impatto della versione del sistema operativo sull'implementazione.

Prova a trovare risposte a domande come, il comportamento sarà diverso tra le versioni? L'implementazione funzionerà con la versione più bassa supportata o no? Ci saranno problemi di prestazioni per l'implementazione delle versioni? C'è qualche caratteristica specifica del sistema operativo che potrebbe influire sul comportamento dell'implementazione? eccetera.

#Due) Nella nota precedente, analizza anche i modelli di telefono, ad es. Ci sono funzionalità del telefono che influiranno sull'implementazione? L'implementazione del cambiamento di comportamento con il GPS? Il comportamento di implementazione cambia con la fotocamera del telefono? ecc. Se ritieni che non ci sia alcun impatto, evita di testare su diversi modelli di telefono.

# 3) A meno che non ci siano modifiche all'interfaccia utente per l'implementazione, consiglierei di mantenere i test dell'interfaccia utente con la minima priorità, puoi informare il team (se lo desideri) che l'interfaccia utente non verrà testata.

# 4) Per risparmiare tempo, evita di testare su buone reti perché è ovvio che l'implementazione funzionerà come previsto su una rete forte. Consiglierei di iniziare con il test su una rete 4G o 3G.

# 5) Questo test deve essere eseguito in meno tempo, ma assicurati di eseguire almeno un test sul campo a meno che non si tratti di una semplice modifica dell'interfaccia utente.

# 6) Se devi testare una matrice di sistemi operativi diversi e la loro versione, ti suggerisco di farlo in modo intelligente. Ad esempio, scegli le coppie di versioni del sistema operativo più bassa, media e più recente per il test. Puoi menzionare nel documento di rilascio che non tutte le combinazioni vengono testate.

# 7) Su una linea simile, per il test di integrità dell'implementazione dell'interfaccia utente, utilizzare dimensioni dello schermo piccole, medie e grandi per risparmiare tempo. Puoi anche usare un simulatore ed un emulatore.

Misure precauzionali

Sanity Testing viene eseguito quando hai poco tempo e quindi non è possibile eseguire tutti i casi di test e, soprattutto, non ti viene dato abbastanza tempo per pianificare i tuoi test. Per evitare i giochi di colpa, è meglio prendere misure precauzionali.

In questi casi la mancanza di comunicazione scritta, la documentazione del test e gli errori sono abbastanza comuni.

Per assicurarti di non cadere preda di questo, assicurati che:

• Non accettare mai una build per il test fino a quando non ti viene fornito un requisito scritto condiviso dal client. Succede che i clienti comunichino le modifiche o le nuove implementazioni verbalmente o in chat o un semplice 1 liner in un'e-mail e si aspettano che lo consideriamo come un requisito. Invita il tuo cliente a fornire alcuni punti di funzionalità di base e criteri di accettazione.
• Prendi sempre note approssimative dei tuoi casi di test e dei bug se non hai tempo sufficiente per scriverli in modo ordinato. Non lasciare mai questi privi di documenti. Se c'è del tempo, condividilo con il tuo lead o team in modo che se manca qualcosa possono segnalarlo facilmente.
• Se tu e il tuo team avete poco tempo, assicurati che i bug siano contrassegnati nello stato appropriato in un'e-mail? Puoi inviare via e-mail l'elenco completo dei bug al team e fare in modo che gli sviluppatori li contrassegnino in modo appropriato. Tieni sempre la palla nel campo dell'altro.
• Se hai Framework di automazione pronto, usalo ed evita di farlo ManualTesting , in questo modo in meno tempo puoi coprire di più.
• Evita lo scenario del 'rilascio in 1 ora' a meno che tu non sia sicuro al 100% che sarai in grado di consegnare.
• Ultimo ma non meno importante, come accennato in precedenza, redigere un'e-mail di rilascio dettagliata che comunichi cosa è stato testato, cosa è stato escluso, ragioni, rischi, quali bug sono stati risolti, cosa è 'Latered' ecc.

In qualità di QA, dovresti giudicare qual è la parte più importante dell'implementazione che deve essere testata e quali sono le parti che possono essere tralasciate o testate di base.

Anche in breve tempo, pianifica una strategia su come vuoi fare e sarai in grado di ottenere il meglio in un determinato lasso di tempo.

Test del fumo

Lo Smoke Testing non è un test esaustivo ma è un gruppo di test che vengono eseguiti per verificare se le funzionalità di base di quella particolare build stanno funzionando bene come previsto o meno. Questo è e dovrebbe sempre essere il primo test da eseguire su qualsiasi build 'nuova'.

Quando il team di sviluppo rilascia una build al QA per il test, ovviamente non è possibile testare l'intera build e verificare immediatamente se una delle implementazioni presenta bug o se una delle funzionalità funzionanti è danneggiata.

Alla luce di ciò, come farà un QA ad assicurarsi che le funzionalità di base funzionino correttamente?

La risposta a questo sarà eseguire un file Test del fumo .

Una volta che i test sono contrassegnati come Smoke test (nella suite di test) superati, solo allora la build viene accettata dal QA per test approfonditi e / o regressione. Se uno dei test del fumo fallisce, la build viene rifiutata e il team di sviluppo deve risolvere il problema e rilasciare una nuova build per i test.

Teoricamente, il test del fumo è definito come test a livello di superficie per certificare che la build fornita dal team di sviluppo al team QA è pronta per ulteriori test. Questo test viene eseguito anche dal team di sviluppo prima di rilasciare la build al team QA.

Questo test viene normalmente utilizzato nei test di integrazione, test di sistema e test del livello di accettazione. Non considerare mai questo come un sostituto dell'effettivo test end to end completo . Comprende test positivi e negativi a seconda dell'implementazione della build.

Esempi di test sul fumo

Questo test viene normalmente utilizzato per l'integrazione, l'accettazione e Test di sistema .

Nella mia carriera di QA, ho sempre accettato una build solo dopo aver eseguito un test del fumo. Quindi, vediamo cosa è un test del fumo dal punto di vista di tutti questi tre test, con alcuni esempi.

# 1) Test di accettazione

Ogni volta che una build viene rilasciata al QA, il test del fumo sotto forma di un file Test di accettazione dovrebbe essere fatto.

In questo test, il primo e più importante test del fumo consiste nel verificare la funzionalità prevista di base dell'implementazione. In questo modo, dovresti verificare tutte le implementazioni per quella particolare build.

Prendiamo i seguenti esempi come implementazioni eseguite in una build per comprendere i test di fumo per quelli:

• Implementata la funzionalità di accesso per consentire ai driver registrati di accedere correttamente.
• Implementata la funzionalità del dashboard per mostrare i percorsi che un conducente deve eseguire oggi.
• Implementata la funzionalità per mostrare un messaggio appropriato se non esistono percorsi per un dato giorno.

Nella build precedente, a livello di accettazione, il test del fumo significherà verificare che le tre implementazioni di base funzionino correttamente. Se uno qualsiasi di questi tre è guasto, il QA dovrebbe rifiutare la build.

# 2) Test di integrazione

Questo test viene solitamente eseguito quando i singoli moduli vengono implementati e testati. Nel Test d'integrazione livello, questo test viene eseguito per assicurarsi che tutte le integrazioni di base e le funzionalità end-to-end funzionino correttamente come previsto.

Può essere l'integrazione di due moduli o di tutti i moduli insieme, quindi la complessità del test del fumo varierà a seconda del livello di integrazione.

Consideriamo i seguenti esempi di implementazione dell'integrazione per questo test:

• Implementata l'integrazione dei moduli percorso e fermate.
• Implementata l'integrazione dell'aggiornamento dello stato di arrivo e riflesso lo stesso sulla schermata delle fermate.
• Implementata l'integrazione dei moduli di funzionalità di ritiro completo fino alla consegna.

In questa build, il test del fumo non solo verificherà queste tre implementazioni di base, ma per la terza implementazione, alcuni casi verificheranno anche la completa integrazione. Aiuta molto a scoprire i problemi che vengono introdotti nell'integrazione e quelli che sono passati inosservati dal team di sviluppo.

# 3) Test di sistema

Come suggerisce il nome stesso, a livello di sistema, il test del fumo include test per i flussi di lavoro più importanti e comunemente utilizzati del sistema. Questo viene fatto solo dopo che il sistema completo è pronto e testato, e questo test a livello di sistema può essere definito test del fumo prima del test di regressione.

Prima di iniziare la regressione del sistema completo, le funzionalità end-to-end di base vengono testate come parte del test del fumo. La suite di test del fumo per il sistema completo comprende i casi di test end-to-end che gli utenti finali useranno molto frequentemente.

Questo di solito viene fatto con l'aiuto di strumenti di automazione.

Importanza nella metodologia SCRUM

Al giorno d'oggi, i progetti seguono difficilmente la metodologia Waterfall nell'implementazione del progetto, per lo più tutti i progetti seguono Agile e MISCHIA solo. Rispetto al tradizionale metodo a cascata, lo Smoke Testing tiene in grande considerazione SCRUM e Agile.

Ho lavorato per 4 anni in SCRUM . E poiché sappiamo che in SCRUM, gli sprint hanno una durata più breve e quindi è di estrema importanza fare questo test, in modo che le build fallite possano essere immediatamente segnalate al team di sviluppo e riparate.

Di seguito sono riportati alcuni porta via sull'importanza di questo test in SCRUM:

• Fuori dallo sprint di due settimane, l'intervallo viene assegnato al QA ma a volte le build per il QA sono ritardate.
• Negli sprint, è meglio per il team che i problemi vengano segnalati in una fase iniziale.
• Ogni storia ha una serie di criteri di accettazione, quindi testare i primi 2-3 criteri di accettazione è uguale al test del fumo di quella funzionalità. I clienti rifiutano la consegna se un singolo criterio non riesce.
• Immagina cosa succederà se sono 2 giorni che il team di sviluppo ti ha consegnato la build e rimangono solo 3 giorni per la demo e ti imbatti in un errore di funzionalità di base.
• In media, uno sprint ha storie che vanno da 5 a 10, quindi quando viene fornita la build è importante assicurarsi che ogni storia sia implementata come previsto prima di accettare la build in testing.
• Quando il sistema completo deve essere testato e fatto regredire, uno sprint è dedicato all'attività. Una quindicina di giorni forse un po 'meno per testare l'intero sistema, quindi è molto importante verificare le funzionalità più elementari prima di iniziare la regressione.

Smoke Test Vs Build Test di accettazione

Il test del fumo è direttamente correlato al Build Acceptance Testing (BAT).

In BAT, eseguiamo gli stessi test per verificare se la build non ha avuto esito negativo e che il sistema funzioni correttamente o meno. A volte, accade che quando viene creata una build, vengono introdotti alcuni problemi e quando viene consegnata, la build non funziona per il QA.

Direi che BAT fa parte di un controllo del fumo perché se il sistema non funziona, come puoi accettare la build per il test come QA? Non solo le funzionalità, il sistema stesso deve funzionare prima che il QA proceda con i test approfonditi.

qual è il miglior downloader mp3 per Android

Ciclo di prova del fumo

Il seguente diagramma di flusso spiega il ciclo di prova del fumo.

Una volta che una build viene distribuita a un QA, il ciclo di base seguito è che se il test del fumo viene superato, la build viene accettata dal team QA per ulteriori test, ma se fallisce, la build viene rifiutata fino a quando i problemi segnalati non vengono risolti.

Ciclo di prova

Chi dovrebbe eseguire il test del fumo?

Non tutto il team è coinvolto in questo tipo di test per evitare la perdita di tempo di tutti i QA.

Il test del fumo viene idealmente eseguito dal responsabile del controllo qualità che decide in base al risultato se passare la build al team per ulteriori test o rifiutarla. Oppure, in assenza del lead, anche gli stessi QA possono eseguire questo test.

A volte, quando il progetto è su larga scala, un gruppo di addetti al controllo qualità può anche eseguire questo test per verificare la presenza di eventuali ostacoli. Ma non è così nel caso di SCRUM perché SCRUM è una struttura piatta senza Lead o Manager e ogni tester ha le proprie responsabilità nei confronti delle proprie storie.

Quindi i singoli QA eseguono questo test per le storie che possiedono.

Perché dovremmo automatizzare i test sul fumo?

Questo test è il primo test da eseguire su una build rilasciata dal team di sviluppo. In base ai risultati di questo test, vengono eseguiti ulteriori test (o la build viene rifiutata).

Il modo migliore per eseguire questo test è utilizzare uno strumento di automazione e programmare l'esecuzione della suite per fumatori quando viene creata una nuova build. Potresti pensare perché dovrei 'Automatizzare la suite di test del fumo'?

Esaminiamo il seguente caso:

Supponiamo che tu sia a una settimana dal tuo rilascio e su un totale di 500 casi di test, la tua suite di test del fumo comprende 80-90. Se inizi a eseguire manualmente tutti questi casi di test 80-90, immagina quanto tempo impiegherai? Penso 4-5 giorni (minimo).

Ma se usi l'automazione e crei script per eseguire tutti questi casi di test 80-90, idealmente, questi verranno eseguiti in 2-3 ore e avrai i risultati con te immediatamente. Non ti ha fatto risparmiare tempo prezioso e ti ha dato i risultati sull'integrazione molto meno tempo?

5 anni fa, stavo testando un'app di proiezione finanziaria, che prendeva input sul tuo stipendio, risparmi, ecc. E proiettava le tue tasse, risparmi, profitti a seconda delle regole finanziarie. Insieme a questo, abbiamo avuto la personalizzazione per i paesi che dipendono dal paese e le sue regole fiscali utilizzate per cambiare (nel codice).

Per questo progetto, avevo 800 casi di test e 250 casi di test del fumo. Con l'uso del selenio, potremmo facilmente automatizzare e ottenere i risultati di quei 250 casi di test in 3-4 ore. Non solo ci ha fatto risparmiare tempo, ma ci ha mostrato AL PIÙ PRESTO sugli spettacoli.

Quindi, a meno che non sia impossibile automatizzare, prendi l'aiuto dell'automazione per questo test.

Vantaggi e svantaggi

Diamo prima un'occhiata ai vantaggi in quanto ha molto da offrire rispetto ai suoi pochi svantaggi.

Vantaggi:

• Facile da eseguire.
• Riduce il rischio.
• I difetti vengono identificati in una fase molto precoce.
• Risparmia sforzi, tempo e denaro.
• Funziona rapidamente se automatizzato.
• Minori rischi e problemi di integrazione.
• Migliora la qualità complessiva del sistema.

Svantaggi:

• Questo test non è uguale o sostitutivo del test funzionale completo.
• Anche dopo che il test del fumo è passato, potresti trovare bug di showstopper.
• Questo tipo di test è più adatto se è possibile automatizzare, altrimenti si spende molto tempo per eseguire manualmente i casi di test, specialmente in progetti su larga scala con circa 700-800 casi di test.

Il test del fumo dovrebbe assolutamente essere fatto su ogni build in quanto evidenzia i principali fallimenti e gli ostacoli in una fase molto precoce. Questo vale non solo per le nuove funzionalità, ma anche per l'integrazione di moduli, la risoluzione di problemi e l'improvvisazione. È un processo molto semplice da eseguire e ottenere il risultato corretto.

Questo test può essere considerato come il punto di ingresso per il test funzionale completo della funzionalità o del sistema (nel suo insieme). Ma prima di allora il team di controllo qualità dovrebbe essere molto chiaro su quali test devono essere eseguiti come test del fumo . Questo test può ridurre al minimo gli sforzi, risparmiare tempo e migliorare la qualità del sistema. Ha un posto molto importante negli sprint poiché il tempo negli sprint è inferiore.

Questo test può essere eseguito sia manualmente che anche con l'aiuto di strumenti di automazione. Ma il modo migliore e preferito è utilizzare gli strumenti di automazione per risparmiare tempo.

Differenza tra fumo e test di sanità mentale

La maggior parte delle volte ci confondiamo tra il significato di Sanity Testing e Smoke Testing. Prima di tutto, questi due test sono molto ' diverso 'Ed eseguito durante le diverse fasi di un ciclo di test.

Di seguito è una rappresentazione schematica delle loro differenze:

TEST DI FUMO

• Questo test ha avuto origine nel hardware testare la pratica di accendere per la prima volta un nuovo componente hardware e considerarlo un successo se non prende fuoco e non emette fumo. Nell'industria del software, questo test è un approccio superficiale e ampio in base al quale vengono testate tutte le aree dell'applicazione senza entrare troppo in profondità.
• Un test del fumo è programmato, utilizzando una serie scritta di test o un test automatizzato
• Un test del fumo è progettato per toccare ogni parte dell'applicazione in modo superficiale. È poco profondo e largo.
• Questo test viene condotto per garantire se le funzioni più cruciali di un programma stanno funzionando, ma non si preoccupano dei dettagli più fini. (Come la verifica della build).
• Questo test è un normale controllo dello stato di salute della compilazione di un'applicazione prima di sottoporlo a un test approfondito.

TEST DI SANITÀ

• Un test di sanità mentale è un test di regressione ristretto che si concentra su una o poche aree di funzionalità. Il test di sanità mentale è generalmente stretto e profondo.
• Questo test è solitamente senza script.
• Questo test viene utilizzato per determinare che una piccola sezione dell'applicazione funziona ancora dopo una piccola modifica.
• Questo test è un test superficiale, viene eseguito ogni volta che un test superficiale è sufficiente per dimostrare che l'applicazione funziona secondo le specifiche. Questo livello di test è un sottoinsieme dei test di regressione.
• Questo per verificare se i requisiti sono soddisfatti o meno, controllando in primo luogo tutte le funzionalità.

Spero che tu sia chiaro sulle differenze tra questi due vasti e importanti tipi di test del software. Sentiti libero di condividere i tuoi pensieri nella sezione commenti qui sotto !!

Lettura consigliata

• Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
• Differenza tra desktop, test server client e test Web
• Test funzionale vs test non funzionale
• Download dell'eBook Testing Primer
• Alpha test e beta test (una guida completa)
• Guida ai test di portabilità con esempi pratici
• Tipi di test del software: diversi tipi di test con dettagli
• Test funzionale vs test delle prestazioni: dovrebbe essere fatto contemporaneamente?