STLC - Guida rapida
STLC è l'acronimo di Software Testing Life Cycle. STLC è una sequenza di diverse attività eseguite dal team di test per garantire la qualità del software o del prodotto.
STLC è parte integrante del ciclo di vita dello sviluppo software (SDLC). Ma STLC si occupa solo delle fasi di test.
STLC inizia non appena i requisiti vengono definiti o l'SRD (Software Requirement Document) viene condiviso dagli stakeholder.
STLC fornisce un processo graduale per garantire la qualità del software.
Nella fase iniziale di STLC, durante lo sviluppo del software o del prodotto, il tester può analizzare e definire l'ambito del test, i criteri di ingresso e di uscita e anche i casi di test. Aiuta a ridurre il tempo del ciclo di prova insieme a una migliore qualità.
Non appena la fase di sviluppo è terminata, i tester sono pronti con i casi di test e iniziano con l'esecuzione. Questo aiuta a trovare bug nella fase iniziale.
Fasi STLC
STLC ha le seguenti diverse fasi ma non è obbligatorio seguire tutte le fasi. Le fasi dipendono dalla natura del software o del prodotto, dal tempo e dalle risorse allocate per il test e dal modello di SDLC che deve essere seguito.
Ci sono 6 fasi principali di STLC:
Requirement Analysis - Quando l'SRD è pronto e condiviso con gli stakeholder, il team di test avvia l'analisi di alto livello riguardante l'AUT (Application under Test).
Test Planning - Test Team pianifica la strategia e l'approccio.
Test Case Designing - Sviluppa i casi di test in base all'ambito e ai criteri.
Test Environment Setup - Quando l'ambiente integrato è pronto per convalidare il prodotto.
Test Execution - Convalida in tempo reale del prodotto e ricerca di bug.
Test Closure - Una volta completato il test, la matrice, i report ei risultati vengono documentati.
In questo capitolo capiremo i fattori di confronto tra STLC e SDLC. Consideriamo i seguenti punti e quindi confrontiamo STLC e SDLC.
STLC fa parte di SDLC. Si può dire che STLC è un sottoinsieme del set SDLC.
STLC è limitato alla fase di test in cui la qualità del software o del prodotto garantisce. SDLC ha un ruolo vasto e vitale nello sviluppo completo di un software o di un prodotto.
Tuttavia, STLC è una fase molto importante di SDLC e il prodotto finale o il software non può essere rilasciato senza passare attraverso il processo STLC.
STLC fa anche parte del ciclo post-rilascio / aggiornamento, la fase di manutenzione di SDLC in cui i difetti noti vengono corretti o viene aggiunta una nuova funzionalità al software.
La tabella seguente elenca i fattori di confronto tra SDLC e STLC in base alle loro fasi:
| Fase | SDLC | STLC |
|---|---|---|
| Raccolta dei requisiti |
|
|
| Design |
|
|
| Sviluppo |
|
|
| Configurazione dell'ambiente |
|
|
| Test |
|
|
| Distribuzione / rilascio del prodotto |
|
|
| Manutenzione |
|
|
L'obiettivo comune del test è trovare i bug il prima possibile. E, una volta risolti i bug, assicurati che funzioni come previsto e non rompa altre funzionalità.
Per raggiungere questi obiettivi, vengono forniti sette principi di base per il test del software:
Cosa mostra il test?
I test possono dimostrare che sono presenti difetti ma non c'è modo di dimostrare che non ci siano difetti nel prodotto. Le fasi di test assicurano che l'applicazione sottoposta a test funzioni in base al requisito specificato e aiuta a ridurre la probabilità di difetti non rilevati nell'applicazione. Ma, anche se non vengono rilevati difetti, non significa che sia assolutamente corretto. Possiamo presumere che AUT corrisponda ai nostri criteri di uscita e mantenga i requisiti secondo SRD.
È possibile eseguire test esaustivi?
La copertura o il test del 100% di tutte le combinazioni di input e possibili combinazioni non sono possibili tranne che in casi banali. Invece di test esaustivi, l'analisi del rischio e le priorità vengono utilizzate per definire l'ambito del test. Qui, la maggior parte degli scenari in tempo reale può considerare di includere anche lo scenario negativo più probabile. Questo ci aiuterà a rintracciare l'errore.
Test precoci
Le attività di test dovrebbero iniziare il prima possibile e concentrarsi su obiettivi definiti nella Strategia di test e sui risultati attesi. La fase iniziale del test aiuta a identificare i difetti dei requisiti o le discrepanze a livello di progettazione. Se questi tipi di bug vengono rilevati nella fase iniziale, ci aiuta a risparmiare tempo ed è anche conveniente. La risposta al motivo per cui il test dovrebbe iniziare in una fase iniziale è molto semplice: non appena viene ricevuto l'SRD, i tester possono analizzare il requisito dal punto di vista del test e possono notare una discrepanza tra i requisiti.
Difetto di clustering
Sulla base della precedente analisi dei difetti del prodotto, si può affermare che la maggior parte dei difetti vengono identificati da un piccolo insieme di moduli che sono critici per l'applicazione. Questi moduli possono essere identificati in base alla complessità, alla diversa interazione del sistema o alla dipendenza da diversi altri moduli. Se i tester possono identificare questi moduli cruciali, possono concentrarsi maggiormente su questi moduli per identificare tutti i possibili bug. In uno studio, si è riscontrato che 8 difetti su 10 sono identificati dal 20% della funzionalità di AUT.
Paradosso dei pesticidi
Cos'è il paradosso dei pesticidi - se i pesticidi sono usati frequentemente sulle colture, arriva quando gli insetti sviluppano un certo tipo di resistenza e gradualmente i pesticidi così spruzzati sembrano essere inefficaci sugli insetti.
Lo stesso concetto è applicabile anche ai test. Qui, gli insetti sono insetti mentre i pesticidi sono casi di test che vengono utilizzati per funzionare ancora e ancora. Se gli stessi set di casi di test vengono eseguiti ripetutamente, questi casi di test diventano inefficaci dopo un certo periodo di tempo e i tester non saranno in grado di identificare alcun nuovo difetto.
Per superare queste condizioni, i casi di test dovrebbero essere rivisti e riesaminati di volta in volta e possono essere aggiunti nuovi e diversi casi di test. Questo aiuterà a identificare nuovi difetti.
Il test dipende dal contesto
Questo principio afferma che due diversi tipi di applicazione non possono essere testati utilizzando lo stesso approccio fino a quando entrambe le applicazioni non sono della stessa natura. Ad esempio, se un tester utilizza lo stesso approccio per l'applicazione basata sul Web e l'applicazione mobile, ciò è completamente sbagliato e vi è un alto rischio di scarsa qualità del rilascio del prodotto. I tester dovrebbero utilizzare approcci, metodologie, tecniche e copertura differenti per diversi tipi e natura di applicazioni.
Assenza di errore - Fallacia
Questo principio afferma la ricerca di difetti e la loro correzione fino a quando l'applicazione o il sistema non è stabile, richiede tempo e consuma anche le risorse. Anche dopo aver riparato il 99% dei difetti, c'è un alto rischio di applicazione instabile. La prima cosa essenziale è verificare la stabilità dell'applicazione e i prerequisiti dell'ambiente. Se queste due condizioni soddisfano, solo allora possiamo iniziare con il test dettagliato.
L'analisi dei requisiti è la prima fase di STLC e inizia non appena l'SRD / SRS viene condiviso con il team di test. Consideriamo i seguenti punti per comprendere l'analisi dei requisiti in STLC.
Il criterio di ingresso di questa fase è la fornitura di SRS (Software Requirement Specification); si consiglia inoltre di tenere a portata di mano l'architettura dell'applicazione.
In questa fase, il team QA analizza a un livello superiore cosa testare e come testare.
Il team QA segue i vari stakeholder come Business Analyst, System Architecture, Client, Test Manager / Lead nel caso in cui siano necessarie domande o chiarimenti per comprendere il requisito.
I requisiti possono essere funzionali o non funzionali come prestazioni, sicurezza, usabilità, ecc. O entrambi funzionali e non funzionali.
Il criterio di uscita da questa fase consiste nel completare il documento RTM, il rapporto di fattibilità dell'automazione e un elenco di domande, se applicabile, per essere più specifici sui requisiti.
Attività eseguite per l'analisi dei requisiti
Ci sono tre attività principali che vengono eseguite dal team QA in questa fase. Le attività sono state descritte di seguito.
Definizione dell'ambito
Il team QA identifica l'ambito del test ad alti livelli e si divide in vari moduli funzionali. Il team identifica anche i tipi di test richiesti per eseguire: test del fumo, test di integrità, test funzionali, test di regressione, ecc. Il team QA analizza i prerequisiti ei dettagli dell'ambiente in cui si suppone che i test vengano eseguiti. Il team raccoglie dettagli sulle priorità dei test e si concentra sulla sequenza di moduli da convalidare. Identifica anche i difetti dei requisiti se i moduli sono contraddetti e la funzionalità non viene trasferita insieme ad altri moduli.
Prepara RTM
Il tracciamento dei requisiti è un processo di documentazione dei collegamenti tra i requisiti e i prodotti di lavoro sviluppati per implementare e verificare tali requisiti. L'RTM acquisisce tutti i requisiti dell'analisi dei requisiti insieme alla loro tracciabilità in un unico documento. Tutto questo viene consegnato alla conclusione del ciclo di vita.
La matrice viene creata all'inizio di un progetto in quanto costituisce la base dell'ambito del progetto e dei risultati finali che verranno prodotti.
Matrix è bidirezionale, poiché tiene traccia del requisito in avanti esaminando l'output dei risultati finali e all'indietro esaminando il requisito aziendale specificato per una particolare caratteristica del prodotto.
Analisi dell'automazione
Nella fase dei requisiti, il team QA analizza l'ambito dell'automazione per i test di regressione. Se si aggiunge l'automazione all'ambito, il team decide quale strumento può essere utilizzato, quali funzionalità saranno coperte come automazione, l'intervallo di tempo e l'allocazione delle risorse coinvolte per lo sviluppo dell'automazione. Una volta completata questa analisi, il team QA fornisce il rapporto di fattibilità dell'automazione a diverse parti interessate per fornire l'approvazione.
In questo capitolo vedremo i criteri di ingresso e di uscita a diversi livelli in STLC. I seguenti punti devono essere considerati per comprendere i criteri.
Idealmente, il team QA non procede con la fase successiva fino a quando non vengono soddisfatti i criteri di uscita della fase corrente. I criteri di ingresso dovrebbero includere il completamento dei criteri di uscita della fase precedente.
In tempo reale, non è possibile attendere la fase successiva fino al raggiungimento dei criteri di uscita. Ora, la fase successiva può essere avviata se i deliverable critici della fase precedente sono stati completati.
In ogni fase di STLC, dovrebbero essere definiti i criteri di ingresso e di uscita.
Criteri di ingresso
I criteri di ingresso per le fasi STLC possono essere definiti come condizioni specifiche; oppure, tutti quei documenti che sono richiesti per avviare una particolare fase di STLC dovrebbero essere presenti prima di entrare in qualsiasi fase STLC.
I criteri di accesso sono un insieme di condizioni che consentono l'esecuzione di un'attività o, in assenza di una di queste condizioni, l'attività non può essere eseguita.
Durante l'impostazione dei criteri di immissione, è anche importante definire l'intervallo di tempo in cui l'elemento dei criteri di immissione è disponibile per avviare il processo.
Ad esempio, per avviare la fase di sviluppo dei test case, devono essere soddisfatte le seguenti condizioni:
- Il documento del requisito dovrebbe essere disponibile.
- È richiesta una comprensione completa del flusso dell'applicazione.
- Il documento del piano di test dovrebbe essere pronto.
Criteri di uscita
I criteri di uscita per le fasi STLC possono essere definiti come elementi / documenti / azioni / attività che devono essere completati prima di concludere la fase corrente e passare alla fase successiva.
I criteri di uscita sono un insieme di aspettative; questo dovrebbe essere soddisfatto prima di concludere la fase STLC.
Ad esempio, per concludere la fase di sviluppo dei test case, dovrebbero essere soddisfatte le seguenti aspettative:
- I casi di test dovrebbero essere scritti e rivisti.
- I dati del test dovrebbero essere identificati e pronti.
- Lo script di automazione del test dovrebbe essere pronto se applicabile.
Per criteri di accettazione si intende il comportamento previsto di una funzionalità, un modulo e un'applicazione come elencato nei documenti dei requisiti. Sono fasi / punti di controllo di verifica per determinare se il sistema software ha soddisfatto o meno le specifiche dei requisiti. Lo scopo principale di questo test è valutare la conformità del sistema ai requisiti aziendali e verificare se ha soddisfatto i criteri richiesti.
I criteri di accettazione sono un insieme di affermazioni che menzionano chiaramente il risultato superato / non superato previsto. I criteri di accettazione specificano i requisiti sia funzionali che non funzionali. Questi requisiti rappresentano "condizioni di soddisfazione o comportamento previsto". Non c'è accettazione parziale; o un criterio è soddisfatto o non è soddisfatto.
Questi criteri definiscono i confini ei parametri di una funzionalità / modulo e determinano se la funzionalità / modulo è completata e funziona come previsto.
I criteri di accettazione di alto livello sono menzionati a livello del piano di test. I criteri di accettazione vengono convertiti in un elenco di punti da verificare o risultati attesi a livello di casi di test.
I criteri di accettazione sono definiti sulla base dei seguenti attributi:
- Correttezza e completezza funzionali
- Integrità dei dati
- Conversione dei dati
- Usability
- Performance
- Timeliness
- Riservatezza e disponibilità
- Capacità di installazione e aggiornamento
- Scalability
- Documentation
Un piano di test delinea la strategia che verrà utilizzata per testare un'applicazione, le risorse che verranno utilizzate, l'ambiente di test in cui verranno eseguiti i test, i limiti del test e la pianificazione delle attività di test. In genere, il responsabile del team di garanzia della qualità sarà responsabile della scrittura di un piano di test.
Cosa include un piano di test?
Un piano di test include quanto segue.
- Introduzione al documento Piano di prova.
- Presupposti durante il test dell'applicazione.
- Elenco dei casi di test inclusi nel test dell'applicazione.
- Elenco delle caratteristiche da testare.
- Il tipo di approccio da utilizzare durante il test del software.
- Elenco dei risultati che devono essere testati.
- Le risorse assegnate per testare l'applicazione.
- Eventuali rischi coinvolti durante il processo di test.
- Un programma di attività e traguardi da raggiungere.
Punti importanti per la pianificazione dei test
I seguenti punti devono essere considerati per la pianificazione dei test in STLC.
Idealmente, l'Analista del Test (Lead) / il Manager prepara la Strategia di Test / Documento Piano di Test.
L'analisi è più focalizzata sui dati / informazioni relativi all'applicazione.
È la prima fase delle attività di test effettive.
Questa fase risponde “CHE COSA deve essere testato” e “QUALI RISORSE devono essere testate”.
Il criterio di immissione di base di questa fase è la fornitura di documenti dei requisiti (versione aggiornata dei requisiti non chiari / mancanti / chiariti) insieme alla matrice di tracciabilità dei requisiti.
Se l'automazione rientra nell'ambito, è necessario preparare il report di fattibilità dell'automazione prima di entrare in questa fase.
Il criterio di uscita da questa fase è il completamento del documento di strategia / piano di test e del documento di stima dello sforzo di test.
Aspetti della fase di pianificazione del test
L'obiettivo principale di questa fase è preparare un documento Piano / Strategia di test. Comprende tre aspetti principali: portata dei risultati finali, stima degli sforzi e piano delle risorse.
Scopo dei risultati
Le seguenti attività devono essere eseguite per concludere sull'ambito dei risultati finali:
- Identificare un modello di coinvolgimento e di consegna adeguato.
- Definire obiettivi di test, ambito di test, fasi e attività di test.
- Esaminare i requisiti aziendali e i requisiti di sistema per identificare la fattibilità del test.
- Definire il processo di test, il tipo di test e le procedure.
- Definire la gestione dei difetti e le procedure di gestione del cambiamento.
- Identificare strumenti, tecniche e best practice di test.
- Definizione dell'analisi dei rischi.
- Definire la soluzione di automazione e identificare i candidati idonei per l'automazione, se applicabile.
Stima dello sforzo
La stima è il processo di ricerca di una stima, o approssimazione, che è un valore che può essere utilizzato per uno scopo anche se i dati di input possono essere incompleti, incerti o instabili.
La stima determina quanti soldi, impegno, risorse e tempo occorreranno per costruire un sistema o un prodotto specifico. La stima si basa su -
- Dati passati / Esperienza passata
- Documenti / conoscenze disponibili
- Assumptions
- Rischi identificati
I quattro passaggi fondamentali nel test della stima sono:
- Stima della dimensione dell'AUT (Application Under Test).
- Stima dello sforzo in mesi-persona o ore-persona.
- Stima della pianificazione in mesi di calendario.
- Stima del costo del progetto nella valuta concordata.
Piano delle risorse
I piani delle risorse sono l'elemento chiave nelle fasi di test. Questi piani sono inversamente proporzionali al tempo impiegato dal team di test per completare una particolare attività. L'aumento del numero di risorse diminuirà il numero di giorni di completamento per un certo limite, dopodiché sarà saturato e l'aumento della risorsa non avrà molto impatto e potrebbe non portare a una diminuzione dei giorni di completamento.
Un Resource Requester, di solito un project manager, crea piani per le risorse per chiedere risorse, tenere traccia degli sforzi e dei costi. Un responsabile delle risorse può modificare e approvare i piani delle risorse prima che i piani vengano utilizzati.
Il normale flusso di lavoro per un piano delle risorse è:
- Pianificazione da Project Manager
- Richiesta sollevata dal Project Manager
- Approva / Modifica / Rifiuta da Resource Manager
- Completo: chiusura della richiesta dopo la disconnessione da Resource Manager
Una volta che il piano di test è pronto, il team QA avvia lo sviluppo dei casi di test. L'obiettivo principale di questa fase è preparare i casi di test per una singola unità. Questi casi di test funzionali e strutturali coprono la funzionalità, i punti di verifica e convalida menzionati nel Piano di test.
I seguenti punti devono essere considerati per lo sviluppo del test case in STLC.
In questa fase, il team QA scrive il test case con un approccio graduale. Lo scenario di test viene quindi firmato da un analista aziendale dopo aver esaminato o rielaborato gli scenari di test nel caso in cui siano necessarie modifiche.
Una volta che i casi di test sono pronti, il team QA prepara i dati di test in base alle precondizioni.
Il criterio di ingresso di questa fase è che le attività nella pianificazione dei test dovrebbero essere terminate e il piano dei test dovrebbe essere pronto.
Il criterio di uscita da questa fase è che i casi di test dovrebbero essere firmati, i dati di test dovrebbero essere pronti e gli script di test preparati se l'automazione è nell'ambito.
I casi di test dovrebbero essere mappati con la matrice di tracciabilità dei requisiti per monitorare la copertura dei requisiti se manca qualcosa.
Attività nella fase di sviluppo del test case
Di seguito sono riportate le tre attività che vengono svolte nella fase di Sviluppo del Test Case:
Identificazione degli scenari di test
Gli scenari facilitano il test e la valutazione di un sistema complesso. Le seguenti strategie aiutano a creare buoni scenari:
Enumerare i possibili utenti, le loro azioni e obiettivi.
Valuta gli utenti con mentalità da hacker ed elenca i possibili scenari di abuso del sistema.
Elenca gli eventi di sistema e in che modo il sistema gestisce tali richieste.
Elenca i vantaggi e crea attività end-to-end per verificarli.
Informazioni su sistemi simili e sul loro comportamento.
Studio dei reclami sui prodotti della concorrenza e sul loro predecessore.
Scrittura di casi di test
Un test case è un documento, che include dati di test, condizioni preliminari, risultati attesi e condizioni post, sviluppato per un particolare scenario di test al fine di verificare la conformità rispetto a un requisito specifico.
Test Case funge da punto di partenza per l'esecuzione del test. Dopo che viene applicato un insieme di valori di input; l'applicazione ha un esito definitivo e lascia il sistema in un punto finale noto anche come condizione post di esecuzione.
Preparazione dei dati di prova
I dati di test vengono utilizzati per eseguire i test su test ware. I dati dei test devono essere precisi ed esaustivi per scoprire i difetti. Per raggiungere questi tre obiettivi, è seguito da un approccio graduale come indicato di seguito:
- Identificare risorse o requisiti di test
- Identificare le condizioni / funzionalità da testare
- Impostare le condizioni di test di priorità
- Seleziona le condizioni per il test
- Determinare il risultato atteso dell'elaborazione dei casi di test
- Crea casi di test
- Documentare le condizioni di prova
- Eseguire il test
- Verifica e correggi i casi di test in base alle modifiche
Diagramma a blocchi dell'attività
Il diagramma seguente mostra le diverse attività che fanno parte dello sviluppo del test case.
L'ambiente di test è costituito da elementi che supportano l'esecuzione di test con software, hardware e rete configurati. La configurazione dell'ambiente di test deve imitare l'ambiente di produzione al fine di scoprire eventuali problemi relativi all'ambiente / alla configurazione.
I seguenti punti devono essere considerati in una configurazione dell'ambiente di test.
È una combinazione di ambiente hardware e software su cui verranno eseguiti i test.
Comprende configurazione hardware, impostazioni del sistema operativo, configurazione software, terminali di test e altro supporto per eseguire il test.
È l'aspetto più cruciale del processo di test. L'indisponibilità o la configurazione errata dell'ambiente possono rovinare tutti gli sforzi di test.
In pratica, il team di QA non può iniziare il lavoro effettivo senza avere l'ambiente giusto per il test.
È un'attività indipendente e può essere avviata insieme allo sviluppo di casi di test.
Più genericamente, questa attività viene eseguita dagli sviluppatori negli aspetti tecnici mentre le condizioni dei requisiti possono essere svolte dai clienti / analisti aziendali.
La prontezza dell'ambiente di prova può essere convalidata mediante test del fumo ed eseguita dal team di controllo qualità.
Idealmente, possiamo dire che i criteri di ingresso di questa fase sono la fornitura del piano di test, la disponibilità dei casi di Smoke Test e la preparazione dei dati dei test.
Il criterio di uscita da questa fase è che l'ambiente di test dovrebbe essere pronto e il test del fumo dovrebbe essere eseguito con successo con i risultati attesi.
Attività eseguite per la configurazione dell'ambiente di test
In questa fase vengono eseguite le seguenti attività.
Ambiente di test di progettazione
I seguenti fattori giocano un ruolo importante per la progettazione di un ambiente di test.
Determina se l'ambiente di test necessita di archiviazione per poter eseguire i backup.
Verifica la configurazione di rete.
Identificare il sistema operativo del server, i database e altri componenti richiesti.
Identificare il numero di licenza richiesta dal team di test.
Configurazione dell'ambiente
Analizza i requisiti di configurazione dell'ambiente e prepara un elenco di requisiti software e hardware per la configurazione. Ottieni la conferma ufficiale per la configurazione dell'ambiente di test e configura per accedere all'ambiente di test.
Test del fumo
Una volta che l'ambiente è impostato e il team QA ha accesso ad esso, è necessario eseguire un rapido ciclo di test del fumo per la convalida della stabilità della build dell'ambiente di test. Se i risultati sono quelli previsti, il team QA può passare alla fase successiva, altrimenti segnalare le discrepanze e attendere la distribuzione dopo le correzioni.
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 -
Defect Life Cycle, noto anche come Bug Life Cycle, è il viaggio di un difetto, il ciclo che un difetto attraversa durante la sua vita. Varia da organizzazione a organizzazione e anche da progetto a progetto, poiché è regolato dal processo di test del software e dipende anche dagli strumenti utilizzati.
Ciclo di vita dei difetti - Flusso di lavoro
Il diagramma seguente mostra il flusso di lavoro di un ciclo di vita del difetto.
Stati di un ciclo di vita del difetto
Di seguito sono riportati i diversi stati di un ciclo di vita del difetto.
New - Potenziale difetto sollevato e ancora da convalidare.
Assigned - Assegnato contro un team di sviluppo da affrontare.
Active- Il difetto è stato risolto dallo sviluppatore e l'indagine è in corso. In questa fase, ci sono due possibili risultati: differito o rifiutato.
Test / Fixed / Ready for Retest - Il difetto è corretto e pronto per il test.
Verified - Il difetto che viene ritestato e il test è stato verificato dal QA.
Closed - Lo stato finale del difetto che può essere chiuso dopo la ripetizione del controllo qualità o può essere chiuso se il difetto è duplicato o considerato NON un difetto.
Reopened - Quando il difetto NON viene risolto, QA riapre / riattiva il difetto.
Deferred - Quando un difetto non può essere risolto in quel particolare ciclo, viene rimandato al rilascio futuro.
Rejected - Un difetto può essere rifiutato per uno dei tre motivi: difetto duplicato, NON difetto, non riproducibile.
I difetti sono classificati dal punto di vista del team QA come Priority e dal punto di vista dello sviluppo come Severity(complessità del codice per risolverlo). Queste sono due classificazioni principali che svolgono un ruolo importante nel lasso di tempo e nella quantità di lavoro necessaria per correggere i difetti.
Cos'è la priorità?
La priorità è definita come l'ordine in cui i difetti devono essere risolti. Lo stato di priorità viene solitamente impostato dal team QA mentre solleva il difetto contro il team di sviluppo menzionando il periodo di tempo per correggere il difetto. Lo stato di priorità viene impostato in base ai requisiti degli utenti finali.
Ad esempio, se il logo dell'azienda è posizionato in modo errato nella pagina Web dell'azienda, la priorità è alta ma di bassa gravità.
Elenco delle priorità
Una priorità può essere classificata nei seguenti modi:
Low - Questo difetto può essere risolto dopo che quelli critici sono stati corretti.
Medium - Il difetto dovrebbe essere risolto nelle build successive.
High - Il difetto deve essere risolto immediatamente perché il difetto influisce notevolmente sull'applicazione e i relativi moduli non possono essere utilizzati fino a quando non viene risolto.
Urgent - Il difetto deve essere risolto immediatamente perché il difetto pregiudica gravemente l'applicazione o il prodotto e il prodotto non può essere utilizzato fino a quando non è stato risolto.
Cos'è la gravità?
La gravità è definita come la malvagità del difetto sull'applicazione e la complessità del codice per risolverlo dal punto di vista dello sviluppo. Itè correlato all'aspetto di sviluppo del prodotto. La gravità può essere decisa in base a quanto grave / cruciale è il difetto del sistema. Lo stato di gravità può dare un'idea della deviazione nella funzionalità dovuta al difetto.
Example - Per il sito web di volo, il difetto nella generazione del numero del biglietto contro la prenotazione è di alta gravità e anche di alta priorità.
Elenco di gravità
La gravità può essere classificata nei seguenti modi:
Critical /Severity 1- Il difetto influisce sulla funzionalità più cruciale dell'applicazione e il team di controllo qualità non può continuare con la convalida dell'applicazione sotto test senza risolverlo. Ad esempio, app / prodotto si bloccano frequentemente.
Major / Severity 2- Il difetto influisce su un modulo funzionale; il team QA non può testare quel particolare modulo ma continuare con la convalida di altri moduli. Ad esempio, la prenotazione del volo non funziona.
Medium / Severity 3- Il difetto presenta un problema con la schermata singola o relativo a una singola funzione, ma il sistema funziona ancora. Il difetto qui non blocca alcuna funzionalità. Ad esempio, Ticket # è una rappresentazione che non segue i caratteri alfanumerici corretti come i primi cinque caratteri e gli ultimi cinque come numerici.
Low / Severity 4- Non influisce sulla funzionalità. Può essere un difetto estetico, incoerenza dell'interfaccia utente per un campo o un suggerimento per migliorare l'esperienza dell'utente finale dal lato dell'interfaccia utente. Ad esempio, il colore di sfondo del pulsante Invia non corrisponde a quello del pulsante Salva.
Un controllo rispetto ai criteri di uscita dal test è molto essenziale per affermare che il test è ora completo. Prima di porre fine al processo di test, la qualità del prodotto viene misurata rispetto ai criteri di completamento del test.
Il criterio di ingresso di questa fase è che l'esecuzione del test case sia completa, i risultati dei test siano disponibili e il report dei difetti sia pronto.
I criteri per il completamento del test includono quanto segue:
- La copertura specificata è stata raggiunta.
- No showstoppers o difetti critici
- Ci sono pochissimi difetti noti a priorità media o bassa. Questi non influiscono sull'utilizzo del prodotto.
Il criterio di uscita da questa fase è la fornitura di rapporti di chiusura del test e la preparazione di matrici che vengono successivamente firmate dal cliente.
Parliamo ora di activities involved in the closure of Test Cycle.
Rapporto di completamento del test
Il report di completamento del test è un processo, in base al quale le metriche del test vengono riportate in formato riepilogativo per aggiornare gli stakeholder. Ciò consente loro di prendere una decisione informata.
Il rapporto di completamento del test contiene le seguenti informazioni.
- Identificatore del rapporto di riepilogo del test
- Summary
- Variances
- Risultati riepilogativi
- Evaluation
- Sforzi pianificati vs effettivi
- cancella la sottoscrizione
Un buon rapporto di completamento del test indica la qualità, misura i rischi in sospeso e identifica il livello di un software testato.
Matrice di completamento del test
Al termine del test, vengono raccolte varie matrici per preparare i rapporti di prova. I criteri per la redazione delle relazioni includono quanto segue:
- Numero di test eseguiti
- Numero di test superati
- Numero di test non riusciti
- Numero di test non riusciti in base a ciascun modulo
- Numero di difetti di test rilevati durante il ciclo di esecuzione
- Numero di difetti del test accettati
- Numero di difetti del test rifiutati
- Numero di difetti di prova differiti
- Stato dei difetti attivi
- Calcolo dell'indice di qualità della build
Risultati del test
Durante l'esecuzione di uno scenario di test, un nuovo test dei difetti e l'esecuzione di uno scenario di test di regressione, Test results articulate devono essere salvati e possono essere prodotti insieme ai documenti di chiusura del ciclo di test per supportare il completamento dell'esecuzione del test.
Gli articoli possono essere screenshot, risultati di query di database, registrazioni, file di registro, ecc.