De hamvraag bij het bouwen van websites, webshops, intranetten, mijn-omgevingen en maatwerksoftware is: Werkt het allemaal zoals we met elkaar hebben afgesproken? De beste manier om daarachter te komen is: testen!
We hebben verschillende testers in huis die de functionaliteit en de prestaties van het design en de software controleren. Want net zoals een schrijver moeite heeft om zijn eigen werk te redigeren, zo kan een developer een blinde vlek hebben voor zijn eigen code (ook al beschikt hij over de 10 kwaliteiten van een succesvolle software developer!). Bovendien kan een developer niet altijd overzien wat er gebeurt als verschillende apart gebouwde delen van de software bij elkaar komen. Daarom is het goed dat een tester de werking van de software helemaal naloopt en kijkt of alles doet wat het moet doen. Testers zijn dus géén designers of developers, het is een aparte discipline!
Testen komt al voor de start van een project om de hoek kijken, namelijk bij het opstellen van de acceptatiecriteria. Deze criteria bevatten de verschillende testonderdelen en de voorwaarden waaraan de software moet voldoen. De tester controleert of de criteria deugen: zijn het reële wensen of verwachtingen en kan de software straks eigenlijk wel datgene uitvoeren waarvoor hij bedoeld is?
Deze manier van werken voorkomt verrassingen bij de acceptatietest aan het eind van het traject. Bij de acceptatietest loopt de opdrachtgever of de gebruiker door de applicatie, website of webshop heen. Als er dan nog fouten aan het licht komen, moet je weer een stap terug in het ontwikkelproces. Voor je het weet, zijn er dan weer twee tot drie weken verstreken. Dankzij de acceptatiecriteria weten we zeker dat de software straks 100% gebruiksvriendelijk is en precies doet wat de opdrachtgever wil. Dat biedt alle partijen houvast en voorkomt vertraging.
De eisen en wensen liggen vast in de Definition Of Done (DoD). Dit document beschrijft waaraan de software moet voldoen en daarmee wat en hoe er getest gaat worden. Iedere keer dat een stuk software gereed is, voert het ontwikkelteam twee technische tests uit:
Naast deze twee standaard technische tests zijn er nog drie performancetests. Deze optionele technische tests garanderen dat het hele systeem, dus alle verschillende onderdelen bij elkaar, naar behoren presteert en dat de verschillende functies snel genoeg worden uitgevoerd. Dit zijn:
Het is aan te raden om de drie performancetests na de oplevering of livegang periodiek te laten plaatsvinden. Zo weet je zeker dat je applicatie, website of webshop goed blijft werken. Vanzelfsprekend kunnen wij deze tests voor je uitvoeren.
Dankzij de technische tests weten we dat de software in technisch opzicht werkt: er zijn geen foutmeldingen, de software stopt er niet plotseling mee, en de snelheid (performance) is voldoende. Maar software moet niet alleen werken, je moet ermee werken. Daarom voeren we drie verschillende gebruikerstests uit:
Regressietest: Iedere keer dat er een nieuw onderdeel van de software gereed is, ontwikkelen we een speciaal testscript dat automatisch controleert of de software doet wat hij moet doen. Dit is de zogenaamde regressietest. Naarmate de software verder wordt uitgebreid, wordt ook de set met testscripts steeds verder uitgebreid. Zo controleren we in de loop van het ontwikkeltraject voortdurend de functionaliteit van de software.
Functionele acceptatietest (FAT): Zowel de tester als de eindgebruiker gaan aan de slag met de software en kijken of alles inderdaad zo werkt als het is bedoeld.
Gebruikersacceptatietest (GAT): Deze test vindt ook vaak plaats met een gebruikerspanel. Zij testen dan of de software voldoende ondersteuning biedt bij hun taken.
Zodra een deel van de software gereed is, voeren we standaard een unittest, een systeemtest en een regressietest uit. Komen er fouten aan het licht? Dan pakken we die meteen op in de volgende stap van het ontwikkeltraject. Aan het eind van het traject vinden de functionele en gebruikersacceptatietests plaats. In overleg met onze opdrachtgever bepalen we hoeveel tijd hiervoor nodig is.
Na afloop van het ontwikkelproces weten we zeker dat het systeem aan de acceptatiecriteria voldoet. Dan is het tijd voor de livegang. Die is niet zo spannend meer, aangezien we alles al heel uitgebreid hebben getest. Is je interesse in testen aangewakkerd? Lees ook ons artikel over de vooroordelen van testen.
AI is het beste gereedschap dat ik de afgelopen jaren aan mijn toolset heb toegevoegd. Maar ook het gevaarlijkste. Niet omdat AI kwaadaardig is, maar omdat het precies datgene versterkt wat je erin stopt. Ik gebruik AI daarom liever niet als antwoordmachine, maar als een manier om mijn denkproces te structureren en versnellen.
Je website is vaak het eerste wat klanten van je bedrijf zien, en eerste indrukken tellen. Met een slecht onderhouden website verlies je klanten en doe je afbreuk aan je merk. Van trage laadtijden tot beveiligingsproblemen, een verouderde website kost je klanten.
Eerder schreven we over de ontwikkeling van artificial intelligence, kortweg AI, en over de mogelijkheden en risico’s ervan. In dit artikel slaan we de brug naar de praktijk en leggen we uit op welke indrukwekkende manieren AI tegenwoordig wordt ingezet.