TESTEN TESTPLAN BIJLAGEN
Testplan Schrijven Jullie hebben tot nu toe een paar testen gedaan met paper prototypes. We gaan nu een stap verder met het voorbereiden en uitvoeren van een test. Je krijgt materiaal aangeleverd uit het boek “Paper Prototyping” van Carolyn Snyder. In dit boek staat nagenoeg compleet omschreven hoe je een paper prototype test moet uitvoeren. Jullie richten je op het testen van een working interface/ demo presentatie/ clickable prototype, bij deze test voer je vergelijkbare stappen uit. Je gaat een testplan schrijven en op de volgende paginaʼs zie je hoe je testplan moet zijn opgebouwd. Vergeet niet de BIJLAGEN in te vullen! Verder Let vooral goed op de aansluiting tussen: A. doel van de test. B. onderzoeksvragen die bij de test horen. C. de instructies die je geeft aan je testdeelnemers. D. de conclusies die uit de test + interview naar voren komen. E. de aanbevelingen die je doet voor de aanpassing. A - E moeten volledig op elkaar aansluiten, ze moeten een aantoonbare relatie met elkaar hebben. In het testplan zie je de letters a-r staan. Alle punten tussen a-r moet je uitschrijven. Succes Anne Marleen
INHOUD TESTPLAN 2.1 Test objective / Doel test a. Formuleer het algemene doel dat je wilt bereiken met je test. b. Leg goed uit waarom dit je doel is. 2.2 Aannames gebruikers Er bestaat geen test zonder het doen van aannames, hoe impliciet deze ook zijn. Aannames geven de insteek voor de uitvoering van het test. Geef antwoord op onderstaande vragen: - Waar verwacht je dat de testpersoon wel moeite mee zal hebben? - Waar verwacht je dat de testpersoon geen moeite mee zal hebben? - Wat verwacht je dat de testpersoon wel zal kunnen? - Wat denk je dat niet goed gaat? (Denk aan usecues (=gebruiks aanwijzingen), mate van ervaring, etcetera) c. Formuleer je verwachtingen ten aanzien van het gebruik. 2.3 Onderzoeksvragen d. Vertaal hier je testdoelen minimaal 3 zorgvuldig geformuleerde onderzoeksvragen. Onderzoeksvragen moeten zo concreet mogelijk zijn, maar zonder dat je teveel detailinformatie te weten komt. Het is dus belangrijk de juiste balans te vinden. “............................” 2.4 Uitvoering 2.4.1 Testmodel: Hoe ziet het testmodel er uit? e. Beschrijf de mobiele applicatie die je hebt ontworpen. 2.4.2 Testomgeving: Hoe ziet de testomgeving er uit? f. Beschrijf de opstelling hoe je gaat testen. Vertel hoe je de test gaat uitvoeren in de context van het gebruik en leg uit hoe zoʼn test er uit ziet.(iemand speelt computer, iemand notuleert, iemand observeert) Ook leg je uit waarom je dit zo aanpakt. 2.4.3 Testpersonen: Wie zijn de testpersonen? g. Omschrijf je testpersonen zorgvuldig. Bedenk goed of de testdeelnemers representatief genoeg zijn voor de doelgroep.
Noteer demografische gegevens, maar ook eventuele beperkingen van de testdeelnemers (wel/niet computer-minded, slechtziend, rsi-patient, etc.) 2.4.4 Taken: Welke instructies ga je geven aan de testpersonen? Voorbeeldinstructie: Je bent in een hutje op de hei, je weet niet waar je bent en je bent op zoek naar een goed hotel. Daarvan wil je te weten komen of het een goed hotel is en of er nog plaats is voor jou voor de komende nacht. h. Formuleer je testinstructies en onderbouw zorgvuldig waarom je deze instructies geeft. Onderbouwen betekent antwoord geven op: - Wat test je d.m.v. het geven van deze instructie? - Waarom test je dat? 2.4.5 Registreren: Hoe ga je de test vastleggen? Leg je de test vast op video of gaat een van de groepsgenoten ter plekke uitschrijven wat de testpersoon zegt. Maak je fotoʼs? i. Leg hier uit hoe de registratie in zijn werk gaat. 2.4.6 Hardop-denken j. Leg uit waarom jullie de testpersonen vragen hardop te denken. Schrijf dit in je testplan. 2.4.7 Interventie: Hoe ga je de testpersonen toch feedback geven, zonder teveel te interveniëren? Je kunt de testpersoon op zʼn gemak stellen door op knelmomenten ze minimale feedback te geven. (Mmm, uhuh, etcetera)? Wanneer een testpersoon geheel vastloopt kun je ze al vragend proberen verder te helpen. Als dat niet lukt, probeer dan aan te geven wat ze goed doen en probeer ze met een kleine aanwijzing weer op weg te helpen. Dit moet je aangeven in je testplan, zodat je laat zien dat je hier voorafgaand aan de test al over hebt nagedacht. Zo kom je niet voor verrassingen te staan. 2.4.8 Checklist met vragen k. Stel een checklist met vragen op die je na de test gaat stellen. Zie de bijlage voor de template. 2.4.9 Deskundigheid van de testpersoon: Welke deskundigheid hebben de testpersonen t.a.v. een mobiele applicatie? l. Formuleer de overeenkomsten in de ervaring met devices/apparaten. Als testpersonen veel verschillende soorten apparaten gebruiken, formuleer dan de overeenkomsten die het gebruik van deze verschillende apparaten in zich heeft. 2.5 Overige punten
2.5.1 Human characteristics m. Formuleer de menselijke karakteristieken die jullie belangrijk vinden om te vermelden in je testplan. (handpalm breedte, lengte, gewicht, knijpkracht, lichamelijke conditie, benodigdheid van een bril etcetera) 2.5.2 Carry-over Bij grote usability-onderzoeken gebeurt het vaak dat taken in verschillende volgordes gegeven worden. Waarom? Testpersonen hebben vaak leermomenten, waardoor ze als ze 1 ding hebben gedaan, het volgende ook makkelijker kunnen. Vandaar dat de taken dan door elkaar gehusseld worden, zodat die opeenvolging van leermomenten niet altijd hetzelfde is. Neem dit punt wel op in je testplan, vermeld daarbij dat jullie 3 testpersonen testen, maar dat dit punt voor deze test niet meegenomen is. 2.5.3 Eind van de sessie Blijf ook scherp na het einde van de test. Vaak wordt dan door de testpersoon nog extra waardevolle reflectieve informatie gegeven over het product dat je test. n. Formuleer hier welke informatie je aan het einde van de sessie nog hebt gekregen van de testdeelnemers. 2.5.4 Pilot. Voer naar aanleiding van je testplan een pilot uit. In dit geval kun je dit doen met een mede-student uit je groepje. Normaal gesproken nodig je hiervoor apart iemand uit. 2.5.5 Hoeveelheid testpersonen o. Geef aan hoeveel testpersonen je hebt geregeld en waarom je voor deze hoeveelheid hebt gekozen. Is deze groep representatief genoeg om de test als valide te beschouwen? (Valide is een woord dat vaak in onderzoeken wordt gebruikt; bijv. als je een steekproef doet, moet je zorgen dat de resultaten betrouwbaar genoeg zijn en als ʻwaarʼ kunnen worden gebruikt. Dat noem je valide of de validiteit van een onderzoek.)
2.6 Analyse 2.6.1 Aanpak analyse p. Formuleer dat je de analyse gaat uitvoeren door de data per testpersoon te analyseren. Je gaat de data per testpersoon gaan uitwerken. Zorg dat je zoveel mogelijk quotes hebt genotuleerd tijdens het testproces. Pak de onderzoeksvragen er bij en analyseer deze gegevens op basis van deze onderzoeksvragen. (vaak wordt een test opgenomen op
video en worden de volledige transcripts uitgetypt; zorg dus WEL ervoor dat je zoveel mogelijk notuleert!!! ) 2.7 Communiceer de resultaten en conclusies q. Formuleer je resultaten van de test en de conclusies zorgvuldig, want dit is het belangrijkste gedeelte van de test. 2.8 Aanbevelingen voor een herontwerp r. Geef aanbevelingen voor aanpassingen in het huidige ontwerp. Doe dit bulletgewijs.
BIJLAGEN I! II ! III! IV! V!
Checklist interviewvragen na de test. Checklist observer rules Checklist working interface vs. paper prototype test Voorbeeld Roadmap van de Test Voorbeeldbrief aan testdeelnemers
BIJLAGE I: CHECKLIST NA TESTEN Voor:! ! Van:! ! Betreft: !! User group:! Datum:! !
naam opdrachtgever namen studenten Checklist interviews over ................ .................. ..................
************************************************************************************************************* Een opdrachtgever wil altijd graag weten wat je precies gaat onderzoeken als je een interview afneemt. Daarom stel je een checklist op. Deze checklist bevat altijd een korte omschrijving van de opdracht. Hierin verwerk je je onderzoeksvraag een verhalende vorm. Schrijf goed op welke vragen je denkt te gaan stellen en waarom je deze vragen stelt. Schrijf een inleiding waarin je de volgende punten behandelt: Rol opdrachtgever - Wie is en wat doet de opdrachtgever? - Waar wil de opdrachtgever naar toe? Rol onderzoekende partij (jullie dus) - Waarom hebben ze daar jullie voor gevraagd? Welke expertise bieden jullie? Opzet onderzoek - Wat ga je precies onderzoeken? - Hoe ga je dit onderzoeken? (vertel welke tools je gebruikt, in dit geval observatieinterviews) - Waarom ga je een interview afnemen? Welke informatie krijg je als je observatieinterviews afneemt? Opzet observatie-interviews - Geef in de checklist aan hoe de interviews worden opgebouwd. (van algemeen naar specifiek) - Geef aan hoe je de interviews begint. - Geef in de checklist steeds aan wat het onderwerp is en wat het doel is van dit onderwerp. -> waarom stel je vragen over dit onderwerp? wat wil je te weten komen? - Geef in de checklist per onderwerp een vijftal vragen aan die een indruk geven van de vragen die je allemaal gaat stellen. - Zet altijd “ + doorvragen “ onderaan, om aan te geven dat je altijd op de antwoorden doorvraagt. Rol deelnemers interviews - Wie zijn de deelnemers aan de interviews? - Geef een overzicht van de demografische gegevens van de deelnemers.
Duur:
3 min.
Inleiding Doel: geïnterviewden op hun gemak stellen en zichzelf laten voorstellen. • • • •
Algemene introductie. Noteren demografische gegevens (leeftijd, geslacht, beroep). Uitleg hoe een interview werkt. Introductie themaʼs.
Thema 1: Doel: inzicht krijgen in de relatie ..................
....... min.
•
Deelonderwerp 1: .................. Waarover ga je de gebruiker ondervragen en waarom? Hoe ga je meer inzicht over dit onderwerp krijgen? 1. 2. 3. 4. 5. 6. + doorvragen •
Deelonderwerp 2: .................. Waarover ga je de gebruiker ondervragen en waarom? Hoe ga je meer inzicht over dit onderwerp krijgen. 1. 2. 3. 4. 5. 6. + doorvragen
........ Thema 2: min. Doel: inzicht krijgen in de relatie .................. •
Deelonderwerp 1: .................. Waarover ga je de gebruiker ondervragen en waarom? Hoe ga je meer inzicht over dit onderwerp krijgen? 1. 2. 3. 4. 5. 6. + doorvragen •
Deelonderwerp 2: .................. Waarover ga je de gebruiker ondervragen en waarom? Hoe ga je meer inzicht over dit onderwerp krijgen. 1. 2. 3. 4. 5. 6. + doorvragen •
Deelonderwerp 3: .................. Waarover ga je de gebruiker ondervragen en waarom? Hoe ga je meer inzicht over dit onderwerp krijgen. 1. 2. 3. 4. 5. 6. + doorvragen
....... Thema 3: min. Doel: inzicht krijgen in de relatie .................. •
Deelonderwerp 1: .................. Waarover ga je de gebruiker ondervragen en waarom? Hoe ga je meer inzicht over dit onderwerp krijgen? 1. 2. 3. 4. 5. 6. + doorvragen •
Deelonderwerp 2: .................. Waarover ga je de gebruiker ondervragen en waarom? Hoe ga je meer inzicht over dit onderwerp krijgen. 1. 2. 3. 4. 5. 6. + doorvragen •
Deelonderwerp 3: .................. Waarover ga je de gebruiker ondervragen en waarom? Hoe ga je meer inzicht over dit onderwerp krijgen. 1. 2. 3. 4. 5. 6. + doorvragen
BIJLAGE II
Rules for Usability Test Observers Everyone who observes a usability test is asked to abide by a set of rules. The purpose of these rules is to minimize stress for the test participants and to maximize the amount of information we get from the usability tests.
Stay for the Entire Test The goal is to have the users forget that anyone else is in the room. Having people constantly coming in and out is distracting, and users may get the mistaken impression that you’re leaving because they’ve done something wrong (like walking out in the middle of a movie). While you are observing a test, you are not available for any interruption short of an emergency. If you can attend only part of a test, discuss this with the facilitator beforehand to determine whether there is a way to accommodate this.
Please turn off cell phones and pagers! Remain Silent While the Users Are Working Usability testing gives you a whole new perspective on the interface. You may notice a problem so surprising that you are tempted to laugh or exclaim out loud. This is not unusual. Unfortunately, the users might think you are laughing at them. Please do your best to keep as quiet as possible. The facilitator will give you opportunities to ask questions after each task and at the end of the test. If you have something to tell/ask that truly can’t wait, pass a note to the facilitator. (Exception: If a user intentionally says something funny, it’s okay to laugh!)
Be Conscious of Your Body Language Although most usability tests are interesting, not every moment will be fascinating. If something is happening that isn’t of interest to you but may be to others, sit quietly without fidgeting. (If inactivity makes you sleepy, one trick is to write down every word that users say.) But if you already thoroughly understand the issue that the users are stuck on and would like to see them move on to the next task, pass a note to the facilitator.
Don’t Reveal How Many Tasks We Have We may well run out of time before users finish all the tasks. If users get stuck on a task, that means that there is a wealth of information we should be fervently taking notes on. It is often more useful to explore an area of difficulty in detail rather than try to “get through” all the tasks. The facilitator will keep an eye on the clock so that we can cover as many of the important areas as possible.
No Helping During the test, it’s likely that users will have problems using the interface, and it is normal to feel a temptation to help. Please don’t. Instead, try to understand why it was that the user got stuck or went down the wrong path. It’s the facilitator’s role to get users back on track if they get really stuck. And if the facilitator poses a question during the test, he or she is asking the users, not you—please don’t answer unless the facilitator specifically directs a question to you.
Avoid “Design Questions” You will have an opportunity to ask questions after each task. Questions that ask the user their opinions about how to design aspects of the application (such as, “Where would you like to see these navigation buttons?”) can take a lot of time to answer and produce only limited results. Instead, focus on trying to understand the problem—we’ll come up with solutions later, outside the test.
Respect Participants and the Confidentiality of Their Data We have promised the participants that their participation is confidential. This means that we should not include their names in any reports or other communication such as email, and we should refrain from discussing them by name outside the test setting. Do not make negative comments about people—there is always a risk that a derogatory comment could be overheard or otherwise make its way back to the user.
From the book Paper Prototyping by Carolyn Snyder, published by Morgan Kaufmann Publishers. Copyright (c) 2003 Elsevier. All rights reserved.
BIJLAGE III
Table 14.1 Checklist: Working Interface vs. Paper Prototype This checklist is a tool that will help you evaluate the potential usefulness of paper prototyping for your project. For each row, place a check mark in the column that best describes your project. The number of checkmarks in each column isn’t especially important, and not all factors will apply to every situation. The main thing you should do is look for “showstoppers” that could prevent you from testing the working interface.
People and Logistics
Development Context
Working Interface
Paper Prototype
There are only a few people working on the design, perhaps 3 or 4 at most
The product team is larger
The people directly responsible for the design are already proficient with a computer-based tool like VB, Dreamweaver, etc.
Using a computer-based prototyping tool would require a learning curve before we were proficient enough to prototype what we envision
Everyone working on the design has a technical (i.e., programming) background
There are non-programmers on the team whose input is important, such as tech writers, customer support reps, or Marketing
The development team and users are all located within a reasonable commuting distance, or remote testing is a viable option
We aren’t all in the same geographic area and remote testing isn’t a good option – if we’re going to do usability testing, someone has to travel
The users are readily available. They won’t be upset if we have to reschedule a test, and a few rescheduling fees won’t break our budget
The recruiting firm charges us a fee to reschedule users, or the users are people we don’t want to inconvenience
The interface is a standalone piece of software or other technology – it doesn’t rely on other stuff
There are many software modules involved in successful completion of the tasks
All the software modules needed for usability testing are stable, or we’re confident we can test around the problems without too much difficulty
Some software modules are under development, are of uncertain reliability, or otherwise not under our direct control
It’s not a problem to pause development for a couple of days to do usability testing
People are constantly submitting changes – we either have to ask them to hold off for a few days or we’d need to set up a separate test environment
It’s not difficult to set up a test environment, including hardware, databases, accounts, etc.
It would take time and/or money to set up a test environment, or it would be hard to create one that’s sufficiently realistic
We can control everything the user sees, including product databases and ads
Some of the content comes from sponsors, manufacturers, or other outside sources, and we can’t always predict or control it
From the book Paper Prototyping by Carolyn Snyder, published by Morgan Kaufmann Publishers. Copyright (c) 2003 Elsevier. All rights reserved.
Page 1
BIJLAGE IV Topic Greeting and introduction
Checklist
Script example
‣ Welcome the users (hang up coats, offer a beverage, ask if the directions were okay).
“Thank you for coming. I’m Carolyn Snyder. I’m an independent consultant, and I specialize in conducting sessions like this one. Here at [company] we’re working on a product for [target market] that will help them to [basic functionality]. I’ll go over the main points in this form we sent you. The purpose of today’s session is for you to help us figure out how to make this interface more user-friendly before we finish developing it. But believe it or not, we aren’t going to use a computer. As you’ll see, we’ve actually created paper versions of the screens, and this guy named Carl will be playing the computer.”
‣ Introduce yourself and the company. ‣ Describe the interface being tested. ‣ Give users the informed consent form (ideally, they brought the copy you sent ahead of time). ‣ Explain the goals of the session. ‣ Introduce the notion of testing paper prototypes. Their role
‣ If using co-discovery, introduce the two users. ‣ Explain what’s expected of them. ‣ Remind them of their qualifications.
“Frank, this is Ernest. The two of you will be working together. We’ll give you some tasks that we think are representative of what people might do in real life. [Give example.] Your job is to tell us what makes sense, what’s confusing, whether it works the way you’d expect it to, etc. You are here because you know [area of expertise], so your perspective will help us make this product more useful.”
Topic Social concerns
Checklist ‣ Explicitly mention in-room observers and/or videotaping. ‣ Explain that you’re testing the interface, not them. ‣ Reassure users about what will happen if they encounter any difficulties. ‣ Reiterate how valuable this is and how much you appreciate their help.
Set expectations
‣ Acknowledge the unfinished nature of the prototype (avoid the temptation to apologize—present this as a benefit). ‣ Explain that the design will evolve. ‣ Explain that you will record their suggestions but don’t promise to implement them (especially important if the user is a customer).
Paperwork and administrivia
‣ Get signature on informed consent form. ‣ Pay users (unless you have decided to pay them at the end). ‣ Escort them into test room.
Script example “About half a dozen members of the development team will be sitting in the same room, observing quietly and taking notes. We’re not going to be videotaping. Keep in mind that we’re testing the interface— we’re not testing you—so if you run into any problems it’s not your fault and it means that there’s something we need to change. I’ll be sitting next to you, and I can help you if you want. We held our first session this morning, and we learned a lot; in fact, we’ve already made some changes. We really appreciate having you come and help us out.” “The prototype still has some rough edges—we’re still thinking through how it should work and some parts of it are incomplete. Before we cast it in concrete, we want to get some feedback about how well this design works. We’re doing several sessions like this one, so it’s likely that the final version of the interface will be different than what you see today. If you have suggestions we’ll make note of them, although at this point it is premature to promise what we’ll be able to include in the interface. When we get done with this series of sessions, we’ll review everyone’s feedback to help determine our priorities for the next release.” “Do you have any questions about what we’ll be doing today? If not, could I please get your signature on this form? And so I don’t forget, I’m going to give you your payment now since you’ve already earned it by virtue of showing up on time. If you need to leave early for any reason, you’re still entitled to keep it.”
BIJLAGE V
INFORMED CONSENT Study Administrator is:
Participant is: (print name and address)
[Company name] [Address]
This is a study about a Web site intended for people who [brief description of audience]. Our goal is to make the Web site appealing, intuitive, and user-friendly. Your participation will help us accomplish this goal. In this session, you will be working with a prototype of the Web site. We’ll ask you to try several things that people might typically do on this site, such as [brief description of 1 or 2 tasks]. Several members of the development team will sit in the same room, quietly observing the session and taking notes. We are scheduling another person to participate in the same session with you, but if this other person cannot attend for some reason, you may be the only participant in your time slot. A session facilitator will sit near you and help you if you are stuck or have questions. All information we collect concerning your participation in the session belongs to [company] and will be used for our internal business purposes. We will not videotape or audio tape the session. We may publish our notes from this and other sessions in internal reports, but all such observations will be confidential and will not include your name. We will not ask you to purchase anything during this session, and entering any of your personal information will be optional. This is a test of the Web site—we are not testing you! We want to find out what aspects of the Web site are confusing so that we can make it better. To the best of our knowledge, there are no physical or psychological risks associated with participating in this study. You will receive a check for $[amount] at the beginning of the session, which will last approximately [length]. You may take breaks as needed and may stop your participation in the study at any time. Statement of Informed Consent I have read the description of the study and of my rights as a participant. I voluntarily agree to participate in the study. Print Name: __________________ Signature: ___________________ Date: _____________ From the book Paper Prototyping by Carolyn Snyder, published by Morgan Kaufmann Publishers. Copyright (c) 2003 Elsevier. All rights reserved.
