Parliamo questo mese di un aspetto meno tecnico ma assolutamente non secondario del ciclo del software, che assume importanza anche in fase di collaudo: la tempificazione e la valutazione dei rischi. Questi due aspetti sia isolatamente che in sinergia fra loro permettono un efficientamento delle attività di test e un regolare ciclo di vita del prodotto, in modo da poter rispettare in pieno tempi e caratteristiche richieste dall’utilizzatore finale.
Partiamo sinteticamente da due definizioni
– La tempificazione è l’attività attraverso cui ad ogni scenario e sotto-caso di test viene attribuito un tempo di realizzazione.
– La valutazione dei rischi è l’attività attraverso la quale è possibile attuare la tempificazione ottimale.
Quindi una buona tempificazione poggia su una buona valutazione del rischio e ne è gerarchicamente legata. Una sottostima anche di un solo di questi elementi porta a un test NON esaustivo e non attendibile; pertanto ad essi deve essere riservato un tempo ragionevole nella pianificazione delle attività. Infatti tempificare e valutare vuol dire testare, in modo inequivocabile. Entriamo ora nel dettaglio della tematica.
1. La tempificazione
Partendo dalla definizione base di cui sopra, cerchiamo di esplicitare meglio il concetto. Tempificare vuol dire attribuire un tempo a un’azione o a un elemento. Assume particolare rilevanza come tempificare e perché.
Innanzitutto come: attraverso una scomposizione in insiemi elementari di fattori o dati. Più è bassa la granularità del caso di test, più facile sarà valutarlo (pensiamo a una maschera che estrae dati e li mostra in una griglia tabellare applicandovi delle formule).
Quali sono le fasi elementari in cui si svolge l’elaborazione? Rifacendoci a un’analisi funzionale e tecnica avremo ad esempio: lettura dei dati, manipolazione del dato ed esposizione del dato. A sua volta, per ottimizzare performance e tempi, il dato può essere “caricato in struttura” ossia letto una volta e mantenuto dinamicamente in memoria per poter essere disponibile subito a procedura accessorie (una stampa ad esempio o un’esportazione in formato PDF o Excel).
Tutte queste caratteristiche vanno esaminate singolarmente e nelle loro iterazioni, in modo da formulare un tempo stimato di test a cui aggiungere un lasso di tempo “salvagente” da utilizzare se necessario per eventuali ritorni o problematiche contingenti.
Occorre poi aggiungere un tempo più o meno variabile riservato alla ricerca e/o verifica di eventuali regressioni. Nel timing di test occorre naturalmente comprendere anche le attività collaterali di confronto con altri enti aziendali per reperire, valutare e interpretare le informazioni necessarie alla tempificazione.
Da ultimo, poniamo particolarmente in risalto un aspetto solitamente poco considerato storicamente negli approcci al test rigidi (pensiamo al vecchio waterfall) che ormai è uno standard nei moderni approcci agile: per poter tempificare occorre addentrarsi nel tecnico, comprendere e conoscere termini e aspetti tecnici e “affinare” il test sia a livello valutativo (oggetto del presente articolo) sia a livello esecutivo (argomento dei precedenti articoli).
2. La valutazione dei rischi
La conoscenza del lato tecnico del programma rappresenta un plus anche e soprattutto quando si dovrà analizzare la valutazione dei rischi. Con il termine “rischio” si indica genericamente la propensione di una correzione, di un adeguamento funzionale o di una nuova funzionalità ad avere impatti involutivi su altre funzioni già disponibili sullo stesso prodotto o su prodotti di famiglie differenti.
Obiettivo principale della valutazione del rischio lato deploy è quello di minimizzare gli impatti invasivi e tollerare quelli di bassa gravità. Per quanto riguarda il lato collaudo, invece, occorre tenere in considerazione i feedback ricevuti dall’area sviluppo, tenendo in particolare conto delle modalità con cui la funzionalità in fase di rilascio è stata implementata.
I principali fattori che influenzano temporalmente la tempificazione sono:
- la tecnologia utilizzata (vb6, .net, c#, java, html);
- la struttura dei dati e gli accessi ad essi (query esplicite, strutture dati, eventuali cache da gestire);
- metodi utilizzati per le elaborazioni massive e/o calcoli (in loco nell’eseguibile, effettuati in componentistica centralizzate).
- modalità di rappresentazione dei dati (ad esempio se viene utilizzata una griglia flexgrid oppure truedb).
Come già accennato la conoscenza di questi elementi orienta moltissimo la tempificazione e, in seguito, la test execution manuale o automatizzata che sia.
Da ultimo, come sempre, un breve accenno agli scenari in cui la tempificazione deve essere obbligatoriamente inserita nel ciclo del software. Tipicamente, ormai tutte le aziende modernamente organizzate, istituzionalizzano nei propri iter procedurali interni la fase di tempificazione e valutazione rischi come parte integrante del test. Essa assume particolare rilevanza in tutti quei contesti in cui il time to market è molto breve o in cui le funzionalità devono soddisfare esigenze normative dettate da organismi istituzionali nazionali o internazionali oppure in quelli in cui l’importanza del dato comunicato o elaborato è di primaria importanza (banche, assicurazioni, finanza).
Conclusioni
Ma perché tempificare? Rispondiamoci con una massima popolare: “Prevenire è meglio che curare”. Anticipare aiuta, sapere già che il collaudo ci costa n giorni con y percentuale di rischio è importante per tutti gli enti aziendali: collaudo, sviluppo, marketing e commerciale.
Ecco la forza di chi si occupa del test: è l’ultimo anello del ciclo di vita del software, ma con la precisione esecutiva e l’accuratezza valutativa è il cardine di tutto il processo perché dal basso aiuta chi sta in alto. Pensiamo a un manovratore di un mezzo di sollevamento edile: ha i piedi piantati a terra e le transenne attorno, ma comanda un mezzo con a bordo altre persone. Con intelligenza, astuzia e prudenza evita conseguenze negative per tutti.
Con questa immagine, vi congedo e vi do appuntamento al prossimo articolo!
Articoli correlati
Leggi l’articolo successivo su casi e scenari di test.