Case

Remote arcade games: de uitvoering van het Elaut project

Nood van de klant

Elaut – een wereldspeler in amusements- en arcadespelen – was geen onbekende meer voor Refleqt. In onze vorige case lees je hoe we – in samenwerking met Cloudway, AppFoundry en Gluo – een succesvolle Proof-of-Concept (PoC) opstelden om de haalbaarheid van remote arcade spellen te testen. Een zeer grote uitdaging daarbij was de latency.

Wanneer je vanop afstand een grijpklauwmachine bedient om een knuffel te proberen scoren, moet je via een livestream kunnen zien hoe de machine reageert. Er mag dus niet te veel vertraging op het beeld zitten.

Vanaf wanneer we bewezen dat we voldoende expertise in huis hebben om dit project met een minimum aan latency te realiseren, mochten we starten met de development. Vanaf dan begon het echte werk.

Refleqt oplossing & deliverables

Opzet development Livecadia

Er was nood aan twee applicaties: eentje voor de spelers, een andere voor de configuratie en monitoring. In die laatste kan de arcadebeheerder de machines en prijzen configureren, maar ook controleren hoeveel spelers er zijn ingelogd, hoeveel van hen al een prijs hebben gewonnen, de gemiddelde duurtijd van een sessie of wanneer er iets misliep tijdens het spelen.

Vanuit Refleqt vervolledigden we het team van front-end- en backend developers met één en tijdelijk twee test automation engineers om de kwaliteit van de geleverde applicaties te verzekeren. Bij Refleqt hechten we er veel belang aan dat onze test automation-oplossing onderhoudsvriendelijk is en zo efficiënt mogelijk kan draaien. Vandaar dat we kort na de start tijdelijk extra versterking voorzagen om op korte termijn up-and-running te zijn met een volwaardige test automation-oplossing en alsnog de snelle oplevering van features konden volgen.

SCRUM werkwijze

Om de development en testing smooth te laten lopen, hadden we daily stand-ups om de stand van zaken te overlopen en werkten we in sprints van twee weken. Zodra developers een nieuwe versie ontwikkelden van een applicatie of de backend, draaiden we daar meteen een sanity check op. Met dit soort test kijken we of het gecreëerde product gezond en dus testbaar is.

Dit zorgde ervoor dat we snel konden schakelen. Er gebeurden veel changes, maar door regelmatige deployments van nieuwere versies konden we in de testomgeving telkens snel aan de slag met de allernieuwste versie. Wanneer we in de testomgeving detecteerden dat de build aan kwaliteitsverlies leed, konden we ook meteen aan de alarmbel trekken bij development.

Elke sprint sloten we af met een retrospective meeting. Dat waren momenten om te evalueren wat er goed liep en wat er minder vlot liep. Ook deze meetings droegen bij om struikelblokken agile aan te pakken.

Bij Refleqt voeren we zoveel mogelijk tests automated uit, maar soms heb je een menselijke blik nodig. Dan kan je er niet omheen dat je manueel moet testen.

Valeska

Continuous integration met regressietesten

Voor het project pasten we dus continuous integration toe. Na elke succesvolle deploy op de DEV-omgeving en nadat deze de sanity test succesvol doorkwam, deployden we die naar de TST-omgeving.

Elke nacht voerden we regressietesten uit. Daarmee controleerden we of alles wat ervoor functioneerde dat nog steeds deed. Zo hadden de developers snelle feedback op de kwaliteit van het opgeleverde product en konden bugs snel opgepikt worden. Het is namelijk makkelijker, maar ook goedkoper om issues op te lossen aan het begin van de ontwikkelstraat dan aan het einde.

Functioneel testen en test automation

Bij het ontwikkelen van applicaties zijn functionele testen ontzettend belangrijk. Bij dit soort testen ga je de applicatie testen alsof je zelf een gebruiker bent. Je schrijft daarom scripts om functie per functie van de app te testen.

Daarnaast heb je end-to-end testing. Deze testen zijn gelijkaardig aan de functionele, maar omvatten langere scenario’s die meerdere pijlers aftoetsen. Je gaat dus naar de hele gebruikservaring en -flow kijken:

  • Front-end
  • Backend
  • MQTT
  • Speelautomaten

Het doel is om te checken of heel het spelproces smooth verloopt: van het inloggen tot het claimen van jouw prijs.

Bij Refleqt kiezen we altijd om zoveel mogelijk testen automated uit te voeren. Toch konden we er niet omheen om bepaalde cases manueel uit te voeren. Sommige zaken moet je gewoon met een menselijke blik bekijken.

Bijvoorbeeld het spelen van spelletjes hebben we manueel getest. Je wil echt de gameplay ervaring na kunnen gaan. Daarom spoorden we het team aan tot exploratory testing. We vroegen aan iedereen uit het team – zowel analisten, developers, de SCRUM master … – om hun gsm regelmatig eens te openen en enkele spelletjes te spelen. Exploratory testing is een heel intuïtieve manier van testen. Het is een weinig gestructureerde aanpak, maar het levert hele waardevolle feedback op.

Struikelblokken en oplossingen

Doordat we midden in de ontwikkelfase al testen runden, moesten we vaak ook flexibel inspelen op vele changes. Wanneer er wijzigingen waren in de opzet van de applicatie, lieten we de testen dan ook zo snel mogelijk mee wijzigen.

Op een zeker moment was er een design change van de app. De lay-out wijzigde, wat grote implicaties kan hebben op een test automation-oplossing. Dit was voor ons gelukkig geen groot struikelblok. We hadden gelukkig gekozen om met een design pattern als Page Object Model te werken. Elke pagina of onderdeel van een pagina van de webapplicatie bestaan dan als een apart object in de test automation-oplossing. Wanneer er dan een pagina qua design verandert in de applicatie, is het makkelijk pinpointen welke elementen je moet updaten op het bijhorende pagina-object. Functioneel gezien moeten de testen echter niet gewijzigd worden, omdat de functionaliteit en de paginasamenstelling proactief apart zijn getrokken.

Development om remote arcade gaming mogelijk te maken

Een andere uitdaging was dat we zoveel mogelijk gebruikers wilden bereiken. Daarbij moet je rekening houden dat er heel wat soorten smartphones bestaan en een grote variëteit aan browsers. Je moet de webapplicatie dus zowel testen op een Mac als een Windows, in verschillende browsers, maar ook op verscheidene mobile devices.

Voor de mobile devices voerden we eerst research uit naar de populairste mobile devices in België en Nederland. We keken daarbij zowel naar high end, middenmoot- als budgettoestellen, om zo een brede testdekking te krijgen. Dit was belangrijk, onder andere omdat niet alle schermen even groot zijn. Dat heeft een invloed op het design en de schaalbaarheid ervan, wat weer een invloed heeft op de gebruikerservaring.

Tools en technologieën

  • Test case design: BDD met Cucumber, Page Object Model
  • Backend test automation-oplossing: Java, Maven, Swagger Codegen, MQTT
  • End user facing front-end test automation-oplossing: Java, Maven, Selenium, BrowserStack
  • Back-office front-end test automation-oplossing: JavaScript, Cypress, BrowserStack

Een resultaat om trots op te zijn

Bij Refleqt kijken we met trots terug op dit project. Allereerst omdat we een project van zo’n grote omvang op een korte tijd up and running hebben gekregen. Het had een totale duurtijd van 11 maanden.

Een tweede reden waarom we met trots terugkijken, is omdat het een technologisch uitdagend project was. We werkten met hardware, Raspberry Pi’s om die hardware aan te sturen. Daardoor voerden we niet alleen front-end en backend tests uit, maar al snel introduceerden we ook MQTT communicatie in onze testen, om rechtstreeks met de hardware te spreken.

Twee personen bij een grijpklauwmachine om te gamen

Tijdens het testen hebben we heel wat issues ontdekt, waardoor we de kwaliteit van het project hoog konden houden. We konden bijvoorbeeld redelijk nauwkeurig nagaan waar de issues zich voordeden. Wanneer we zagen dat de backend call verliep zoals die moest, maar er een error zich voordeed in de MQTT flow, dan wisten de developers ook waar ze gericht moesten zoeken. Resultaat: we konden zeer snel schakelen.

Ten slotte was het project ook een schoolvoorbeeld van samenwerken over functiegrenzen heen. Onze developers en testers werkten nauw samen om op korte termijn resultaten te boeken. Wanneer de testers merkten dat er iets faalde in de testen, kregen ze vaak van de developers de reactie: “we zijn dat al aan het oplossen” omdat ook zij naar de testresultaten keken na een deploy.

Heb jij een uitdagend project waarvoor meerdere expertises nodig zijn? Neem contact met ons op: onze testers en analisten staan klaar om hun talent in de strijd te gooien.

Heb jij een vergelijkbare uitdaging waar je hulp bij nodig hebt? Neem gerust contact op!