Meer informatie Ja, ik geef toestemming
Automatisch testen

Automatisch testen

Waarom automatisch testen?

Een webapplicatie bestaat uit bestaat uit vele, 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.

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.

Voorbeeld 1. een behavior test

  1. Ik kijk op de URL www.ditismijnapplicatie.nl naar het loginformulier als bezoeker
  2. Ik vul het formulier in: ‘E-mailadres = gebruiker@way2web.nl’ en ‘Wachtwoord = wMFQsXuuoeav1qYKOq’
  3. Ik klik op ‘Inloggen’
  4. Ik verwacht de pagina ‘/dashboard’ en lees de tekst ‘Welkom terug’

Way2Web login test

Voorbeeld 2. een behavior test in code

/**
* Tests that a user can login successfully to the application.
*/
public function testLoginForm()
{
$this->browse(
function (Browser $browser) {
$browser
->visit(‘www.ditismijnapplicatie.nl’)
->waitFor(‘@login-form’)
->type(‘email’, ‘gebruiker@way2web.nl’)
->type(‘password’, ‘wMFQsXuuoeav1qYKOq’)
->click(‘@submit’)
->waitFor(‘@welcome-text’)
->assertSeeIn(‘@welcome-text’, ‘Welkom terug!’);

$this->assertEquals(‘www.ditismijnapplicatie.nl/dashboard’, $browser->driver->getCurrentURL());
}
);
}

Code coverage

De code van een applicatie wordt dus op verschillende niveaus automatisch getest. Wanneer je 80 tot 90% van de applicatie ‘bereikt’ hebt, spreken we van een goede code coverage. Niet alle code is namelijk even belangrijk om te testen. De laatste 10 tot 20% voegt nauwelijks nog waarde toe.

Way2Web Code coverage

Way2Web gebruikt tools om de code coverage te meten

Het gewenste percentage overleggen we overigens met de klant. 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!

Bent u klaar voor the next level?

De digitale transformatie biedt fantastische nieuwe mogelijkheden en kansen. Ook voor uw onderneming, dat weet ik zeker. Als IT-specialist én ondernemer praat ik daar graag eens met u over verder. Geheel vrijblijvend natuurlijk. Zullen we een afspraak maken?