DSW gebruikt cookies

Wij (en derde partijen via third-party cookies) gebruiken de cookies om de website te verbeteren en u gerichte informatie te bieden. Als u alle cookies accepteert, geeft u naast de verplichte functionele cookies toestemming voor het plaatsen van analytische cookies en volg cookies.

  • Analytische cookies: meten het gebruik van de website, om de gebruikerservaring te verbeteren en problemen te signaleren.
  • Volg cookies: meten uw internetgedrag en voorkeuren, zodat we gerichte informatie op onze website kunnen aanbieden. Deze cookies kunnen ook op andere websites gebruikt worden.

U kunt uw cookie instellingen altijd later aanpassen via ons cookiebeleid.

Instellen

Automatisch testen: een functionele aanpak


Zo, klaar! Code ingecheckt en weer verder met een nieuw item van de backlog. Maar hoe weet ik nou of die code die ingecheckt is niet iets anders heeft kapotgemaakt?

Geen functionaliteit omgooien

Allereerst wordt alle code die we inchecken ge-unit-test en ook handmatig getest door testers. Maar daarnaast gebruiken we bij DSW automatische regressietests om de kwaliteit van onze applicaties te waarborgen. Dit doen we zodat we snel feedback hebben dat gedane wijzigingen geen bestaande functionaliteit hebben omgegooid en we zeker kunnen zijn van de kwaliteit van onze software terwijl we de OTAP-straat doorlopen.

Links: de testpiramide die beschrijft welke en hoeveel tests je van elke soort tests het beste kunt hebben, waarbij integratietesten onze automatische testen zijn. Rechts: SpecFlow

Zoeken naar balans

De afgelopen jaren zijn we bezig geweest met het opzetten van deze tests voor ons applicatielandschap. In eerste instantie hebben we deze tests vrij technisch ingestoken. We zetten veel data klaar om een proces te testen en deden dan een technische Assert dat het proces tot de verwachte wijzigingen in gegevens (database, outputbestanden) had geleid. Dit werkte op zich prima, maar het klaarzetten van de testdata kostte veel tijd en we kwamen tot het inzicht dat deze manier van testen onderhoudsgevoelig is en niet de volledige kracht van onze tooling (=Specflow) gebruikt.

Functionele insteek

Inmiddels hebben we binnen ons team een verbeterslag doorgevoerd; we testen nu functionele stromen in plaats van technische processen. Deze manier van testen hebben we ontleend aan de ontwikkelstroming Behaviour Driven Development, dat propageert om functionele testscenario’s op te stellen. Deze scenario’s zijn leesbaar voor niet-ontwikkelaars en bevatten de hoofdlijnen van een procesflow. Een ontwikkelaar kan vervolgens de code achter de test programmeren en Specflow verenigt deze beide werelden, waardoor leesbare tekst in code wordt omgezet.

Een automatische test voor het inlezen van het bankbestand dat onze financiële transacties bevat, bevat de hoofdlijnen van dit proces. Ondereenvolgens: het functionele scenario, de binding van een regel van het functionele scenario van de code en de onderliggende code.

Voordelen

Het grote voordeel dat onze nieuwe aanpak oplevert, is dat de automatische tests nu als levende documentatie kunnen fungeren; de tests beschrijven de functionaliteit van de software, zowel de happy flow als de verwachte uitval. Daarnaast zorgt onze nieuwe aanpak ervoor dat de tests sneller op te stellen en te ontwikkelen zijn en zijn ze bestendig voor nieuwe aanpassingen.

Continuous delivery

Met deze aanpak zijn we klaar voor de toekomst van continuous delivery. We kunnen kwaliteit centraal stellen, terwijl we toch wijzigingen aan onze software kunnen doen zonder het risico per ongeluk de boel plat te gooien op productie.


Naar boven