In dit tweede deel van het SAP S/4HANA vierluik kijken we naar een min of meer nieuw fenomeen van testen binnen de SAP omgeving: het testen op apparaten als mobiele telefoons, tablets en PDA’s. SAP was voor de komst van Fiori een typische desktop applicatie, waar aparte webapplicaties nodig waren om PDA invoer te genereren. SAP op je telefoon was er nog niet bij. Tot een paar jaar geleden. Omdat bedrijven niet direct bij introductie vanuit Waldorf overgaan op de nieuwste versie, is het testen op devices nu pas actueel en nog vaak onderschat. Bovendien verwacht de hedendaagse gebruiker een gebruiksvriendelijke interface, sinds de opkomst van apps op de telefoon.

Het testen op devices vraagt een aanpak die twee grote obstakels opwerpt. Ten eerste is device testing tijdrovend. Naast het testen van de desktop versie, moet de tester dezelfde functionaliteiten op bijvoorbeeld een iPad of iPhone testen. Of erger nog: op vier of vijf verschillende apparaten. En verschillende versies van een mobiel besturingssysteem. Het andere punt is dat het testen van bijvoorbeeld een Android telefoon pas zin heeft als de testsetting lijkt op de dagelijkse praktijk van de beoogde gebruiker. In deze blog geven we tips voor device testing, die de komst van dit relatief nieuwe fenomeen een stuk gemakkelijker maken.

Welke apparaten te testen?

De eerste vraag die opdoemt. Welke mobiles moet ik testen? Welke tablets? De kern van device testing is responsiveness. Met andere woorden: schaalt het scherm zoals ik dat op mijn desktop zie, netjes over naar het scherm van een Samsung tablet? En worden de voor devices specifieke front end functies juist getoond? Wat gebeurt er als de Android gebruiker op ‘terug’ klikt? Een ander mooi voorbeeld daarvan is het zogenaamde hamburger menu dat in veel apps te zien is. De juiste keuze in welke devices te testen kan gemaakt worden door Google Analytics in te zetten. Dat laat zien welke apparaten en welke software versies het meest door klanten en/of medewerkers gebruikt worden. Of je kunt simpelweg kijken naar de devices die aan medewerkers door het bedrijf worden verstrekt. En in logistieke omgevingen moet een PDA (personal digital assistent) vaak onderdeel zijn van de testcyclus. Onze tip is het maximaal tot twee mobiles en twee tablets te beperken, uiteraard afhankelijk van de gebruikssituatie. Een managementrapportage over de financiën zal een ander gebruik vragen dan het inchecken van goederen in een distributiecentrum. Bij het testen op nog meer devices zoek je naar de onwaarschijnlijke uitzondering op de regel en vind je meestal alleen defects die je op de andere apparaten ook al vond.

Technische setup van device testen

Juist omdat apparaten als mobiles en tablets anders reageren op software dan desktops, is het van belang de setup van het device overeen te laten komen met de praktijk. Denk daarnaast ook aan beveiliging. Voor veel bedrijven betekent dit dat er via VPN wordt gewerkt op productie en/of getest (later meer hierover). Bovendien wil je de dagelijkse apps van de gemiddelde gebruiker er op hebben staan. Het liefst actief in gebruik. Sommige testers neigen er naar hinderlijke apps van het toestel te verwijderen. Hiermee houdt je jezelf voor de gek. Bij een grutterbedrijf werden bijvoorbeeld de Google managed services van de PDA gehaald om afleiding te voorkomen. Totdat later bleek dat een nieuwe update van S/4HANA deze juist nodig had. Zonder device testing was dit niet naar voren gekomen.

Zorg voor een setup die zoveel mogelijk gelijk is aan de werkelijke situatie

Nu zijn er online ook emulatoren en simulatoren te vinden, die voorkomen dat je met allerlei hardware in je maag zit. Die moet je namelijk veilig opbergen, opgeladen houden en meer van dat soort randzaken. Browserstack is een hele bekende in dit genre. Het nadeel van deze ‘latoren’ is dat ze voornamelijk naar de schaling van het scherm kijken. Als je bijvoorbeeld uren wilt boeken via Fiori, kom je hier niet mee weg. Omdat doorgaans alleen de IP adressen van de bedrijfsdevices op de whitelist staan, zegt dit niets of de medewerker thuis op zijn iPhone zijn declaratie in kan vullen. Een van de zaken waar je aan kunt zien dat device testing nieuw is in de SAP wereld, blijkt uit dit voorbeeld. Bij het uren boeken op devices, komt heel wat kijken. De technische setup van het device speelt in ieder geval een grote rol.

VPN

Bedrijfsgevoelige informatie wil je alleen benaderbaar laten zijn via een VPN verbinding in de situatie dat de gebruiker vanuit huis of bijvoorbeeld in de trein werkt. De meeste gebruikers van SAP hebben waarschijnlijk een mobieltje van de zaak en werken dus via een VPN verbinding. Dus ook het testen doe je dan altijd via een VPN om de productiesituatie zo veel mogelijk na te bootsen.

Testscenario's

Dan het testen zelf. Je weet welk apparaat, je hebt de technische setup die je moet hebben. En nu? Wat ga je precies testen? Stel, je hebt twee mobiles en twee tablets waarop je wilt testen. Samen met de desktop versie, heb je dan vijf keer hetzelfde scenario te testen. Dit kun je oplossen door voor de devices een dambord model te hanteren. Een scenario dat uit negen testcases bestaat (inloggen en acht andere functionaliteiten) verdeel je over de vier apparaten. Dus naast het inloggen doe je twee functionaliteiten op ieder apparaat.

Voorbeeld dambord testscenario

Om vervolgens bij een nieuwe test de scenario’s te switchen van het ene naar het andere apparaat. Zo beperk je de testomvang, maar blijk je in de praktijk zelden iets over het hoofd te zien. Een techniek die vaak gebruikt wordt voor devices is exploratory testing en error guessing, nadat je de structuur en dekking hebt afgebakend in de emulator.

PTWEE helpt SAP gebruikende bedrijven beter en slimmer te testen en hanteert daarbij een pragmatische aanpak. Deze tip is opgesteld door Martin Heining in samenwerking met Stefan Roza, SAP Testconsultants bij PTWEE. Heeft u behoefte om vrijblijvend met ons van gedachten te wisselen over uw testuitdagingen? Neem dan contact met ons op.