Managed hosting door True

Zelf testen niet serieus genomen

Interne evaluatie gebruiksvriendelijkheid vergroot kundigheid softwarebureaus

 

Gebruiksvriendelijkheid is cruciaal voor de kwaliteit van software en het slagen van projecten. Er zijn verschillende manieren om die gebruiksvriendelijkheid te vergroten. Het effectiefst is het testen van de gebruikersinterface via gebruikerssessies. Een softwarebureau kan dit soort testen uitbesteden of zelf doen. Zelf testen heeft vele voordelen, waaronder efficiëntie, flexibiliteit en kennisgroei. Een softwarebureau dat kwaliteit hoog in het vaandel wil dragen is erbij gebaat bruikbaarheidexpertise in huis te hebben.

Het ontwikkelen van gebruiksvriendelijke software blijft volop in de belangstelling staan. Ruben Acohen noemt in 'Negen Narigheden' (Computable, 10 oktober 2003) gebruiks(on)vriendelijkheid zelfs als eerste van de negen narigheden van ict-oplossingen. Niet voor niets: de gebruikersinterface verzorgt het eerste contact tussen het systeem en de gebruiker. Daarom is die interface van essentieel belang voor het slagen van de interactie tussen mens en computerprogramma. Het is dan ook belangrijk om bij ict-projecten aandacht aan dit onderwerp te geven.
Gebruiksonvriendelijke software is voor gebruikers per definitie van slechte kwaliteit.
In veel projecten is gebruiksonvriendelijkheid de belangrijkste oorzaak van een lage acceptatiegraad, waardoor de software niet of nauwelijks in gebruik wordt genomen.
De formule e=kxa (effectiviteit is de kwaliteit maal de acceptatie) is ook hier van toepassing. Wil je het als softwarebureau ver schoppen, dan kun je dus niet om gebruiksvriendelijkheid heen.

Ellende

Wat is gebruiksvriendelijkheid? De ISO-definitie luidt: gebruiksvriendelijkheid is de mate waarin bepaalde gebruikers een bepaald product kunnen gebruiken om op een effectieve, efficiënte en tevredenstellende manier bepaalde doelen te bereiken in een bepaalde context (ISO9241-11). Enkele belangrijke factoren in het kader van gebruiksvriendelijkheid zijn: snelheid, leerbaarheid, onthoudbaarheid en gebruikersgerichte foutafhandeling. Er komt echter meer bij kijken. Als bijvoorbeeld de geboden functionaliteit of de 'beeldtaal' niet aansluit op de doelgroep, is er van gebruiksvriendelijkheid ook geen sprake meer.
In veel gevallen wordt bij het ontwikkelen van software nauwelijks aandacht gegeven aan de gebruiksvriendelijkheid. De programmeur of, met meer geluk, de interactieontwerper, ontwerpt naar eer en geweten de schermen en dat is het dan. Deze werkwijze leidt bijna altijd tot een gebrekkige interface.
De gebruiksvriendelijkheid kan al flink verbeteren door een specialist op dat terrein de software in een aantal rondes te laten evalueren. Als dit in een vroeg stadium van een project gebeurt, valt een hoop ellende te voorkomen. Toch kunnen ook dan nog onvolkomenheden blijven zitten. Om dit te vermijden, moeten gebruikers bij het project betrokken worden. Gebruikers laten meepraten over de functionaliteit en de interface in klankbordgroepen is niet genoeg. Wie werkelijk wil weten hoe zijn interface de weerbarstige praktijk doorstaat, moet onderzoeken hoe de gebruiker in de praktijk met de software aan de slag gaat. Dit gebeurt door de gebruiksvriendelijkheid te testen.

Praktisch

De efficiëntste manier om de gebruiksvriendelijkheid te testen is via gebruikerssessies. Hierbij verrichten de gebruikers zoveel mogelijk dagelijkse taken. Een onderzoeker begeleidt het proces, maar grijpt zo min mogelijk in. Zo valt zowel bewust als onbewust gedrag te registreren. Een beperkt aantal sessies (vijf per doelgroep) is voldoende. Een sessie duurt ongeveer drie kwartier. Het resultaat van de test is een rapport met daarin onder ander de gevonden zwakke en sterke kanten en een lijst met praktisch toepasbare aanbevelingen. Voorbeelden daarvan zijn: voeg een 'homeknop' toe; verwijder de 'checkboxen' voor de regels in de uitgebreid zoeken 'pop-up' en bepaal impliciet de criteria van de zoekvraag door na te gaan welke velden zijn ingevuld; en maak velden alleen 'case-sensitive' als dat echt nodig is (dus niet bij adresgegevens).
Door het feitelijke gedrag van gebruikers te bekijken zijn problemen op het gebied van de gebruiksvriendelijkheid te vinden die met andere methoden (webonderzoeken, klankbordgroepen) worden gemist. Implementatie van de uit de test voortkomende aanbevelingen verbetert de kwaliteit van de interface en daarmee die van de applicatie aanzienlijk. Oplevering van hogere kwaliteit vergroot de kans dat de klant terugkomt.
Worstelende gebruikers zien levert overtuigend bewijsmateriaal van de problemen. Hierdoor stijgt de bereidheid in het projectteam om er iets aan te doen meer dan bij andere methoden, zoals webonderzoeken of beoordeling door een specialist. Meer kwaliteit en de gebruikers serieus nemen vergroot de acceptatie bij de gebruikers en daardoor bij de klant. Er komt meer informatie over de doelgroep los (wat verwachten ze, wat willen ze enzovoort), waardoor daarop ingespeeld kan worden.
In veel gevallen krijg je minstens terug wat het kost: gebruikers kunnen efficiënter werken, je bent minder tijd kwijt aan instructies, er zijn minder helpdesks nodig, acceptatietests verlopen sneller et cetera. Het is dus een investering die zich terugbetaalt.

Misvatting

Een softwarebureau dat zijn programmatuur wil testen op gebruiksvriendelijkheid staat voor de keuze 'zelf doen' of 'uitbesteden'. Als er al getest wordt, kiezen bureaus meestal voor de laatste optie. Ze nemen de eerste optie vaak niet serieus - ten onrechte, want hij is veel aantrekkelijker dan wordt gedacht.
Het integraal opnemen van bruikbaarheidtesten in de dienstverlening van een softwarebureau heeft nog geen grote vlucht genomen. Daar zijn redenen voor, maar deze blijken niet altijd zo sterk te zijn. Bruikbaarheidtesten wordt bijvoorbeeld vaak gezien als een activiteit die veel geld en inzet kost. Dit is een misvatting. Een test van gebruiksvriendelijkheid hoeft niet groot en zwaar te zijn om belangrijke inzichten op te leveren. Veelvuldig lichte tests doen levert veel meer op. Zeker is dat een eenvoudige test oneindig veel meer oplevert dan helemaal niet testen, terwijl dit in een groter project gemakkelijk valt in te passen. Voor kleinere projecten is ook een lichtere versie mogelijk met een verslag in plaats van een uitgebreid rapport. Een dergelijke test kost (bij één doelgroep) twintig manuur.
Een andere reden is dat het door het softwarebureau laten uitvoeren van de test lijkt te botsen met de noodzakelijke objectiviteit. Die objectiviteit mag nooit in het gedrang komen. Zoals bij elk soort test is het een vereiste dat degene die de test uitvoert niet zelf de betreffende software ontwikkelt. Er is in feite geen verschil met de situatie waarin een collega die geen deel is van het ontwikkelteam een systeemtest doet.
Een volgend motief is de stelling dat bruikbaarheid testen niet een noodzakelijk onderdeel is van de dienstverlening van softwarebureaus. Kwalitatief goede software opleveren is in elk geval wél een noodzakelijk onderdeel van de dienstverlening. Zodra de software enigszins 'interactie-intensief' is, wordt een test naar gebruiksvriendelijkheid noodzakelijk om deze kwaliteit te waarborgen. Dit kan je uitbesteden, maar daarmee mis je de voordelen van het zelf doen.
Tot slot leeft het idee dat softwarebureaus niet de mensen met de juiste expertise in huis hebben. Dit is allicht het beste argument voor uitbesteding. Toch zullen er bij nogal wat bureaus werknemers rondlopen met de vereiste analytische-, luister- en communicatieve vermogens. Deze personen kunnen, met behulp van boeken, het web en cursussen, zich betrekkelijk snel ontwikkelen tot bruikbaarheidtesters. Dit vergt een relatief kleine inspanning en financiële investering. Natuurlijk zijn dit niet meteen de beste bruikbaarheidonderzoekers, maar dat is ook niet nodig. Budgettests naar gebruiksvriendelijkheid zijn niet de ingewikkeldste vormen van onderzoek. Buiten de genoemde vaardigheden zijn affiniteit met het onderwerp en bereidheid om het vakgebied te leren wel vereisten.

Voordelen

Zelf testen van gebruiksvriendelijkheid blijkt veel voordelen te hebben. Allereerst is het efficiënter. Er is geen extra partij nodig binnen in het project. Dit betekent minder overhead aan communicatie en administratie. Bovendien is de communicatie sneller omdat de 'lijntjes' korter zijn als de testbegeleiders binnen het bedrijf zitten. Bovendien kan er flexibeler worden omgegaan met de onvermijdelijke aanpassingen in de planning van een project. Doordat de tester een collega is, is de werkrelatie anders en zijn de lijnen korter. Daardoor valt er gemakkelijker op onverwachte ontwikkelingen in te spelen.
Verder worden gebruiksvriendelijkheidtests vaker toegepast. Doordat er testers in huis zijn, is de drempel voor het doen van zo'n test lager. Hierdoor komt het er vaker van. Het gevolg is dat de opgeleverde producten vaker van hogere kwaliteit zijn. Alle voordelen van het hebben gedaan van een gebruiksvriendelijkheidtest binnen een project zijn dus vaker van toepassing. Daarnaast is de kans op implementatie van aanbevelingen groter. De interne gebruiksvriendelijkheidtester is beter op de hoogte van de ontwikkelproblemen uit de praktijk. Ook kan hij beter rekening houden met eventuele technische randvoorwaarden. Dit heeft geen invloed op de analyse van de sterke en zwakke punten van de software. Het maakt het wel mogelijk gerichter aanbevelingen te presenteren, zodat die beter aansluiten op de ontwikkelpraktijk. Daardoor zijn de aanbevelingen vaker praktisch haalbaar en betaalbaar en is de kans op implementatie ervan groter.
Ook groeit de kennis van gebruiksvriendelijkheid. Door directe terugkoppeling groeit de kennis bij tester. Hetzelfde geldt voor het ontwikkelteam en daarmee het hele bedrijf. Het ontwikkelteam krijgt van binnenuit terugkoppeling, is er daardoor sterker bij betrokken en leert meer vanuit het oogpunt van de gebruiker te denken. Dit is des te meer het geval als de bruikbaarheidspecialist steeds voor vragen voorhanden is. Het verwerken van aanbevelingen uit een gebruiksvriendelijkheidtest wordt een natuurlijk proces, net als bij testmeldingen. Er ontstaat minder snel een sfeer van wij (ontwikkelaars) versus zij (het bruikbaarheidbureau).
Tot slot is het goed voor het kwaliteitsimago. Een organisatie die als kwalitatief goed bekend wil staan, zal moeten verantwoorden hoe ze omgaat met gebruiksvriendelijkheid. Zelf de expertise hebben om gebruiksvriendelijkheidtests te doen, illustreert de serieuze en actieve houding op dit punt.

Afwegen

Voor het inpassen van de test hoef je het ontwikkeltraject niet anders in te richten dan gebruikelijk. Je moet wel rekening houden met het feit dat de aanbevelingen verwerkt moeten worden. Wat het beste moment is om de tests te doen hangt af van de situatie. Als een geheel nieuwe site of software wordt ontwikkeld, is het verstandig om in de ontwerpfase een concepttest te doen. Uit de reacties van gebruikers op de ontwerpplaatjes valt namelijk al veel af te leiden. Zo kan je nagaan of de knoppen op de juiste plaats staan, de juiste (beeld)taal gebruikt wordt, de functionaliteit overeenkomt met wat de gebruiker verwacht et cetera.
Het is efficiënter om veel kleine tests te doen dan één hele grote. Het is echter niet altijd haalbaar om meerdere tests te doen. In zo'n geval wordt de test meestal gedaan als de software grotendeels werkt, zodat de interactie goed te controleren is. In een vroege fase een bruikbaarheidspecialist een beoordeling laten doen verkleint de kans dat tijd en energie verspild wordt doordat de verkeerde weg ingeslagen is. Dit is ook te voorkomen door gebruikers bij de ontwikkeling te betrekken via workshops en 'prototyping'.
Een softwarebureau dat kwaliteit hoog in het vaandel wil dragen is erbij gebaat om bruikbaarheidexpertise in huis te hebben. Zelf testen is een goed alternatief voor het laten uitvoeren van een gebruiksvriendelijkheidtest door een extern bureau; het heeft vele voordelen, waaronder efficiëntie, flexibiliteit en kennisgroei binnen de organisatie. De verbetering van kwaliteit en acceptatie is een belangrijke factor in het uitbreiden en vasthouden van de klantenkring.
Het is niet voor alle softwarebureaus de beste strategie om zelf gebruiksvriendelijkheid te testen. De voor- en nadelen wegen voor ieder bureau anders. De conclusie is wel dat het zelf testen van gebruiksvriendelijkheid een interessantere optie is dan men veelal denkt.

 
Frans van der Veen, Deloitte Management & ICT Consultants

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/1371032). © Jaarbeurs IT Media.

?


Lees meer over


 
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×