Group 1670

Quality Engineering

Kwaliteit is geen toeval, dat is het motto van de quality engineers bij Trivento. In elk traject zijn we vanaf dag één betrokken om de kwaliteit van onze producten te waarborgen. Dat doen we niet alleen, dat doen we met het hele team, iedereen binnen het team is verantwoordelijk voor de kwaliteit van de producten die we opleveren.

Quality engineering staat voor samen verantwoordelijkheid nemen voor de kwaliteit van het IT-product. Wij zijn dan ook erg enthousiast over het testing manifesto en verwijzen hier regelmatig naar.

Binnen onze quality engineering aanpak maken we voor het gemak onderscheid tussen de aanpak voor het testen van de functionele requirements en de non functionals.

Functionele testen

Binnen Trivento is de aanpak voor functionele testen gebaseerd op de Testing Trophy van Kent C. Dodds.

In het verleden werden met geautomatiseerde testen vaak het gedrag van een gebruiker nagebootst via de frontend. Vaak via tools als Selenium. Deze testen zijn kostbaar in ontwikkeling en onderhoud, kosten veel tijd in uitvoer en geven niet gericht aan waar een fout zich voordoet (frontend, backend, database, platform…). 

Als tegenhanger werd de test automation piramide ontwikkelt, met de focus op kosten en snelheid van de testen. Zeker in een agile project is het belangrijk om snel feedback te krijgen op je product. Unit testen zijn uitermate snel en geven een ontwikkelaar feedback tijdens het ontwikkelen. Een kleinere hoeveelheid Integratie en E2E testen moest zorgen voor het vertrouwen dat het product juist gebouwd was.

Door de ontwikkelingen met bijv tools als Docker en Cypress en het hanteren van CI/CD pipelines is het ontwikkelen, onderhouden en draaien van de verschillende geautomatiseerde testen eenvoudiger, goedkoper en sneller geworden. Dit biedt de mogelijkheid om niet te stoppen bij de stap van icecream cone naar piramide, maar om de test engineering strategie te baseren op de testing trophy.

We proberen zoveel mogelijk van onze testen te automatiseren, dit doen we tijdens de development sprint. Het liefst parallel aan het schrijven van de code. We opleveren van een user story wordt dan een samenwerking tussen developer en tester waarbij veel gepaired wordt. 

We beginnen met het uitwerken van de integratietesten van een component, bijvoorbeeld een micorservice of microsite. Hiervoor gebruiken we Cypress.io voor frontend componenten en Kotlintest voor de backend componenten (voor sommige projecten gebruiken we Scalatest of Cucumber). Zijn er units die lastig zijn om via integratietesten te testen, is het niet efficiënt om het via integratietesten te testen of heeft de developer tijdens het ontwikkelen behoefte aan kleine specifieke controles, dan worden unit testen opgesteld. Op basis van de integratie en unit testen wordt de code coverage bepaald. De coverage gegevens worden naar Sonarcloud.io gestuurd, waar ook nog een aantal statische testen worden uitgevoerd.

Nadat de componenten getest zijn middels unit- en integratietesten deployen we de componenten naar een test omgeving waar het gehele platfom / de gehele oplossing voor de klant draait. Daar worden met behulp van Cypress.io nog een aantal E2E testen gedraaid, of zoals wij het noemen Customer Journey Testen. 

Non functionele testen

Applicaties, systemen en platforms moeten natuurlijk voldoen aan de functionele requirements. De applicatie moet de business waarde leveren die de gebruikers verwachten. De non functional requirements worden echter steeds belangrijker. Deze verschillen qua applicatie maar een aantal daarvan zien we in elk project wel in meer of mindere mate terugkomen.

Accessibility

Gebruikers vertrouwen op de gebruiksvriendelijkheid van een website of app. In de EU heeft 1 op de 4 mensen een beperking. Ontoegankelijke websites maken het moeilijk voor deze mensen. Sterker nog ontoegankelijke websites werpen barrières op voor alle gebruikers, niet alleen voor gebruikers met een beperking.

Toegankelijkheid is daarom een onderwerp wat wij in het beginstadium van een applicatie al mee nemen, in designs en customer journeys. Maar ook in de testen zal er voldoende aandacht besteed moeten worden. Wij doen dat door in de CI/CD pipelines een automatische teststap op te nemen voor het testen van toegankelijkheid. In deze testen wordt middels Cypress en AXE de toegankelijkheid getoetst volgens bijvoorbeeld de AA-rating standaarden op diverse schermresoluties.


Monitoring en Alerting

Binnen het Customer Succes Team van Trivento zijn we verantwoordelijk voor de gehele lifecycle van een aantal producten van klanten. Monitoring en alerting is daarbij cruciaal en is wat ons betreft daarmee ook een cruciaal onderdeel van Quality Engineering. Monitoring en alerting moeten het team helpen bij het vroegtijdig signaleren van mogelijke problemen, en dienen genoeg informatie te bevatten om het probleem te analyseren en te repareren. Hiervoor gebruiken we dashboards binnen ons Apollo platform en maken we gebruik van Kibana, Grafana en Checkly
 
 

Resiliency (Chaos Monkey)

Veel van onze opdrachten zijn gericht op digitale platforms en microservice architectuur. In een landschap waarin meerdere instanties van meerdere services met elkaar integreren en verbonden zijn is het uiterst belangrijk dat een applicatie resilient (“veerkrachtig” of “weerbaar”) is. Geïnspireerd door Netflix voeren we een aantal resiliency testen uit op ons platform. We doen dit (nog) niet zoals Netflix op een productie omgeving maar in de production like acceptatie omgeving. We gebruiken hierbij Gatling om diverse loadlevels te genereren en stoppen random instances in ons Appollo Platform om te checken of de micro services hier goed op reageren. En om te controleren of onze monitoring en alerting ons op de juiste wijze waarschuwt mocht er toch iets mis gaan.

 

Performance

Websites en mobiele applicaties zijn vandaag de dag meer geavanceerd dan ooit tevoren. Gebruikers verwachten van bedrijven dat zij hun dienstverlening aanbieden via deze kanalen. Daarom is het erg belangrijk dat websites en mobiele applicaties een vloeiende ervaring bieden zonder lange laadtijden. Diverse onderzoeken tonen aan dat gebruikers de User Experience als ‘slecht’ ervaren wanneer een website niet tijdig reageert. Wat bijvoorbeeld resulteert in een hoge bounce-rate; gebruikers vertrekken na het bekijken van één pagina van de website. Reden te meer om de front-end performance goed te analyseren en te verbeteren waar nodig!

De belangrijkste performance elementen waaraan een website of een mobiele applicatie moet voldoen zijn:

  • De snelheid waarmee de basis van de pagina wordt geladen. Denk hierbij aan:
    • Zichtbare tekst
    • Afbeeldingen
    • Opmaak en lay-out (CSS)
    • Functionele elementen (knoppen, links, formulieren, etc.)
  • De tijd waarbinnen elementen reageren op gebruikersacties
  • De snelheid waarmee functionele elementen gebruikers verzoeken kunnen uitvoeren
  • De totale tijd dat het duurt voordat de volledige pagina is geladen.

De prioriteit van de deze elementen hangt sterkt af van het doel van de website of applicatie. Bijvoorbeeld: voor een pagina dat als enkel doel heeft om verschillende afbeeldingen weer te geven, is de snelheid waarmee de afbeeldingen laden belangrijker dan de andere performance elementen.

Middels Cypress en de Lighthouse plugin borgen we dat de belangrijkste performance elementen niet worden overschreven na een nieuwe release.

Het testen van de performance, op de onderliggende microservices in de platform architectuur, doen we met behulp van Gatling. Deze testen voeren we bij elke release uit om te controleren of de nieuwe wijzigingen geen negatieve impact hebben op de performance van de applicatie. Om een goed oordeel te vellen over de performance zijn kengetallen nodig over verwachte aantallen gebruikers, piekbelasting etc. Ervaring leert dat het opstellen van deze kengetallen voor een applicatie vaak ingewikkeld is voor de stakeholders. Daarom helpt Trivento hierbij, onder andere door inzicht te geven in de performance van de applicatie onder verschillende omstandigheden.


Security

Als onderdeel van van de diverse pipelines worden OWASP security checks uitgevoerd en wordt er gecheckt of gebruikte libraries vulnerabilities bevatten. Daarnaast kan een applicatie voor elke release getoetst worden volgens de security standaarden van internet.nl

 

 

 

 

CI/CD

Onze testen zijn onderdeel van een CI/CD pipeline in gitlab of wercker. Nadat een developer code wijzigingen heeft gepushed worden automatisch een aantal testen uitgevoerd. Afhankelijk van de branch (feature branch, develop of master) wordt bepaald welke testen uitgevoerd worden en naar welke omgeving de code wijzigingen automatisch gedeployed worden. Een falende test, of een afname in code coverage zal leiden tot een falende pipeline. Het team kriigt hiervan meteen een signaal zodat aanpassingen doorgevoerd kunnen worden en de code wijzigingen (de user story) alsnog snel in gebruik genomen kunnen worden.

Patrick Lanters CTO

Patrick Lanters CTO

Laat hier je
gegevens achter

Patrick Lanters neemt contact met je op