Operazione: Definizione dell'approccio al test
Questo compito descrive in che modo definire la strategia di test e le specifiche tecniche che saranno impiegate e illustra l'architettura di automazione del test.
Discipline: Verifica
Scopo

Lo scopo di questo compito è di:

  • Identificare ciascuna tecnica specifica che sarà impiegata per abilitare la verifica desiderata
  • Descrivere le attività di ciascuna tecnica includendo i tipi di verifica supportati
  • Definire un'architettura candidata per il sistema di automazione del test.
Relazioni
Passi
Controllo delle motivazioni e degli elementi del test
Scopo:  Per determinare l'influenza sulla missione, sulle motivazioni e sugli elementi di test nell'approcciare il prossimo impegno di test. 

Utilizzando come contesto la missione di valutazione, verificare il piano di test dell'iterazione ed esaminare le motivazioni che sono state identificate per il prossimo impegno di test. Potrebbe essere necessario effettuare ulteriori verifiche sulla fonte delle motivazioni - di solito il piano di iterazione fornisce un modo per individuare le informazioni aggiuntive.

Per ciascuna motivazione, occorre stabilire l'approccio test e le relative tecniche richieste. Inoltre, verificare il piano del test di iterazione ed esaminare gli elementi del test. Ciascun elemento test di destinazione deve essere considerato in relazione ad ogni motivazione e l'approccio e le tecniche estesi conseguentemente. Se non si è in grado di individuare maggiori dettagli o non si ha dimestichezza con gli elementi del test, potrebbe essere utile discutere gli elementi di destinazione con il personale di sviluppo, iniziando solitamente con l'architetto di software o con i responsabili del team di sviluppo.

Concentrare l'attenzione sull'identificazione della minima serie di tecniche necessaria per affrontare soddisfacentemente la missione di valutazione e le motivazioni. Ricercare le opportunità dove è possibile utilizzare una tecnica per affrontare più di un aspetto della verifica richiesta. Prendere nota di altre potenziali tecniche che sembrano interessanti da esaminare, essendo comunque capace di identificarle come aggiuntivi piuttosto che essenziali.

Controllo dell'architettura software
Scopo:  Per considerare l'influenza dell'architettura software sull'approccio di test. 

Analizzare l'architettura software per acquisire una conoscenza degli elementi-meccanismi chiave, le principali viste e così via. Di solito il documento dell'architettura software fornisce delle ottime informazioni orientate al giusto livello di dettaglio per l'uso nel considerare una strategia di test. Per una giusta interpretazione delle informazioni o in assenza di un documento, è utile discutere l'architettura con il personale di sviluppo, di solito parlando direttamente con l'architetto di software o con uno dei responsabili del team di sviluppo.

Concentrare l'attenzione sull'identificazione e discussione dei meccanismi chiave e sull'acquisizione di una buona conoscenza di questi aspetti del sistema. Ciascun meccanismo e funzione chiave dell'architettura presenterà probabilmente delle sfide e dei vincoli per l'impegno del test. Ad esempio, un'architettura distribuita può richiedere di organizzare il team del test in team secondari, con ciascun team destinato ad un livello strutturale.

Mentre un modo creativo per verificare la strategia di implementazione & esecuzione può spesso essere utilizzato per superare queste sfide, si rende necessario al team di sviluppo modificare il software per attivare l'esecuzione del test come discusso nella sezione Compito: Definizione degli elementi di verificabilità.

Considerazioni sulle ampie valutazioni di approccio al test
Scopo:  Per considerare la completezza dell'approccio di test in termini di ampiezza e profondità. 

Considerando tutti i dettagli ora conosciuti sui requisiti dell'approccio del test, è opportuno fare un passo indietro e considerare l'approccio del test da una prospettiva di livello più alto. Quali sono gli elementi che l'approccio del test dovrebbe evidenziare ma non evidenzia? Ci sono delle considerazioni da approfondire che non appaiono in alcuna delle informazioni documentate?

In base all'esperienza acquisita, revisionare i requisiti per l'approccio del test al fine di ampliare il proprio controllo in questa fase del ciclo di vita del progetto. E' necessario considerare dei requisiti aggiuntivi che aiuteranno a presentare un approccio più completo.

Identificazione delle tecniche di test esistenti per il riutilizzo
Scopo:  Per riutilizzare o adattare le tecniche di test collaudate esistenti, dove appropriato. 

In base alla propria esperienza o di altre pratiche acquisite, identificare le tecniche esistenti che soddisferanno i requisiti dell'approccio al test oppure che possono essere adottate per soddisfarli.

Identificazione di tecniche aggiuntive
Scopo:  Per identificare le tecniche richieste per fornire un approccio al test completo e sufficiente. 

Non è tremendamente utile pensare in termini di approccio test "completo" - esistono sempre delle tecniche aggiuntive che si possono provare se solo si avessero tempi e risorse illimitate.

Tuttavia, è importante che l'approccio al test sia abbastanza completo ed esauriente per consentire una valutazione utile della qualità percepita. Ciò richiede un approccio che valuti sufficienti aspetti del rischio qualità o delle dimensioni di qualità per il team del progetto al fine di valutare la qualità percepita con un livello di confidenza giustificato.

Definizione delle tecniche
Scopo:  Per descrivere le attività di ciascuna tecnica, incluso l'obiettivo della verifica che supporta. 

Descrivere le attività di ciascuna tecnica. Indicare il tipo di verifica che supporta, l'obiettivo e lo scopo, il metodo di implementazione e di valutazione e le necessità di automazione della tecnica.

In molti casi verranno riutilizzate le tecniche da un progetto all'altro. In questa situazione è possibile semplicemente fare riferimento ad una comune definizione della tecnica o copiare la definizione esistente e controllarla opportunamente.

Per ciascuna tecnica esistente o richiesta:

Definizione degli obiettivi e dell'ambito Inizio pagina

Molte tecniche supporteranno più di un tipo di verifica, pertanto occorre prestare attenzione nell'identificare quali test la tecnica dovrà supportare. Ciò aiuta ad identificare l'obiettivo dell'impegno richiesto se la tecnica viene definita per la prima volta.

Riflettere sull'obiettivo e sul valore sottostanti che questa tecnica rappresenta.

Descrizione del metodo di implementazione Inizio pagina

Definire in che modo verrà implementata la tecnica. Non è sufficiente semplicemente affermare "Si stanno verificando le prestazioni del sistema"-occorre seriamente considerare in che modo è possibile completare questa operazione.

Alcune tecniche che si intendono utilizzare non saranno economiche da perseguire. Mediante una breve descrizione su come si intende accostarsi all'implementazione di questa tecnica, sarà possibile avere un quadro completo della logistica interessata e della praticità di perseguire più avanti questa tecnica.

Identificazione del metodo di valutazione appropriata Inizio pagina

Stabilire in che modo si osserveranno e valuteranno i risultati di ciascun test implementato utilizzando questa tecnica. Considerare le diverse previsioni di test che sono disponibili - esiste un'unica previsione o vi sono modi diversi per determinare il risultato di ciascun test?

Identificazione dell'uso applicabile dell'automazione Inizio pagina

L'automazione può giocare un ruolo importante in molte tecniche di test. In alcuni casi sarà meno complessa, fornendo semplicemente un supporto per la conduzione dei test manuali.

Riflettere in che modo il lavoro che utilizza questa tecnica può essere efficacemente implementato, sostenuto e gestito. Occorre essere di ampie vedute, considerando quante più opzioni possibili.

Identificazione dei tool applicabili Inizio pagina

Identificare i tool appropriati da utilizzare con questa tecnica di test. Utilizzare il lavoro della fase successiva che ha identificato gli impieghi dell'automazione.

Ricordarsi di considerare una vasta gamma di categorie di tool; il proprio elenco di tool candidati deve includere più tool di quelli solo per l'automazione di esecuzione del test. Oltre ai tool che automatizzano l'esecuzione del test, utilizzare i tool che miglioreranno la produttività del team di test riducendo le attività ripetitive e laboriose, come i tool per la gestione dei dati del test, l'analisi dei risultati e la notifica degli errori e delle richieste di modifica, ecc.

Descrizione dell'architettura di automazione test
Scopo:  Per definire un'architettura candidata per il sistema di automazione del test. 

Sulla base dell'esperienza acquisita in sistemi analoghi o in simili domini di problemi, definire un'architettura candidata per il sistema di automazione del test.

È consigliato il controllo delle informazioni relative allo sviluppo dell'architettura software per ricevere assistenza su questa attività.

Definizione della strategia per la gestione della configurazione della risorsa del test
Scopo:  Per identificare i requisiti che il test avrà per la gestione della configurazione. 

Come molti altri prodotti di lavoro realizzati durante un progetto di sviluppo software, le risorse del test sono candidate per la gestione della configurazione e il controllo della versione.

I requisiti specifici possono essere complessi, con la decisione di utilizzare dei servizi di recupero e di backup basilari abilitati, oppure di pieno supporto per lo sviluppo parallelo di script di test automatizzati in più siti rispetto a diverse versioni di un'applicazione.

Delineare i propri requisiti per la gestione della configurazione e descrivere le necessità logistiche probabili per realizzare quei requisiti.

Valutazione della disponibilità delle risorse riutilizzabili
Scopo:  Per ridurre il rischio e l'impegno riutilizzando le risorse sperimentate esistenti. 

A volte può avere senso realizzare delle nuove risorse e altre volte non lo ha. Stabilire un buon equilibrio tra una propria filosofia "autonoma" e un rigido e burocratico criterio di creazione di un nuovo prodotto di lavoro.

Può verificarsi che in determinati casi un approccio sia migliore di un altro; occorre essere sufficientemente flessibili per trarre vantaggio dai benefici che entrambi gli approcci apportano.

Cattura dei risultati
Scopo:  Per registrare informazioni importanti sull'approccio del test. 

Subordinato da un numero di fattori, inclusi la dimensione del team e la cultura dell'organizzazione, ci saranno modalità migliori e peggiori per registrare le proprie decisioni sull'approccio del test.

Si avranno tipicamente due tipi di audience da considerare: il team di gestione intenderà revisionare queste informazioni per fornire un'approvazione ed essere al corrente di implicazioni logistiche dell'approccio e il team del test che intenderà utilizzare l'approccio come guida per il lavoro da intraprendere. Individuare un mezzo appropriato per affrontare entrambe le esigenze: probabilmente utilizzando un sito web Intranet del progetto.

Valutazione e verifica dei risultati
Scopo:  Verificare che il compito sia stato completato in modo appropriato e che i prodotti di lavoro risultanti siano accettabili. 

Una volta completato il lavoro è bene verificare che questo sia stato di buona qualità, e che non si siano consumate unicamente grosse quantità di carta. È necessario valutare se il proprio lavoro sia stato all'altezza, e che sia completo abbastanza da essere utile ai membri del team che l'utilizzeranno in seguito. Dove possibile, utilizzare l'elenco di controllo fornito da RUP per verificarne la qualità e la completezza.

Richiedere ai componenti del team di concentrarsi sul flusso di operazioni che hanno come input il vostro lavoro e partecipare all'analisi effettuata durante il suo corso. Procedere in questo modo mentre si ha ancora tempo a disposizione per prendere decisioni e discutere delle loro considerazioni. È inoltre necessario considerare il proprio lavoro nei confronti dei prodotti di lavoro di input chiave, per assicurarsi che siano stati rappresentati in modo accurato e sufficiente. Potrebbe essere utile chiedere all'autore del prodotto di lavoro di input di revisionare il vostro lavoro su queste basi.

Tenere presente che RUP è un processo di produzione iterativo e che in molti casi i prodotti di lavoro evolvono nel tempo. Su questa base è spesso non necessario o addirittura controproducente, definire in modo completo un prodotto di lavoro che verrà utilizzato solo parzialmente o affatto, nel lavoro immediatamente successivo. Questo perché vi è un'alta probabilità che il contesto che circonda il prodotto di lavoro possa cambiare e che i presupposti definiti, quando questo è stato creato, possano dimostrarsi errati prima del suo utilizzo, portando così al dispendio inutile di sforzi ed ad ulteriori costi di rilavorazione. Non effettuare inoltre troppi cicli sulla presentazione per evitare il detrimento del valore del contenuto. Negli ambienti di progetto dove la presentazione ha la medesima importanza e valore economico di un componente distribuibile, è bene considerare la possibilità di utilizzare una risorsa amministrativa per il compito di presentazione.



Ulteriori informazioni