Tip - Bouw meteen je Testhulp – “Focus on Feature”
Naam Paul Bentvelzen
Functie Product Owner ANWB Connected
Bedrijf Implementatiemanager IOT
Sinds we aan de slag zijn met IOT lopen we er regelmatig tegenaan dat we een nieuwe feature bouwen op de IOT-component in een API terwijl we nog geen uitgewerkt product hebben om het in te testen. De leverancier van het IOT-component levert de nieuwe feature op en roept trots “Het werkt!”, waarna wij ons hoofd breken over de afname test en de ingebruikname in een product voor de klant. We kunnen niet wachten op de uitwerking en realisatie van de implementatiein bijvoorbeeld een app (vaak ook weer door een ander team) terwijl we wel nu moeten starten met testen en accepteren.
Wat we wel weten en vooraf kunnen vaststellen zijn de criteria waar ons product (meestal via een API-laag) aan moet voldoen én dat de geboden data via de API-laag ook accuraat moet zijn. Wij ontsluiten immers de IOT-component en nemen daarmee ook verantwoordelijkheid voor de bruikbaarheid en de kwaliteit van de geboden data.
Laten we er een concreet voorbeeld bij halen. Bij Connected Car ontsluiten we data uit een auto door een Connector (lees IOT-component) in de OBD II-poort van de auto te prikken die constant data uitleest en via het 2G netwerk naar ons in de backend stuurt. Deze data maken wij weer beschikbaar voor de bestuurder van de auto zodat hij/zij via een app of laptop de status van zijn auto kan zien.
Nu werken we aan een nieuwe feature die straks in de Connected Car App het brandstofniveau van de auto zichtbaar kan maken. Hiervoor ontwikkelen we een CAR API die de data beschikbaar stelt voor de Connected Car App of het dashboard op de Laptop/PC.Als we tijdens de refinement/ontwerpfase nadenken hoe we deze nieuwe feature in de Connector en de CAR API moeten gaan testen bedenken we ook een Testhulp die een eigen userstory krijgt. Voor het zichtbaar maken van de brandstofmetingen uit de auto via de connector hebben we alsTesthulp “Focus on Fuel” gemaakt.
We ontwerpen dan eerst een simpel scherm waarin we alle relevante testdata van een specifieke (test-) auto verzamelen en met elkaar in verband brengen.Het testen en hertesten wordt op deze manier zeer vereenvoudigd omdat tijdens het testen alleen maar opgegeven hoeft te worden naar welke testauto gekeken moet worden en alle bijbehorende API-calls worden direct uitgevoerd en met de opgehaalde data gepresenteerd.
Bevindingen zoals rare pieken in de metingen, het nooit registreren van een 100% volle brandstoftank, of een auto die helemaal geen data afgeeft, zien we terug in een grafiek en deze grafiek kunnen we weer duidelijk bespreken met onze (internationale) partners. Een hertest is een druk op de knop waarna de laatste brandstofstanden weer in één keer zichtbaar worden.
De Tip in een notendop
De “Focus on Feature” wordt als Development-story opgenomen in de sprint, gebouwd door het Team en gebruikt door het Team tijdens testen en acceptatie.
De Product Owner kan tijdens de Sprint Review de “Focus on Feature” gebruiken om te laten zien dat de nieuwe feature werkt zonder dat er een eindproductvoor de klant beschikbaar is.
Tijdens de beheerfase gebruikt het Team de “Focus on Feature” om beheervragen van klanten te onderzoeken of changes vanuit de IOT-keten te testen.
Waarom ben ik zo enthousiast over deze tip dat ik hem wilde delen met jullie in deze Testblog? Deze aanpak maakt vanaf het begin testen tot een Team-effort waarbij iedereen naar beste kunnen bijdraagt aan het testen van een nieuwe feature én er gezamenlijk verantwoording genomen wordt voor een werkend product.
Agile testen ten voeten uit!