Modello di piano di test (esempio di documento di esempio)
Tommaso Hamilton
⚡ Riepilogo intelligente
Il modello di piano di test definisce la strategia, l'ambito, la pianificazione, i risultati attesi e le risorse necessarie per convalidare la qualità del software. Questo documento funge da modello controllato che guida ogni attività di test e rafforza la responsabilità tra le diverse release.
Che cos'è un modello di piano di test?
A Modello del piano di test Si tratta di un documento dettagliato che descrive la strategia di test, gli obiettivi, la pianificazione, la stima, i risultati attesi e le risorse necessarie per l'esecuzione dei test. Aiuta a determinare l'impegno necessario per convalidare la qualità e funge da modello controllato dal responsabile dei test.
Creazione di un Piano di test è obbligatorio per garantire il successo del tuo progetto di test. Se non hai familiarità con questo argomento, consulta Come creare un piano di test.
Scarica il modello di piano di test di esempio
Struttura del modello di piano di test
Di seguito sono elencati i componenti principali di un modello di piano di test, spiegati in ordine:
- 1. introduzione
- 1.1 Scope
- 1.1.1 Nell'ambito
- 1.1.2 Fuori ambito
- 1.2 Obiettivo Qualità
- Ruoli e responsabilità di 1.3
- 2. Metodologia di prova
- 2.1 Panoramica
- 2.2 Livelli di prova
- 2.3 Valutazione dei bug
- 2.4 Criteri di sospensione e requisiti di ripresa
- 2.5 Completezza del test
- 3. Risultati dei test
- 4. Esigenze in materia di risorse e ambiente
- 4.1 Strumenti di test
- 4.2 Ambiente di prova
- 5. Termini/Acronimi
1) Introduzione
L'introduzione fornisce una breve panoramica delle strategie di test, dei processi, del flusso di lavoro e delle metodologie utilizzate per il progetto.
1.1) Campo di applicazione
L'ambito di applicazione è suddiviso in due parti in modo che i confini della verifica rimangano inequivocabili.
1.1.1) Nell'ambito
In Scope definisce le caratteristiche, i requisiti funzionali o non funzionali del software che sarà testato.
1.1.2) Fuori ambito
Out of Scope definisce le caratteristiche, i requisiti funzionali o non funzionali del software che non sarà testato.
1.2) Obiettivo Qualità
Qui si menzionano gli obiettivi generali che il team intende raggiungere attraverso i test manuali e i test automatizzati. Alcuni obiettivi tipici di un progetto di test includono:
- Assicurarsi che l'applicazione in fase di test (AUT) sia conforme ai requisiti funzionali e non funzionali.
- Assicurarsi che l'AUT soddisfi le specifiche di qualità definite dal cliente.
- Individuare e correggere i bug prima che l'applicazione venga pubblicata.
1.3) Ruoli e responsabilità
Fornire una descrizione dettagliata dei ruoli e delle responsabilità dei diversi membri del team coinvolti, come ad esempio:
- Analista QA
- Responsabile del test
- Gestore configurazione
- Sviluppatori
- Team di installazione
Tra gli altri.
👉 Iscriviti al progetto di test software live gratuito
2) Metodologia di prova
Questa sezione definisce il ciclo di vita, i livelli e le regole utilizzate per governare l'esecuzione dei test.
2.1. Panoramica
Indicare il motivo per cui è stata adottata una particolare metodologia di test per il progetto. La metodologia di test selezionata per il progetto potrebbe essere:
- Cascata
- iterativo
- Agile
- Programmazione estrema
La metodologia selezionata dipende da molteplici fattori. Puoi leggere ulteriori informazioni sulla metodologia di test. Qui..
2.2) Livelli di prova
I livelli di test definiscono i tipi di test da eseguire sull'applicazione in fase di test (AUT).I livelli scelti dipendono principalmente dalla portata del progetto, dai tempi e dai vincoli di budget.
2.3) Valutazione dei bug
L'obiettivo del triage dei bug è:
- Definisci il tipo di risoluzione per ogni bug.
- Assegna priorità ai bug e stabilisci una pianificazione per tutti i bug contrassegnati come "Da correggere".
2.4) Criteri di sospensione e requisiti per la ripresa
I criteri di sospensione definiscono le condizioni in base alle quali l'intera procedura di test, o parte di essa, verrà sospesa. I criteri di ripresa determinano quando il test può riprendere dopo essere stato sospeso.
2.5) Completezza del test
Qui si definiscono i criteri che considereranno completa la fase di test. Ad esempio, i criteri comuni per verificare la completezza del test potrebbero essere:
- Copertura dei test raggiunta: 100%.
- Sono stati eseguiti tutti i casi di test manuali e automatizzati.
- Tutti i bug noti sono stati corretti o la loro risoluzione è prevista per la prossima versione.
3) Risultati del test
Elenca ogni artefatto prodotto durante il ciclo di test. Registrarli in anticipo evita mancate comunicazioni tra i team.
|
4) Esigenze di risorse e ambiente
Elencare gli strumenti e le infrastrutture necessari per garantire budget, licenze e ambienti prima dell'inizio dell'esecuzione.
4.1) Strumenti di test
Fai un elenco di strumenti come:
- Strumento di monitoraggio dei requisiti
- Strumento di tracciamento dei bug
- Strumenti di automazione
Questi elementi sono necessari per testare il progetto in modo efficace.
4.2) Ambiente di prova
Indicare il minimo hardware requisiti che verranno utilizzati per testare l'applicazione.
Le seguenti Software è necessario, oltre al software specifico del cliente:
- Windows 11 e versioni successive
- Microsoft 365 (o Office 2021 e versioni successive)
- MS Exchange, ecc.
5) Termini/Acronimi
Documenta tutti i termini e gli acronimi utilizzati nel progetto, in modo che i nuovi arrivati possano leggere il piano senza ambiguità.
| TERMINE/ACRONIMO | DEFINIZIONE |
|---|---|
| API | Interfaccia del programma applicativo |
| funzione AUT | Applicazione in prova |
Scarica il formato del modello del piano di test riportato sopra
Esempio di piano di test: applicazione web bancaria
Il seguente esempio pratico mostra come compilare il modello sopra riportato per l'applicazione web di Guru99 Bank.
1. introduzione
Il Piano di Test definisce l'ambito, l'approccio, le risorse e la tempistica di tutte le attività di test per il progetto Guru99 Bank. Identifica gli elementi e le funzionalità da testare, le tipologie di test da eseguire, il personale responsabile e i rischi associati al piano.
1.1 Scope
1.1.1 Nell'ambito
Tutte le funzionalità del sito web di Guru99 Bank definite nei requisiti software occhiali devono essere testati.
| Nome modulo | Ruoli applicabili | Descrizione |
|---|---|---|
| Richiesta di equilibrio | Responsabile, Cliente | Cliente: Un cliente può avere più conti bancari e visualizzare solo i saldi dei propri conti. Allenatore: Un responsabile può visualizzare il saldo di tutti i clienti sotto la sua supervisione. |
| Trasferimento di fondi | Responsabile, Cliente | Cliente: Un cliente può trasferire fondi dal proprio conto a qualsiasi conto di destinazione. Allenatore: Un gestore può trasferire fondi da qualsiasi conto di origine a qualsiasi conto di destinazione. |
| Mini dichiarazione | Responsabile, Cliente | Un mini estratto conto mostra le ultime 5 transazioni di un conto. Cliente: Visualizza solo il mini-estratto conto dei propri conti. Allenatore: Visualizza il mini-estratto conto di qualsiasi conto. |
| Dichiarazione personalizzata | Responsabile, Cliente | Un estratto conto personalizzato filtra e visualizza le transazioni di un conto in base alla data o al valore della transazione. Cliente: Solo i suoi resoconti personali. Allenatore: Qualsiasi account. |
| Cambiare la password | Responsabile, Cliente | Cliente: Può cambiare la password del proprio account. Allenatore: Può cambiare la password del proprio account, ma non quella dei suoi clienti. |
| NUOVO CLIENTE | direttore | Allenatore: Un manager può aggiungere un nuovo cliente. |
| Modifica cliente | direttore | Allenatore: È possibile modificare dettagli quali indirizzo, email e numero di telefono di un cliente. |
| Nuovo account | direttore | Il sistema offre due tipi di conto: conto di risparmio e conto corrente. Un cliente può detenere più conti di risparmio (individuali o cointestati) e più conti correnti. Allenatore: È possibile aggiungere un nuovo account per un cliente già esistente. |
| Modifica account | direttore | Allenatore: È possibile modificare i dettagli di un account esistente. |
| Eliminare l'account | direttore | Allenatore: È possibile eliminare un account appartenente a un cliente. |
| Elimina cliente | direttore | Un cliente può essere eliminato solo se non ha conti correnti o di risparmio attivi. Allenatore: È possibile eliminare un cliente. |
| Cauzione | direttore | Allenatore: È possibile depositare denaro su qualsiasi conto, in genere quando si deposita contanti presso una filiale bancaria. |
| Ritiro | direttore | Allenatore: È possibile prelevare denaro da qualsiasi conto, in genere quando si preleva contanti presso una filiale bancaria. |
1.1.2 Fuori ambito
Queste funzionalità non vengono testate perché non fanno parte delle specifiche dei requisiti software:
- Interfacce utente
- Interfacce hardware
- Interfacce software
- Progettazione logica del database
- Interfacce di comunicazione
- Sicurezza e prestazioni del sito web
1.2 Obiettivo Qualità
Gli obiettivi del test sono: verificare la funzionalità del sito web di Guru99 Bank. Il progetto dovrebbe concentrarsi sul test del operazioni bancarie, come la gestione dell'account, il prelievo e la richiesta del saldo, per di garanzia che tutte queste operazioni funzionino normalmente in un contesto aziendale reale.
Ruoli e responsabilità di 1.3
Il progetto dovrebbe utilizzare esternalizzato membri come tester per ridurre i costi del progetto.
| No. | Member | Compiti |
|---|---|---|
| 1. | Responsabile del test | Gestisce l'intero progetto, definisce la direzione del progetto e si occupa di reperire le risorse necessarie. |
| 2. | Tester | Identifica e descrive tecniche di test, strumenti e architettura di automazione appropriati; verifica l'approccio di test; esegue i test; registra i risultati; segnala i difetti. Membri esterni. |
| 3. | Sviluppatore in prova | Implementa casi di test, programmi di test, suite di test, ecc. |
| 4. | Amministratore di prova | Crea e gestisce l'ambiente di test e le relative risorse; fornisce supporto ai tester durante l'esecuzione. |
| 5. | Membri della SQA | Assumiti la responsabilità del controllo qualità e verifica che il processo di test soddisfi i requisiti specificati. |
2. Metodologia di prova
2.1 Panoramica
Il progetto Guru99 Bank adotta una metodologia di test compatibile con gli Agile, consentendo ai tester di allinearsi ai rapidi sprint di sviluppo pur mantenendo una documentazione strutturata.
2.2 Livelli di prova
Nel progetto Guru99 Bank, è necessario effettuare tre tipi di test:
- Test d'integrazione: I singoli moduli software vengono combinati e testati come un gruppo.
- Test di sistema: Condotta su un sistema completo e integrato per valutare la conformità ai requisiti specificati.
- Test API: Esegue test su ogni API esposta dal software in fase di test.
2.3 Valutazione dei bug
Le riunioni di triage dei bug si tengono due volte a settimana per classificare la gravità del difetto, il responsabile e la versione di correzione prevista.
2.4 Criteri di sospensione e requisiti di ripresa
If 40% dei casi di test hanno mancato, sospendere i test fino a quando il team di sviluppo non avrà risolto tutti i casi di errore.
2.5 Completezza del test
- Specifica i criteri che denotano a di successo completamento di una fase di test.
- Tasso di esecuzione è obbligatorio a 100% a meno che non venga fornita una motivazione chiara.
- Tasso di passaggio is 80%; raggiungere il tasso di superamento è obbligatorio.
2.6 Attività del progetto, stima e pianificazione
| Task | Utenti | Sforzo stimato |
|---|---|---|
| Creare la specifica del test | Progettista di test | 170 ore lavorative |
| Eseguire l'esecuzione del test | Tester, amministratore del test | 80 ore lavorative |
| Rapporto di prova | Tester | 10 ore lavorative |
| Prova di consegna | Responsabile del test | 20 ore lavorative |
| Totale | - | 280 ore lavorative |
Orario: Il team si impegna a completare questi compiti entro la finestra temporale concordata per il ciclo di test.
3. Risultati dei test
Le attività di test per il progetto Guru99 Bank sono organizzate in tre fasi.
Prima della fase di test:
- Documento relativo al piano di test.
- Casi test documenti.
- Specifiche di progettazione del test.
Durante la fase di test:
- Simulatori di strumenti di prova.
- Dati di test.
- Matrice di tracciabilità dei test, registri degli errori e registri di esecuzione.
Al termine dei cicli di test:
- Risultati e referti dei test.
- Rapporto sui difetti.
- Linee guida per le procedure di installazione e collaudo.
- Note di rilascio.
4. Esigenze in materia di risorse e ambiente
4.1 Strumenti di test
| No. | Gestione | Descrizione |
|---|---|---|
| 1. | server | Un server di database in esecuzione MySQL e un server web che esegue Apache. |
| 2. | Strumento di prova | Uno strumento in grado di generare automaticamente i risultati dei test in un formato predefinito e di automatizzare l'esecuzione dei test. |
| 3. | Reti | Una connessione LAN gigabit e una linea internet con una velocità minima di 5 Mb/s. |
| 4. | computer | Almeno 4 postazioni di lavoro in esecuzione Windows 11, con 8 GB di RAM e una CPU da 3.4 GHz. |
4.2 Ambiente di prova
Questa sottosezione elenca i requisiti hardware e software minimi necessari per testare l'applicazione. Oltre al software specifico del client, è richiesto il seguente software:
- Windows 11 e versioni successive
- Microsoft 365 (o Office 2021 e versioni successive)
- MS Exchange, ecc.
Come l'IA aiuta nella pianificazione dei test
La pianificazione dei test moderni utilizza sempre più l'IA per comprimere gli sforzi e far emergere i punti ciechi. Assistenti generativi come ChatGPT, Claude o Gemini È possibile redigere un piano di test iniziale a partire da un documento dei requisiti, suggerire casi limite mancanti e produrre automaticamente matrici di tracciabilità. I modelli di apprendimento automatico individuano i moduli a rischio in base ai dati storici sui difetti, aiutando il responsabile dei test a concentrare gli sforzi dove è più importante.
Tuttavia, l'assistenza dell'IA non sostituisce il giudizio umano. RevI revisori devono convalidare l'ambito di applicazione, la copertura normativa e l'intento aziendale prima di approvare qualsiasi piano generato dall'IA. I suggerimenti dell'IA devono essere considerati come una prima bozza, non come il documento definitivo.
Le migliori pratiche per un piano di test efficace
Un piano di test ben redatto mantiene allineate tutte le parti interessate. Applica queste best practice durante la stesura del documento:
- Sii conciso: Utilizza un linguaggio chiaro ed elenchi puntati; evita il gergo tecnico che rallenta i lettori non esperti di controllo qualità.
- Fallo Reviewable: Condividi tempestivamente le informazioni con gli sviluppatori e gli analisti aziendali per individuare eventuali requisiti mancanti.
- Quantificare i criteri di uscita: Definire la copertura numerica, la percentuale di superamento e le soglie di difetto.
- Collegare i rischi alle misure di mitigazione: Ogni rischio deve essere accompagnato da una strategia di contenimento o di riserva.
- Gestione della versione del piano: Archiviatelo in uno strumento di documentazione per tenere traccia delle modifiche apportate durante tutto il progetto.
