Q&A webinar End-to-End (Mobile) Performance Testing | Polteq, passie voor testen
Delen Printen E-mail

Dit waren de vragen en de antwoorden tijdens het webinar “End-to-End (Mobile) Performance Testing” dat Polteq op dinsdag 10 november 2020 organiseerde.

Vraag 1
Q : Performance is toch meer dan alleen responstijden?  Het aankunnen van een bepaald volume per tijdseenheid is net zo belangrijk, plus het gedrag van de onderliggende infrastructuur… En daarbij uiteraard de acceptatiecriteria.
A : Klopt. Responstijden zijn één van de indicatoren – en één van de meest bekende – om performance zichtbaar en meetbaar te maken. Dit is inderdaad ‘maar’ een onderdeel van de performance. Hetzelfde geldt voor de stabiliteit van een systeem of de mate waarin het systeem gebruikt wordt. Dat laatste is bijvoorbeeld meetbaar te maken door te kijken naar het CPU-gebruik van het systeem. Het is afhankelijk van het testobject en de omgeving waarin je opereert welke performance indicatoren (ofwel KPI’s) van belang zijn.
Vraag 2
Q : Wat bedoel je met “Optimize!” op de laatste slide van de presentatie over “Waarom End-to-End (Mobile) Performance Testing?
A : “Optimize!” werd genoemd als onderdeel van “het creëren en onderhouden van een ‘Software Performance’ Mindset”. Hiermee bedoelen we dat Performance (en het testen van performance) geen sluitstuk moet zijn van de Software Development Lifecycle (of kort gezegd ‘SDLC’), maar een intrinsiek c.q. integraal onderdeel moet zijn van het streven naar de meest optimale softwarekwaliteit bij oplevering. Dit houdt o.a. in dat performance van de end-to-end keten continu gemonitord dan wel gemeten wordt en performance issues regulier worden opgepakt als zijnde onderdeel van de softwarekwaliteit optimalisatie.

In de praktijk zien we nog (te) vaak een mindset waarbij Performance pas belangrijk wordt op moment dat er in productie verstoringen plaatsvinden (en er negatieve publiciteit ontstaat) of het wordt gezien als hygiënefactor voor het behalen van een bepaalde audit. In veel gevallen is het dan te laat en komt het oplossen van performance issues dan met de (on)nodige technical debt.

Vraag 3
Q : Is performance testing goed te automatiseren? Hoe? En: waarom niet iedere deployment performance testen?
A : ‘Server-side’ performancetesten leent zich bij uitstek voor automatiseren. Er zijn vele tools in omloop om je hierbij te helpen. Hoe je dit kan automatiseren hangt van meerdere factoren af, zoals het testobject, wie gaat het gebruiken, hoe het aansluit op bestaande werkwijzen en de omgeving.

Zoals Robby toelichtte in de online Q&A, is ‘Client Side’ c.q. Mobile Resource Performance Testen (nog!) een lastig fenomeen om te automatiseren. Dit heeft te maken met het nabootsen van gedrag van gebruikers in combinatie met de vele factoren die de performance van Mobile Resources kunnen beïnvloeden. Uiteraard hanteren wij vanuit Polteq ook een Performance mindset en zijn we continu op zoek naar hoe we onze dienstverlening kunnen optimaliseren en dit geval kunnen automatiseren. We houden u op de hoogte van deze ontwikkelingen.

Vraag 4
Q : Mag je zomaar een performancetest doen op je applicatie als hij in een datacenter draait?
A : Het uitvoeren van een performancetest gaat altijd in overleg met alle stakeholders. Eén van de stakeholders bij performancetesten zijn de systeembeheerders of in ieder geval degenen die gaan over de beschikbaarheid van de gebruikte systemen. Regelmatig is het zo dat er meerdere applicaties of services op dezelfde machine, al dan niet virtueel, draaien. Dan is het ook van belang om de stakeholders van deze applicaties of services op de hoogte te houden. Het gaat hierbij met name om het voorkomen van niet representatieve (negatieve dan wel positieve) impact op de performance van het te testen systeem. Voorbeelden kunnen zijn dat er tegelijkertijd nog een andere performancetest gaande is, of andere mogelijk verstorende acties door anderen, die de resultaten kunnen beïnvloeden.
Vraag 5
Q : Een lastig item voor wat betreft de testomgeving is de belasting door alle gebruikers op alle verschillende systemen, die wel actief zijn op de P-omgeving, maar doorgaans nooit op de A-omgeving..
A : Mocht deze belasting van invloed zijn op de performance, dan moet dit ook meegenomen worden in de performancetest. Dit wordt ook wel achtergrondbelasting genoemd. De achtergrondbelasting bestaat uit vaste scripts die gestart kunnen worden om deze belasting te simuleren. Hierbij kun je ook denken aan het starten van bepaalde batch-jobs. Batch-jobs of bijvoorbeeld back-ups kunnen impact hebben op de performance. Soms wil je deze tijdens een performancetest langs zien komen, maar soms ook niet. Dus zorg ervoor dat er een compleet beeld is ook van wat er op de achtergrond gebeurt.
Vraag 6
Q : Hoe is het end-to-end performance testen in te passen in de DevOps wereld?
A : Interessante vraag. Vanuit Polteq hebben we hierover op maart jl. een klantseminar gegeven en kunnen we u vanuit onze kennis en ervaring helpen om naar DevOps (incl. End-to-End Performance Testing) toe te werken en dit te realiseren. Dit vraagstuk is echter te complex en afhankelijk van veel factoren die per organisatie anders kunnen zijn, om hier in het kort een eenduidig antwoord op te geven.

Mocht u geïnteresseerd zijn in wat we voor uw organisatie op dit onderwerp kunnen betekenen, kunt u contact met ons opnemen via info@polteq.com of telefonisch via 033-27735 22.

Vraag 7
Q : Wat is de beste tool voor Performance Testing?
A : Een goede vraag, omdat we vaak in de praktijk zien dat organisaties zich deze vraag exact zo stellen en ook een eenduidig antwoord verwachten. Vanuit Polteq zijn we van mening dat er geen enkele “beste tool” is, maar dit afhankelijk is van de doelstellingen, testaanpak, requirements en beschikbare kennis intern (en extern) een organisatie. Kortom: de beste performance tool voor een organisatie, is in onze ogen de performance test tool met “the best fit” tussen de organisatie en de tool (en achterliggende (support)organisatie / leverancier).

Polteq heeft ruime ervaring op het gebied van het onderzoeken van de beste fit tussen de klantorganisatie en beschikbare testtooling (en achterliggende leverancier). Mocht u geïnteresseerd zijn in wat we voor uw organisatie op dit onderwerp kunnen betekenen, kunt u contact met ons opnemen via info@polteq.com of telefonisch via 033-27735 22.

Vraag 8
Q : En wat is de beste tool voor (Mobile) Resource Performance Testing?
A : Voor iOS heeft Apple’s Xcode Instruments de mogelijkheid om bijvoorbeeld CPU, geheugen, netwerk en energie te meten. Een soortgelijke oplossing heeft Android Studio Profiler ook. Wil je meer focusgebieden kunnen testen (scherm, CPU, datagebruik), dan zijn er meerdere losse tools nodig om alles te kunnen testen. Deze bieden meer functies om dieper kunnen testen. Mocht u geïnteresseerd zijn in wat we voor uw organisatie op dit onderwerp kunnen betekenen, kunt u contact met ons opnemen via info@polteq.com of telefonisch via 033-27735 22.
Vraag 9
Q : Bij het performance testen van ‘Micro Services’, is het dan ook noodzakelijk om een complete productie-like database, inclusief testdata te hebben?
A : Ja. Op het moment dat je een performancetest gaat uitvoeren, dan moet je ervoor zorgen dat de performancetest relevant is. Bekijk dus goed wat er nodig is. Als de micro-service gebruik maakt van een database dan is deze onderdeel van de testomgeving. Echter bij micro-services is het de bedoeling dat deze kleinschalig zijn en ze hebben vaak een eigen persistente database. Eventueel kan er voor het performancetesten van micro-services ook gebruik gemaakt worden van een mock of stub.
Vraag 10
Q : Wat komen jullie vanuit Polteq in het veld tegen als belangrijkste oorzaken van het feit dat jullie geen goede performance test kunnen uitvoeren, dan wel dat de conclusies niet representatief zijn voor productie?
A : Geen productie-like omgeving in combinatie met onvoldoende vulling van de database met testdata. Hierbij worden er aannames gemaakt in de mate waarin een systeem schaalbaar is en we weten allemaal wat testers over aannames zeggen. Dit geldt met name voor Performance testen, omdat Performance geen lineair (stijgende of dalende) lijn kent. Bij performance zien we vaak een plotseling moment (i.e. ‘saturation point’) waarop het systeem instabiel wordt en/of de performance significant wegvalt.

Een andere oorzaak die we tegenkomen is dat er onvoldoende inzicht is in wat er op productie gebeurt. Hierdoor worden er testscripts en load profielen gemaakt die de “happy flow” onvoldoende representeren of er wordt voorbijgegaan aan achtergrondbelasting veroorzaakt door bijvoorbeeld een batch-job. Dit kan ook veranderen. Door wijzigingen in de applicatie kan het zijn dat de gebruikers van een applicatie ander gedrag gaan vertonen. Inzicht in wat er productie gebeurt, is iets wat onderhouden moet worden en waarop het load profiel en de test scripts aangepast dienen te worden. Als je kijkt naar een webshop dan zie je nog steeds dat elk jaar het verkeer toeneemt. De test zal dus regelmatig bijgesteld moeten worden.

Vraag 11
Q : Met de opkomst van 5G, wat betekent dit voor Mobile Testing (met in het bijzonder Mobile Performance Resource Testing)?
A : Momenteel wordt 4G geleidelijk vervangen door 5G, maar downloaden is niet veel sneller in de Benelux (maximaal 150 Mbit/s) en het uploaden ligt in de praktijk rond de 6 Mbit/s (verdubbeling t.o.v. 4G). Op dit moment hebben providers in Nederland nog niet de volledige bandbreedte van 3.5 GHz tot hun beschikking. Deze volgt na de veiling in 2022. En pas daarna volgt het toevoegen van mmWave om 5G echt supersnel te maken (1500 Mbit/s). Voor nu is ons advies om te testen met dezelfde provider op 4G (voor low-end devices) en later met 5G (voor high-end devices). Voor meer informatie over dit onderwerp: Tweakers.net – Waarom we nog geen supersnel 5G hebben.. Ook vanuit Polteq houden we het ‘gedrag’ in productie (zie antwoord vraag 10) t.a.v. 4G versus 5G trend nauwlettend in de gaten en we zullen u op de hoogte houden van het moment waarop we ons advies bijstellen.
Vraag 12
Q : In de presentatie van Mobile Resource Performance Testing werden een aantal tools genoemd (i.e. Xcode en Charles Proxy). Zijn deze tools gratis te gebruiken?
A : Alle tools in de presentatie zijn gratis te downloaden. Echter de ene tool zal alleen werken op een Apple computer (Xcode), waarbij de ander een gratis proeflicentie is voor 30 minuten (Charles Proxy).
Vraag 13
Q : Bij elke nieuwe versie van een Mobile OS wordt er opnieuw getest. Doe je dit enkel bij de uiteindelijke release, of zijn er meerdere momenten in het jaar waarop jullie adviseren te testen?
A : Rond het einde van de zomerperiode brengen Apple en Google van hun nieuwe OS een publieke beta versie uit en niet veel later volgt de definitieve versie. Voor developers is het meestal al maanden daarvoor mogelijk om de eerste versies te downloaden. Het is een mooie gelegenheid om te kijken of uw app überhaupt valt te installeren en niet tussendoor crasht. Echter deze bèta OS-versie is nog niet geoptimaliseerd op de resources, en bijna elke week worden er updates uitgebracht om de vele fouten op te lossen. Kortom, we adviseren organisaties om gebruik te maken van de mogelijkheden om alvast te testen op basis van de beta versies. Echter voor het doen van definitieve uitspraken over softwarekwaliteit, is ons advies om te wachten op de definitieve OS-versies.
Vraag 14
Q : Wat is +/- de doorlooptijd van een Mobile (Resource) Performance Test? Dit omdat jullie aangaven dat deze vorm van testen, moeilijk te automatiseren is.
A : Dit hangt af van de onderliggende risico’s en daarmee diepte van de Mobile Resource Performance Test. Wilt u enkel op basis van één OS (Android of iOS) testen? Kiest u ervoor om op één device te testen, of wilt u onderscheid maken tussen ‘low’ en ‘high end’? Is de Mobile Resource Performance Test enkel gericht op geheugenlekken en CPU, of worden alle focusgebieden meegenomen? Hoe meer focusgebieden, hoe meer tools en hoe meer analyse-inspanning er nodig is. De doorlooptijd kan variëren van één dag (bijvoorbeeld alleen Android met 1 device, met 1 focusgebied binnen 1 tool) tot 15 werkdagen (indien alle focusgebieden op zowel iOS als ook op Android en met twee verschillende devices getest worden). In de praktijk komen we vaak tot een gepast advies op basis van diverse risicoafwegingen en heeft de Mobile Resource Performance Test een doorlooptijd van 10 werkdagen.

 

 Wilt u het webinar (nog) een keer (terug)zien? Dat kan op deze pagina.

Meer informatie

Heeft u een vraag of wilt u een vrijblijvende afspraak maken? Laat hieronder uw gegevens achter, dan nemen wij zo snel mogelijk contact met u op. U kunt ons natuurlijk ook bellen:

+31 (0) 33 277 35 22 (Nederland)
+32 (0) 16 39 48 04 (België)

    Uw gegevens gebruiken wij alleen voor een correcte afhandeling van uw vraag. Lees voor meer informatie onze privacyverklaring.

    Hoe wij dat doen?
    Lees meer
    Focus
    Focus
    Vakmanschap
    Vakmanschap
    Kennisdeling
    Kennisdeling
    Persoonlijk
    Persoonlijk
    Lokaal
    Lokaal
    Oprecht
    Oprecht
    Plezier
    Plezier
    Meer
    Deze website is gerealiseerd door Webheads.

    Neem contact op!