martedì 4 settembre 2012

Mobile App Testing

Per le applicaizoni mobile l'approccio al testing, indipendentemente dal modello seguito per lo sviluppo, è decisamente cambiato per far fronte ai principali "problemi" legati alla natura di questo tipo di applicazioni, ed in particolare:

  • L'usabilità, o meglio la differente Esperienza Utente rispetto alle applicazioni tradizionali, fattore che spesso determina il successo o il fallimento di un'app
  • La compatibilità relativamente alle molteplici combinazioni HW/SW su cui l'app deve essere eseguita
  • I problemi legati alla connettività e all'interazione con altre funzionalità dei dispositivi mobile, quali chiamate o messaggi

Il Test Funzionale deve essere integrato da famiglie e casi di test che includano la verifica di aspetti quali l'interazione tramite touchscreen, la possibilità di eseguire le applicazioni in modalità portrait e landscape, la capacità di imprimere movimento.

Il possibile numero di combinazioni HW/SW, problema particolarmente sentito per i telefoni Android, rende difficile, se non impossibile la verifica delle applicazioni su tutti i dispositivi disponibili sul mercato, senza considerare le diverse combinazioni dettate dalla versione del sistema operativo e dalle diverse dimensioni (risoluzioni) degli schermi.

Dal punto di vista del Test Non Funzionale va innanzitutto considerato il vasto target di utenza, con gusti e tipologie d'interazione differenti, il consumo della batteria del dispositivo, le interazioni con chiamate e/o messaggi in ingresso, il consumo di memoria, ed in caso di applicazioni che scrivono in locale sul file system l'occupazione della memoria.

Ultimo ma non meno importante, il fattore legato all'operatore telefonico (test da effettuare dopo la verifica con la rete wireless), poichè in base al segnale e la relativa qualità del servizio, l'applicazione può performare in modo differente, ed in caso di assenza di connettività non deve bruscamente interrmpere la propria esecuzione.

Questi sono solo alcuni degli aspetti funzionali e non funzionali che hanno portato al cambiamento di approccio al testing per le applicazioni mobile, aspetti che devono assolutamente essere tenuti in considerazione dai Software Test Engineer e Manager nella pianificazione e progettazione delle attività di test.



lunedì 3 settembre 2012

Quanto costa la Qualità?


Di primo acchito si potrebbe pensare che la Qualità rappresenti un costo, e la domanda sorge spontanea: quanto costa la Qualità?

Rispondere nulla potrebbe apparire insensato, quindi vediamo quali sono i principali costi della Qualità e cerchiamo di quantificarli, in modo da dare fondamento a questa affermazione.

Possiamo raggruppare i costi in due categorie principali:
  1. Costi di Prevenzione (CP), quali formazione legata all’ Assicurazione Qualità, revisione del codice, pianificazione delle attività di Controllo Qualità, progettazione e realizzazione dei Casi di Test, esecuzione dei Casi di Test, produzione della reportisitica,etc...
  2. Costi dovuti ai fallimenti/insuccessi (CF), e qui possiamo ulteriormente distinguere tra:
    • Costi legati ai fallimenti interni (CFi), che vengono introdotti direttamente durante lo sviluppo, quando il programmatore, provando il codice appena prodotto, rileva dei difetti, che deve quindi correggere e successivamente ri-verificarne l’assenza. L’applicazione del testing formale introduce anch’essa un CFi, perchè il tester, eseguento i Casi di Test, rileverà e riporterà al programmatore dei difetti, che dovranno essere risolti e ri-testati una volta che il  fixing viene rilasciato nell’ambiente di test.
    • Costi legati ai fallimenti esterni (CFe), che vengono introdotti quando al posto di un tester e/o uno sviluppatore, è il Cliente o l’Utente finale a rilevare i difetti. Questi costi sono decisamente più alti rispetto ai precedenti, perchè in aggiunta a quello legato all’attività di testing spiegato poc’anzi, vanno considerati il supporto al Cliente, un flusso di comunicazione più lungo per raggiungere il programmatore responsabile del fixing, l’attività di rilascio di una hot-fix sulla versione ufficiale e non solo nell’ambiente di test. Ci sono inoltre costi non tangibili, come l’insoddisfazione del Cliente, l’eventuale perdita di business, il danno all’immagine Aziendale e nella peggiore delle ipotesi cause legali o penali da corrispondere.
Un ipotetico caso di studio

Vediamo ora un esempio per illustrare quale sia il ROI nell’applicare il testing. I valori economici, sebbene indicativi, rappresentano in percentuale un caso reale.

Supponiamo di dover realizzare per un nostro Cliente, un’applicazione web il cui sviluppo è stimato in 200 Giorni/Uomo, che però debba venir rilasciata al Cliente in 4 mesi di calendario.

Supponendo di avere 3 sviluppatori assegnati, e che ognuno di essi introduca in media due bugs per ogni giorno di sviluppo, si raggiunge un totale di 1200 bugs.

Se il costo legato alla risoluzione dei bugs rilevati dai programmatori viene definito pari a 40 Euro ciascuno e quello relativo ai bugs rilevati dal Cliente pari a 400 Euro, supponendo che i programmatori ne rilevino il 25% e che il resto sia rilevato poi dal Cliente, arriviamo ad un totale di costo della Qualità pari a 372.000 Euro come illustrato in figura:


Introducendo formalmente il testing nel progetto, e supponendo che il costo legato alla risoluzione dei bugs rilevati dai tester sia pari a 200 Euro,  e che ne vengano rilevati il 35% durante la fase di testing, arriviamo ad un totale di costo della Qualità pari a 288.000 Euro come illustrato in figura:


In questo modo, si è all’incirca dimezzato il numero di bugs rilasciati al Cliente, e si è ridotto il costo totale della Qualità di 84.000 Euro.

Per calcolare il ROI, dobbiamo tenere in considerazione l’investimento fatto per il testing, e per semplificare parliamo di testing manuale eseguito da un solo tester. Ci sono due possibilità:
  1. Team interno: la risorsa è in forza all’Azienda in modo permanente, con un costo annuo pari a 70.000 Euro.
  2. Outsourcing: ci rivolgiamo ad un Azienda che eroga servizi di Software Quality Control, e richiediamo la risorsa per il tempo necessario (messo a budget).
Nel primo caso il ROI risulta limitato, anche se dobbiamo considerare che la risorsa, quando non impiegata sul progetto portato come esempio, possa lavorare anche su altri progetti, ma ovviamente il periodo pianificato per il testing non deve sovrapporsi, altrimenti dobbiamo prendere più risorse introducendo un overhead notevole azzerando, se non rendendo addirittura negativo il ROI. Nell’esempio in questione, il ROI risulta pari al 20% :

  • Costo del test = 70.000 Euro
  • Riduzione lorda del costo totale della Qualità = 84000
  • Riduzione reale = 14.000
Nel secondo caso siamo più tutelati, perchè abbiamo la garanzia di avere a disposizione la risorsa esattamente quando ci serve, senza dover sostenere dei costi quando la stessa risulta inattiva. In questo caso il ROI risulta pari al 230% :

  • Costo del test = 25.600 Euro (40 x Rate giornaliero del tester) dove 40 sono i giorni/uomo di test stimati come 20% sullo sviluppo.
  • Riduzione lorda del costo totale della Qualità = 84000
  • Riduzione reale = 58.400
Abbiamo quindi illustrato come l’introduzione del testing non solo porti ad un contenimento dei costi, ma che se esternalizzato porta sicuri vantaggi in termini di massimizzazione del valore aggiunto dato al prodotto software sviluppato.

Affidandoci ad aziende che offrono servizi di testing in modo esclusivo, abbiamo sempre la garanzia di avere a disposizione risorse molto preparate e concentrate su questo tipo di attività. Inoltre, siccome nel mondo reale è normale, se non addirittura consuetudine, avere degli slittamenti della timeline, causa fattori interni (sviluppo non proprio efficiente, problematiche tecniche, ...) ed esterni (requisiti non chiarissimi, che arrivano in ritardo, richieste di cambiamento dell’ultimo minuto,...), anche facendo la miglior pianificazione, spesso e volentieri i piani saltano, e a rimetterci è quasi sempre la qualità, talvolta rischiando di “danneggiare” un progetto piuttosto che un altro causa insufficienza di risorse di test.

Non è nemmeno pensabile mantenere un team di test più grande del dovuto, perchè altrimenti i costi si impennano velocemente riducendo drasticamente i ricavi.

Software Testing Coaching


Anche quando gli obiettivi, aziendali o di progetto, risultano chiari, talvolta l'efficacia e le performance del team non sono ottimali.

La Strategia, i processi e le metodologie implementate spesso non risultano sufficienti per il raggiungimento dei migliori risultati.


Una trasformazione rivolta a migliorare ed amplificare le proprie potenzialità per raggiungere obiettivi personali, di team e manageriali è sicuramente il processo che mette a disposizione gli strumenti che permettono di elaborare ed identificare i propri obiettivi e nel contempo rafforzare la propria efficacia e la propria prestazione.


IxmaSoft aiuta i propri Clienti in questo processo di trasformazione, fornendo tutti gli strumenti necessari per scoprire ed utilizzare le potenzialità latenti dei membri del Team di Software Testing, agendo come facilitatore del cambiamento, stimolando ed indirizzando le energie ed aiutando a prendere consapevolezza delle proprie potenzialità.


Per maggiori informazioni: http://www.ixmasoft.it/coaching.html