Good Mood

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

In questo tutorial, impareremo cos’è il test di sanità mentale e il test del fumo nei test del software. Impareremo anche le differenze chiave tra la sanità mentale e il test del fumo con semplici esempi.

La maggior parte delle volte ci confondiamo tra il significato del test di sanità mentale e il test del fumo. Prima di tutto, questi due test sono “diversi” e vengono eseguiti durante diverse fasi di un ciclo di test.,

Test di sanità mentale

Il test di sanità mentale viene eseguito quando come QA non abbiamo tempo sufficiente per eseguire tutti i casi di test, che si tratti di test funzionali, UI, OS o test del browser.

Quindi, definirei,

“Test di sanità mentale come esecuzione di test che viene eseguita per toccare ogni implementazione e il suo impatto ma non in modo approfondito o approfondito, può includere funzionale, interfaccia utente, versione, ecc. test 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 il test non è ancora stata rilasciata?,

Ah sì, scommetto che anche tu devi aver affrontato questa situazione almeno una volta nella tua esperienza di test del software. Bene, l’ho affrontato molto perché i miei progetti erano per lo più agili e a volte ci è stato chiesto di consegnarlo lo stesso giorno. Oops, come potrei testare e rilasciare la build in un arco di ore?

A volte andavo matto perché anche se fosse una piccola funzionalità, l’implicazione potrebbe essere tremenda. E come ciliegina sulla torta, i clienti a volte si rifiutano semplicemente di dare più tempo., 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 la strategia di test di sanità mentale.

Quando eseguiamo questo test per un modulo o una funzionalità o un sistema completo, i casi di test per l’esecuzione vengono selezionati in modo tale da toccare tutti i bit e i pezzi importanti dello stesso test, ad esempio test ampi ma poco profondi.

A volte il test viene eseguito in modo casuale senza casi di test., Ma ricordate, test di sanità mentale dovrebbe essere fatto solo quando si esegue a corto di tempo, non utilizzare mai questo per le vostre uscite regolari. Teoricamente, questo test è un sottoinsieme di test di regressione.

La mia esperienza

Dei miei oltre 8 anni di carriera nel test del software, per 3 anni ho lavorato in metodologia Agile e quello era il momento in cui ho usato principalmente un test di sanità mentale.

Tutte le grandi release sono state pianificate ed eseguite in modo sistematico, ma a volte, le piccole release sono state richieste per essere consegnate 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) Sedersi con il manager e il team di sviluppo quando stanno discutendo l’implementazione perché devono lavorare velocemente e quindi non possiamo aspettarci che ci spieghino separatamente.

Questo ti aiuterebbe anche a farti un’idea di cosa implementeranno, quale area influenzerà ecc.,, questa è una cosa molto importante da fare perché a volte semplicemente non realizziamo le implicazioni e se qualsiasi funzionalità esistente sta per essere ostacolata (nel peggiore dei casi).

#2) Poiché hai poco tempo, nel momento in cui il team di sviluppo sta lavorando all’implementazione, puoi annotare i casi di test approssimativamente in strumenti come Evernote, ecc. Ma assicurati di scriverli da qualche parte in modo da poterli aggiungere in seguito allo strumento test case.,

#3) Mantieni pronto il tuo banco di prova secondo l’implementazione e se ritieni che ci siano bandiere rosse come una specifica creazione di dati se un banco di prova richiederà tempo (ed è un test importante per il rilascio), quindi alza immediatamente quelle bandiere e informa il tuo manager o PO sul blocco stradale.

Solo perché il client vuole asap, non significa che un QA rilascerà anche se è a metà testato.,

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

#5) Quando il team di sviluppo sta testando alla fine, prova ad accoppiarli (chiamati dev-QA pairing) e fai un round di base sul loro setup stesso, questo aiuterà ad evitare il avanti e indietro della build se l’implementazione di base sta fallendo.,

#6) Ora che hai la build, prova prima le regole aziendali e tutti i casi d’uso. È possibile mantenere test come una convalida di un campo, navigazione, ecc.

#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 si dispone di un requisito per il test delle prestazioni complessive o il test di stress o carico, assicurarsi 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 infatti l’ultimo passo della vostra sanità mentale strategia di test – “Quando il progetto di rilascio e-mail o il documento, parlare di tutti i casi di test eseguiti, il bug trovati con stato marcatore e se nulla è stato lasciato non testati parlare con le ragioni” Prova a scrivere un croccante storia circa la vostra prova, che riuscirà a trasmettere a tutti quello che è stato testato, verificato e ciò che non è stato.

Ho seguito questo religiosamente quando stavo usando questo test.,

Permettetemi di condividere la mia esperienza:

#1) Stavamo lavorando su un sito web e ha usato per gli annunci popup in base alle parole chiave. Gli inserzionisti utilizzati per inserire l’offerta per particolari parole chiave che aveva uno schermo progettato per lo stesso. Il valore di offerta predefinito era mostrato come $0.25, che l’offerente poteva anche cambiare.

C’era un altro posto in cui questa offerta predefinita veniva visualizzata e poteva essere cambiata anche in un altro valore. Il cliente è venuto con una richiesta di modificare il valore predefinito da $0.25 a $0.5 ma ha menzionato solo la schermata ovvia.,

Durante la nostra discussione di brainstorming, abbiamo dimenticato (?) a proposito di questo altro schermo perché non è stato usato molto per questo scopo. Ma durante il test quando ho eseguito il caso base dell’offerta di being 0,5 e controllato da un capo all’altro, ho scoperto che il cronjob per lo stesso stava fallendo perché in un posto stava trovando 0 0,25.

Ho segnalato questo al mio team e abbiamo apportato la modifica e l’abbiamo consegnata con successo lo stesso giorno.

#2) Nell’ambito dello stesso progetto (menzionato sopra), ci è stato chiesto di aggiungere un piccolo campo di testo per note/commenti per l’offerta., È 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 fatto alcuni test di convalida, ho scoperto che quando ho inserito una combinazione di caratteri speciali come</>, la pagina si è bloccata.

Ci abbiamo pensato e abbiamo capito che gli offerenti effettivi non useranno in nessun caso tali combinazioni. Quindi, l’abbiamo rilasciato con una nota ben redatta sul problema., Il cliente lo ha accettato come un bug ma ha concordato con noi di implementarlo in seguito perché era un bug grave ma non precedente.

#3) Recentemente, stavo lavorando a un progetto di app mobile e avevamo l’obbligo di aggiornare il tempo di consegna mostrato nell’app secondo il fuso orario. Non era solo per essere testato in app, ma anche per il servizio web.

Mentre il team di sviluppo stava lavorando 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’articolo di consegna., Questo ha salvato i miei sforzi e abbiamo potuto ottenere risultati migliori in breve tempo.

Test di integrità 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 il sistema operativo e la versione del browser per applicazioni 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.,

Quindi una formulazione di strategia diventa critica quando si esegue questo test su un’app mobile perché un errore può farti finire in grossi guai. Il test deve essere fatto in modo intelligente e con cautela troppo.

Di seguito sono riportati alcuni suggerimenti per aiutarti a eseguire correttamente questo test su una “app mobile”:

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

Prova a trovare risposte a domande come, il comportamento sarà diverso tra le versioni? L’implementazione funzionerà sulla versione supportata più bassa o no?, Ci saranno problemi di prestazioni per l’implementazione delle versioni? Esiste una caratteristica specifica del sistema operativo che potrebbe influire sul comportamento dell’implementazione? ecc.

#2) Nella nota di cui sopra, analizzare per i modelli di telefono anche cioè ci sono caratteristiche del telefono che avrà un impatto l’implementazione? L’implementazione del comportamento cambia con il GPS? Il comportamento di implementazione sta cambiando con la fotocamera del telefono? ecc. Se si scopre che non c’è alcun impatto, evitare di testare su diversi modelli di telefono.,

#3) A meno che non ci siano modifiche all’interfaccia utente per l’implementazione, consiglierei di mantenere il test dell’interfaccia utente sulla priorità minima, puoi informare il team (se vuoi) che l’interfaccia utente non verrà testata.

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

#5) Questo test deve essere fatto in meno tempo, ma assicurati di fare almeno un test sul campo a meno che non si tratti di un semplice cambiamento dell’interfaccia utente.,

#6) Se devi testare una matrice di diversi sistemi operativi e la loro versione, ti suggerirei di farlo in modo intelligente. Per esempio, scegliere il più basso, medio e l’ultima versione del sistema operativo coppie per il test. È possibile menzionare nel documento di rilascio che non tutte le combinazioni sono testate.

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

Misure precauzionali

Il test di sanità mentale viene eseguito quando si è a corto di tempo e quindi non è possibile eseguire ogni caso di test e, soprattutto, non viene dato abbastanza tempo per pianificare il test. Al fine di evitare i giochi di colpa, è meglio prendere misure precauzionali.

In questi casi la mancanza di comunicazione scritta, documentazione di test e miss out sono abbastanza comuni.,

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

• Non accetti mai una build per il test finché non ti viene dato un requisito scritto condiviso dal client. Succede che i clienti comunicano modifiche o nuove implementazioni verbalmente o in chat o un semplice liner 1 in una e-mail e si aspettano che lo trattiamo come un requisito. Obbligare il cliente a fornire alcuni punti di funzionalità di base e criteri di accettazione.
• Fai sempre note approssimative dei tuoi casi di test e bug se non hai abbastanza tempo per scriverli ordinatamente. Non lasciare mai questi senza documenti., Se c’è un po ‘ di tempo, condividilo con il tuo lead o team in modo che se manca qualcosa possano indicarlo facilmente.
• Se tu e il tuo team siete a corto di tempo, assicuratevi che i bug siano contrassegnati nello stato appropriato in una e-mail? Puoi inviare 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 il framework di automazione pronto, usalo ed evita di fare test manuali, in questo modo in meno tempo puoi coprire di più.,
• Evita lo scenario di “rilascio in 1 ora” a meno che tu non sia sicuro al 100% di essere in grado di consegnare.
• Ultimo ma non meno importante, come detto sopra, redigere un’email di rilascio dettagliata che comunichi ciò che viene testato, ciò che viene lasciato fuori, ragioni, rischi, quali bug vengono risolti, cosa sono “Successivamente” ecc.

Come QA, dovresti giudicare qual è la parte più importante dell’implementazione che deve essere testata e quali sono le parti che possono essere lasciate fuori o testate di base.,

Anche in breve tempo, pianificare una strategia su come si vuole fare e sarete in grado di ottenere il meglio nel lasso di tempo dato.

Smoke Testing

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 funzionano correttamente come previsto o meno. Questo è e dovrebbe sempre essere il primo test da eseguire su qualsiasi “nuova” build.,

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 qualsiasi delle implementazioni presenta bug o se una qualsiasi delle funzionalità di lavoro è interrotta.

Alla luce di ciò, in che modo un QA assicurerà che le funzionalità di base funzionino correttamente?

La risposta a questo sarà eseguire un test del fumo.

Una volta che i test sono contrassegnati come test di fumo (nella suite di test) passano, solo allora la build viene accettata dal QA per test approfonditi e / o regressione., Se uno qualsiasi dei test smoke fallisce, la build viene rifiutata e il team di sviluppo deve risolvere il problema e rilasciare una nuova build per il 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 in test di integrazione, test di sistema e test di livello di accettazione. Non trattare mai questo come un sostituto per il test completo end to end effettivo., Comprende test sia positivi che negativi a seconda dell’implementazione della build.

Esempi di test del fumo

Questo test viene normalmente utilizzato per l’integrazione, l’accettazione e il test del sistema.

Nella mia carriera come QA, Ho sempre accettato una build solo dopo aver eseguito un test di fumo. Quindi, capiamo cos’è 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, dovrebbe essere eseguito il test del fumo sotto forma di test di accettazione.,

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

Prendiamo i seguenti esempi come implementazioni fatte in una build per capire i test del fumo per quelli:

• Implementata la funzionalità di accesso per consentire ai driver registrati di accedere con successo.
• Implementata la funzionalità dashboard per mostrare i percorsi che un driver deve eseguire oggi.,
• Implementata la funzionalità per mostrare un messaggio appropriato se non esistono percorsi per un determinato giorno.

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

#2) Test di integrazione

Questo test viene solitamente eseguito quando i singoli moduli vengono implementati e testati., Nel livello di test di integrazione, questo test viene eseguito per assicurarsi che tutte le funzionalità di integrazione di base e 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 route e stops.
• Implementato l’integrazione di aggiornamento dello stato di arrivo e riflettere lo stesso sullo schermo si ferma.,
• Implementato l’integrazione di pick up completo fino ai moduli di funzionalità di consegna.

In questa build, il test smoke 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, per livello di sistema, il test smoke include test per i flussi di lavoro più importanti e comunemente usati del sistema., Questo viene fatto solo dopo che il sistema completo è pronto & testato, e questo test a livello di sistema può essere indicato come test del fumo prima del test di regressione anche.

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

Questo di solito viene fatto con l’aiuto di strumenti di automazione.,

Importanza nella metodologia SCRUM

Al giorno d’oggi, i progetti difficilmente seguono la metodologia Waterfall nell’implementazione del progetto, per lo più tutti i progetti seguono solo Agile e SCRUM. Rispetto al metodo tradizionale a cascata, il test del fumo tiene in alto in SCRUM e Agile.

Ho lavorato per 4 anni in SCRUM. E come sappiamo in SCRUM, gli sprint sono di 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 corrette.,

Di seguito sono riportati alcuni takeaway sull’importanza di questo test in SCRUM:

• Fuori dallo sprint di quindici giorni, l’intervallo è assegnato al QA ma a volte le build al QA sono ritardate.
• Negli sprint, è meglio per la squadra 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 regredito, 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ù basilari prima di iniziare la regressione.

Smoke Test Vs Build Acceptance Test

Il test del fumo è direttamente correlato al test di accettazione Build (BAT).

In BAT, facciamo lo stesso test – per verificare se la build non ha fallito 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 sta fallendo, come puoi come QA accettare la build per il test? Non solo le funzionalità, il sistema stesso deve funzionare prima che il QA proceda con test approfonditi.

Ciclo di prova del fumo

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

Una volta che una build viene distribuita in un QA, il ciclo di base seguito è che se il test smoke passa, 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 deve eseguire il test del fumo?

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

Il test del fumo è idealmente eseguito dal lead QA che decide in base al risultato se passare la build al team per ulteriori test o rifiutarla. O in assenza del piombo, gli stessi QA possono anche eseguire questo test.

A volte, quando il progetto è su larga scala, un gruppo di QA può anche eseguire questo test per verificare la presenza di eventuali showstoppers., Ma questo 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 del fumo?

Questo test è il primo test da eseguire su una build rilasciata dai team di sviluppo. Sulla base dei 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 pianificare l’esecuzione della suite smoke quando viene creata una nuova build. Potresti pensare perché dovrei “automatizzare la suite di test del fumo”?

Diamo un’occhiata al seguente caso:

Diciamo che sei a una settimana dal tuo rilascio e sui 500 casi di test totali, la tua suite di test smoke comprende 80-90. Se inizi a eseguire manualmente tutti questi 80-90 casi di test, immagina quanto tempo impiegherai? Penso 4-5 giorni (minimo).,

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

5 anni fa, stavo testando un’app di proiezione finanziaria, che prendeva input sul tuo stipendio, sui risparmi, ecc., e proiettò le Sue tasse, risparmi, profitti secondo le 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, ho avuto 800 casi di test e 250 erano casi di test di 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 ha salvato il nostro tempo, ma ci ha mostrato al più presto sugli showstoppers.

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 sono identificati in una fase molto precoce.
• Consente di risparmiare sforzi, tempo e denaro.
• Funziona rapidamente se automatizzato.
• Meno rischi e problemi di integrazione.
• Migliora la qualità complessiva del sistema.

Svantaggi:

• Questo test non è uguale o un sostituto per il test funzionale completo.
• Anche dopo il test del fumo passa, si possono trovare bug showstopper.,
• Questo tipo di test è più adatto se è possibile automatizzare altrimenti viene speso 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 essere fatto su ogni build in quanto sottolinea i principali fallimenti e showstoppers in una fase molto precoce. Ciò 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 complesso). Ma prima di questo, il team QA dovrebbe essere molto chiaro su quali test devono essere fatti come test sul fumo. Questo test può ridurre al minimo gli sforzi, risparmiare tempo e migliorare la qualità del sistema. Detiene un posto molto importante negli sprint in quanto il tempo negli sprint è inferiore.

Questo test può essere fatto sia manualmente che anche con l’aiuto di strumenti di automazione. Ma il modo migliore e preferito è quello di utilizzare 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 Test di sanità mentale e test di fumo. Prima di tutto, questi due test sono modo “diverso” ed eseguiti durante le diverse fasi di un ciclo di test.

di Seguito è una rappresentazione schematica delle loro differenze:

PROVA del FUMO

• Questo test nato nel test hardware pratica di attivazione di un nuovo pezzo di hardware per la prima volta e considerando che è un successo, se non prendere il fuoco e il fumo. Nel settore del software, questo test è un approccio superficiale e ampio in cui vengono testate tutte le aree dell’applicazione senza entrare troppo in profondità.,
• Un test di fumo è sceneggiato, utilizzando una serie scritta di test o un test automatico
• Un test di fumo è progettato per toccare ogni parte dell’applicazione in modo superficiale. È poco profondo e largo.
• Questo test è condotto per garantire se le funzioni più cruciali di un programma funzionano, ma non preoccuparsi dei dettagli più fini. (Come la verifica della compilazione).
• Questo test è un normale check-up di salute per la compilazione di un’applicazione prima di prendere per testare in profondità.,

TEST DI SANITÀ MENTALE

• Un test di sanità mentale è un test di regressione ristretta che si concentra su una o poche aree di funzionalità. Test di sanità mentale è di solito 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 di test di regressione.,
• Questo è quello di verificare se i requisiti sono soddisfatti o meno, controllando tutte le caratteristiche ampiezza-prima.