Se c’è una cosa importante quando sviluppate un software è il testing. Come tante affermazioni, questa può sembrare scontata ma, credetemi, non lo è affatto.
E non sto parlando di Unit Testing quanto di vero e proprio test funzionale e di usabilità dell’applicazione che state andando a sviluppare.
Se avete seguito i punti precedenti di questa serie di articoli, a questo punto avrete già sviluppato una buona parte del vostro codice. Le prime pagine avranno preso forma ed i primi dati avranno iniziato a popolare le vostre form. A questo punto vi porgo una domanda: quanti di voi hanno installato la propria applicazione sul dispositivo? Quanti di voi hanno iniziato ad usare le funzionalità già sviluppate?
In genere, la risposta che ottengo a questa domanda è NO.
Ed i motivi che giustificano questa risposta sono sintetizzabili in questa affermazione:
NO perché l’applicazione NON E’ COMPLETA
Se la vostra risposta è riconducibile a quella riportata qui sopra, state sbagliando qualcosa e, questo errore, potrebbe farvi perdere davvero molto tempo per finalizzare l’applicazione.
Se state lavorando su una applicazione amatoriale, questa situazione potrebbe non essere un problema. Ma se state lavorando per una applicazione commerciale, per cui è previsto un lancio, potreste perdere parecchie ore di sonno.
Ma vediamo il perchè, spesso, si arriva alla risposta di sopra.
In generale, il problema nasce nel momento in cui, partendo dal vostro disegno di cui abbiamo parlato qui, decidete come dividere lo sviluppo. E’ in questa fase che si commette il primo vero errore, ossia quello di lavorare sui parti dell’applicazione tra loro slegate. Come potete facilmente intuire, lavorando su parti tra loro slegate, non sarà mai possibile testare un ramo dell’applicazione.
Quando decidete cosa sviluppare, fatelo seguendo una logica che vi permetta di completare un ramo dell’applicazione che sia installabile su un dispositivo ed usabile.
Personalmente, usando la metafora di un albero, mi piace partire dalle foglie di un ramo per arrivare a completarlo. Quando il ramo è completo, passo al ramo successivo.
Dato che, come ho detto all’inizio, per questioni di correttezza non parlerò di applicazioni di terze parti, prendo come esempio la mia applicazione StickyNotes.
Lo scopo principale dell’applicazione è quello di prendere note. Dopo aver abbozzato il disegno dell’applicazione e l’interazione tra le pagine, decisi ovviamente di iniziare lo sviluppo dalla parte di creazione / editing e cancellazione della nota.
Qui in basso una bozza del disegno (preferisco lavorare con carta e penna su certe cose 
)
Lo sviluppo dell’interazione completa, compresa grafica e funzionalità accessorie, avrebbe richiesto un certo tempo di sviluppo così, per evitare di mettere “troppa carne al fuoco”, decisi di sviluppare prima la parte core di creazione e cancellazione della nota.
Appena completata questa parte, installai l’app sul device e, mentre lavoravo ad altre funzionalità di contorno, iniziai ad usare l’applicazione notando che:
- tornare alla nota appena creata al salvataggio era scomodo e poco intuitivo
- non avere un feedback dell’avvenuto salvataggio disorientava
- dover cancellare ogni volta titolo e testo era palloso
- la cancellazione senza conferma era pericolosa
- il testo nelle note non andava a capo
- il testo nella nota non era selezionabile
Oltre a questi primi punti, ne emersero altri di minore importanza.
Dopo qualche giorno di utilizzo REALE del ramo dell’applicazione, decisi di sistemare questi dettagli che erano emersi durante l’uso e ricominciai nuovamente ad usare l’app.
Questo genere di testing è stato svolto per svariate volte prima di passare alle funzionalità successive.
Cosa sarebbe successo se avessi testato tutto alla fine?
Non è difficile immaginare che:
Il mio consiglio è quello di scegliere BENE l’ordine delle cose da sviluppare, mettendovi sempre nella condizione di chiudere una funzionalità in modo che sia installabile sul device ed usabile per intero per qualche giorno.
Fate inoltre molta attenzione nel non cadere nel tranello dell’emulatore!!!!
Sento spesso da molti dire: testo nell’emulatore. Che va benissimo fino ad un certo punto ma l’emulatore non può permettervi di testare l’applicazione in condizioni di utilizzo reali (e mi riferisco a condizioni ambientali).
Un esempio?
Provate ad usare la vostra applicazione con una mano, mentre con l’altra portate un peso (come una busta della spesa).
La usate comodamente? (e credetemi, la risposta non è sempre SI 
)
9d651b89-d17f-4a9d-a222-1d2ea643e57e|1|5.0
Windows Phone 7
Windows Phone 7