Linea guida: Decisioni importanti nei test
Queste linee guida descrivono importanti elementi da considerare nella personalizzazione degli aspetti di test del processo.
Relazioni
Descrizione principale

Decidere le modalità di utilizzo dei prodotti di lavoro

Determinare quali prodotti del lavoro  utilizzare e le relative modalità d'impiego.  Oltre ad identificare i prodotti del lavoro da utilizzare, è importante anche personalizzarli in modo da farli aderire alle necessità del progetto. 

La tabella riportata di seguito specifica i prodotti del lavoro di test raccomandati e quelli facoltativi (da utilizzare ad esempio solo in certi casi). Per ulteriori considerazioni sulla personalizzazione, consultare la sezione relativa nella pagina descrittiva del prodotto del lavoro.

Prodotto di lavoro Scopo Personalizzazione (Facoltativo, Raccomandato)
Riepilogo valutazione test Riassume i risultati del test principalmente perché li utilizzi il team di gestione e gli altri stakeholder esterni al team di test. Consigliato per la maggior parte dei progetti.

Dove la cultura del progetto è relativa alle informazioni, potrebbe essere appropriato semplicemente registrare i risultati di test e non creare riepiloghi di valutazione formali. Negli altri casi, è possibile includere i riepiloghi di valutazione test come sezione all'interno di altri prodotti di lavoro di valutazione, quali Valutazione iterazione oppure Relazione revisione.
Risultati del test Questo prodotto di lavoro è il risultato analizzato determinato dai dati non elaborati in uno o più log di test. Raccomandato. La maggior parte dei team mantiene alcuni moduli di record ragionevolmente dettagliati dei risultati della verifica. I risultati della verifica manuale vengono di solito registrati direttamente qui e combinati con i log di test distillati dai testi automatici.

In alcuni casi, i team di test passano direttamente dai log di test alla produzione del riepilogo della valutazione del test.
Log di test

L'output dei dati non elaborati durante l'esecuzione del test, solitamente prodotto dai testi automatici.

Facoltativo.

In molti progetti in cui si esegue la verifica automatica si disporrà di alcuni modelli di log di test. La differenza nei vari progetti è determinata da se i test di log vengono conservati o eliminati una volta determinati i risultati del test.

E' possibile mantenere i log di test se è necessario soddisfare determinati requisiti di controllo, se si desidera eseguire delle analisi su come si modificano nel tempo i primi dati di output del test oppure se non si è certi all'inizio di tutte le analisi richieste.

Suite di test Utilizzato per raggruppare i testi relativi singoli (Script di test) con sottoinsiemi validi. Consigliato per la maggior parte dei progetti.

Richiesto anche per definire tutte le sequenze di esecuzione dello script di test richieste per il corretto funzionamento dei test.
Elenco proposte di test Si tratta di un elenco numerato di proposte, spesso formulate parzialmente, da considerare come test utili da eseguire. Consigliato per la maggior parte dei progetti.

In alcuni casi questi elenchi verranno definiti in modo informale ed eliminati una volta definiti i casi di test o gli script di test.
Strategia di test Definisce il piano strategico relativo alle modalità di impegno lavorativo per il test condotto nei confronti di uno o più aspetti del sistema di destinazione. Consigliato per la maggior parte dei progetti.

Nella maggior parte dei casi, si consiglia una singola strategia di test per progetto o per fase in un progetto. Facoltativamente, è possibile riutilizzare strategie esistenti laddove appropriato oppure è possibile suddividere ulteriormente le strategie di test basate sul tipo di verifica in esecuzione.
 Piano di test Definisce gli obiettivi di verifica a granularità più sottile, gli obiettivi, le motivazioni, l'approccio, le risorse, la pianificazione e i prodotti del lavoro che governano un'iterazione. Consigliato per la maggior parte dei progetti.

Si consiglia un piano di test separato per iterazione per definire la specifica strategia di test a granularità sottile. Facoltativamente. è possibile includere il piano di test come sezione all'interno del Piano di iterazione.
 Piano di test Definisce gli obbiettivi di verifica a livello elevato, gli obiettivi, l'approccio, le risorse, la pianificazione e i prodotti del lavoro che governano una fase o l'intero ciclo di vita. Facoltativo. Utile per la maggior parte dei progetti.

Un piano principale di test definisce la strategia di livello elevato per l'impegno di lavoro di test su ampie parti del ciclo di vita di sviluppo del software. Facoltativamente, è possibile includere un piano di test come sezione all'interno del Piano di sviluppo del software.

Considerare la possibilità di mantenere un piano di test "Principale" in aggiunta ai piani di test di "Iterazione". Il piano di test principale copre principalmente le informazioni sull'approvazione del processo e della logistica che si riferiscono di solito all'intero ciclo di vita del progetto, perciò è improbabile che cambi tra le iterazioni.
 Script di test,  Dati di test Gli script di test ed i dati di test sono la realizzazione o l'implementazione del test, dove lo script di test rappresenta gli aspetti procedurali ed i dati di test le caratteristiche di definizione. Consigliato per la maggior parte dei progetti.

I progetti differiscono nel modo in cui vengono trattati questi prodotti di lavoro. In alcuni casi, questi sono informali e transitori ed il team del test viene giudicato in base ad altri criteri. In altri casi - specialmente con i test automatici - gli script di test ed i dati di test associati (o alcuni sottoinsiemi) vengono considerati come componenti distribuibili principali dell'impegno di lavoro del test.
 Scenario di test

Definisce un insieme di input di test, condizioni di esecuzione e i risultati previsti.

La documentazione dei casi di test ne consente la revisione per completezza e correttezza e che vengano considerati prima che l'impegno di lavoro d'implementazione venga pianificato & consumati.

Ciò è maggiormente utile dove l'input, le condizioni di esecuzione ed i risultati attesi sono particolarmente complessi.

Si consiglia, nella maggior parte dei progetti, dove le condizioni richieste per condurre un test specifico sono complesse o estese, di definire i casi di test. Sarà inoltre necessario documentare i casi di test in cui questi ultimi sono un componente distribuibile richiesto contrattualmente.

nella maggior parte dei casi si consiglia di conservare l'elenco delle idee di test e gli script di test implementato, invece dei casi di testo testuale dettagliati.

In alcuni progetti verranno semplicemente abbozzati gli scenari di test a livello elevato e i dettagli verranno differiti agli script di test. Un altro stile utilizzato comunemente è quello di documentare le informazioni sullo scenario di test come commenti all'interno degli script di test.

 Modello di analisi del carico di lavoro

Un tipo di scenario di test specializzato. Utilizzato per definire un carico di lavoro rappresentativo per consentire i rischi qualità associati al sistema operativo sotto carico da valutare.

Raccomandato per la maggior parte dei sistemi, specialmente per quelli in cui è necessario valutare la prestazione del sistema sotto carico oppure in cui esistono altri rischi qualità significativi associati alle operazioni del sistema sotto carico.

Non viene richiesto, di solito, per i sistemi che verranno distribuiti su un sistema di destinazione autonomo.

 Classi di testabilità nel modello di progettazione

 Elementi di testabilità nel modello di implementazione

Se è necessario che il progetto sviluppi un comportamento specializzato ulteriore significativo per conformarsi e supportare la verifica, queste considerazioni vengono rappresentate dall'inclusione delle classi di testabilità nel modello di progettazione & e degli elementi di testabilità nel modello di implementazione.

Dove richiesto.

Gli  Stub sono una categoria comune di classi di test e di componenti di test.

 Architettura di automazione test

Fornisce una panoramica strutturale del sistema di automazione test, utilizzando un numero di diverse viste strutturali per descrivere i diversi aspetti del sistema.

Facoltativo.

Raccomandato nei progetti in cui l'architettura di test è relativamente complessa, quando uno staff molto numeroso collabora alla creazione di test automatici oppure quando si prevede di mantenere il sistema di automazione test per un lungo periodo di tempo.

In alcuni casi potrebbe essere semplicemente un diagramma lavagna registrato centralmente per le parti interessate al consulto.

 Specifica dell'interfaccia di test

Definisce un insieme richiesto di comportamenti da parte di un classificatore (in modo specifico, una classe, un sottosistema o un componente) a scopo di verifica (testabilità). I tipi comuni includono accesso al test, comportamento stub, registrazione log diagnostica e previsione test.

Facoltativo.

In molti progetti, esiste sufficiente accessibilità per il test nelle operazioni visibili sulle classi, le interfacce utenti ecc.

Alcuni motivi comuni per creare le specifiche d'interfaccia test includono le estensioni UI per consentire ai tool di test della GUI di interagire con il tool e le routine diagnostiche di registrazione log messaggi, specialmente per i processi.



Decidere le modalità di revisione dei prodotti di lavoro

In questa sezione vengono fornite linee guida come supporto per decidere il modo in cui riesaminare i prodotti di lavoro di test. Per una guida generale, consultare Linea guida: Riesaminare i livelli.

Difetti

Il trattamento delle revisioni dei difetti dipende moltissimo dal contesto, tuttavia essi vengono trattati come Informal, Formal-Internal o Formal-External. Questo processo di revisione viene applica spesso oppure almeno è utile per la gestione del flusso di lavoro in un sistema che esegue la traccia dei difetti. Come commento generale, il livello di formalità di revisione spesso è relativo alla gravità percepita oppure all'impatto del difetto, tuttavia fattori come la cultura del progetto ed il livello di formalità spesso condizionano la scelta della gestione della revisione.

In alcuni casi è necessario considerare di separare la gestione dei difetti - noti anche come sintomi o errori - dagli errori; l'origine effettiva dell'errore. Per progetti piccoli, è possibile eseguire la traccia dei soli difetti e gestendo implicitamente gli errori. Tuttavia, se il sistema diviene più complesso, si potrebbe trarre beneficio dal separare la gestione dei difetti da quella degli errori. Ad esempio, è possibile che diversi difetti vengano causati dallo stesso errore. Perciò, se viene corretto un errore, sarà necessario trovare i difetti segnalati ed informare gli utenti che hanno inoltrato i difetti, che è possibile solo se se i difetti e gli errori vengono identificati separatamente.

Piano di test e strategia di test

In qualsiasi progetto in cui la verifica non è rilevante, saranno necessari moduli di strategie o piani di test. Generalmente è necessario un piano di test per ogni iterazione ed alcuni moduli di strategie di test governanti. Facoltativamente è possibile creare e mantenere un piano di test principale. In molti casi, questi prodotti di lavoro vengono riesaminati come Informal; ossia, vengono rivisti, ma non approvati formalmente. Nei casi in cui la visibilità di verifica è importante per gli stakeholder esterni al team di test, è necessario che vengano trattati come Formal-Internal o anche Formal-External.

Script di test

Gli script di test vengono trattati di solito comeInformal; ossia, vengono approvati da qualcuno all'interno del team di test. Se gli script di test devono essere utilizzati da molti tester e condivisi o riutilizzati per molti test diversi, è necessario che vengano trattati come Formal-Internal.

Scenari di test

Gli scenari di test vengono creati dal team di test e - a seconda del contesto - vendono riesaminati di solito utilizzando un processo Informale oppure semplicemente non vengono riesaminati. Laddove appropriato, i casi di test potrebbero essere approvati da altri membri del team nel qual caso possono essere trattati come Formal-Internal oppure da stakeholder esterni, in questo caso sarebbero Formal-External.

Come euristica generale, si consiglia di pianificare solo formalmente la revisione i casi di test per cui è necessario, che di solito sono limitati ad un insieme piccolo che rappresenta i casi di test maggiormente significativi. Ad esempio, se un cliente desidera convalidare un prodotto prima che venga realizzato, è possibile selezionare alcuni sottoinsiemi di casi di test come base per la convalida. casi di test come Formal-External.

Prodotti di lavoro di test nella progettazione e nell'implementazione

Le classi di testabilità si trovano nel modello di progettazione e negli elementi di testabilità nel modello di implementazione. Vi sono anche alti due prodotti di lavoro correlati (sebbene non specifici per il test): i pacchetti nel modello di progettazione ed i sottosistemi nel modello di implementazione.

Questi prodotti di lavoro sono prodotti di lavoro di implementazione e progettazione, tuttavia, vengono creati allo scopo di supportare la funzionalità di verifica nel software. L'ubicazione naturale relativa è con i prodotti di lavoro di implementazione e progettazione. Ricordarne il nome o altrimenti etichettarli in modo che vengano chiaramente separati dalla progettazione e dall'implementazione del sistema principale. Riesaminare i prodotti di lavoro seguendo le procedure di revisione per i prodotti di lavoro di implementazione e progettazione.

Decidere i criteri di approvazione iterazione

Quando si inserisce ogni iterazione, cercare di definire chiaramente anticipatamente la modalità dell'impegno di lavoro di test che verrà giudicato sufficiente e su quali basi tale giudizio verrà valutato. Definire questi elementi con una discussione con il responsabile di gruppo o singolarmente per l'approvazione.

Seguono esempi di modalità di gestione di approvazione dell'iterazione :

  • Il team di gestione del progetto approva l'iterazione e valuta l'impegno di lavoro di test riesaminando i riepiloghi della valutazione dei test.
  • Il cliente approva l'iterazione riesaminando i riepiloghi della valutazione del test.
  • Il cliente approva l'iterazione in base ai risultati di una dimostrazione eseguita da un determinato insieme dei test totali. E' necessario definire e concordare con questo sottoinsieme di test prima di passare, preferibilmente in modo rapido all'iterazione. Questi test vengono trattati come Formal-External e vengono indicati spesso come test di accettazione.
  • Il cliente approva la qualità del sistema conducendo dei test propri indipendenti. E' nuovamente necessario definire chiaramente la natura di tali test prima di passare, preferibilmente in modo rapido all'iterazione. Questi test vengono trattati come Formal-External e vengono spesso indicati come test di accettazione..

E' un'importante decisione - è impossibile raggiungere un obiettivo se non lo si conosce.