Testen van Mobile Apps is (g)een vak apart. De overall testaanpak is hetzelfde maar de risico's, de omgevingen en de doelgroep zijn wezenlijk anders. Egbert Bouman van Valori presenteerde op het TestNet event 2014 samen met projectleider Bas Timmerman van Achmea een referentiemodel en hun ervaringen met het testen van een digitale app in de keten.
Download hier de Presentatie met Achmea's Bas Timmermans "Testen van een Mobile App in de keten".
Lees hier de tekst van de uitnodiging:
Eind 2013 verscheen de Zilveren Kruis Achmea App voor online declareren in de App Store. Een business kritische App die integreert met de Achmea back office. Het testtraject was een zeer interessante combinatie van app-specifieke testen en ketentesten.
In deze presentatie komen de projectleider, de business stakeholders, de architecten en de bouwers van de App aan het woord. En uiteraard ook de testmanager, die alle requirements en acceptatiecriteria beoordeelde en voorzag van een passende teststrategie. Dat gaf nieuwe uitdagingen en problematische momenten over "wie is nu eigenlijk verantwoordelijk voor wat?" en "welke risico's kun je testen en welke niet?". De standaard antwoorden bleken niet te voldoen.
De gekozen teststrategie bleek effectief. De reviews in de app store zijn positief en de keten heeft een hoog "Straight Through Processing" percentage. Er valt veel te leren van dit project en dat delen we graag.
U verkent bovendien een nieuw referentiemodel voor App Testen, gevalideerd met o.a. dit project en wellicht een preview van het nieuwe boek van Julian Harty over testen van Mobile Apps.
Testen van een Mobiele App in de keten (volledige tekst, zie boven voor de PDF)
Egbert Bouman, voor TestNet Nieuws voorjaar 2014
Met dank aan de stakeholders, projectleider en testers bij
Mobiele Apps bieden verzekeraars nieuwe mogelijkheden om kosten te reduceren en tegelijkertijd de 'user experience' van de klant te verbeteren. In dit artikel een ervaringsverhaal over de specifieke (test)uitdagingen van het inpassen van zo'n Mobiele App in de totale verwerkingsketen. De evaluatie van het project loopt momenteel nog en is vertrouwelijk. Auteur Egbert Bouman zal op het voorjaarsevent het complete verhaal vertellen.
Declareren is duur
Een belangrijk deel van de administratie - en dus van de kosten - van verzekeraars zit in het verwerken van door de verzekerden ingediende declaraties. De data wordt gecontroleerd, gevalideerd en doorgezet naar de database van het back-office systeem zoals OHI (Oracle Health Insurance), IDIT (een Israëlisch pakket), Level-7 (van de Nederlandse leverancier CCS) of een eigen maatwerk applicatie. Elke maatregel die dat proces sneller en soepeler doet verlopen betekent kostenreductie, en veelal ook snellere en betere service voor de klant.
Gebruikelijke maatregelen zijn:
Nieuwe mogelijkheden bieden Mobiele Apps op de smartphone van de klant.
Straight Through Processing
Automatische verwerking van scans lukt anno nu nooit 100% automatisch. Er is altijd een percentage uitval dat geheel of gedeeltelijk handmatig moet worden verwerkt. Het percentage dat wel geheel automatisch wordt verwerkt wordt het Straight Through Processing (STP) percentage genoemd. Hoe hoger het STP percentage hoe mooier!
Declareren met een Mobiele App: de ambities
Als je nadenkt over verdere optimalisatie van het declaratieproces dan ligt een Mobiele App natuurlijk voor de hand. Dat is dus precies wat men bij heeft gedaan. De belangrijkste ambities bij de start van dit project waren:
Voor de denkers in mogelijkheden (DIM'ers) was het niet zo moeilijk om hier een klinkende business case bij te definiëren. En dat was ook de basis voor het project "Digitaal Declareren".
Van DIM'men naar DIP'pen
Tegelijkertijd is het niet moeilijk om de leeuwen en beren te vinden. Wie wil denken in problemen (DIP'pen) kan bovenstaand rijtje moeiteloos omturnen:
Ketenrisico's !
We hebben uiteraard allerlei App-specifieke risico's geëvalueerd. Bijgaande mindmap / checklist, ontwikkeld door collega Derk-Jan de Grood was zeker waardevol geweest als die tijdig beschikbaar was geweest. De afbeelding is weliswaar onleesbaar maar geeft een indruk van de veelheid aan aspecten die van belang kunnen zijn.
Op het voorjaarsevent zal ik wat verder inzoomen op dit kwaliteitsmodel voor "Mobile Development & Testing" als goed Mobile App -specifiek alternatief voor de ISO9126 / ISO 25010 kwaliteitsmodellen!
Maar: bijna alle serieuze discussies bleken een ketenaspect te hebben. De business stakeholders waren zuinig op hun STP keten en zaten niet te wachten op een nieuw kanaal dat potentieel tot een stijging van de additionele handmatige verwerking zou kunnen leiden.
Als een scan niet automatisch "Straight Through" verwerkt kan worden, kun je dat dan terugkoppelen naar de klant en hem helpen een betere scan te maken? Als dat volautomatisch kan dan is dat veel goedkoper dan de scan handmatig verwerken. Maar het vergt wel een complexe terugkoppel lus die zowel door de App als door de gehele keten ondersteund moet worden. Het leek geen goed idee.
Eisen van de business stakeholders
De belangrijkste business stakeholder was degene die zich verantwoordelijk voelde voor het STP percentage. Haar eis was in eerste instantie: de App moet 100% STP opleveren.
Dat heeft heel wat stof tot discussie opgeleverd, want is dat een reële eis? Reëler leek de eis: Het STP percentage van declaraties via de App moet minimaal op het niveau liggen van het STP percentage van gescande papieren declaraties.
Je kunt zelfs nog een stapje verder gaan: we hebben de PR voordelen en het extra gemak voor de klant. Bovendien vervalt de bewerkelijke stap van papieren inscannen c.q. inkomende mails verwerken. Dus zelfs met een iets lager STP percentage is de business case nog gezond. Maar de stakeholder die dit brede perspectief met autoriteit inbracht ontbrak in eerste instantie.
SMART requirements?
Een voorbeeld van een door de business bij het testteam neergelegde eis is onderstaande requirement, die ik hier maar even ongeredigeerd doorgeef:
"De leesbaarheid van de declaraties via de App is gelijk aan de online keten:
a. 80.34% van de nota's krijgt kwalificatie 'goed'
b. 14,53% van de nota's krijgt kwalificatie 'redelijk'
c. 0,85% van de nota's krijgt maximaal kwalificatie 'matig'
d. 0,85% van de nota's krijgt maximaal kwalificatie 'slecht'
e. 3,42% maximaal van de nota's zijn 'leeg' (foute testgevallen, komen in productie niet voor)"
Dit lijkt op het eerste gezicht heel mooi kwantitatief en meetbaar, maar als je wat langer kijkt komen de vragen:
Wat kun je testen?
Het testteam werd onvermijdelijk deze discussies in getrokken. Zij kregen de opdracht: toon aan dat het STP percentage met de nieuwe App minimaal 90% is. Dat oogt als een redelijk "business driven" testdoel, maar is dat ook zo?
Nou, nee dus! Je kunt de App testen, je kunt de keten testen, maar je kunt niet het gedrag van je klanten 'testen'. Daar kun je hooguit onderzoek naar doen, maar daarvoor voelde het testteam zich terecht niet verantwoordelijk.
Wat wel als een 'normale' testklus kon worden benaderd is dit:
Deze en dergelijke zaken vielen binnen de normale kaders die men gewend was. Natuurlijk, er waren testbevindingen, discussies en issues. Maar allemaal binnen bekende kaders.
Wat kun je niet testen?
Veel lastiger waren de issues buiten de vertrouwde kaders:
Deze en dergelijke vragen gaven aanleiding tot voortdurende discussie over de verantwoordelijkheid en de scope van het project en vooral van het testteam. Met telkens weer het gevaar van een patstelling die levensbedreigend was voor het projectresultaat.
Pragmatische aanpak
Hoe voorkomen we dat we in een patstelling blijven hangen? Gewoon door nuchtere vragen te stellen zoals: OK, misschien is het STP percentage in eerste instantie niet wat je graag had gezien, maar is dat erg? Je hebt in elk geval andere voordelen en de eerste versie van de App zal niet de laatste versie zijn. Dat is dan weer het gemak van een Mobiele App: je kunt eenvoudig betere versies uitrollen zonder dat dat irritaties wekt bij de klant.
Om toch een gevoel van comfort te creëren rond de 'niet testbare' eisen is besloten om de principiële discussie te parkeren en een 'scan workshop' te organiseren.
Een set van ongeveer 100 (papieren) declaraties is vanuit de App gefotografeerd en verstuurd. In een Excel sheet is bijgehouden wat de kwaliteit was van de verstuurde foto's zoals deze op de smartphone stonden.
De verstuurde foto's (declaraties) zijn vervolgens visueel beoordeeld als Goed, Redelijk, Matig of Slecht. De criteria hiervoor bleken niet 100% objectiveerbaar, maar vertrouwen in de uitvoerende personen haalde ook die kou uit de lucht.
Resultaat
De App is met succes uitgerold en de eerste recensies in de App store waren lovend.
Kritische recensies zijn er inmiddels ook en het is zaak dat die in een volgende release worden opgepakt.
De STP percentages vallen niet tegen en de discussie of de App wel zo'n goed idee was speelt niet meer. De App is een vanzelfsprekend nieuw declaratiekanaal geworden.
Nog niet perfect, maar wel een aanwinst.
Samenvattend
Het testen van een Mobiele App in de keten is niet alleen een technische uitdaging. Ook hier is "langszij komen" bij de stakeholders en transparante communicatie doorslaggevend.
Het testteam koos er uiteindelijk voor om samen met de projectleider, de bouwers en de business stakeholders "in de duivelsdriehoek" van tijd, geld en kwaliteit te gaan zitten.
De principiële standpunten werden even geparkeerd en ingeruild voor de vraag "wat kunnen we wél doen om de risico's voldoende te verkennen en minimaliseren". Dat heeft geholpen en het resultaat mag er zijn.
Egbert Bouman
@EgbertBouman
Download hier het artikel "Testen van een Mobile App in de keten" in TestNet Nieuws. Dit artikel sluit aan bij de hiernaast beschreven presentatie.
Drerk-Jan de Grood ontwikkelde bij Valori een referentiemodel voor testen van Mobile Apps.
Op de blog van Derk-Jan kunt u het model bekijken.
In de slides van de presentatie die u hiernaast kunt downloaden nog wat meer informatie en enkele toepassingsvoorbeelden.