Thomas de Graaf Testpeople

Als we straks allemaal een elektrische auto hebben die we na het werk willen opladen, zou het net daar niet tegen kunnen. Vervanging van het net is evenwel enorm duur. Een slimmere optie is de behoefte te nivelleren. De meeste auto’s hoeven immers pas de volgende ochtend te zijn opgeladen.

De standaard die de organisatie wil neerzetten, staat beschreven in een dik boek met specificaties, dat regelmatig werd bijgewerkt door het designteam. Dit team was geen onderdeel van het scrum team waarin ik zat, maar leverde wel de product owner voor ons team en de user stories. Ons teamhet bouwteam bestond uit een architect, een scrum master, 6 ontwikkelaars en in eerste instantie 1 en later 2 testers. Doel van ons team was het bouwen van een referentieimplementatie.

Mijn ervaring tot dan toe lag vooral in backofficeapplicaties in de financiële sector met 99,9.. % up time. In mijn referentiekader was daarom de eigenschap productiewaardig naadloos verbonden met de definitie van een backofficesysteem. Toen ik in het project kwam was er een test achterstand van een paar sprints. Het testen van het werk van 6 ontwikkelaars in combinatie met de test achterstand leek daarom op het eerste oog een onmogelijke opgave. Hoe zou jij dit hebben aangepakt?

Een referentie-implementatie

Er lag een duidelijke nadruk op de definitie van referentie-implementatie toen mij werd verteld wat we aan het bouwen waren. Dit triggerde mij gelukkig om door te vragen: Wat is een referentie-implementatie in jullie ogen en wat is het doel? Hier kwam gelukkig een zeer helder antwoord op terug:

  • De referentie-implementatie moet de specificaties toetsen;
  • De referentie-implementatie moet gebruikt kunnen worden om simulaties te kunnen draaien t.b.v. onderzoek;
  • De referentie-implementatie moet gebruikt kunnen worden als uitgangspunt voor partijen die de standaard willen implementeren in JAVA.

Na verder te hebben doorgevraagd over deze doelen kon ik bepalen wat de consequenties waren voor de testaanpak.

Toetsen van de specificaties

De specificaties bestaan hoofdzakelijk uit procesbeschrijvingen en interfacespecificaties. Met een review kun je fouten uit specificaties halen, maar als specificaties als standaard je belangrijkste deliverable is, wil je dat elk detail klopt. Pas als je er mee aan de slag gaat, kijk je goed naar details. Een soortgelijke situatie herken ik vaak bij grooming/refinementsessies; je denkt alles helder te hebben, maar loopt tijdens de voorbereiding toch tegen vragen aan.

Hoe heb ik dit vertaald naar een testaanpak?

De waarde van de specificaties is dusdanig groot, dat je als tester niet alleen de individuele stukken functionaliteit moet begrijpen, maar ook waar deze stukken in het proces passen. En dat je dit als proces moet toetsen. Het variëren in mogelijke flows door het proces is daarnaast belangrijker dan het testen van foutsituaties binnen stukken functionaliteit.

Om te beginnen heb ik functionele testen opgezet om vervolgens snel een procesgerichte test op te zetten. Omdat het proces over meerdere rollen loopt, heb ik dit als integratietest aangeduid en om de test elke sprint te kunnen uitvoeren, heb ik dit net als de functionele testen geautomatiseerd in SoapUI. (In een volgende blog zou ik hierop in kunnen gaan, als daar behoefte aan is.)

Simulaties draaien t.b.v. onderzoek

Het nivelleren van de energiebehoefte gaat niet vanzelf, daarvoor wil de standaard marktwerking gebruiken. Omdat het lastig is te voorspellen hoe een nog niet bestaande markt zal functioneren, en waarbij verschillende partijen verschillende belangen hebben, is het belangrijk simulaties te kunnen draaien. Tijdens de simulatie moet aan knoppen kunnen worden gedraaid, om te zien wat het effect is. Dit moet bij voorkeur versneld kunnen worden uitgevoerd, zodat niet meerdere dagen hoeft te worden gewacht op concrete resultaten.

Hoe heb ik dit vertaald naar een testaanpak?

Tijdens een simulatie wil je ervan uit kunnen gaan dat de applicatie een happy flow goed verwerkt. Syntactische fouten zijn niet relevant, omdat men zich daar aan de beschreven standaard dient te houden. Wél relevant is de performance. Als initieel uitgangspunt is een performance requirement neergelegd. Toen snel bleek dat deze eis niet reëel was, hebben we gekeken waar de limieten van de applicatie lag. Performance in deze context is niet iets waar je tegenaan wilt lopen gedurende een simulatie, maar het kon zowel door performance-verbetering worden voorkomen als door het managen van verwachtingen van de mensen die hiermee simulaties willen maken.

Uitgangspunt bij implementatie

Deliverable van het bouwteam is feitelijk de sourcecode met scripts om een omgeving op te kunnen zetten. Daarnaast zijn simpele stubs gemaakt op de punten waar een klant een link moet leggen met zijn eigen back end-systeem en interactie vereist is.

Dit zou geschikt moeten zijn voor een partij om een volwaardige implementatie te maken. Belangrijk hierin is dat de applicatie functioneel helemaal in lijn is met de specificaties. Eisen aan de productiewaardigheid dienen door de betreffende partij zelf aangebracht te worden, evenals de koppeling met back endsystemen van die partij.

Hoe heb ik dit vertaald naar een testaanpak?

Dit doel was het lastigste te begrijpen en vertalen naar een concrete aanpak. Waar ik gewend was een complete oplossing te testen, moest ik nu een deeloplossing testen die enkel als voorbeeld diende.

Om te beginnen, is duidelijk dat het functioneel testen van de happy flow belangrijk is, net als het testen van het proces. Het testen van aanpasbaarheid van de applicatie is een ander verhaal. Vanuit een ontwikkelperspectief was dit al wel snel duidelijk: Als code je deliverable is, en niet een gecompileerd object, moet de code goed leesbaar zijn. Coding-standaarden en code reviews moesten ervoor zorgen dat de code goed leesbaar was (alsof ze door 1 persoon was geschreven).

Vanuit een testperspectief werd dit pas duidelijk toen we daadwerkelijk met de testen waren begonnen. De stubs die standaard waren gebouwd, waren vaak niet afdoende om alle relevante paden in het proces te dekken of om een goede uitgangssituatie te creëren voor functionele testen van stukken functionaliteit aan de achterkant van het proces. Een optie in zo’n geval is om de testdata aan te passen, maar een alternatief was de meegeleverde stubs aan te passen.

Omdat we als testers met enige programmeerervaring blanco naar een stub konden kijken en beoordelen of we deze konden aanpassen, waren we in feite precies hetzelfde aan het doen als een externe partij zou doen. Daarbij werd geaccepteerd dat als wij, als testers, de applicatie konden aanpassen, andere ontwikkelaars dat ook moeten kunnen. Bijkomend voordeel was dat we functionele testen verderop in de keten deden op basis van door de hele keten gegenereerde data, niet door de database handmatig aan te passen.

Het testen of je van de applicatie een productiewaardig systeem kan maken, hebben we bijvoorbeeld gedaan door te testen of de applicatie database-onafhankelijk is. We hebben H2 database als uitgangspunt genomen, een database waarvan niet wordt aangeraden om deze in een productie-omgeving te draaien. We hebben aangetoond dat de applicatie ook met Maria DB valt te configureren.

Tot slot

Belangrijke les voor mij was om als tester niet enkel het correct functioneren van het systeem als vanzelfsprekend te zien, maar ook eisen rondom een systeem als productiewaardigheid. Ik ben benieuwd naar jullie ervaringen!”

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *