De situatie in het algemeen
Een applicatie wordt gebouwd voor klanten en eindgebruikers. Doel is ervoor te zorgen, dat zij tevreden zijn en tevreden blijven. Het eerste kan je nog wel achter komen. Als je klanten en eindgebruikers niet tevreden zijn, krijg je dat via een of ander kanaal vanzelf wel te horen. Tevreden blijven, is waar het probleem zit. Hier gaat het om een moeilijker terrein: hoe gaan nieuwe klanten je applicatie gebruiken en hoe gaan je bestaande klanten in de toekomst je applicatie op een andere manier gebruiken? Juist in deze tweede situatie kan je als tester veel betekenen. Wat zijn de kwaliteitsaspecten voor onze applicatie en welke zijn van belang voor onze klanten?
Wat vindt de klant belangrijk?
Het is van belang te weten wat voor je klant belangrijk is. Over het algemeen wordt bij zogenaamde kantoorapplicaties de layout niet zo belangrijk gevonden. De mogelijkheid om snel en eenvoudig gegevens in te voeren, wordt vaak veel belangrijker gevonden. Liever een snel, dan een mooi scherm. Op websites, waar thuisgebruikers gebruik van maken, is layout en vormgeving daarentegen vaak een van de doorslaggevende factoren. Als je concurrent een betere eerste indruk maakt, zullen veel klanten naar de concurrent gaan. Maar als je wat gebruikssnelheid inlevert voor gebruikersvriendelijkheid, zal daar niet snel over geklaagd worden. Het kan zelfs pluspunten opleveren.
Elke tester moet erbij stil staan welke kwaliteitsaspecten belangrijk zijn voor zijn of haar applicatie. Hoe belangrijk is gebruikersvriendelijkheid, vormgeving, performance, gebruiksgemak, leerbaarheid, enz? Als je klant zou moeten kiezen, welke aspecten zouden blijven en welke zouden overgeslagen worden? Van je testtijd moet zeker 75% besteed worden aan de belangrijkste kwaliteitsaspecten. Als dit niet het geval is, is het tijd om je teststrategie eens onder de loop te nemen. Zeker als je klanten klagen over deze kwaliteitsaspecten.
Betrouwbaarheid
Ongeacht de klant, betrouwbaarheid is altijd belangrijk. Getoonde gegevens moeten correct zijn en ingevoerde gegevens moeten goed opgeslagen worden. Maar uit mijn ervaring als tester weet ik, dat deze betrouwbaarheid vaak ter discussie wordt gesteld. Vaak ten behoeve van klantgerichtheid. Om zowel mogelijk te bouwen wat de HUIDIGE klanten NU willen, wordt alles wat daar niet in valt als minder belangrijk gezien. Als er 10 combinaties mogelijk zijn en er worden er maar 5 gebruikt, hoeven de andere 5 niet goed te werken. Dat komt tenslotte de klantgerichtheid ten goede, toch?
Nee! Klantgerichtheid gaat naast snel opleveren van gewenste wijzigingen en fixes, ook om het voorkomen van wensen voor wijzigen en fixes. De meest tevreden klant is vaak de klant die weinig te wensen heeft, omdat de applicatie aan zijn wensen voldoet en volledig naar wens werkt. Het voorkomen van wijzigingen is niet het terrein van de tester. Het voorkomen van fixes natuurlijk wel. Als er 10 combinaties mogelijk zijn, moeten ze alle 10 werken. Zodat nieuwe klanten, die een nieuwe combinatie gaan gebruiken, niet eerst een wijzigingstraject in moet, om de aangeboden functionaliteit ook werkelijk te kunnen gebruiken. En zodat bestaande klanten, die besluiten een andere combinatie te gebruiken, niet eerst contact hoeven op te nemen met een helpdesk.
Waar het op neerkomt:wat je aanbiedt, moet goed werken. En zorg er anders voor, dat je het niet aanbiedt.
Kwaliteit en deadlines
Het halen van deadlines is een van de belangrijkste aspecten van klantgerichtheid. Om deze reden wordt vaak gekeken of de applicatie niet met wat minder kwaliteit opgeleverd kan worden, om een deadline te halen. Hoe vervelend je dit als tester ook mag vinden, in veel gevallen moet je hiervoor open staan.
Maar ook hier moet je je wel in de klant blijven verplaatsen. Hoe blij een klant ook is met een product, dat op tijd opgeleverd is, die blijheid kan snel afnemen. Bijvoorbeeld als de klant vervolgens een ontzettend lang testtraject heeft, omdat de applicatie heel veel fouten heeft. Of als de gebruikers gaan klagen, omdat de applicatie duidelijke fouten heeft of langzamer werkt. Er kunnen talloze redenen zijn, waarom het halen van een deadline uiteindelijk in je nadeel kan gaan werken.
Ook hier is het van belang om te weten wat voor je klanten belangrijk is. Wat zijn ze bereid in te leveren om de deadline te halen? Minder functionaliteit, mindere vormgeving, minder performance? En daarbijhorend: wat zijn ze NIET bereid in te leveren om de deadline te halen? Soms is het verstandiger om de klant om meer tijd te vragen, dan om een product op te leveren waar ze niet blij van worden.
Mijn eigen richtlijn: elk product dat opgeleverd wordt moet een betere kwaliteit hebben dan het product ervoor. Het kan dus zijn dat het product kwalitatief beter is, door de toevoeging van nieuwe functionaliteit. Maar er iets op achteruit gaat, omdat een bestaand scherm wat foutjes bevat. In dit geval zal de kwaliteit van het product over het algemeen als hoger worden beoordeeld. Maar als de kwaliteit toeneemt, doordat een kleine, nieuwe functie is toegevoegd, terwijl je 10 bugs hebt geïntroduceerd, is het de vraag of een oplevering wel een verstandige keuze is.
Dus hoe kijk je naar kwaliteit?
Kwaliteit wordt bepaald door je klanten, voornamelijk je huidige klanten in hun huidige situatie. Maar een eerste indruk bij nieuwe klanten moet zeker niet vergeten worden. En je huidige klanten moeten zonder veel problemen hun gebruik van de applicatie kunnen wijzigen. Van belang is daarom meer te kijken naar de kwaliteitsaspecten, die belangrijk zijn, dan naar bepaalde veel gebruikte functies of invoercombinaties, die belangrijk zijn.
Waar het om gaat, ook onder tijdsdruk, is dat elke nieuwe versie van een product beter is dan de vorige. Beter in de ogen van klant. Maar natuurlijk moet het algehele kwaliteitsoordeel daarmee niet uit het oog worden verloren. Dus gebruik dit niet als excuus om eenmaal opgeleverde fouten niet op te lossen. Voor de korte termijn strategie kan opleveren met een bekende problemen verstandig zijn. Op de lange termijn moet gewoon je hele product een goede kwaliteit hebben, om weer terug te komen in de gewenste situatie. Hoe een klant je applicatie ook gebruikt, je applicatie moet gewoon een goede kwaliteit hebben.
