Door de steeds snellere ontwikkeling van software en de toegenomen complexiteit ervan, is grondig testen belangrijker dan ooit. Allereerst om te garanderen dat het programma doet waarvoor het bedoeld is, maar ook om bugs te vinden en op te lossen, de veiligheid te borgen en om de gebruiksvriendelijkheid te monitoren.
Niet gek dus, dat testen bij xential een belangrijke plek in het werkproces inneemt. In deze blog geven we een kijkje achter de schermen en gaan we in op de verschillen tussen ‘het oude testen’ en ‘het nieuwe testen’.
Na de ontwikkeling van een nieuw softwarepakket, wordt de release vrijgegeven en in gebruik genomen. Gebruikers gaan ermee aan de slag en vanuit het werkveld komt feedback binnen in de vorm van gebruikersvragen of bijvoorbeeld foutmeldingen.
Aan de hand van deze feedback worden keuzes gemaakt voor de verdere ontwikkeling van de software. Bij xential kiezen we ervoor om eens per kwartaal een nieuwe release uit te brengen waarin een selectie van de aangedragen punten wordt opgelost en bijvoorbeeld nieuwe features worden toegevoegd.
Het aanpassen en testen van deze nieuwe softwareversie doen we meestal in een gedupliceerde omgeving. In het verleden gebeurde het testwerk allemaal handmatig: een tijdrovend proces.
Tegenwoordig testen we een groot deel automatisch. De snelheid schiet hierdoor omhoog en de ontwikkelaars zien na afloop direct of er eventuele regressie is opgetreden.
Dankzij automatisch testen is er meer tijd voor completere tests: we kunnen het geheel of een groep aan tests draaien of juist heel specifiek één enkele functie testen. Wat hierbij helpt is dat moderne software modulair is opgebouwd.
We werken bij xential in agile sprints en gebruiken het systeem van Behaviour Driven Development (BDD). Een methode waarbij alle specificaties in duidelijk Engels worden beschreven: begrijpelijk voor alle partijen. Hierdoor ontstaat transparantie en consistentie en is er minder communicatieruis. Dankzij het werken in sprints kunnen we de modulaire software al tijdens het bouwen verfijnen. Dit doen we aan de hand van de BDD ‘given – when – then’ scenario’s. Uitgangspunt voor deze scenario’s is de vraag waarom een feature ontwikkeld moet worden.
Doordat we bij iedere test ditzelfde scenario volgen, wordt de uitwisseling tussen de business enerzijds en developers en testers anderzijds laagdrempeliger dan in het verleden. Ook kunnen we in kortere tijd veel verschillende scenario’s testen. Mogelijke problemen worden hierdoor al in een vroeg stadium gedetecteerd.
De voorbeeldscenario’s uit de testfase vormen een concrete link tussen het werk van het R&D team en de wens van de klant. Het team kan nu dus ook alternatieven voorstellen. Zo inspireren team en klant elkaar om de beste oplossing te realiseren. Dankzij de betere interactie wordt de ontwikkelsnelheid en -kwaliteit van de software verhoogd. En dat is voor iedereen goed nieuws!
Kwaliteitsborging is niet alleen belangrijk in onze software, maar juist ook in de (functionele) consultancy die wij aanbieden. Daarom hebben wij een vaste werkwijze om projecten aan te vliegen. Deze aanpak brengt rust, levert tijdwinst op en garandeert dat we kunnen leveren wat we beloven.
Lees meer
Onze developers ontwikkelen de software doormiddel van agile werken. Benieuwd hoe dit te werk gaat? Dat lees je in deze blog.
Lees meer
Soms bedenk je een term… en blijkt dat die term al bestaat. Zo verging het ons toen we intern de term User Centered Design steeds vaker gebruikten om te beschrijven hoe we tegen het ontwikkelen van onze software aankijken. Een bestaande term dus. En eigenlijk is het logisch dat meer ontwikkelaars deze term gebruiken. Wie de gebruiker centraal stelt, kan de software naar een hoger plan tillen.
Lees meer