In de ontwikkeltrajecten voor mobile apps wordt nog wel eens getwijfeld aan het nut van testen. Dat is veelal iets voor legacy-toepassingen van hele grote organisaties, is de perceptie. Nauwkeurig geplande testtrajecten die maanden kunnen duren. En waar testteams met tientallen leden bezig zijn met het uitgebreid specificeren van testscripts en het testen van de oplossing. De mobiele wereld is te onzeker om ver vooruit te plannen. Er is nauwelijks tijd om uitgebreide testscripts te maken. Een app lijkt ook maar een klein stuk software met weinig functionaliteit. Wat is dan een verantwoord testtraject?
In de mobiele wereld twijfelt niemand aan het belang van de kwaliteit voor het succes van de app. Uit ons jaarlijks wereldwijde onderzoek naar software kwaliteitszorg blijkt dat testen van mobiele apps voor velen nog altijd een grote uitdaging is.
Zo blijkt uit het World Quality Report dat bijna de helft van de ondervraagden (45 procent) vindt dat de validatie van de functionaliteit, performance en beveiliging van mobiele applicaties en apparaten tekortschiet. Hoewel het rapport een explosieve groei van mobiel testen laat zien (van 31 procent in 2012 naar 55 procent in 2013), geeft ruim de helft van de organisaties (56 procent) aan dat het gebrek aan specialistische methoden het grootste obstakel is bij het mobiele testen. Ook meldt 48 procent van de ondervraagden dat er nog steeds een gebrek is aan experts voor mobiel testen.
Een paradox? De behoefte aan kwaliteit blijft of wordt zelfs groter. Tegelijkertijd wordt testen als een bureaucratisch en vertragend proces ervaren. Hoe komt dat? Het antwoord is helder. De eisen die gesteld worden aan de mobiele tester zijn totaal anders dan die van de tester van tien jaar geleden.
Testopdracht
Ik herinner me mijn eerste testopdracht nog goed. Zo’n tien jaar geleden. ‘Jij gaat het proces ‘Controleren aanvragen’ testen.’ Deze opdracht werd uitgesproken door de testcoördinator die opdracht had gekregen de test van het nieuwe pensioensysteem in goede banen te leiden. Ik kreeg drie weken de tijd en een document van vijftig pagina’s met taaie terminologie over het pensioensysteem. De eerste week had ik nodig om me door dit stuk van zware kost heen te worstelen. Na de eerste week werd deze functie van het systeem opgeleverd voor het testen. En de testuitvoer bleek nog veel meer werk te zijn.
Ik sloeg me er doorheen. Voerde alle testgevallen uit en ik vond een aantal issues die werden opgelost. Na een hertest bleek alles in orde te zijn. Uiteindelijk was ik ruim drie weken verder. Dat was toen geen enkel probleem. Op zo’n groot project was enige uitloop niet erg, zo werd gezegd.
In die drie weken was ik gekluisterd aan mijn bureau. Ik had nauwelijks contact met anderen uit de organisatie. Uiteraard had ik wel vragen voor de persoon die mij de documentatie had overhandigd. Ook had ik nog wel eens contact met de programmeur. Daar bleef het bij. De gebruikers van de software sprak ik niet. Ik nam ook maar aan dat de opgeleverde kwaliteit in orde was toen de test was afgerond.
Hoe anders gaat dat nu ik een mobiele iPhone app test voor een grote organisatie. Ik maak deel uit van een team van ontwikkelaars. Er is geen persoon die mijn testen ‘aanstuurt’. Als team beslissen we samen wat en hoeveel we gaan testen. Een deadline is er wel. Binnen een week moet de mobiele app goed functioneren. De app gaat vervolgens via de app store naar de productie-omgeving.
Documentatie is er nauwelijks. Om te achterhalen hoe de app zou moeten werken, ga ik in gesprek met allerlei mensen. Natuurlijk de analisten en de ontwikkelaars, maar denk ook aan marketing, beheer, sales, gebruikers, enzovoort.
We hebben weinig tijd voor de specificatie. De eerste versie van de app is beschikbaar. Tegelijkertijd gaat het testen van start. In mijn eerste bevindingen vind ik een paar issues die ik zelf kan aanpassen door een kleine wijziging te maken in de code.
Op datzelfde moment spreken teamleden hun zorg uit over performance, security en usability. Hoe gaan we dat testen? Ze kijken mij aan voor een oplossing. Mijn kennis moet zich dus veel verder uitstrekken dan tien jaar geleden. Ik moet een performancetest kunnen inrichten en een gebruikerstest organiseren. Verder moet ik weten wat belangrijk is voor de security van de app.
Compleet andere baan
Als je de werkzaamheden van toen en nu naast elkaar zet, is het eigenlijk gek om beide ‘testen’ te noemen. Ik heb nu een compleet andere baan. Er zijn fundamentele verschillen tussen de aanpak van toen en nu. Een nieuwe generatie testers is opgestaan. Leve de tester dus!
Thomas Veltman. mobile app testconsultant Sogeti
Testingconferentie
Meer weten over de toekomst van mobiel testen? Kom naar de ‘tmapdag’, de grootste testingconferentie van ons land op 1 oktober 2013 in Bussum.
Reacties
Thomas,
Als ik de stukken in de krant lees krijg ik weleens de indruk dat het testen van pensioensysteem nu ongeveer gaat zoals jij beschrijft. Het ene proefballonetje na het andere wordt gelanceerd om een oplossing te vinden voor dat andere urgente probleem, de financiering van een stelsel aan afhankelijkheden.
Dat 'time-to-market' nu belangrijker is wil dus nog niet zeggen dat het proces van testen zelf veranderd is. Integendeel zelfs als ik kijk dat er nu pas rekening gehouden lijkt te worden met aspecten zoals beveiliging, performance en misschien zelfs wel het uiteindelijke beheer.
Prachtig als er elke maand een nieuw app komt met nieuwe rekenregels om me een idee te geven van uiteindelijke pensioenrechten maar dat lijkt me het probleem van de keten dus nog niet op te lossen.
Ewout,
Mijn ervaring met het testen van pensioensystemen is dat het behoorlijk gestructureerd en met zorg gaat. Heb je een specifiek voorbeeld in gedachten?
Mijn voornaamste stelling is dat het werk voor een tester in een mobiele omgeving totaal anders is dan in een traditionele omgeving. Je hebt andere vaardigheden nodig, en je moet misschien wel een ander persoon zijn.
Misschien is een goede vergelijking met voetbal te maken: je hebt spelers die het fantastisch doen als spits in een bepaald systeem, maar als ze naar een andere club gaan en een ander systeem dan schieten ze er geen een meer in.
Dan kan je ook zeggen: ja, het blijft allebei voetbal. Maar toch heb je in het ene systeem een ander persoon nodig met andere vaardigheden dan in het andere.
Dit geldt denk ik ook voor het proces testen: je hebt op een bepaald niveau dezelfde activiteiten om uit te voeren (testuitvoering, specificatie, planning, etc.) maar hoe je die activiteiten invult verschilt enorm.
Thomas,
volgens mij benoem jij hier gewoon een aantal verschillen tussen testen in een agile ontwikkeltraject en een waterval ontwikkeltraject. Nou zal die eerste ongetwijfeld veel gebruikt worden bij het ontwikkelen van mobiele apps, maar is niet exclusief aan mobiele apps.
Hoe populairder agile wordt, hoe meer de testrol zal veranderen zoals jij beschrijft. Wie weet, misschien ontwikkelen we over een paar jaar wel een pensioenapplicatie mbv agile.
Arjan,
Je hebt gelijk dat voor een groot deel dit met Agile te maken heeft (maar niet alles, ook met de grootte van het project en de eisen die worden gesteld aan de software).
Ik ben wel benieuwd naar de "Wie weet....". Wat denk jij? Dat er in een pensioen/legacyomgeving ruimte is voor Agile? Ik weet toevallig dat jij er ook wat ervaring in dat soort omgevingen...
Hoi Thomas,
Ik werk zelf graag in een Agile omgeving. Maar ik denk niet dat de pensioen/legacyomgeving heel goed in een Agile omgeving past.
Alle requirements en business rules liggen vast en processen moeten voor een correcte werking dan ook vastgelegd worden.
Het is dan ook niet vreemd dat het nog steeds in een waterval omgeving ontwikkelt wordt. Je kan denk ik niet heel erg flexibel zijn. Het is vaak ook niet mogelijk om kleine delen op te leveren. Wanneer de processen zelfstandig zijn en gekoppeld kunnen worden is dat niet meteen Agile omdat je dan de volgorde kan bepalen.
Alles moet gebouwd worden en dan pas heb je een volledig product.