Auteur: Fatih Topcuoglu
Hoe pak je het testproces aan in teams waarin front-end- en mobiele applicaties gebouwd worden? Testen in de cloud klinkt als de logische oplossing. Maar is dat altijd wel het geval? Dekken cloudproviders als Browserstack of SauceLabs de behoefte volledig? Is de aanschaf en beheer van een eigen apparaten voorraad noodzakelijk? Zo ja, hoe bepaal je welke apparaten opgenomen moeten worden in de voorraad?
Fysieke voorraad
Uitgaande van eigen ervaringen kan ik zeggen dat veel organisaties een fysieke voorraad hebben. Hiernaast worden ook virtuele apparaten ingezet die verkrijgbaar zijn bij de cloudproviders. Met name bij projecten waar veel aandacht wordt besteed aan de zogeheten ‘user-testen’ is het hebben van een apparatenvoorraad vaak noodzakelijk. Het gaat om diverse apparaten die achter slot en grendel op een afdeling worden bewaard en beschikbaar zijn voor zulke testdoeleinden. Tijdens de ‘user-testen’ worden de testpersonen in een lab-omgeving geobserveerd om feedback te verkrijgen. Deze personen behoren tot de doelgroep en zijn meestal bestaande of potentiële gebruikers.
Ook vergemakkelijkt het hebben van een apparatenvoorraad het ontwikkel- en testproces. Het handmatig testen en/of reproduceren van een bevinding is op een fysiek apparaat gemakkelijker en sneller. Waar virtuele apparaten uitermate geschikt zijn voor testautomatisering.
Analyse
Maar hoe bepaal je dan welke apparaten opgenomen moeten worden in de voorraad? Met gebruik van tools als Google-Analytics kan gemakkelijk getraceerd worden via welke kanalen de eindgebruikers binnenkomen. Denk hierbij aan OS, OS-versies, browsers, browserversies en (mobiele) apparaten. Aan de hand hiervan kan besloten worden om een apparaat wel of niet aan te schaffen. Als bijvoorbeeld 30% van de eindgebruikers gebruikmaken van een iPhone10, dan is de aanschaf van dit apparaat wellicht een waardevolle investering.
De bovengenoemde analyse is eveneens een krachtig middel om de impact van bugs te bepalen en daarbij de juiste strategische keuzes te maken. Het accepteren van een bug zou zo’n keuze kunnen zijn. Als bijvoorbeeld veel bugs op een iPhone4 voorkomen, het verkeer vanaf dit kanaal maar 1% is en de kosten voor de oplossing erg hoog zijn.
Ook kan deze analyse ingezet worden bij de inrichting van de automatische teststraat. Hierbij is het eveneens belangrijk om rekening te houden met de meest gebruikte os, os-versies, browsers, browserversies en (mobiele) apparaten. Een aanpak zou kunnen zijn om de top5 van de meestgebruikte platformen en apparaten te bepalen voor de inrichting van de teststraat.
Bovenstaande voorbeelden stippen het belang van de gebruikersanalyse aan. Naast de beschikbaarheid van een enorme diversiteit aan apparaten op de markt is het een dynamische markt waarin de vraag en aanbod continu veranderen. Het is daarom raadzaam om deze analyse periodiek uit te voeren om eventueel de voorraad dan wel teststrategie hierop aan te passen. Anders loop je het risico om ‘bugs’ te missen en kun je overspoeld worden met productieverstoringen. De ontwikkelde software kan zich namelijk anders gedragen op nieuwe apparaten.
Snelheid van ontwikkelen
Ten slotte wil ik nog het belang van virtuele apparaten aanstippen. Snelheid dan wel ‘performance’ is een breed begrip en wordt vaak geassocieerd met de prestaties van de back-end en het belang hiervan. Niets is minder waar, de prestaties van de back-end zijn uiteraard van essentieel belang. Deze vertalen zich in de vorm van wachttijden naar de eindgebruiker.
Minstens even belangrijk is de snelheid van de ‘bouwstraat’ waar automatische testen een onderdeel van zijn. Door gebruik van virtuele apparaten kan de doorlooptijd van testen en hiermee de ‘bouwtijd’ verkort worden. Een veelgebruikte aanpak hierbij is ‘parallelle’ testuitvoer, waarbij testgevallen parallel over verschillende apparaten uitgevoerd worden. Een andere aanpak is het implementeren van automatische testen in de nachturen. Het één sluit de ander niet uit, meestal worden beide technieken gecombineerd.
De snelheid van de bouwstraat is medebepalend voor de ‘time-to-market’ van nieuwe features dan wel bugfixes.