64 / 86
SOFTWARE
|
QUALITÁ
64
EMBEDDED
55 • FEBBRAIO • 2015
market”. Spesso, gli eccessivi timori fanno per-
dere il vantaggio della “prima mossa”, optando
per l’attesa del completamento dei test. Tuttavia,
sacrificare la qualità per il “time to market” è una
scelta sempre molto pericolosa, che può avere un
significativo effetto negativo anche sul valore del
marchio.
Come è possibile soppesare l’equilibrio tra quali-
tà e tempi di commercializzazione? Un esempio
del normale ciclo di vita del prodotto in una ap-
plicazione software è riportato in figura 1.
Nel diagramma di figura la linea etichettata 1.0
è la prima release per i clienti; le linee che si spo-
stano a destra rappresentano i successivi rilasci,
quando i bug sono stati corretti, e vengono rila-
sciate le funzionalità che mancavano nella ver-
sione 1.0. La linea etichettata con “?” è il punto in
cui gli utenti sono soddisfatti dalla qualità e dal-
le caratteristiche del prodotto. Il Quality Deficit
(Deficit di Qualità) si posiziona tra la prima ver-
sione del prodotto e il momento in cui il mercato
considera quel prodotto di buona qualità. Ridurre
al minimo o eliminare il Quality Deficit dovrebbe
essere in cima alla lista delle priorità di ogni or-
ganizzazione che sta realizzando software.
Una seconda sfida che i team di sviluppo devono
affrontare è l’assegnazione e la suddivisione delle
risorse di sviluppo tra la stesura dei requisiti, la
progettazione, la codifica ed il test. Storicamente,
il flusso di lavoro è sempre stato impostato come
mostrato nello schema di figura 2.
Nella maggior parte dei team di sviluppo, la
priorità più alta viene posta sulla codifica, con
meno enfasi sulla scrittura dell’interfaccia API
(Application Programming Interface) e sulla
preparazione dei testcase. In generale, infatti,
i manager assegnano il personale più esperto
alla codifica del prodotto, e quello junior al test.
La convinzione di Vector Software è che questo
modello debba essere completamente invertito.
Le componenti più importanti nello sviluppo del
software sono un’interfaccia API completa e fles-
sibile e i testcase che dimostrano la correttezza
di questa API.
Se si sviluppano in maniera intelligente ed effi-
ciente l’interfaccia API e i test che ne verificano
il corretto comportamento, la scrittura del codi-
ce vero e proprio potrà essere affidata a persona-
le junior, il codice potrà essere nuovamente re-
ingenerizzato con fiducia e la qualità risultante
sarà notevolmente migliorata.
Un terzo problema è che la maggior parte dei
team mantiene una grande varietà di testcase
(Fig. 3), e ogni diverso gruppo nell’organizzazio-
ne “possiede” il proprio tipo di testcase. È molto
comune per gli sviluppatori creare e gestire i test
di basso livello, mentre il reparto di Quality As-
surance (QA) è responsabile per gli altri test, di
livello superiore. I test di QA sono generalmente
eseguiti solo dopo diverse settimane di svilup-
po, quando cioè centinaia di modifiche ai sorgen-
ti sono già state integrate nella base di codice.
Ciò rende laborioso e frustrante trovare la causa
principale di un test fallito. La soluzione a questo
problema è quella di trattare tutti i casi di test
come una risorsa preziosa dell’organizzazione, e
sfruttarli per tutto il team e per tutto il ciclo di
vita delle applicazioni. Rendere disponibili tutti i
test case per tutti i componenti del team, li rende
facili da eseguire, e con maggior frequenza.
Vector Software è impegnata nell’aiutare i team
di sviluppo ad affrontare le sfide sopra descritte.
La società fornisce ai gruppi una suite di prodotti
che consentono ai test di essere facilmente utiliz-
zati da tutti i componenti, durante l’intero ciclo di
vita dello sviluppo, oltre ai corsi e alla formazione
sui processi di sviluppo e test, e alla consulenza
per rendere l’attuazione più efficiente possibile.
Lo staff presente in tutto il mondo e i 20 anni di
Fig. 2 – Schematizzazione del normale flusso di
lavoro