PIANO DI PROVA - TEST DEL SOFTWARE

Un piano di test è un documento dettagliato che descrive le aree e le attività di test del software. Delinea la strategia di test, gli obiettivi, il programma dei test, le risorse richieste (risorse umane, software e hardware), la stima dei test e i risultati finali dei test.

Il piano di test è la base per il test di ogni software. È l'attività più cruciale che garantisce la disponibilità di tutti gli elenchi delle attività pianificate in una sequenza appropriata.

Il piano di test è un modello per condurre attività di test del software come un processo definito completamente monitorato e controllato dal responsabile del test. Il piano di test è preparato dal Test Lead (60%), dal Test Manager (20%) e dall'ingegnere del test (20%).

Tipi di piano di test

Esistono tre tipi di piano di test

Piano di prova generale
Piano di test di fase
Piani di test specifici per tipo di test

Piano di prova generale

Il piano di test principale è un tipo di piano di test che prevede più livelli di test. Include una strategia di test completa.

Piano di test di fase

Un piano di test di fase è un tipo di piano di test che affronta qualsiasi fase della strategia di test. Ad esempio, un elenco di strumenti, un elenco di casi di test, ecc.

Piani di test specifici

Piano di test specifico progettato per i principali tipi di test come test di sicurezza, test di carico, test delle prestazioni, ecc. In altre parole, un piano di test specifico progettato per test non funzionali.

Come scrivere un piano di test

Fare un piano di test è il compito più cruciale del processo di gestione del test. Secondo IEEE 829, seguire i seguenti sette passaggi per preparare un piano di test.

Innanzitutto, analizzare la struttura e l'architettura del prodotto.
Ora progetta la strategia di test.
Definire tutti gli obiettivi del test.
Definire l'area di prova.
Definire tutte le risorse utilizzabili.
Pianificare tutte le attività in modo appropriato.
Determinare tutti i risultati finali del test.

Componenti o attributi del piano di test

Il piano di test è composto da varie parti, che ci aiutano a ricavare l'intera attività di test.

Obiettivi: Consiste in informazioni su moduli, funzionalità, dati di test, ecc., che indicano lo scopo dell'applicazione, ovvero il comportamento dell'applicazione, l'obiettivo, ecc.

Scopo: Contiene informazioni che devono essere testate con ciascuna applicazione. L’ambito può essere ulteriormente suddiviso in due parti:

Nell'ambito
Fuori portata

Nell'ambito: Questi sono i moduli che devono essere testati rigorosamente (in dettaglio).

Fuori ambito: Questi sono i moduli che non necessitano di essere testati rigorosamente.

Per esempio , Supponiamo di avere un'applicazione Gmail da testare, dove caratteristiche da testare ad esempio Componi posta, Posta inviata, Posta in arrivo, Bozze e il caratteristiche che non possono essere testate ad esempio Aiuto , e così via, il che significa che in fase di pianificazione decideremo quale funzionalità deve essere verificata o meno in base al limite di tempo indicato nel prodotto.

Ora come decidiamo quali funzionalità non testare?

Abbiamo i seguenti aspetti in cui possiamo decidere quale funzionalità non testare:

Come abbiamo visto sopra Aiuto le funzionalità non verranno testate, poiché sono scritte e sviluppate dallo scrittore tecnico e riviste da un altro scrittore professionista.
Supponiamo di avere un'applicazione che abbia P, Q, R e S funzionalità, che devono essere sviluppate in base ai requisiti. Ma in questo caso la funzionalità S è già stata progettata e utilizzata da qualche altra azienda. Quindi il team di sviluppo acquisterà S da quella società e lo integrerà con funzionalità aggiuntive come P, Q e R.

Ora non eseguiremo test funzionali sulla funzionalità S perché è già stata utilizzata in tempo reale. Ma eseguiremo i test di integrazione e i test di sistema tra le funzionalità P, Q, R e S perché le nuove funzionalità potrebbero non funzionare correttamente con la funzionalità S, come possiamo vedere nell'immagine seguente:

Supponiamo che nella prima versione del prodotto, gli elementi che sono stati sviluppati, come P, Q, R, S, T, U, V, W…..X, Y, Z . Ora il cliente fornirà i requisiti per le nuove funzionalità che migliorano il prodotto nella seconda versione e le nuove funzionalità lo sono A1, B2, C3, D4 e E5.

Successivamente, scriveremo l'ambito durante il piano di test come

Scopo

Caratteristiche da testare

A1, B2, C3, D4, E5 (nuove funzionalità)

P, Q, R, S, T

Caratteristiche da non testare

W X Y Z

Pertanto, controlleremo prima le nuove funzionalità e poi continueremo con quelle vecchie perché ciò potrebbe essere influenzato dopo l'aggiunta delle nuove funzionalità, il che significa che influenzerà anche le aree di impatto, quindi eseguiremo un ciclo di test di regressione per P, Q , R…, caratteristiche T.

Metodologia di prova:

Contiene informazioni sull'esecuzione di diversi tipi di test come test funzionali, test di integrazione e test di sistema, ecc. sull'applicazione. In questo decideremo quale tipo di test; eseguiremo le varie funzionalità in base ai requisiti dell'applicazione. E qui, dovremmo anche definire che tipo di test utilizzeremo nelle metodologie di test in modo che tutti, come il management, il team di sviluppo e il team di test, possano capire facilmente perché i termini di test non sono standard.

Per esempio, per applicazioni autonome come Adobe Photoshop , eseguiremo i seguenti tipi di test:

Test del fumo → Test funzionali → Test di integrazione → Test di sistema → Test ad hoc → Test di compatibilità → Test di regressione → Test di globalizzazione → Test di accessibilità → Test di usabilità → Test di affidabilità → Test di ripristino → Test di installazione o disinstallazione

E supponiamo di dover testare il https://www.jeevansathi.com/ applicazione, quindi eseguiremo i seguenti tipi di test:

Test del fumo	Test funzionale	Test d'integrazione
Test del sistema	Test ad hoc	Test di compatibilità
Test di regressione	Test di globalizzazione	Test di accessibilità
Test di usabilità	Test delle prestazioni

Approccio

Questo attributo viene utilizzato per descrivere il flusso dell'applicazione durante l'esecuzione del test e per riferimento futuro.

Possiamo comprendere il flusso dell'applicazione con l'aiuto degli aspetti seguenti:

Scrivendo gli scenari di alto livello Scrivendo il grafico del flusso

Scrivendo gli scenari di alto livello

Per esempio , supponiamo di testare il file Gmail applicazione:

Accedi a Gmail: invia un'e-mail e controlla se è nella pagina Posta inviata
Accedere …….
……
…....

Stiamo scrivendo questo per descrivere gli approcci che devono essere adottati per testare il prodotto e solo per le funzionalità critiche in cui scriveremo gli scenari di alto livello. In questa sede non ci concentreremo sulla copertura di tutti gli scenari perché può essere deciso dal particolare ingegnere di test quali caratteristiche debbano essere testate o meno.

Scrivendo il grafico del flusso

Il grafico di flusso è stato scritto perché la scrittura degli scenari di alto livello richiede un po' di tempo, come possiamo vedere nell'immagine seguente:

Stiamo creando grafici di flusso per ottenere i seguenti vantaggi come:

La copertura è facile
Unire è facile

L’approccio può essere classificato in due parti che sono le seguenti:

Approccio dall'alto verso il basso
Approccio dal basso verso l'alto

Assunzione

Contiene informazioni su un problema o questione che potrebbe essersi verificata durante il processo di test e quando stiamo scrivendo i piani di test, verrebbero fatte le ipotesi certe come risorse e tecnologie, ecc.

Rischio

Queste sono le sfide che dobbiamo affrontare per testare l'applicazione nella versione corrente e se le ipotesi falliscono, allora ci sono dei rischi.

Per esempio, l'effetto per una domanda, la data di rilascio viene posticipata.

Piano di mitigazione o piano di emergenza

È un piano di riserva preparato per superare i rischi o i problemi.

Vediamo insieme un esempio di presupposto, rischio e piano di emergenza perché sono correlati tra loro.

In qualsiasi prodotto, il assunzione faremo è che tutti e 3 gli ingegneri di test saranno presenti fino al completamento del prodotto e a ciascuno di loro verranno assegnati moduli diversi come P, Q e R. In questo particolare scenario, il rischio potrebbe succedere se l'ingegnere del test abbandonasse il progetto nel bel mezzo di esso.

quindi, il piano di emergenza verrà assegnato un proprietario principale e uno subordinato a ciascuna funzionalità. Pertanto, se l'ingegnere di test se ne va, il proprietario subordinato assume quella funzionalità specifica e aiuta anche il nuovo ingegnere di test, in modo che possa comprendere i moduli assegnati.

Le ipotesi, il rischio e il piano di mitigazione o di emergenza sono sempre precisi sul prodotto stesso. Le varie tipologie di rischi sono le seguenti:

piedi contro piede

Prospettiva del cliente
Approccio alle risorse
Parere tecnico

Ruolo e responsabilità

Definisce l'attività completa che deve essere eseguita dall'intero team di test. Quando arriva un grande progetto, allora il Responsabile delle prove è una persona che scrive il piano di test. Se sono presenti 3-4 piccoli progetti, il responsabile del test assegnerà ciascun progetto a ciascun responsabile del test. Quindi, il responsabile del test scrive il piano di test per il progetto, che gli viene assegnato.

Vediamo un esempio in cui comprenderemo i ruoli e le responsabilità del responsabile del test, del responsabile del test e degli ingegneri del test.

Ruolo: Responsabile del test

Nome: Ryan

Responsabilità:

Preparare (scrivere e rivedere) il piano di test
Condurre l'incontro con il team di sviluppo
Condurre l'incontro con il team di test
Condurre l'incontro con il cliente
Condurre uno stand up meeting mensile
Firma la nota di rilascio
Gestione delle escalation e dei problemi

Ruolo: Test Lead

Nome: Harvey

Responsabilità:

Preparare (scrivere e rivedere) il piano di test
Condurre riunioni quotidiane in piedi
Rivedere e approvare il caso di test
Preparare il RTM e i report
Assegnare moduli
Programma di gestione

Ruolo: Test Engineer 1, Test Engineer 2 e Test Engineer 3

Nome: Louis, Jessica, Donna

Assegnare i moduli: M1, M2 e M3

Responsabilità:

Scrivere, rivedere ed eseguire i documenti di test costituiti da casi di test e scenari di test
Leggere, rivedere, comprendere e analizzare i requisiti
Scrivere il flusso dell'applicazione
Eseguire il caso di test
RTM per i rispettivi moduli
Tracciamento dei difetti
Preparare il rapporto di esecuzione del test e comunicarlo al Test Lead.

Programma

Viene utilizzato per spiegare i tempi di lavoro, cosa deve essere fatto o questo attributo copre esattamente quando dovrebbe iniziare e finire ciascuna attività di test? E per ogni attività di test per la data specifica vengono menzionati anche i dati esatti.

Pertanto, come possiamo vedere nell'immagine sottostante, per una particolare attività ci sarà una data di inizio e una data di fine; per ogni test su una build specifica, ci sarà la data specificata.

Per esempio

Scrivere casi di test
Processo di esecuzione

Tracciamento dei difetti

Generalmente viene eseguito con l'aiuto di strumenti perché non possiamo monitorare manualmente lo stato di ciascun bug. Commentiamo anche come comunichiamo i bug identificati durante il processo di test e li rimandiamo al team di sviluppo e come il team di sviluppo risponderà. Qui menzioniamo anche la priorità dei bug come alta, media e bassa.

Di seguito sono riportati i vari aspetti del monitoraggio dei difetti:

Bloccante o bloccante

Per esempio

Critico

Maggiore

Minore

Alto-P1

Medio-P2

Basso-P3

Pertanto, in base alla priorità dei bug come alta, media e bassa, lo classificheremo come P1, P2, P3 e P4.

Ambienti di prova

Questi sono gli ambienti in cui testeremo l'applicazione e qui abbiamo due tipi di ambienti, che sono di Software E hardware configurazione.

IL configurazione del software significa i dettagli su diversi Sistemi operativi ad esempio Windows, Linux, UNIX e Mac e vari Browser Piace Google Chrome, Firefox, Opera, Internet Explorer , e così via.

E il configurazione hardware indica le informazioni sulle diverse dimensioni di RAM, ROM e processori .

Per esempio

IL Software include quanto segue:

server

Sistema operativo	Linux
Server web	Apache Tomcat
Server dell'applicazione	Sfera Web
Server della banca dati	Oracle o MS-SQL Server

Nota: i server sopra indicati sono i servizi utilizzati dal team di test per testare l'applicazione.

Cliente

Sistema operativo	Windows XP, Vista 7
Browser	Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 e Internet Explorer 8

Nota: i dettagli sopra riportati forniscono i vari sistemi operativi e browser in cui il team di test testerà l'applicazione.

IL Hardware include quanto segue:

server : Sole StarCat 1500

Questo particolare server può essere utilizzato dal team di test per testare la propria applicazione.

Cliente:

Ha la seguente configurazione, che è la seguente:

Processore	2GHz totali
RAM	2GB
….	….

Nota: fornirà la configurazione dei sistemi degli ingegneri di test che costituiscono il team di test.

Il team di sviluppo fornirà la configurazione di come installare il software. Se il team di sviluppo non fornirà ancora il processo, lo scriveremo come sviluppo basato su attività (TBD) nel piano di test.

Criteri di entrata e di uscita

È una condizione necessaria, che deve essere soddisfatta prima di avviare e interrompere il processo di test.

Criteri di ingresso

I criteri di ammissione contengono le seguenti condizioni:

Il test della scatola bianca dovrebbe essere terminato.
Comprendere e analizzare i requisiti e preparare i documenti di test o quando i documenti di test sono pronti.
I dati del test dovrebbero essere pronti.
La compilazione o l'applicazione devono essere preparate
I moduli o le funzionalità devono essere assegnati ai diversi ingegneri di test.
La risorsa necessaria deve essere pronta.

Criteri di uscita

I criteri di uscita contengono le seguenti condizioni:

Quando tutti i casi di test vengono eseguiti.
La maggior parte dei casi di test devono esserlo passato .
Dipende dalla gravità dei bug, il che significa che non devono esserci blocchi o bug importanti, mentre esistono alcuni bug minori.

Prima di iniziare a eseguire i test funzionali, tutto quanto sopra Criteri di ingresso dovrebbe essere seguito. Dopo aver eseguito i test funzionali e prima di eseguire i test di integrazione, quindi Criteri di uscita di il test funzionale dovrebbe essere seguito perché la percentuale dei criteri di uscita viene decisa dall'incontro sia con il responsabile dello sviluppo che del test perché la loro collaborazione può raggiungere la percentuale. Ma se i criteri di uscita del test funzionale non vengono seguiti, non possiamo procedere oltre con il test di integrazione.

Qui in base alla gravità del bug significa che il team di testing avrebbe deciso di procedere oltre per le fasi successive.

Testare l'automazione

In questo, decideremo quanto segue:

Quale funzionalità deve essere automatizzata e quale non deve essere automatizzata?
Quale strumento di automazione dei test utilizzeremo su quale framework di automazione?

Automatizziamo il test case solo dopo il primo rilascio.

Qui sorge la domanda: su quali basi Noi Volere decidere quali funzionalità devono essere testate?

Nell'immagine sopra, come possiamo vedere, le funzionalità più comunemente utilizzate devono essere testate ancora e ancora. Supponiamo di dover controllare l'applicazione Gmail dove si trovano le funzionalità essenziali Componi posta, Posta inviata e Posta in arrivo . Quindi testeremo queste funzionalità perché durante l'esecuzione dei test manuali ci vuole più tempo e diventa anche un lavoro monotono.

Ora, come decidiamo quali funzionalità non verranno testate?

Supponiamo l'aiuto La funzionalità dell'applicazione Gmail non viene testata più e più volte poiché queste funzionalità non vengono utilizzate regolarmente, quindi non è necessario controllarle frequentemente.

Ma se alcune funzionalità sono instabili e presentano molti bug , il che significa che non testeremo tali funzionalità perché devono essere testate più e più volte durante i test manuali.

Se c'è una funzionalità che deve essere testata frequentemente , ma ci aspettiamo la modifica dei requisiti per quella funzionalità, quindi non la controlliamo perché la modifica dei casi di test manuali è più comoda rispetto alla modifica nello script di test di automazione.

Stima dello sforzo

In questo, pianificheremo lo sforzo necessario che deve essere applicato da ogni membro del team.

Risultati finali della prova

Questi sono i documenti risultanti dal team di test, che abbiamo consegnato al cliente insieme al prodotto. Include quanto segue:

Piano di prova Casi test Script di prova RTM (matrice di tracciabilità dei requisiti) Rapporto sui difetti Rapporto sull'esecuzione del test Grafici e metriche Note di rilascio

Grafici e metriche

Grafico

In questo, discuteremo dei tipi di grafici invieremo e forniremo anche un campione di ciascun grafico.

Come possiamo vedere, abbiamo cinque diversi grafici che mostrano i vari aspetti del processo di test.

Grafico1: In questo mostreremo quanti difetti sono stati identificati e quanti difetti sono stati risolti in ogni modulo.

Grafico 2: La Figura uno mostra quanti difetti critici, maggiori e minori sono stati identificati per ogni modulo e quanti sono stati risolti per i rispettivi moduli.

Grafico3: In questo particolare grafico, rappresentiamo il costruire un grafico saggio , il che significa che in ogni build quanti difetti sono stati identificati e corretti per ciascun modulo. In base al modulo, abbiamo determinato i bug. Aggiungeremo R per mostrare il numero di difetti in P e Q, e aggiungiamo anche S per mostrare i difetti in P, Q e R.

Grafico4: Il responsabile del test progetterà il Analisi delle tendenze dei bug grafico che viene creato ogni mese e inviarlo anche alla Direzione. Ed è proprio come la previsione che viene fatta alla fine del prodotto. E qui possiamo anche farlo valutare le correzioni dei bug come possiamo osservare arco ha un tendenza al rialzo nell'immagine qui sotto.

Grafico5: IL Responsabile delle prove ha progettato questo tipo di grafico. Questo grafico ha lo scopo di comprendere il divario nella valutazione dei bug e dei bug effettivi che si sono verificati, e questo grafico aiuta anche a migliorare la valutazione dei bug in futuro.

Metrica

Come sopra, creiamo il grafico della distribuzione dei bug, che è nella Figura 1, e con l'aiuto dei dati sopra menzionati, progetteremo anche le metriche.

Per esempio

Nella figura sopra, conserviamo i record di tutti gli ingegneri di test in un particolare progetto e di quanti difetti sono stati identificati e risolti. Possiamo anche utilizzare questi dati per analisi future. Quando arriva un nuovo requisito, possiamo decidere a chi fornire la funzionalità impegnativa da testare in base al numero di difetti rilevati in precedenza in base ai parametri di cui sopra. E ci troveremo in una situazione migliore per sapere chi può gestire molto bene le caratteristiche problematiche e trovare il numero massimo di difetti.

Nota di rilascio: È un documento che viene preparato durante il rilascio del prodotto e firmato dal Responsabile del Test.

Nell'immagine seguente, possiamo vedere che il prodotto finale è stato sviluppato e distribuito al cliente e il nome della versione più recente lo è Beta .

IL Nota di rilascio è costituito da quanto segue:

Manuale d'uso.
Elenco dei difetti pendenti e aperti.
Elenco delle funzionalità aggiunte, modificate ed eliminate.
Elenco della piattaforma (Sistema Operativo, Hardware, Browser) su cui è testato il prodotto.
Piattaforma in cui il prodotto non viene testato.
Elenco dei bug risolti nella versione corrente e elenco dei bug risolti nella versione precedente.
Processo di installazione
Versioni del software

Per esempio

Supporre che Beta è la seconda versione dell'applicazione dopo la prima versione Alfa è rilasciato. Alcuni dei difetti identificati nella prima versione e che sono stati risolti nella versione successiva. E qui indicheremo anche l'elenco delle funzionalità appena aggiunte, modificate ed eliminate dalla versione alpha alla versione beta.

Modello

Questa parte contiene tutti i modelli per i documenti che verranno utilizzati nel prodotto e tutti gli ingegneri di test utilizzeranno solo questi modelli nel progetto per mantenere la coerenza del prodotto. Qui abbiamo diversi tipi di modello che vengono utilizzati durante l'intero processo di test come:

Modello di caso di prova
Modello di revisione dei casi di test
Modello RTM
Modello di segnalazione di bug
Rapporto sull'esecuzione del test

Vediamo un esempio del documento del piano di test

Pagina 1

Pagina3-pagina18

Pagina-20

Nella pagina 1, riempiamo principalmente solo il file Versioni, autore, commenti e revisione da parte di campi e, dopo l'approvazione del manager, menzioneremo i dettagli nel file Approvato da e data di approvazione campi.

Nella maggior parte dei casi il piano di test viene approvato dal Responsabile del test e gli ingegneri del test si limitano a revisionarlo. E quando arriveranno le nuove funzionalità, modificheremo il piano di test e apporteremo le modifiche necessarie Versione campo, quindi verrà inviato nuovamente per ulteriore revisione, aggiornamento e approvazione del manager. Il piano di test deve essere aggiornato ogni volta che si sono verificati cambiamenti. A pagina 20, il Riferimenti specificare i dettagli su tutti i documenti che utilizzeremo per scrivere il documento del piano di test.

Nota:

Chi scrive il piano di test?

Cavo di prova→60%
Responsabile del test→20%
Ingegnere collaudatore→20%

Pertanto, come possiamo vedere da sopra, nel 60% del prodotto, il piano di test è scritto dal Test Lead.

Chi revisiona il piano di test?

Testare il cavo
Responsabile delle prove
Ingegnere di prova
Cliente
Team di sviluppo

L'ingegnere del test esamina il piano di test dalla prospettiva del modulo e il responsabile del test esamina il piano di test in base all'opinione del cliente.

Chi approva il piano di test?

Cliente
Responsabile delle prove

Chi scrive il test case?

Testare il cavo
Ingegnere di prova

Chi esamina il caso di test?

Ingegnere di prova
Testare il cavo
Cliente
Team di sviluppo

Chi approva i casi di test?

Responsabile delle prove
Testare il cavo
Cliente

Linee guida del piano di test

Comprimi il tuo piano di test.
Evitare sovrapposizioni e ridondanze.
Se ritieni di non aver bisogno di una sezione già menzionata sopra, elimina quella sezione e procedi.
Sii specifico. Ad esempio, quando specifichi un sistema software come parte dell'ambiente di test, menziona la versione del software invece del solo nome.
Evita paragrafi lunghi.
Utilizza elenchi e tabelle ove possibile.
Aggiorna il piano quando necessario.
Non utilizzare un documento obsoleto e inutilizzato.

Importanza del piano di test

Il piano di test dà la direzione al nostro pensiero. Questo è come un libro di regole, che deve essere seguito.
Il piano di test aiuta a determinare gli sforzi necessari per convalidare la qualità dell'applicazione software sottoposta a test.
Il piano di test aiuta le persone a comprendere i dettagli del test legati all'esterno come sviluppatori, manager aziendali, clienti, ecc.
Aspetti importanti come il programma di test, la strategia di test, l'ambito del test ecc. sono documentati nel piano di test in modo che il team di gestione possa esaminarli e riutilizzarli per altri progetti simili.