Automatisch testen
Snel, grondig en foutloos opleveren dankzij automatisch testen.
Waarom automatisch testen?
Een webapplicatie bestaat uit veel, vaak complexe functies die met code zijn opgebouwd. Voor ingebruikname van de applicatie wordt die code uiteraard uitgebreid getest. Wanneer je nieuwe functionaliteit of nieuwe pagina’s toevoegt, is het efficiënt om delen van die code opnieuw, in iets aangepaste vorm, te gebruiken.
Bij het opnieuw gebruiken van code kan blijken dat de oorspronkelijke functionaliteit corrupt is geworden. Zo’n ‘regression bug’ klinkt als iets dat eenvoudig op te lossen is, maar een applicatie wordt uiteindelijk te groot om bij elke aanpassing alles handmatig helemaal opnieuw te testen.
Daarvoor gebruiken onze Scrum teams dus automatische tests. Dat werkt sneller en ook grondiger want een automatische test ‘vergeet’ niets. Zo leveren we kwalitatief betere software eerder op.
Kies hier direct je ideale team
Onze autonome teams bestaan uit ervaren en betrokken specialisten die niets liever willen dan er samen een succes van maken. Leer ze hier alvast kennen en kies het ideale team dat straks voor jou door het vuur gaat.
Unit tests, integration tests en behavior tests
Testen doe je op verschillende niveaus. Je kunt losse componenten testen of juist een groter geheel. Een unit test gebruik je voor classes of methods. Dat zijn losse stukjes code. Een integration test gebruik je voor functionaliteit. Een functionaliteit in een applicatie wordt gevormd door de integratie van classes/methods die met elkaar communiceren.
Deze twee tests gebruik je voor óf frontend óf backend. De volgende stap is testen op het niveau van de gebruiker. Werkt de applicatie zoals verwacht? Dit noemen we een behavior test of bij webapplicaties ook wel een browsertest.
Voor deze drie testvormen gebruiken we PHPUnit, een testframework voor de PHP-programmeertaal. Voor de behavior test gebruiken we daarnaast Laravel Dusk.
Testplannen schrijven
Het geschreven testplan is een gedetailleerde, menselijke weergave van de behavior tests die kunnen worden uitgevoerd op de website of applicatie. Door deze te beschrijven kunnen ze vervolgens worden geautomatiseerd.
Voor ieder testplan definiëren we eerst:
- Gewenste OS/browsercombinaties (bijvoorbeeld ‘Windows 10 i.c.m. Microsoft Edge 15’)
- De te testen gebruikersrollen (bijvoorbeeld ‘bezoeker’ of ‘admin’)
Per test wordt vervolgens uitgeschreven op welke URL deze plaatsvindt, welke rol hierbij actief is, welke actie(s) worden uitgevoerd en wat het te verwachten resultaat van de test is. En uiteraard wordt het testplan voor elke website- of applicatie-update uitgebreid met de nieuw te testen functies of onderdelen.
Code coverage
PAQT heeft altijd inzicht in de code coverage
Onze specialisten weten altijd hoe grondig de applicatie getest is. Met een te lage coverage gaat een applicatie niet live
Monitoring
Een applicatie bij PAQT wordt voor, maar juist ook na livegang continu in de gaten gehouden. Zo zorgen we voor duurzaamheid
Het gewenste percentage overleggen we overigens met de opdrachtgever. Het wordt opgenomen in de Definition of Done, waarin we vastleggen wanneer een applicatie ‘af’ is. Welk percentage ons overtuigt van voldoende kwaliteit hangt af van het type applicatie en project.
Voor alle duidelijkheid: code coverage is een indicatie van hoevéél code getest is en zegt nog niets over de kwaliteit van de tests zelf. Je kunt met zo’n test bijvoorbeeld kijken of de applicatie werkt als de gebruiker doet wat hij moet doen. Testen van verwacht gedrag noemen we ook wel de ‘happy path’. Je hebt dan nog geen kennis van het functioneren als de gebruiker iets onverwachts doet. En ook daar wil je op voorbereid zijn!
Advies nodig? We helpen je graag.
Maak direct een afspraak voor een adviesgesprek