+31 35 543 1000 info@kza.nl

Veel niet-ICT’ers denken vaak dat software ‘zacht’ is of makkelijk aanpasbaar. Er zijn geen moeren en bouten die de boel bij elkaar houden. Natuurlijk is dit niet zo. Software is als elk mechanisch systeem, het heeft een ontwerp en structuur. Het is niet zo zacht als veel mensen denken.

Er is de afgelopen jaren veel veranderd in de manier van software ontwikkeling. Op het gebied van proces heeft Agile een grote opmars gemaakt. Er wordt op dit moment vaak ontwikkeld volgens de principes van object georiënteerd programmeren. Dit is een andere manier van tegen ontwikkelen aankijken dan dat men dat vroeger deed. Ook voor ‘ons’ testers zijn er zaken veranderd. Eén van de grootste veranderingen is test automatisering. Een volgende stap kan Object Georiënteerd Testen zijn!

De ‘verandering’ die Agile heet:

Het principe van Agile werken betekent dat van te voren nog niet alles uitgetekend en vastgelegd hoeft te zijn. Het is mogelijk om gaandeweg de richting te veranderen, om op die manier de klantwens te beantwoorden.

In traditionele ontwikkeltrajecten zit testen helemaal achteraan in het traject. Alle functionaliteit werd eerst ontwikkeld, vervolgens moest altijd de volledige functionaliteit getest worden. Hier kwamen – laten we eerlijk zijn – altijd defects uit wat betekent dat er opnieuw ontwikkeld moest worden. Opnieuw moest dan de hele functionaliteit getest worden. Dit hele proces nam maanden zo niet jaren in beslag.

De ‘time to market’ van producten moet korter. Producten moeten van hoge kwaliteit zijn. Producten moeten sneller en makkelijker aanpasbaar zijn. Agile werken geeft teams de mogelijkheid om aan al deze verwachtingen te voldoen. Om te werken binnen zo’n team is wel een andere instelling en kijk op software ontwikkeling nodig. Ik heb ervaren dat door de opkomst van Agile de rol van de tester, ontwikkelaar en de klant is veranderd. In één van mijn projecten kwam het regelmatig voor dat deze drie rollen samenwerkte achter dezelfde computer. Korte communicatie, snel even iets aanpassen, is het zo goed? Nog even dat aanpassen, dan is het goed!

De ‘verandering’ die Object Georiënteerd Programmeren heet:

Een principe dat voor het eerst werd toegepast op M.I.T. ergens tussen 1950-1960. Het idee achter deze oplossing is dat stukjes functionaliteit in een object worden gestopt. Vervolgens moeten deze objecten met elkaar communiceren. Als deze objecten bij elkaar vormen samen een groter stuk functionaliteit.

Als voorbeeld staat hiernaast een plaatje van een tweet. Alle roze gebieden zou je als tester kunnen zien als objecten. Als je alle tweets zou bekijken dan zijn deze objecten qua code hetzelfde. De inhoud van de objecten is voor elke tweet anders.

 

Als je het principe achter object georiënteerd ontwikkelen door trekt naar de toekomst, dan gaat software de komende jaren steeds meer bestaan uit kleine modules die samen één groot geheel vormen. Vervolgens als de gebruiker om andere functionaliteit vraagt dan kan er een object gewijzigd/verwijderd/toegevoegd worden. Uiteindelijk is het mogelijk om uit alle objecten een compleet nieuwe applicatie te maken. De nieuwe applicatie lijkt niet meer op het origineel en bestaat toch uit dezelfde objecten.

De ‘verandering’ die Test Automatisering heet:

Doordat veel bedrijven op een Agile manier software zijn gaan ontwikkelen heeft Test Automatisering een grote opmars gemaakt. Aan het eind van elke sprint moet er een stuk(je) ‘potential shipable’ functionaliteit opgeleverd worden. Deze nieuwe functionaliteit moet natuurlijk getest worden. Daarnaast moet naarmate de sprints vorderen alle oude functionaliteit blijven werken.

Dit betekent dat er ook elke sprint op regressie getest moet worden. Het plaatje laat zien hoe dit eruit ziet naarmate de sprint vorderen. In ‘Sprint 1’ wordt er een blokje functionaliteit (F) ontwikkeld en hoeft ook alleen dat getest te worden. Elke sprint wordt er een nieuw stuk functionaliteit ontwikkeld wat betekent dat er steeds meer nadruk komt te liggen op regressie testen. Als er geen gebruik wordt gemaakt van Test Automatisering zal de tester op een gegeven moment het werk niet meer aankunnen.

Deze ontwikkeling heeft ervoor gezorgd dat Test Automatisering een opmars heeft gemaakt binnen ons werkveld. Het is een vereiste geworden binnen Agile projecten.

Object georiënteerd testen:

Het is een feit dat de doorontwikkeling van Agile werken naar bijvoorbeeld ‘DevOps’ of ‘Continuous Delivery’, alleen mogelijk is als de architectuur van de systeemlandschappen modulair wordt opgebouwd. Alleen dan kun je ‘feature-wise’ bouwen en dus ook testen. Volgens mij moet testen zich meer gaan richten op de objecten en de communicatie tussen deze verschillende objecten. De werking en communicatie (ingaand & uitgaand) van de losse objecten moet worden getest.

Als voorbeeld:

“Een applicatie is op gebouwd uit 5 verschillende modules die in een willekeurige volgorde tot een keten gemaakt kunnen worden, elke module kan maar 1 keer gebruikt worden. Dat betekent dat er 120 (5 x 4 x 3 x 2 x 1) mogelijkheden zijn waarop deze applicatie in elkaar gezet kan worden. In dit voorbeeld zou het testen nog wel te overzien zijn.”

Wanneer er één restrictie wordt gewijzigd, dan gaat het aantal testen significant omhoog.

 “Bijvoorbeeld elke module mag nu    meerdere keren gebruikt worden. Dan ontstaan er 3125 (5 x 5 x 5 x 5 x 5) mogelijkheden.”

In de bovenstaande voorbeelden is een simpele applicatie beschreven. De mogelijkheden die ontstaan wanneer er modules worden toegevoegd zijn eindeloos. Het is vrijwel onmogelijk om de kwaliteit van software aan te tonen wanneer al deze objecten met de hand worden getest.

Wat zijn dan deze objecten? Wat voor functioneel gebied beslaan die?

De objecten zijn een stuk groter zijn dan de objecten waarin ontwikkeld wordt. Als we het bovenstaande voorbeeld nogmaals gebruiken. In dat voorbeeld gaat het over functionele brokken, deze functionele brokken bestaan uit een X aantal geprogrammeerde objecten. Ontwikkelaars proberen alle – het liefst zo klein mogelijke – stukjes code in objecten te vangen. Dit is voor testers minder relevant, wij richten ons op – zoals we altijd gedaan hebben – functionele gebieden. Zelfs als we kleine functionele stukken aanpakken kan dit vanuit ontwikkelaars oogpunt bestaan uit meerdere objecten.

Het principe van Object Georiënteerd Testen is dat we drie gebieden testen. De communicatie die het object ‘in’ & ‘uit’ gaat en natuurlijk de werking van het object zelf. Een applicatie zou er dus uit kunnen zien als in het onderstaande plaatje links.

Als er nu een wijziging moet worden doorgevoerd in de applicatie, ‘object B’ wordt gewijzigd naar ‘object X’. Doordat er getest wordt op basis van objecten en de communicatie daartussen. Hoeft op dit moment alleen de communicatie die ‘object X’ ingaat, ‘object X’ zelf en de communicatie vanuit ‘object X’ getest te worden. Aan de andere objecten is niks veranderd en dus hoeven dus ook niet getest te worden.

Om Object Georiënteerd Testen goed door te voeren moet er wel voldaan worden aan een aantal voorwaarden:

  • Duidelijk definitie van de objecten binnen de applicatie.
  • Communicatie tussen de objecten moet op een uniforme manier ingericht zijn binnen de applicatie.
  • Communicatie van en naar andere applicatie of het internet moet via één object lopen.

Object Georiënteerd Testen heeft veel voordelen, het grootste voordeel is dat er slimmer getest wordt. Als er geen risico is dan hoeft er ook niet getest te worden. Als er één object wordt aangepast hoeft ook alleen dat object getest te worden. Het testen zal dus efficiënter gaan en dat bespaard tijd en geld.

Functioneel testen sterft uit:

De tijd waar er een klein legertje testers werd binnen gehaald om een regressie- of integratietest te doen bij een nieuwe release is voorbij. Door alle veranderingen is dit voor een bedrijf niet meer haalbaar. Wat betekent dat wij als testers ook moeten veranderen.

De opmars van Agile, object georiënteerd programmeren en test automatisering heeft al voor veel verandering gezorgd binnen de test wereld. Object georiënteerd testen zal deze verandering een nieuwe impuls geven en een enorme verschuiving binnen de testwereld tot gevolg hebben. Daarom moeten testers de komende tijd zichzelf gaan voorbereiden hierop. Door object georiënteerd te gaan testen, test automatisering te omarmen en de samenwerking te zoeken met ontwikkelaars.

Frank Lansink