In een vorige blog over QA is al uitgebreid gesproken over wat een QA is en welke eigenschappen een QA over het algemeen heeft. Het is nu tijd voor de volgende stap: Wat is er nodig om een QA te zijn?

Ieder bedrijf en team heeft een andere invulling van wat een QA taak is en wat niet. Daar horen dan ook bepaalde tooling bij. In deze blog vertellen we wat wij binnen Egeniq onder de taken van een QA verstaan en wat daarvoor nodig is, met daarbij een aantal tools en termen uitgelegd.

De QA is binnen een team en organisatie op veel verschillende manier in te zetten. Van “alleen maar een korte check” tot en met “elke PR gaat ook langs de QA”. Afhankelijk van de rol die de QA wordt toebedeeld, is een bepaalde capaciteit nodig. Hierin zit geen goed of fout. Het is vooral afhankelijk van hoe je als organisatie of bedrijf naar de rol van de QA kijkt, plus de kwaliteit van de developers.

Egeniq is een bedrijf dat al ruim 10 jaar lang apps maakt voor smart devices. Hierin zijn we flink gegroeid, zowel in het aantal collega’s, als in de soorten apps. Met deze groei is ook de rol van QA gegroeid. Op dit moment zien wij de rol van QA zo: de QA is binnen het team DE persoon die de kwaliteit van de app en toegevoegde waarde voor de gebruiker in het oog houdt. Dit is expres heel breed gedefinieerd. Ieder project heeft namelijk een ander level van intensiteit nodig. Grofweg bestaat binnen Egeniq het takenpakket van de QA uit de volgende zaken:

• Het testen van de tickets die ontwikkeld zijn
• Het opsporen en registreren van bugs
• Vergelijkingen maken en gelijktrekken van verschillende platformen
• Vragen, vragen en nog eens vragen
• QA als eerste gebruiker
• Het uitvoeren van regressietesten
• Het in de gaten houden van crashes

Binnen Egeniq werken wij vrijwel geheel met Jira borden, waarbij aan de hand van tickets bepaalde zaken ontwikkeld worden. Een Jira bord heeft hierbij verschillende lanes die de voortgang en verschillende stadia van een ticket weergeeft. Een van deze lanes is de QA lane. Vrijwel elk ticket komt uiteindelijk in deze QA lane. Hierbij is het aan de QA om in feite een fiat slag te doen op dat wat ontwikkeld is. Een belangrijke stap, want development blijft mensenwerk en daar zitten dus soms fouten in. Daarnaast zal de QA ook controleren of er geen andere zaken omgevallen zijn. En, afhankelijk van het soort ticket, of alles op elk device of OS versie goed gaat.

Een belangrijk deel van het hooghouden van de kwaliteit van een app, is het minimaliseren van bugs. De QA speelt hierin een belangrijke rol. Om bugs echt goed op te kunnen lossen, moet deze namelijk als eerste bekend zijn, en als tweede reproduceerbaar zijn. Beide doet de QA. Door regelmatig net iets verder te kijken dan een ticket, of gewoon globaal door de app heen te gaan, komt hij of zij bugs tegen. Hier worden tickets van gemaakt op het Jira bord, waarnaar de developers de bug kunnen vinden.

Reproduceerbaarheid hierin is zeer belangrijk. Niet alleen bij het fixen van een bug, maar ook bij het daarna testen of de bug ook echt weg is. Soms is dit simpel, bijvoorbeeld door een specifieke pagina te open of op een plaatje te tikken. Maar het kan ook ingewikkelder zijn waarbij meerdere specifieke stappen achter elkaar gemaakt moeten worden. Door de QA deze stappen te laten zoeken en registreren, kunnen de developers focussen op waar ze goed in zijn: het nog beter maken van de app.

De meeste apps die wij ontwikkelen, ontwikkelen we voor verschillende platformen. Bijvoorbeeld de player die wij ontwikkeld hebben voor Mediahuis. Deze is te gebruiken op web, Android app en iOS app. Of de Lotto app van de Nederlandse Loterijen, waarbij we een speciale app hebben gemaakt voor het Huawei platform HarmonyOS.
Doordat de meeste developers maar aan één platform ontwikkelen, ontstaan er soms verschillen tussen de verschillende platformen. Dit kan zijn doordat tickets op verschillende manier geïnterpreteerd wordt. Maar ook omdat sommige standaard icoontjes nu eenmaal anders zijn (zoals de share icon bij iOS en Android). Of omdat dingen nu eenmaal anders functioneren (terug werkt anders in een browser dan bij een mobile app). Doordat de QA alle platformen test, ziet de QA deze verschillen. Wanneer de verschillen anders zijn dan “omdat het nu eenmaal anders werkt bij desbetreffend OS”, is het aan de QA om dit te melden. Vaak is dan de eerste stap om het verschil met de klant te bespreken. De klant kan dan beslissen wat de juiste manier is, waarna vervolgens de developers aan zet zijn om de verschillen recht te trekken.

Dit is wat elke QA veel doet. Heel veel vragen stellen. Niet alleen om te checken of iets wel goed is, maar ook om te achterhalen hoe iets hoort te werken. Deze vragen kunnen aan iedereen gericht zijn. Van developer, tot aan projectmanager, van de klant tot aan de designer.

Vooral het soort vragen is hierbij van belang. Of het design goed geïmplementeerd is, is bijvoorbeeld iets dat de QA tot op zekere hoogte zelf kan beoordelen. Maar vooral hoe bepaalde user flows zouden moeten zijn, is niet altijd vooraf even duidelijk. Dat kan dus door verschillende developers op verschillende manieren geïnterpreteerd en ontwikkeld worden. Als onderdeel van het gelijktrekken, door aan allerlei betrokkenen vragen te stellen, is het de taak van de QA om erachter te komen wat de juiste interpretatie is.

De QA is in feite de allereerste gebruiker van de nieuwe functionaliteit en kan daardoor belangrijke inzichten geven. Vanuit Egeniq denken we zo veel mogelijk vanuit het oogpunt van de gebruiker, en de QA is hierbij daardoor een belangrijke toevoeging. Want als iets voor de QA niet duidelijk is, is de kans groot dat de gebruiker het ook niet gaat snappen. Dit betekent dat op sommige punten er op andere manieren naar tickets en het testen van tickets gekeken wordt dan wat gebruikelijk is. Namelijk, wat werkt echt voor de gebruiker. En minder, wat zijn precies de requirements in het ticket.

Wanneer een ticket wordt opgesteld, wordt er altijd uit gegaan van een bepaalde situatie. Het kan goed voorkomen dat de uitwerking op papier wel logisch is, maar in de applicatie zelf niet werkt. Kritisch blijven nadenken en kijken is daarom een must. Want uiteindelijk moet niet de klant, maar de gebruiker de app gebruiken. Als het voor deze gebruiker niet werkbaar is, is voor de klant de toegevoegde waarde ook minder.

Door naar elke nieuwe functionaliteit te kijken door de ogen van een gebruiker wordt deze toegevoegde waarde gewaarborgd. En vaak geeft het verrassende inzichten voor de klanten. Want hoe je het ook went of keert, de praktijk werkt altijd anders dan wat uitgedacht is op papier.

Voordat er een app live gezet wordt, is het belangrijk om zeker te weten dat alles in de app nog naar behoren werkt. Dit doen we door middel van een regressietest.

Bij een regressietest worden alle belangrijke functionaliteiten langs gegaan, om zeker te weten dat ze nog doen wat ze moeten doen. Zo is het bijvoorbeeld bij de BankGiro Miljonairs app. belangrijk dat de gebruiker antwoord kan geven op de vragen, de hulplijnen kan gebruiken en bij een fout antwoord terug is bij af. Iedere app heeft zo zijn eigen belangrijke functionaliteiten. De QA is degene die als geen ander weet wat de belangrijkste functionaliteiten zijn en hoe deze goed te checken.

Soms is het ook goed om minder belangrijke functionaliteiten te checken bij een regressietest. Bijvoorbeeld om dat er een nieuwe functionaliteit is toegevoegd, of omdat uit het verleden is gebleken dat een bepaalde functionaliteit het soms opeens niet meer doet. Ook dit is een belangrijke taak van de QA.

Een laatste, belangrijke taak bij het uitvoeren van een regressietest, is na te gaan of “alles nog overal werkt”. Dan spreken we met name over, of alle OS versies die ondersteund worden alle user flows nog wel naar behoren kunnen uitvoeren. Hierbij is het ook belangrijk om de verwante smart devices in de gaten te houden, zoals Chromecast en Airplay.

Maar, met welke versie en waar is het het beste om een regressietest te doen? Het antwoord is kort, maar soms wat ingewikkeld. Een regressietest moet gedaan worden op de plek die het dichts tegen productie aan zit. Voor iOS is de plek dan ook een no-brainer: regressietesten doe je via een Testflight build. De volgende stap hierna is namelijk de app echt live zetten (na review van Apple), dus dichterbij productie behalve productie zelf kom je niet.

Voor Android heb je een aantal keuzes. Developers kunnen zorgen voor een APK file. Een APK file is namelijk ook datgene wat geupload moet worden naar de Google Playstore. Wat voor Android ook kan, is gebruik maken van de Alfa of Beta track binnen de Google Playstore. Hierbij kan je kiezen voor een internal, closed of open testing. Afhankelijk van het soort app, wat je wilt testen en met wie, kan hierin een keuze gemaakt worden. Omdat het maken van een APK file vaak sneller is, en een Alfa of Beta track opgezet moet worden binnen de Playstore, is binnen Egeniq regressietesten via een APK file de standaard. Maar de Alfa of Beta track van de Playstore is zeker ook een goede optie.

Voor web of API platformen, is vaak het meest eenvoudige om een beta-omgeving op te zetten. Deze dient dan gevuld te worden met productie data. Zonder productie data is er namelijk te weinig te zeggen of bepaalde functionaliteiten het wel of niet goed doen.

Om gelijk een mythe de wereld uit te helpen: iedere app heeft crashes. Hoe goed en eenvoudig een app ook is, altijd is er wel ergens een gebruiker die iets doet waardoor de app ermee ophoudt of een error geeft.

Toch is het goed om crashes in de gaten te houden, zeker vlak na een release. Wanneer namelijk het aantal crashes opeens stijgt, zegt dit iets over de stabiliteit van de app. In een ideale wereld gaan het aantal crashes iedere release weer iets omlaag. In de praktijk is het al prettig als het aantal crashes na een release gelijk blijft.

Wel kan er iets gedaan worden aan crashes in de app. De QA speelt binnen Egeniq hier een belangrijke rol in. Bij vrijwel elke app die wij ontwikkelen, integreren wij Firebase. Dit is een online tool van Google waar veel mee gedaan kan worden. Een van de opties is bijhouden van de crashes via Crashlytics. De eerste 24 uur van een app release houdt de QA in Firebase de crashes in de gaten. Wanneer er meer dan gemiddeld crashes binnen komen, wordt dit gemeld aan het team. Dan kan er besloten worden een hotfix uit te brengen.

Op het moment dat het aantal crashes niet omhoog gaat, maakt de QA na een dag of 3/4 tickets in het Jira bord aan, welke een volgende sprint opgepakt worden. Op deze manier wordt de app iedere release ook echt net weer een stukje beter.

Eén van de manieren binnen Egeniq om ervoor te zorgen dat het design zo goed mogelijk wordt geïmplementeerd, is het organiseren van Design Review Meetings. Binnen Egeniq hebben we allerlei soorten projecten. Wat alle projecten gemeen hebben, is dat vroeg of laat een nieuw design geïmplementeerd moet worden. Zo’n implementatie van een design is wat de gebruiker uiteindelijk ziet. Het is dan ook niet raar dat dit voor onze klanten een belangrijk aspect is van het ontwikkelproces.

De QA speelt hierbij een belangrijke rol. De QA is namelijk degene die als eerste, nadat de ontwikkelaars klaar zijn, die de implementatie van het design ziet. En dit dan op verschillende devices en verschillende schermgroottes. Vooral dat laatste is nogal eens een uitdaging. Vaak wordt een design namelijk niet voor elk schermgrootte gemaakt. Met name voor de bijna wildgroei aan devices bij Android kan dit soms nog al een uitdaging zijn.

Daarnaast is een design vaak een statisch iets. Allemaal aparte schermpjes die soms wel aan elkaar gelinkt zitten. Maar echt het gevoel van hoe het op een device echt werkt, kan je er niet mee krijgen.

Om deze redenen hebben we binnen Egeniq Design Review Meetings geïntroduceerd. Wanneer een pagina of een gedeelte van de applicatie klaar is, en de grootste design bugs zijn eruit, wordt er een screen sharing sessie gepland met zowel de klant als de designer. Hierbij wordt er vrijwel niet naar het design gekeken, maar staat de gebruiker centraal. Door samen door de app of pagina los van het design heen te lopen, ontstaat er vrijheid voor zowel de designer als voor de klant om aanpassingen aan te dragen op het geïmplementeerde design. Deze aanpassingen worden opgesomd in een nieuw ticket.

Dit geeft rust in de sprint, omdat tickets minder vaak terug komen met van die laatste puntjes op de i. En rust bij de klant en designer, omdat zij beide nadat het design definitief is altijd nog zaken kunnen en mogen aanpassen.

Dit zijn een aantal voorbeelden van hoe wij van Egeniq tegen de rol van QA aankijkt. Zoals in het begin al beschreven, er is geen goed of fout hierin. Het belangrijkste is dat erover nagedacht is en er bewust keuzes gemaakt zijn om voor een bepaalde invulling te kiezen.

Deel 2

Deel 3