STLC - Esecuzione del test
L'esecuzione del test è il processo di esecuzione del codice e confronto dei risultati previsti e effettivi. I seguenti fattori devono essere considerati per un processo di esecuzione del test:
- In base a un rischio, selezionare un sottoinsieme di suite di test da eseguire per questo ciclo.
- Assegna i casi di test in ciascuna suite di test ai tester per l'esecuzione.
- Esegui test, segnala bug e acquisisci lo stato del test continuamente.
- Risolvi i problemi di blocco non appena si presentano.
- Segnala lo stato, modifica le assegnazioni e riconsidera quotidianamente piani e priorità.
- Segnala i risultati e lo stato del ciclo di test.
I seguenti punti devono essere considerati per l'esecuzione del test.
In questa fase, il team QA esegue la convalida effettiva dell'AUT sulla base di casi di test preparati e confronta il risultato graduale con il risultato atteso.
I criteri di ingresso di questa fase sono il completamento del piano di test e la fase di sviluppo dei casi di test, anche i dati dei test dovrebbero essere pronti.
La convalida della configurazione dell'ambiente di test è sempre consigliata tramite test del fumo prima di entrare ufficialmente nell'esecuzione del test.
I criteri di uscita richiedono la convalida positiva di tutti i casi di test; I difetti dovrebbero essere chiusi o differiti; l'esecuzione del test case e il report di riepilogo dei difetti dovrebbero essere pronti.
Attività per l'esecuzione dei test
L'obiettivo di questa fase è la validazione in tempo reale di AUT prima di passare alla produzione / rilascio. Per uscire da questa fase, il team QA esegue diversi tipi di test per garantire la qualità del prodotto. Insieme a questo difetto, anche la segnalazione e la ripetizione del test sono attività cruciali in questa fase. Di seguito sono riportate le attività importanti di questa fase:
Test di integrazione del sistema
La vera validazione del prodotto / AUT inizia qui. System Integration Testing (SIT) è una tecnica di test black box che valuta la conformità del sistema rispetto a requisiti / casi di test preparati.
Il test di integrazione del sistema viene solitamente eseguito su un sottoinsieme di sistema. Il SIT può essere eseguito con un utilizzo minimo di strumenti di test, verificato per le interazioni scambiate e viene anche studiato il comportamento di ogni campo di dati all'interno del singolo livello. Dopo l'integrazione, ci sono tre stati principali del flusso di dati:
- Stato dei dati all'interno del livello di integrazione
- Stato dei dati all'interno del livello del database
- Stato dei dati all'interno del livello dell'applicazione
Note- Nei test SIT, il team QA cerca di trovare il maggior numero possibile di difetti per garantire la qualità. L'obiettivo principale qui è trovare il maggior numero possibile di bug.
Segnalazione dei difetti
Un bug del software si verifica quando il risultato atteso non corrisponde al risultato effettivo. Può essere un errore, un difetto, un guasto o un guasto in un programma per computer. La maggior parte dei bug derivano da errori ed errori commessi da sviluppatori o architetti.
Durante l'esecuzione dei test SIT, il team QA rileva questi tipi di difetti e questi devono essere segnalati ai membri del team interessati. I membri intraprendono ulteriori azioni e correggono i difetti. Un altro vantaggio della segnalazione è che facilita il monitoraggio dello stato dei difetti. Esistono molti strumenti popolari come ALM, QC, JIRA, Version One, Bugzilla che supportano la segnalazione e il monitoraggio dei difetti.
La segnalazione dei difetti è un processo di individuazione dei difetti nell'applicazione sottoposta a test o nel prodotto testando o registrando il feedback dei clienti e creando nuove versioni del prodotto che correggono i difetti in base al feedback del cliente.
Il monitoraggio dei difetti è anche un processo importante nell'ingegneria del software poiché i sistemi complessi e critici per l'azienda hanno centinaia di difetti. Uno dei fattori più impegnativi è gestire, valutare e dare la priorità a questi difetti. Il numero di difetti viene moltiplicato in un periodo di tempo e per gestirli efficacemente, viene utilizzato il sistema di tracciamento dei difetti per rendere il lavoro più facile.
Mappatura dei difetti
Una volta che il difetto è stato segnalato e registrato, dovrebbe essere mappato con i casi di test non riusciti / bloccati interessati e i requisiti corrispondenti nella matrice di tracciabilità dei requisiti. Questa mappatura viene eseguita da Defect Reporter. Aiuta a redigere una corretta segnalazione dei difetti e ad analizzare la malizia del prodotto. Una volta che i casi di test e i requisiti sono stati mappati con il difetto, le parti interessate possono analizzare e prendere una decisione sull'opportunità di correggere / differire il difetto in base alla priorità e alla gravità.
Nuovo test
Il nuovo test esegue un test precedentemente fallito su AUT per verificare se il problema è stato risolto. Dopo che un difetto è stato risolto, viene eseguito un nuovo test per verificare lo scenario nelle stesse condizioni ambientali.
Durante il nuovo test, i tester cercano dettagli granulari nell'area modificata della funzionalità, mentre i test di regressione coprono tutte le funzioni principali per garantire che nessuna funzionalità venga interrotta a causa di questo cambiamento.
Test di regressione
Una volta che tutti i difetti sono in stato chiuso, differito o rifiutato e nessuno dei casi di test è in corso / non riuscito / non eseguito, si può affermare che il test di integrazione del sistema è completamente basato su casi di test e requisiti. Tuttavia, è necessario un ciclo di test rapidi per garantire che nessuna delle funzionalità sia interrotta a causa di modifiche al codice / correzioni di errori.
Il test di regressione è una tecnica di test della scatola nera che consiste nel rieseguire quei test che hanno avuto un impatto a causa delle modifiche al codice. Questi test dovrebbero essere eseguiti il più spesso possibile durante il ciclo di vita dello sviluppo del software.
Tipi di test di regressione
Final Regression Tests- Viene eseguito un "test di regressione finale" per convalidare la build che non ha subito modifiche per un periodo di tempo. Questa build viene distribuita o spedita ai clienti.
Regression Tests - Viene eseguito un normale test di regressione per verificare se la build NON ha rotto altre parti dell'applicazione a causa delle recenti modifiche al codice per la correzione di difetti o per il miglioramento.
Diagramma a blocchi dell'attività
Il seguente diagramma a blocchi mostra le attività importanti svolte in questa fase; mostra anche la dipendenza dalle fasi precedenti -
