Tipologie di testing software: Il Sanity Test

Tipologie di testing software: Il Sanity Test

Cosa si intende per sanity test?

Sanity Testing è una delle metodologie di test utili che viene eseguita per garantire la correzione di bug rilevati in precedenza e contemporaneamente per assicurarsi che qualsiasi tipo di cambiamento o modifica minore o maggiore introdotto nel codice o nelle funzionalità o nel modulo non porti all’esistenza di alcun nuovo difetto, ovvero l’alterazione prodotta nelle applicazioni software non influisce e influisce sulle funzionalità di base esistenti e sul funzionamento dell’applicazione.

Perché il sanity test è importante?

Lo scopo principale dei sanity test è quello di verificare e convalidare la veridicità delle funzionalità essenziali del software dopo i test di regressione, poiché durante il corso della fase di test di regressione, la correzione di bug o qualsiasi modifica nel codice o modulo potrebbe produrre un impatto o una deviazione nel previsto funzionalità dell’applicazione software. I test di integrità sono test generali di base utilizzati per valutare eventuali nuove funzionalità aggiunte o qualsiasi tipo di modifica prodotta nell’applicazione e per garantire che la loro introduzione o esistenza non influisca sul funzionamento esistente e previsto del prodotto software.

Nei sanity test, il pensiero razionale e le implementazioni logiche degli sviluppatori vengono testati attraverso la loro applicazione sviluppata (build), cioè se lo sviluppatore ha applicato correttamente le razionalità di base durante lo sviluppo delle applicazioni o meno.

Se la compilazione non riesce a eseguire correttamente le funzioni e le operazioni di base e normali, la compilazione viene considerata non idonea per attività di test approfondite e rigorose. Un errore nel sanity test pone la build nell’elenco sospeso delle build software, rimandata per ulteriori test approfonditi e rigorosi fino a quando la build non supera il sanity test. Pertanto, i sanity test sono utili per risparmiare tempo e sforzi del team di test per lavorare su build relativamente instabili.

Tipologie di testing software: Il Sanity Test

Caratteristiche del sanity test

  • A differenza del test del fumo (o Smoke Testing) che viene eseguito sulla build iniziale, il sanity test viene eseguito su build software relativamente stabili.
  • Gate per superare le build del software per superare test più rigorosi.
  • Una o più funzionalità specifiche sono coperte dal sanity test.
  • Il rifiuto di build software difettose consente di risparmiare tempo e sforzi del team QA.
  • Tipo di test di regressione stretto e profondo.
  • È un sottoinsieme dei test di accettazione ed è anche noto come test di accettazione del tester.
  • In genere, i sanity test vengono eseguiti dai tester.
  • casi di test completi non sono coperti da questo test.
  • Il sanity test viene solitamente eseguito manualmente. Tuttavia, l’approccio dell’automazione può essere utilizzato anche per le esecuzioni dei test.
  • Non è richiesta alcuna documentazione e i test sono generalmente privi di script.
  • Si tratta di un tipo di test superficiale che prevede cicli rapidi di test per garantire il funzionamento del software come definito nei requisiti e nelle specifiche.

Approccio al sanity test

Non esiste una regola rigida e veloce per eseguire il processo di esecuzione dei sanity test. Il test di integrità è un processo rapido e veloce per testare l’applicazione in quanto non implica lo scripting dei casi di test. Nel sanity test, vengono considerati e testati principalmente due aspetti o elementi:

  • Bug e problema identificati o rilevati in precedenza sono stati risolti o no?
  • Se l’introduzione di nuove caratteristiche e funzionalità o il processo di correzione di bug e patch hanno influenzato le funzionalità e il funzionamento principali dell’applicazione?

Quindi, i seguenti passaggi in modo sequenziale possono essere considerati ed eseguiti durante i sanity test.

  • Identifica le funzionalità e le caratteristiche appena aggiunte insieme alle modifiche o ai cambiamenti introdotti nel codice durante il processo di correzione dei bug.
  • Valutare queste caratteristiche e modifiche identificate per garantire il loro funzionamento corretto e previsto.
  • Successivamente, possiamo considerare e testare tutti i parametri correlati, le funzionalità associate e gli elementi delle caratteristiche e delle modifiche sopra valutate per assicurarne il funzionamento appropriato e previsto.
  • Se tutto va bene, la build può essere sottoposta a test più approfonditi e faticosi.

Perché sanity test invece di test di regressione?

Il test di regressione non consente ai tester di eseguire attività di test in un tempo minore. Inoltre, aumenta il budget del progetto a causa del suo fabbisogno di più manodopera e tempo per eseguire casi di test completi.

Venendo al sanity test, è fondamentalmente un sottoinsieme di test di regressione. È una sorta di test a livello di superficie che garantisce il funzionamento previsto di funzionalità specifiche del software dopo più regressioni. Offre vantaggi derivanti dall’esecuzione di test in un periodo di tempo limitato. Inoltre, non influisce sul costo del progetto a causa del minore fabbisogno di manodopera e tempo per eseguire un numero limitato di casi di test non completi rispetto ai test di regressione.

Quando andare per il sanity test?

  • Dopo il completamento di un accurato test di regressione.
  • Dopo poche versioni del software o delle sue versioni.

Infine, il sanity test può essere visto come uno strumento di gestione del tempo nel ciclo di vita dello sviluppo del software (SDLC) che fornisce l’accettabilità del software per test più approfonditi e rigorosi in breve tempo in modo da evitare e risparmiare tempo e sforzi preziosi del tester sull’esame della build del software difettoso.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *