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:

• Uitbesteden van de declaratieverwerking aan een externe servicepartner;
• De klant alle gegevens laten invullen via een portaal, wat het werk naar de klant verplaatst;
• Scannen van de papieren declaraties gevolgd door veld- en karakterherkenning (OCR) en automatisch overzetten van de content naar het back-office systeem;
• Idem, maar dan op basis van scans die per e-mail of via een web portaal binnenkomen.

 

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:

• PR: een App is hip en kan veel positieve exposure opleveren;
• Gemak voor de klant: wat is makkelijker dan je nota's via een dedicated app even scannen met je smartphone en op een veilige manier direct naar je verzekeraar sluizen;
• Kostenreductie: door een hoger STP percentage.

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:

• Negatieve PR: Met een App sta je in de etalage, inclusief mogelijke negatieve reviews in de App Store;
• Klagende klanten: als de App niet stabiel is op alle mobiele platforms heb je een dissatisfier voor je klanten gecreëerd in plaats van een blijmaker;
• Hogere kosten: als de klanten hun smartphone niet goed stilhouden of met slecht licht scannen dan is de kwaliteit van de scans belabberd en is het STP percentage misschien wel veel lager dan bij gescande papieren.

 

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:

• Waarom de huidige cijfers uit de online keten als maatstaf nemen?
• Is het reëel om de bestaande keten te vergelijken met een nieuw kanaal?
• De cijfers zijn blijkbaar meetwaarden, maar waarom 2 cijfers achter de komma? Als requirement zou je rondere cijfers verwachten.
• Wat is de definitie van 'goed', 'redelijk', 'matig' en 'slecht'?
• Wat moeten we eigenlijk met categorie e. aan?

 

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:

• Je kunt je App op zichzelf technisch en functioneel prima testen: doet 'ie wat 'ie volgens het ontwerp moet doen? Kun je je profielgegevens goed invullen? Is e.e.a. voldoende beveiligd?
• Ook de communicatie met de STP straat is prima te testen: komen de declaraties goed binnen en wordt een kwalitatief goede scan juist verwerkt?
• Je kúnt ook de kwaliteit van je veld- en karakterherkenning, en de juiste mapping op de databasevelden testen. Dat vergt wel een standaard referentie set van scans. Die was er niet echt.

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:

• Je kunt niet de discipline van de klanten testen: houden ze hun smartphone recht boven de nota, zorgen ze voor goed licht, trillen ze niet? Daar kun je wel onderzoek naar doen uiteraard, maar is dat testen? Nee dus.
• Je kunt wel functionaliteit en helpende functies in de App bouwen die de klant helpen om een betere scan te maken. En die functies kun je inderdaad testen.
• De kwaliteit van je scans is ook nog eens afhankelijk van de kwaliteit van de camera in je smartphone. Welke variaties in hardware en besturingssystemen moeten we allemaal meenemen? Die vraag werd rijkelijk laat gesteld en is nogal pragmatisch geadresseerd met de devices die 'toevallig' in de organisatie (projectteam, testteam en betrokkenen) beschikbaar waren.
• Kun je de kwaliteit van de camera's 'testen'? Ja dat kan: uiteraard zijn er methoden en technieken om de kwaliteit van de opnamen in een labaratoriumopstelling te beoordelen. Konden we dat in het kader van het project even doen? Nee, dat niet.

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@valori.nl

@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.