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.
|
|