Facciamo un test?

by Giuseppe Lanzi on 20 febbraio 2015

Una delle domande che mi viene posta spesso durante gli incontri di consulenza è “tu cosa consigli di fare per i test?”. È una domanda molto interessante che mi fa piacere essere tra le prime preoccupazioni di chi imposta un nuovo progetto, i test applicativi sono l’unica cosa che può garantire all’utente finale una piacevole esperienza d’uso.

Per rispondere a questa domanda faccio riferimento ai casi analizzati nel lavoro di assistenza tecnica, perché la quantità e la diversità delle applicazioni studiate è un buon campione per capire qual è la natura degli errori più frequenti.

Suggerisco queste tre regole:

Chi sviluppa non fa il test
Chiaramente non intendo dire che chi sviluppa debba farlo senza provare quel che ha fatto ma che il test dello sviluppatore dovrebbe essere solo preliminare, una verifica da superare prima di consegnare la funzionalità a qualcun altro che non ha partecipato allo sviluppo di quella parte dell’applicazione. È un’attenzione molto importante, perché chi ha implementato una videata la userà secondo la sua linea di pensiero, esattamente la stessa che ha portato all’implementazione corrente. È davvero difficile uscire dai propri binari. Non a caso il test delle applicazioni è anche un mestiere a sé.

Chi fa il test interno non deve essere istruito
Vale a dire che il collega che si occuperà del test della funzionalità non dovrebbe essere istruito su come deve funzionare l’app, dovrebbe provarla seguendo il suo intuito. Infatti capita spesso che un problema apparentemente irreplicabile in locale venga replicato con il supporto di un operatore di assistenza. Avviene perché essendo a conoscenza di come deve essere usata l’applicazione non si esce dagli schemi prestabiliti e in pratica si clicca sempre nel posto giusto al momento giusto. Ma non appena l’applicazione viene usata dagli utenti finali, che non hanno percorsi mentali prestabiliti, vengono fuori i problemi.

Implementare il beta test
Quando si mette in produzione l’applicazione, anche se si è stati attenti a seguire i punti precedenti, accade sempre che vengono fuori i problemi meno evidenti e meno semplici da replicare. Nella maggior parte dei casi che abbiamo visto in assistenza servivano almeno 2-3 cause contemporaneamente. Una possibile soluzione è installare due versioni dell’applicazione: l’ultima versione stabile senza debug e la versione con le ultime modifiche con il debug attivato. Dopodiché identificando un gruppo di utenti finali ai quali chiedere di usare la versione in debug si avrà la maggior parte degli utenti che usano la versione stabile mentre il gruppo dei beta tester è già conscio di poter incontrare dei piccoli problemi.

Voi che ne dite, qual è la miglior politica da adottare per i test?

  •    Non si può testare a fondo senza appoggiarsi ad un servizio esterno.
  •    C'è bisogno di un team interno dedicato unciamente ai test del prodotto.
  •    Entrambe le precedenti.
  •    Nessuna delle precedenti (inserire un commento)

{ 2 comments… read them below or add one }

1 poidomani giovanni 20 febbraio 2015 alle 16:11

mi sembra di aver sentito dire che all Microsoft funziona così, gruppi piccoli composti da due sviluppatori e due tester, appena lo sviluppatore finisce i suoi test lo passa al suo tester.
Io penso che i test debbano essere effettuati da chi è addetto all’assistenza ai clienti e anche da chi non conosce per nulla la procedura, che saranno ovviamente due persone distinte. Il secondo dei due può dare importanti indicazioni sulla semplicità di utilizzo e di comprensione dei meccanismi dell’applicativo.

2 poidomani giovanni 20 febbraio 2015 alle 16:13

Leave a Comment

Previous post:

Next post: