Test e garanzia di qualità

Il sistema software deve essere controllato per il comportamento previsto e la direzione del progresso in ogni fase di sviluppo per evitare la duplicazione di sforzi, superamenti di tempo e costi e per garantire il completamento del sistema entro il tempo stabilito. comportamento previsto e direzione del progresso in ogni fase di sviluppo per evitare la duplicazione degli sforzi, il superamento dei tempi e dei costi e per assicurare il completamento del sistema entro il tempo stabilito.

Il test del sistema e la garanzia della qualità vengono in aiuto per il controllo del sistema. Include:

  • Qualità a livello di prodotto (test)
  • Qualità a livello di processo.

Esaminiamoli brevemente:

Test

Il test è il processo o l'attività che controlla la funzionalità e la correttezza del software in base ai requisiti utente specificati al fine di migliorare la qualità e l'affidabilità del sistema. È un approccio costoso, dispendioso in termini di tempo e critico nello sviluppo del sistema che richiede un'adeguata pianificazione del processo di test complessivo.

Un test riuscito è quello che trova gli errori. Esegue il programma con l'intenzione esplicita di trovare errori, ovvero di far fallire il programma. È un processo di valutazione del sistema con l'intenzione di creare un sistema forte e si concentra principalmente sulle aree deboli del sistema o del software.

Caratteristiche del test di sistema

Il test del sistema inizia a livello di modulo e procede verso l'integrazione dell'intero sistema software. Diverse tecniche di test vengono utilizzate in momenti diversi durante il test del sistema. È condotto dallo sviluppatore per piccoli progetti e da gruppi di test indipendenti per grandi progetti.

Fasi del test di sistema

Le seguenti fasi sono coinvolte nel test:

Test Strategy

È una dichiarazione che fornisce informazioni sui vari livelli, metodi, strumenti e tecniche utilizzati per testare il sistema. Dovrebbe soddisfare tutte le esigenze di un'organizzazione.

Test Plan

Fornisce un piano per testare il sistema e verifica che il sistema sottoposto a test soddisfi tutte le specifiche di progettazione e funzionali. Il piano di test fornisce le seguenti informazioni:

  • Obiettivi di ogni fase del test
  • Approcci e strumenti utilizzati per i test
  • Responsabilità e tempo richiesto per ogni attività di test
  • Disponibilità di strumenti, strutture e librerie di test
  • Procedure e standard richiesti per la pianificazione e l'esecuzione dei test
  • Fattori responsabili del completamento con successo del processo di test

Test Case Design

  • Per ogni modulo del sistema da testare viene identificato un certo numero di casi di test.

  • Ciascun caso di test specificherà come deve essere testata l'implementazione di un particolare requisito o decisione di progettazione ei criteri per il successo del test.

  • I casi di test insieme al piano di test sono documentati come parte di un documento di specifica del sistema o in un documento separato chiamato test specification o test description.

Test Procedures

Consiste nei passaggi da seguire per eseguire ciascuno dei casi di test. Queste procedure sono specificate in un documento separato chiamato specifica della procedura di test. Questo documento specifica anche eventuali requisiti e formati speciali per la comunicazione del risultato del test.

Test Result Documentation

Il file dei risultati del test contiene brevi informazioni sul numero totale di casi di test eseguiti, il numero di errori e la natura degli errori. Questi risultati vengono quindi valutati rispetto ai criteri nella specifica del test per determinare il risultato complessivo del test.

Tipi di test

I test possono essere di vari tipi e diversi tipi di test vengono condotti a seconda del tipo di bug che si cerca di scoprire -

Test unitario

Conosciuto anche come test di programma, è un tipo di test in cui l'analista verifica o si concentra su ciascun programma o modulo in modo indipendente. Viene eseguito con l'intenzione di eseguire almeno una volta ogni istruzione del modulo.

  • Nel test unitario, non è possibile garantire l'accuratezza del programma ed è difficile condurre in dettaglio i test di varie combinazioni di input.

  • Identifica gli errori massimi in un programma rispetto ad altre tecniche di test.

Test d'integrazione

In Integration Testing, l'analista testa più moduli che lavorano insieme. Viene utilizzato per trovare discrepanze tra il sistema e il suo obiettivo originale, le specifiche attuali e la documentazione del sistema.

  • Qui gli analisti cercano di trovare aree in cui i moduli sono stati progettati con specifiche diverse per lunghezza dati, tipo e nome elemento dati.

  • Verifica che le dimensioni dei file siano adeguate e che gli indici siano stati creati correttamente.

Test funzionali

Il test funzionale determina se il sistema funziona correttamente secondo le sue specifiche e la relativa documentazione degli standard. Il test funzionale inizia tipicamente con l'implementazione del sistema, che è molto critico per il successo del sistema.

Il test funzionale è diviso in due categorie:

  • Positive Functional Testing - Si tratta di testare il sistema con input validi per verificare che gli output prodotti siano corretti.

  • Negative Functional Testing - Si tratta di testare il software con input non validi e condizioni operative indesiderate.

Regole per il test del sistema

Per eseguire correttamente il test del sistema, è necessario seguire le regole fornite:

  • Il test dovrebbe essere basato sui requisiti dell'utente.

  • Prima di scrivere script di test, è necessario comprendere a fondo la logica aziendale.

  • Il piano di test dovrebbe essere fatto il prima possibile.

  • Il test dovrebbe essere eseguito da terze parti.

  • Dovrebbe essere eseguito su software statico.

  • Il test deve essere eseguito per condizioni di input valide e non valide.

  • I test dovrebbero essere riesaminati ed esaminati per ridurre i costi.

  • Sia i test statici che quelli dinamici dovrebbero essere condotti sul software.

  • Deve essere eseguita la documentazione dei casi di test e dei risultati dei test.

Garanzia di qualità

È la revisione del sistema o dei prodotti software e la relativa documentazione per garantire che il sistema soddisfi i requisiti e le specifiche.

  • Scopo del controllo qualità è fornire fiducia ai clienti attraverso la consegna costante del prodotto secondo le specifiche.

  • Il Software Quality Assurance (SQA) è una tecnica che include procedure e strumenti applicati dai professionisti del software per garantire che il software soddisfi lo standard specificato per l'uso e le prestazioni previsti.

  • L'obiettivo principale di SQA è fornire all'amministrazione una corretta e accurata visibilità del progetto software e del prodotto sviluppato.

  • Esamina e controlla il prodotto software e le sue attività durante il ciclo di vita dello sviluppo del sistema.

Obiettivi della garanzia di qualità

Gli obiettivi della conduzione della garanzia di qualità sono i seguenti:

  • Monitorare il processo di sviluppo del software e il software finale sviluppato.

  • Per garantire se il progetto software sta implementando gli standard e le procedure stabilite dalla direzione.

  • Informare gruppi e individui sulle attività SQA e sui risultati di queste attività.

  • Per garantire che i problemi, che non vengono risolti all'interno del software, vengano affrontati dal management superiore.

  • Per identificare le carenze nel prodotto, nel processo o negli standard e risolverle.

Livelli di garanzia della qualità

Esistono diversi livelli di QA e test che devono essere eseguiti per certificare un prodotto software.

Level 1 − Code Walk-through

A questo livello, il software offline viene esaminato o verificato per eventuali violazioni delle regole di codifica ufficiali. In generale, l'accento è posto sull'esame della documentazione e sul livello dei commenti nel codice.

Level 2 − Compilation and Linking

A questo livello, viene verificato che il software possa compilare e collegare tutte le piattaforme ei sistemi operativi ufficiali.

Level 3 − Routine Running

A questo livello, viene verificato che il software possa funzionare correttamente in una varietà di condizioni come un certo numero di eventi e dimensioni di eventi piccoli e grandi, ecc.

Level 4 − Performance test

A questo livello finale, viene verificato che le prestazioni del software soddisfino il livello di prestazioni specificato in precedenza.