Operazione: Obtain Testability Commitment
In questa attività si punta l'attenzione sulla definizione, l'assegnazione di priorità, e la promozione delle necessità e dei vantaggi della verificabilità.
Scopo

Lo scopo di questo compito Š di:

  • Promuovere la creazione di software verificabile che supporta le necessità dell'impegno di test
  • Promuovere e supportare l'utilizzo delle tecniche e dei tool di automazione appropriati
Relazioni
Passi
Esame delle necessità di verificabilità
Scopo:  Comprendere bene le necessità di implementazione e valutazione del test da soddisfare tramite il processo di distribuzione di software o l'architettura e il progetto del software. 

Studiare l'architettura di automazione e le specifiche dell'interfaccia di test per ottenere una buona comprensione delle necessità di implementazione e di valutazione del test. In particolare, comprendere i vincoli che tali necessità imporranno sia sul processo di distribuzione del software che sulla relativa architettura e progettazione.

Valutazione dell'impatto e assegnazione della priorità
Scopo:  Identificare le necessità di verificabilità più importanti per l'impegno di test e sostenerne la risoluzione prima di quelle minori. 

Studiare le necessità di verificabilità ed eseguire l'analisi di impatto di base nei termini dell'impatto sull'impegno di test le cui necessità non sono soddisfatte. Considerare anche alcune analisi di base dell'impegno potenziale richiesto dal team di sviluppo per indagare e fornire una soluzione per le necessità. Per ogni necessità, identificare le soluzioni potenziali alternative che avrebbero un impatto inferiore sui team di sviluppo.

Utilizzando queste informazioni, formulare un elenco di priorità che posizioni prima le necessità con un grande impatto sull'impegno di test, se non vengono soddisfatte, e che non dispongono di soluzioni alternative. Fare ciò per evitare lo spreco di risorse di sviluppo di valore su necessità di verificabilità meno essenziali, riservandosi tale opportunità per quelle realmente importanti.

Definizione dei vantaggi della verificabilità
Scopo:  Essere in grado di vendere il valore delle necessità di verificabilità agli stakeholder in termini di costi/benefici di base.  

Chiedendo al team di sviluppo di sviluppare software con misure specifiche per l'impegno di test, si aggiungeranno ulteriori requisiti e vincoli all'impegno di sviluppo; ciò significa essenzialmente più lavoro e ulteriori rischi e complessità per il team di sviluppo. Alcuni team di sviluppo vedranno la progettazione per la verificabilità come al di fuori dello scopo della loro responsabilità. In altri casi, le necessità di verificabilità dovranno competere per le risorse di sviluppo con le necessità e i requisiti dei clienti a cui verrà data, di solito, maggiore priorità. Perciò, occorre "vendere" i vantaggi delle necessità di verificabilità al responsabile del progetto, all'architetto del software e agli altri stakeholder del team di sviluppo.

Formulare un'analisi dei vantaggi di ogni necessità di verificabilità che si desidera fare ottenere al committente. Cercare giornali, articoli e studi che supportino il valore della necessità della verificabilità e utilizzare le statistiche ROI, dove disponibili. Pensare ai vantaggi in termini di valore fornito al team di sviluppo; quali informazioni utili vengono fornite agli sviluppatori che altrimenti non riceverebbero se questa necessità di valutazione non venisse soddisfatta? In che modo ciò renderà più semplice ed efficiente la fornitura al team di sviluppo di un riscontro tempestivo, accurato e approfondito durante ogni ciclo di build? Questa necessità fornisce al team di sviluppo una caratteristica utile che può essere utilizzata nel loro impegno di test o in future diagnosi di errori software? Nel caso di competizione con le necessità del cliente, considerare i modi in cui è possibile dimostrare che fornendo prima una soluzione alla necessità di verificabilità, verranno fornite ulteriori opportunità per i requisiti del cliente da supportare nei successivi cicli di build.

Identificazione e impiego dei campioni di verificabilità
Scopo:  Formare alleanze con importanti stakeholder che sosterranno la creazione di software verificabile e il supporto delle necessità dei team di test a tal riguardo. 

Poiché verrà imposto potenzialmente ulteriore lavoro e rischio al team di sviluppo, occorre identificare e impiegare gli stakeholder autorevoli che hanno la capacità di approvare o dare mandato per il supporto della verificabilità. A tal fine, attivarsi il più presto possibile, prima di promuovere attivamente le necessità di verificabilità che si desidera supportare.

I tre stakeholder più importanti sono l'architetto del software, il responsabile di progetto, il rappresentante del cliente. Impiegare il tempo con l'architetto del software e promuovere il valore della creazione di un'architettura software che supporti la verificabilità. Impiegare il tempo con il responsabile del progetto e promuovere i vantaggi della verificabilità in termini di produttività del team di test e passare velocemente alle informazioni di valutazione. Incoraggiare il cliente a porre valore su un prodotto di qualità che viene distribuito.

Promozione delle necessità e dei vantaggi della verificabilità
Scopo:  Informare gli stakeholder principali dell'importanza delle necessità di verificabilità dell'impegno di test e ottenere il loro supporto per la verificabilità. 

È importante promuovere le necessità di verificabilità nel modo giusto. Ogni combinazione di stakeholder di responsabile di progetto, di team di sviluppo e di cliente ha una diversa dinamica sociale e cultura ed è importante essere sensibili a ciò quando si promuovono le necessità di verificabilità. Come euristica generale, non presentare una "campagna" di verificabilità formale se il team è relativamente accomodante e informale e non utilizzare un approccio informale in un progetto a elevata formalità.

In alcuni casi, una sessione collaborativa di "brainstorming" rappresenta un utile formato di presentazione, dove la necessità viene presentata come una sfida per il team di sviluppo, che viene incoraggiato a identificare soluzioni creative per soddisfare la o le necessità di verificabilità. Ciò incoraggia i rispettivi titolari della soluzione e favorisce un sentimento associativo nel tentativo.

Per questa fase è importante anche la scelta del momento opportuno. Come regola generale, si dovrebbe provare a identificare e promuovere i problemi di verificabilità più importanti prima possibile, generalmente durante l'elaborazione e, dove possibile, nella fase iniziale. Quando i problemi di verificabilità vengono esposti in questa fase anticipata del progetto, il team è di solito più piccolo e più favorevole alle modifiche. È anche più facile includere queste necessità nel progetto in evoluzione come minima rilavorazione che viene solitamente richiesta.

Un buon sistema per identificare le necessità di verificabilità e presentarle in modo positivo e meno "ufficiale" è quello di fare offrire al team di test i propri servizi in attività di valutazione di prova e nella valutazione della selezione di componenti di terze parti per l'utilizzo nell'impegno di sviluppo. In particolare, il coinvolgimento del team di test durante la selezione del componente di database, la selezione del controllo UI o del componente, dei componenti middleware ecc, significa che i problemi di verificabilità possono essere utilizzati come un aspetto del criterio di selezione del componente. Ad esempio, in molti casi i team di sviluppo avranno un interesse minimo su quale libreria widget UI utilizzeranno; se una libreria è più verificabile di un'altra, il team di sviluppo sarà felice di selezionare la libreria widget più verificabile.

Se si hanno problemi nell'identificazione o nell'impiego dei sostenitori, può essere necessario considerare un approccio che introduca le modifiche in modo più incrementale, rendendole potenzialmente meno rischiose e favorendo blocchi di sforzo minori oppure può essere necessario aggravare le necessità di verificabilità più importanti come problemi critici del progetto che impediscono il successo dell'impegno di test fino a quando non vengono risolti. Nell'ultimo caso, si consiglia di considerare attentamente tutte le opzioni prima di decidere per questa azione.

Ottenere l'impegno per supportare e sostenere la verificabilità
Scopo:  Ottenere un accordo per cui il team di sviluppo continuerà a supportare e sostenere le caratteristiche della verificabilità. 

È importante assicurare che le necessità di verificabilità vengano considerate al pari di qualsiasi altro requisito o vincolo nell'impegno di sviluppo. È necessario essere sicuri che le caratteristiche di verificabilità disponibili attualmente non vengano abbandonate in futuro.

In alcuni casi, il tentativo di ottenere tale impegno può generare il rifiuto del team di sviluppo di sviluppare o supportare le necessità di verificabilità. Anche se questa situazione può essere demoralizzante, è meglio esserne consapevoli e occuparsi di questa realtà prima possibile; è molto peggio impiegare molto tempo e impegno nello sviluppare un'implementazione di test il cui supporto verrà abbandonato dal team di sviluppo.

Sostenere la risoluzione dei problemi di verificabilità
Scopo:  Monitorare e sostenere la risoluzione dei problemi di verificabilità. 

Mentre il team di sviluppo può concordare di fornire il supporto necessario per le necessità di verificabilità dell'impiego di test, è importante interessarsi attivamente della progettazione, implementazione e completamento di questo lavoro. Non abbandonare l'interesse poiché il team di sviluppo ha acconsentito al supporto delle necessità di verificabilità oppure ha iniziato a lavorare su una soluzione; è necessario assicurare che venga sviluppata una soluzione appropriata in tempi ragionevoli.

Rendersi insieme all'altro personale del team di test prontamente disponibili per rispondere alle domande del team di sviluppo e offrirsi per valutare i prototipi non appena vengono creati. Offrire un riscontro costruttivo e mostrare entusiasmo per l'impegno che il team di sviluppo ha inserito nell'aiutare a soddisfare le proprie necessità. Offrire la disponibilità del proprio personale a frequentare o agevolare i laboratori di progettazione per le necessità di verificabilità più complesse, ma guardarsi bene dall'avere personale arrogante e che controlla lo spazio delle soluzioni del processo di progettazione per gli sviluppatori.

Laddove emergono problemi e si avverte l'assenza di adeguata attenzione o premura nel risolverli, esporre i propri problemi all'architetto del software e al responsabile del progetto. Fare annotare al responsabile del progetto un problema sull'elenco dei problemi di progetto, se appropriato.

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.



Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile