Analisten duikelen over elkaar heen met de meest uitlopende aantallen van dingen die straks allemaal aan het internet hangen. Welk getal het ook zal worden – meer of minder dan 26 miljard objecten in 2020 – het Internet of Things wordt in de komende jaren gemeengoed. Daarmee wordt het nu ook tijd om bestaande teststrategieën te ‘IoT-seren’.
Hoe anders is het testen van een IoT-toepassing vergeleken met het testen van een willekeurig stuk nieuwe software of een aangepast systeem? Afgelopen maand werd een aangepaste versie van de TMap marktstandaard testmethodiek gelanceerd voor het Internet of Things. De grootste verschillen met traditioneel testen zijn: 1) de primaire aandacht voor non-functionele aspecten, 2) een andere manier van samenwerken in een it-team en 3) het handelen als een start-upper.
Het ‘ding’
Het eerste dat opvalt, is dat nu ook de hardware, het ‘ding’, integraal onderdeel is van de testprocedure. In de bestaande testomgevingen is hardware al een gegeven. Een ERP-applicatie draait op een server in een voorspelbare opstelling, bijvoorbeeld in een datacenter tussen alle andere servers in. De software wordt getest. Niet de server, want de gebruiker mag ervan uitgaan dat de kwaliteit van het apparaat op orde is. Die verantwoordelijkheid ligt tenslotte bij de technologieleverancier. Dat ligt anders bij het ‘ding’ dat verbonden wordt met het internet. Deze hardware wordt veelal zelf gebouwd en is een belangrijk onderdeel van de IoT-toepassing. Of het ding is onderdeel van een product van een leverancier die niet vanzelfsprekend alle testen uitvoert voor de aan te brengen elektronica. De omgeving waarin de IoT-toepassing wordt gebruikt, varieert voortdurend of is op zijn minst veel complexer. Een auto verbonden aan het internet komt in legio omgevingen. Het is uiteraard geen doen om de IoT-toepassing in elke willekeurige omgeving te testen.
Vier vaste onderdelen
Een IoT-testaanpak bestaat uit vijf stappen (zie verderop in dit artikel) die geprojecteerd kunnen worden op de vier vaste onderdelen van een IoT-toepassing:
- Het object dat wordt voorzien van een (slimme) sensor die informatie verzamelt.
- De netwerkverbinding die ervoor zorgt dat het met internet uitgeruste ‘ding’ verbinding maakt met de dataopslag.
- Data moeten worden opgeslagen in een cloudomgeving of in een lokaal opslagsysteem. In deze laag worden data ook verwerkt en/of verrijkt.
- Gegevens worden ontsloten via een website, mobiele app of een touchscreen op het slimme object.
Deze ‘Connect-Think-Talk-Act’-lagen moeten zowel los van elkaar als in zijn geheel getest kunnen worden.
Testuitdagingen
Om te bepalen hoe je de IoT-toepassing gaat testen, moet je vaststellen wat je wilt testen, op welke manier en misschien wel het allerbelangrijkste, waar houdt het testen op? De grote valkuil bij het testen in een IoT-omgeving is dat je onnodig veel gaat testen en dat er overlap ontstaat bij het testen van de verschillende onderdelen, omdat ze zo in elkaar overlopen. Moet je bijvoorbeeld de totale IoT-omgeving simuleren in een huis waar alles verbonden is met het internet? Het is natuurlijk niet de bedoeling dat de auto voor de deur start als je de slimme wasmachine aanzet. Het klinkt vast vreemd, maar het is niet ondenkbaar dat ontwikkelaars dezelfde set commando’s kiezen die via het draadloze netwerk door de ether worden gestuurd. Met het testen van de slimme wasmachine in de omgeving van de auto wordt dat voorkomen. Het is cruciaal om vast te stellen tot op welk punt in de keten van verbindingen je blijft testen. En stopt met testen. Een eindeloos aantal variabelen valt niet meer te testen. Dat wordt te complex en veel te duur. Gemiddeld genomen is het testen van drie tot vier scenario’s van IoT-omgevingen een uitgangspunt. Uiteraard hangt dat in sterke mate af van de type toepassing. Het maakt nogal uit of je een slim wegwerpding ontwikkelt of een zware industriële toepassing om bijvoorbeeld een windmolenpark te onderhouden. Bij het wegwerpding zal de nadruk van testen meer liggen op de omgeving daar waar de interface en de gebruikersvriendelijkheid bij de industriële toepassing veel meer aandacht moeten krijgen.
Non-functioneel
Het is ook een hele uitdaging om ervoor te zorgen dat het fysieke object veilig is. Het ding is veelal een samenstelling van complexe ingebouwde technologie afkomstig van een uiteenlopend aantal leveranciers. Laten we weer die auto als voorbeeld nemen, die verbonden is aan het internet. De verschillende onderdelen komen van honderden leveranciers die allemaal andere veiligheidsmaatregelen treffen. De testers moeten verder gaan dan de gebruikelijke veiligheidstesten. Zo moeten ze ook de veiligheid van afstand kunnen testen.
Om de veiligheid, kwaliteit en een goede gebruikerservaring te testen, verschuift testen in een IoT-omgeving van het functioneel testen naar de non-functionele kwaliteitsaspecten. Zoals de prestaties van de IoT-toepassing, de snelheid, gebruikersvriendelijkheid, de betrouwbaarheid en de compatibiliteit. Die zijn allemaal nog belangrijker dan het testen van alle (combinaties van) functies onder de knoppen van een navigatiesysteem. Of bijvoorbeeld de volledige functionaliteit van een IoT-wasmachine. Je mag ervan uitgaan dat de fabrikant een goede wasmachine kan produceren. Maar het testen van de connectiviteit is geen specialiteit van de wasmachinefabrikant.
Testexpertises
Anders dan in een traditionele omgeving van softwareontwikkeling en testing, heb je bij IoT-testen veel meer verschillende testexpertises nodig. Het testen van diverse onderdelen van een IoT-oplossing vraagt om het combineren van de juiste testexpertises. Zo is het testen van een mobiele app iets anders dan het testen van benodigde datavarianten of veiligheidstandaarden. En wanneer heb je wie nodig? Niet iedereen is op elk moment even nodig. De teams kunnen dus voortdurend van samenstelling wisselen. Daarbij bestaat het risico dat er onnodig veel wordt getest en dat er overlap ontstaat met de inzet van zoveel verschillende testexpertises. Intensieve samenwerking en regie daarop zijn dan ook van cruciaal belang. Er moet wel iemand zijn die integratie en afstemming in de gaten houdt.
Niet uitontwikkeld
Bij het testen van een IoT-toepassing krijgt de eindgebruiker een prominente rol. Het is zaak deze eindgebruiker vanaf het begin bij de ontwikkeling van de oplossing te betrekken. Of op zijn minst de marketeer of producteigenaar die de eindgebruiker vertegenwoordigt. Deze persoon moet onderdeel zijn van het testteam. Zoals het een succesvolle start-upper betaamt, heb je het lef om een product te maken dat nog niet helemaal uitontwikkeld is. Je vraagt om feedback van de eerste groep klanten. Bij deze aanpak verandert ook de rol van de testprofessional. In plaats van zelf te testen, zorgt de testengineer voor het binnenhalen van de reacties en voor het bepalen van welke informatie daarvan belangrijk is. De feedback kan op een intelligente manier geanalyseerd worden. Daarmee kan de testprofessional patronen halen uit de reacties. Bij het aansturen van een koffiemachine via een app kan de tester zien dat de gebruikers steeds na het indrukken van een bepaalde knop in de app op een knop voor uitleg klikken. Het is een hele kunst om erachter te komen wat daarvan de oorzaak is. Dat kan bij wijze van spreken voortkomen uit een poort op een switch bij het telecommunicatiebedrijf die onterecht dicht of open staat. Deze start-up-mentaliteit van snel een product in de markt zetten terwijl het nog niet volledig uitgekristalliseerd is, vraagt om een andere cultuur. Of beter: om mensen met andere vaardigheden.
De vijf stappen
Ongeacht de type IoT-toepassing die wordt ontwikkeld, zijn er altijd vijf stappen nodig op weg naar een goede testaanpak: 1) het testen van de verschillende IoT-lagen, 2) het combineren van testexpertises, 3) de selectie van de juiste IoT-testomgeving, 4) het vaststellen van de te testen kwaliteitseisen en 5) het bepalen van bouwstenen die nodig zijn voor de meest effectieve teststrategie bij het verbinden van dingen en mensen aan het internet.
Testen van de IoT-lagen
Binnen de vier lagen (‘Connect-Talk-Think-Act’) wordt functioneel getest, veelal in agile teams. Uiteindelijk moet de toepassing ook in zijn geheel worden getest.
Combineren van testexpertises
In deze fase maak je een inventarisatie van de benodigde testexpertises. Dat moet op tijd gebeuren, zodat ook het besef ontstaat welke diversiteit nodig is en dat teams dus voortdurend van samenstelling kunnen veranderen.
Selectie van de juiste testomgevingen
We hadden al geconstateerd hoe moeilijk het is om vast te stellen tot hoever je wilt gaan in het testen in verschillende omgevingen. Het ligt voor de hand dat aan het internet verbonden auto’s met elkaar moeten communiceren. Maar de vraag is of zo’n auto ook verbinding mag maken met de koelkast of wasmachine? Dat kan handig zijn of juist tot ongewenste interacties leiden. Het is zaak na te denken over de schillen rondom de IoT-toepassing. Bijvoorbeeld de contacten onderling tussen de auto’s. De contacten met de database van de leverancier en het contact met het slimme huis. Hoe verder je van binnen naar buiten door de schillen gaat, hoe groter het aantal combinaties dat moet worden getest. Dat levert uiteindelijk een onmogelijk aantal op. Dus moeten er keuzes worden gemaakt. De consequenties van die keuzes, bijvoorbeeld voor beveiliging, moeten in kaart worden gebracht. Het indelen in die schillen helpt de bewustwording en moet dus zo vroeg mogelijk in het ontwikkeltraject plaatsvinden.
Vaststellen van de te testen kwaliteitseisen
Tijdens stap vier wordt vastgesteld welke eigenschappen van de oplossing getest moeten worden. Zoals de mate van compatibiliteit, betrouwbaarheid en gebruikersvriendelijkheid. Een ander belangrijk aspect is de interoperabiliteit. IoT vraagt bijvoorbeeld om communicatie met de app op een smartphone. Voor iOS-apparatuur is de diversiteit nog overzichtelijk met ongeveer tien modellen. Maar bij Android heeft Samsung alleen al veel meer hardware-modellen. Om nog maar te zwijgen van de vele versies aan besturingssystemen die in omloop zijn. De eis bij elke IoT-oplossing is dat de app op alle smartphones werkt.
Bepalen van benodigde bouwstenen
Bij het bepalen van de bouwstenen in deze laatste fase wordt bijvoorbeeld vastgesteld welk deel van de IoT-oplossing volledig geautomatiseerd getest wordt en waar al dan niet crowdtesting of andere testhulpmiddelen worden ingezet. De inzet van kunstmatige intelligentie en machine-learning wordt ook steeds meer toegepast bij de inzet van de juiste bouwstenen.
Op dit moment werken veel organisaties aan de ontwikkeling van een aangepaste teststrategie voor IoT-toepassingen. Meer weten? Lees dan het boek Testing in an IoT Environment (http://bit.ly/1UYcFBA).
Tom van de Ven is auteur van het boek Testing in an IoT Environment en Senior Consultant bij Sogeti
