Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Flss Test Plan

408 views

Published on

FLSS vuole essere un supporto tecnologico alla gestione della vita condivisa, semplice, giocoso e facile da usare, volto a rendere piacevole e formativo quel periodo della vita in cui giovani studenti e lavoratori condividono un appartamento, soprattutto nelle grandi città dove i canoni d'affitto sono molto alti.

  • Be the first to comment

  • Be the first to like this

Flss Test Plan

  1. 1. FLSS Flatmates life support system Usability Test Plan Chiara Frantini Sara Minoli MatteoVacca
  2. 2. INDICE 1. Panoramica del documento 2. Metodologia 2.1 Partecipanti 2.2 Procedura 2.3 Ruoli 3.Tasks e scenari 3.1 Scenario 1 3.2 Scenario 2 3.3 Scenario 3 3.4 Scenario 4 3.5 Scenario 5 3.6 Scenario 6 4. Errori 4.1 Errori non critici 4.2 Errori critici 5. Metriche di usabilità 5.1 Completion rate 5.2 Error-free rate 5.3Time onTask (TOT) 5.4 Subjective Measures 6. Gravità del problema 6.1 Impatto 6.2 Frequency 7.Valutazioni soggettive
  3. 3. 1. Panoramica del documento Questo documento descrive il piano usato per condurre il test di usabilità durante lo sviluppo dell’app FLSS. La tecnica di progettazione da noi utilizzata è quella dello User Centered Design (UCD), che pone al centro dell’attenzione il punto di vista e le esigenze dell’utente. Gli obbiettivi di un test di usabilità sono : 1. valutare il livello di facilità d’uso e comprensibilità dell’interazione dell’interfaccia e dell’architettura dei contenuti; 2. misurare le prestazioni degli utenti durante l’uso dell’app (tempi di completamento dei vari tasks, misure soggettive, ecc...); 3. individuare gli eventuali problemi di design, architettura informativa, flusso delle informazioni all’interno del sistema al fine di migliorare l’efficienza, la produttività e la soddisfazione d’uso dell’utente finale; 4. valutare la piacevolezza dell’interfaccia. Il metodo prescelto per la conduzione del test di usabilità è il cosiddetto “scenario-based”, che prevede la definizione di scenari d’uso che identificano alcuni contesti di azione e obiettivi tipici e plausibili da conseguire. Le potenziali sorgenti d’errore possono essere: - Errori di navigazione – impossibilità a trovare / accedere alle funzioni del sistema, eccessiva lunghezza del flusso di navigazione per raggiungere una determinata area / funzione, eccessivo uso della tastiera. - Errori di presentazione - impossibilità a trovare e usare propriamente le informazioni desiderate, errori dati dall’ambiguità delle labels. - Problemi di utilizzo dei controlli (form, textfield, buttons).
  4. 4. 2. Metodologia 2.1 Partecipanti Per il test verranno reclutati 5 partecipanti. Questa scelta si basa su una ricerca effettuata da Nielsen, secondo la quale con 5 partecipanti si individuano l’80% dei problemi di usabilità. In fase di definizione dei requisiti, i dati raccolti con un questionario on-line a 60 soggetti, ci hanno permesso di definire gli utenti-tipo del nostro sistema. Le categorie di partecipanti rappresentative per il nostro test sono principalmente 3 : 1. Studenti che vivono in casa con altre persone 2. Lavoratori che vivono in casa con altre persone 3. Coppie conviventi 2.2 Procedura Nella fase di test ci siamo avvalsi di un prototipo, funzionante nelle sezioni interessate per lo svolgimento delle tasks, sviluppato con Axure, un software concepito per supportare l’attività del progettista di applicazioni web e mobile. Abbiamo svolto il test di usabilità seguendo 3 fasi principali: - preparazione: definizione degli obiettivi generali del test; definire il profilo degli utenti, i compiti, e i contesti d’uso (scenari); - conduzione: illustrazione dei compiti e della metodologia ai partecipanti al test; effettuazione del test con l’osservazione; questionario valutativo; - analisi e report: stesura del report con la valutazione dei problemi riscontrati e con indicazioni e suggerimenti su come risolverli. In fase di conduzione si è tenuto conto di alcuni accorgimenti: • mettere gli utenti a proprio agio, per ridurre al massimo lo stress da esame; • spiegare bene che lo scopo è di provare il sistema, non l’utente; • spiegare bene quali compiti dovranno eseguire, e in quale ordine. Il test verrà effettuato seguendo il metodo Thinking Aloud. Con questo metodo il partecipante è invitato ad esprimere ad alta voce pensieri, opinioni, commenti ed eventuali dubbi e difficoltà mentre interagisce con l’interfaccia. In questo modo è possibile capire perchè l’utente effettui una
  5. 5. scelta piuttosto che un’altra, mettendo in luce i cosiddetti Pain Points, ovvero i punti in cui l’utente esegue un’azione ottenendo un risultato diverso da quello atteso. 2.3 Ruoli Il test di usabilità prevede la presenza di tre figure: Conduttore • fornisce una panoramica sul servizio Facilitatore • Fornisce una panoramica sul test • Risponde alle domande dei partecipanti • Assiste i partecipanti durante il test     Osservatore • prende nota di commenti, suggerimenti, punti di stallo • osserva le espressioni del partecipante (linguaggio non verbale) al fine di ricavare più informazioni possibili
  6. 6. 3. Tasks e Scenari Gli scenari sono ricostruzioni dettagliate delle situazioni d’ uso del nostro sistema, che prevedono la documentazione puntuale delle azioni eseguite dagli utenti. Durante il test, si chiederà all’utente di interagire con esso in base agli scenari di seguito descritti. Ogni scenario prevede diversi task. Il completamento di uno scenario avviene dopo aver ultimato ogni singolo task. La buona riuscita di uno scenario significa che l’interfaccia risulta all’utente chiara e usabile. Può succedere che l’utente dichiari di aver completato uno scenario pur non avendo ultimato tutti i tasks. Questo tipo di situazione potrà aiutarci ad individuare eventuali errori di progettazione. Di seguito presentiamo gli scenari da noi proposti: 3.1 Scenario 1: Arriva una bolletta del gas da 80 euro riferita al periodo gennaio-febbraio. La bolletta deve essere pagata entro il 25 maggio. Decidi di notificarne l’arrivo ai tuoi coinquilini, inserendo le informazioni relative (importo, scadenza, periodo di riferimento). Task 1: entra in gestione spese /calendario Task 2: cliccare sul + Task 3: inserisci bolletta Esecuzione ottimale: L’utente dopo aver effettuato l’accesso al sistema, potrà inserire la bolletta in due modi: - dalla sezione gestione spese cliccando in basso sul bottone “+”. - dalla sezione calendario, cliccando in basso sul bottone “+”. Si aprirà un pannello overlay al centro della schermata dove sarà possibile inserire i seguenti dati:   tipologia bolletta, periodo di riferimento, scadenza, coinquilini che contribuiranno alla spesa, e stato del pagamento (pagata o ancora da pagare).
  7. 7. Ultimato l’inserimento di queste informazioni, e dopo aver cliccato sul bottone SALVA, il sistema informa l’utente attraverso un feedback, che una notifica è stata inviata agli altri coinquilini. 3.2 Scenario 2: Decidi di pagare la bolletta anticipando l’intero importo. Successivamente avviserai i tuoi coinquilini del pagamento. Task 4 : entra in gestione spese Task 5: aprire la bolletta Task 6: segnalare come pagata Esecuzione ottimale: Nella sezione gestione spese, o nella sezione calendario, l’utente apre la voce bolletta precedentemente inserita e modifica lo stato da pagare in pagata. 3.3 Scenario 3 In casa sono terminati alcuni prodotti di uso comune (detersivo per piatti, carta igienica, sale).Vuoi informare i tuoi coinquilini in modo che possano ricomprarli il prima possibile. Task 7 : entra in lista spesa Task 8: inserire items Esecuzione ottimale: L’utente accede alla sezione lista spesa dove può aggiungere gli item con la relativa quantità, inserendoli nel box di inserimento testo in alto.
  8. 8. 3.4 Scenario 4 Ti trovi in prossimità di un supermercato, e ricevi la notifica di nuovi item inseriti. Decidi di acquistare i prodotti e di registrare in seguito l’importo nella sezione gestione spese. Task 9: entrare il lista spesa Task 10: selezionare gli items da mettere nel carrello Task 11: concludi spesa Esecuzione ottimale: L’utente effettua la spesa consultando l’app: man mano che trova un prodotto, clicca sul suo nome nella lista. Automaticamente lo visualizzerà all’interno del carrello virtuale situato nella parte inferiore dello schermo. Raccolti tutti gli items, l’utente conclude la spesa, cliccando sul bottone relativo. Il sistema mostrerà una finestra pop-up chiedendo all’utente se vuole inserire l’importo e la foto dello scontrino. L’utente declinerà la richiesta, rinviando l’azione ad un secondo momento. 3.5 Scenario 5 Vai a fare uno stage all’estero di 90 giorni e subaffitti la tua camera. Comunica al sistema che non sarai attivo per quel periodo e non verrai calcolato nella divisione delle spese. Task 12: cliccare su on Esecuzione ottimale: L’utente clicca sulla scritta on in verde impostando su off il suo stato.
  9. 9. 3.6 Scenario 6 Devi visualizzare i debiti che hai con gli altri. Task 13: entrare nel profilo personale Esecuzione ottimale: L’utente accede alla pagina profilo personale cliccando sulle tre linee in alto al pannello più scuro da una qualunque pagina della nostra app, oppure trascinando questo pannello perso il basso. 4. Errori 4.1 Errori non critici Gli errori non critici sono errori commessi dai partecipanti durante il completamento dello scenario, ma senza ostacolare la buona riuscita delle tasks. Solitamente se riconosciuti portano frustrazione al partecipante. Questi errori possono essere di tipo procedurale: i partecipanti non completano lo scenario in maniera  ottimale (es. step eccessivi). Possono essere anche errori di confusione (selezione della funzione scorretta, uso di un controllo in maniera scorretta come provare ad editare un campo non editabile). 4.2 Errori critici Gli errori critici sono deviazioni dal completamento degli obbiettivi dello scenario. L’obbiettivo principale è il completamento autonomo dello scenario. Ricevere un aiuto è un errore critico, in quanto sta a significare che l’utente non riesce ad uscire da una situazione e ha bisogno di aiuto. Gli errori critici sono i più importanti da risolvere al fine di migliorare l’esperienza d’uso del prodotto.    
  10. 10. 5. Metriche di usabilità 5.1 Completion Rate    Per tasso di completamento intendiamo la percentuale di compiti portati a termine con successo, senza commettere errori critici. Se un partecipante richiede assistenza per completare un task in maniera corretta il task dovrà essere considerato affetto da errore critico. 5.2 Error-free rate Percentuale di partecipanti che completano il task senza errori (critici e non). 5.3 Time on Task (TOT) IlTime onTask è il tempo richiesto da un determinato compito per essere completato e viene misurato da quando l’utente inizia lo scenario a quando lo dichiara completato. 6. Gravità del problema Per assegnare una priorità ad ogni problema rilevato durante l’esecuzione del test, si considerano due fattori - l’impatto del problema e la frequenza con cui gli utenti ne fanno esperienza. 4.3.1 Impatto L’impatto è il peso che ogni problema ha sul completamento del task. Ci sono 3 livelli di impatto: • Alto - impedisce gli utenti di portare a termine il task (critical error) • Moderato - causa difficoltà all’utente, ma il task può essere completato (non-critical error) • Basso - problemi minori che non impattano sul completamento del task  (non-critical error) 4.3.2 Frequency E’ la percentuale dei partecipanti che incontrano il problema durante il task. • Alto: 40% o più fanno esperienza del problema • Moderato: 21% - 39% hanno esperienza del problema • Low: 20% o meno fanno esperienza del problema
  11. 11. 7. Valutazioni soggettive Ultimata l’esperienza di testing, verrà sottoposto ai soggetti un breve questionario volto a valutare l'efficacia, la soddisfazione d'uso della nostra app ed eventuali miglioramenti consigliati. A questo scopo abbiamo scelto di utilizzare la scala di valutazone di tipo Likert a 5 alternative di risposta. La scala Likert misura gli atteggiamenti e i comportamenti utilizzando una serie di opzioni di risposta (semanticamente collegate agli atteggiamenti che si vuole indagare), che vanno da un estremo all’altro (ad esempio, da per niente probabile a estremamente probabile).A differenza di una semplice domanda "sì/no", una scala Likert ti permette di scoprire i diversi gradi di giudizio. La serie di opzioni di risposta aiuta, inoltre a identificare più facilmente le possibili aree di miglioramento. Il questionario è volto a indagare il grado dei seguenti aspetti: 1. facilità d’uso 2. consapevolezza della sezione in cui ci si trova 3. accesso alle informazioni 4. look / appeal 5. soddisfazione Le domande del questionario sono le seguenti: 1. Come valuti l’interazione con l’applicazione? Per niente semplice - Poco semplice - Piuttosto semplice - Molto semplice - Estremamente semplice 2. Ti è sembrato chiaro capire esattamente in quale sezione ti trovi mentre utilizzi l’app? Per niente chiaro - Poco chiaro - Piuttosto chiaro - Molto chiaro - Estremamente chiaro 3. Quanto è stato facile individuare le informazioni desiderate? Per niente semplice - Poco semplice - Piuttosto semplice - Molto semplice - Estremamente semplice 4. Come giudichi il look della nostra app? Per niente piacevole - Poco piacevole - Piuttosto piacevole - Molto piacevole - Estremamente piacevole 5. Complessivamente ti ritieni soddisfatto dall’esperienza? Per niente soddisfatto - Poco soddisfatto - Piuttosto soddisfatto - Molto soddisfatto - Estremamente soddisfatto

×