Testadvies

Testtrajecten verlopen in de praktijk vaak anders dan men voor ogen had. Daardoor wordt testen vaak gezien als lastig terwijl het juist zo belangrijk is! Waarom lopen testtrajecten vaak anders? En wat kun je daaraan doen zodat het belang van testen weer voorop komt te staan?

Zorg voor duidelijke specificaties

Bij werken volgens de watervalmethode behoort het testteam de functionele documentatie aan het begin van hun werkzaamheden te krijgen. Maar wat als het testteam slechts een aantal screendumps krijgt van diverse schermen zonder verdere specificaties? Om op basis daarvan te moeten bepalen wat er getest moet worden? De kans is dan groot dat na de eerste installatie van de applicatie blijkt dat de schermen anders opgebouwd zijn waardoor de testvoorbereiding opnieuw gedaan moet worden. Mogelijk gevolg van een dergelijke onduidelijke start: maanden later dan gepland kan er pas een eerste versie naar productie terwijl het aantal tussen releases niet meer bij te houden is! Zorg om dit te voorkomen voor duidelijke specificaties aan het begin van het traject.

Laat de opdrachtgever de functionele documenten reviewen

Een andere valkuil kan zijn, dat men de externe leverancier de functionele documenten laat schrijven, maar deze niet laat reviewen door de opdrachtgever. Dan kan het zomaar gebeuren dat de applicatie niet werkt zoals verwacht. Of dat er geen rekening is gehouden met de wettelijke regelgeving in Nederland. Dan wordt het voor een testteam heel lastig om aan te tonen dat het geleverde product niet voldoet aan wat de klant verwacht: de leverancier is immers van mening dat hij gebouwd heeft wat er functioneel beschreven is. Dit maakt het testtraject zeer lastig. Het kan dan gebeuren dat er na een aantal teleurstellende leveringen wordt besloten om stappen terug te maken in het ontwikkelproces en het testteam de systeemtest te laten ontwikkelen en uitvoeren. Een andere oplossing: het project stoppen en dus geen applicatie maar wel financiële consequenties! Geef om dit te voorkomen de software leverancier duidelijke specificaties mee zodat al tijdens de bouw van de applicatie duidelijk is wat de klant verwacht.

"Vaak zegt men Agile te werken, maar is dit in werkelijkheid niet het geval!"

Gebruik testontwerptechnieken

Testontwerptechnieken kunnen ervoor zorgen dat er vanuit een gestandaardiseerde werkwijze testgevallen af te leiden zijn die een bepaalde testdekking bereiken. Helaas wordt hier nog maar weinig gebruik van gemaakt. Waarschijnlijk komt dat doordat het opzetten van testontwerptechnieken in eerste instantie tijd – en dus geld – kost. Dit verdien je echter gedurende de duur van het project weer terug. Een aantal voordelen van testontwerptechnieken:

  • Testontwerptechnieken tonen aan welke onderdelen mogelijke financiële- of imagoschade opleveren en dus intensiever getest moeten worden.
  • Het toepassen van testontwerptechnieken en het vastleggen ervan in testspecificaties geeft onderbouwing voor dekking op de juiste plaats.
  • Met testontwerptechnieken kunnen bepaalde fouten effectiever opgespoord worden.
  • Testontwerptechnieken maken tests reproduceerbaar en verhogen daarmee de overdraagbaarheid.
  • Met testontwerptechnieken zijn tests beter te plannen en te beheersen.

Werk Agile als je zegt Agile te werken

Om écht Agile te werken werk je in vaste sprints met een klein, multidisciplinair en zelfsturend team dat een minimale hoeveelheid aan documentatie oplevert. Vaak zegt men Agile te werken, maar is dit in werkelijkheid niet het geval. Het is voor een organisatie vaak moeilijk om de bestaande (waterval) structuur los te laten en de nieuwe technieken van Agile correct te gebruiken. Veel voorkomende valkuilen:

  • De architecten en ontwikkelaars zitten bij elkaar op een etage en de testers op een andere.
  • Men kiest voor meerdere externe ontwikkelpartijen, met elk hun eigen werk- en denkwijze.
  • De jaarplanning met vaste release momenten wordt op voorhand vastgelegd door een Project Manager.
  • Beperkte kennis van de te gebruiken technieken, bijvoorbeeld het schrijven van use cases.
  • Onduidelijke communicatie. Bijvoorbeeld vergaderingen en demo’s in het Nederlands, terwijl buitenlandse collega’s dat niet kunnen volgen.

Wil je als organisatie Agile werken? Pas deze werkwijze dan ook echt correct toe binnen je organisatie.

Dus hoe maken we testen belangrijk in plaats van lastig?

Bewuster omgaan met het ontwikkelen van software en de theorie beter toepassen vergroot de kans op een succesvol ontwikkeltraject. Serieus rekening houden met het goed inrichten van de projectorganisatie, zorgt ervoor dat projecten soepeler en voorspelbaarder verlopen. Dit brengt ook het testen naar een hoger niveau, wat betere kwaliteit met minder verstoringen tot gevolg heeft. Mijn tips:

  • Zorg voor duidelijke specificaties aan het begin van het traject.
  • Geef de software leverancier duidelijke specificaties mee zodat al tijdens de bouw van de applicatie duidelijk is wat de klant verwacht.
  • Gebruik testontwerptechnieken, de investering hierin verdient zichzelf terug tijdens de duur van een project.
  • Pas de Agile werkwijze ook echt correct toe binnen je organisatie als je zegt Agile te willen werken.

Met dit in gedachten kan testen weer de plek innemen die het verdient: een belangrijk onderdeel van het softwareontwikkelproces om zo samen tot het beste resultaat te komen.

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

Ontwerp zonder titel (19)

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Bijtanken bij Bartosz

Data & Testen

Mei14

Bij onze klanten komen we op verschillende manieren in contact met data. Hoe ga je als tester om met de (technische) uitdagingen die hierbij komen kijken? En wat voor impact heeft deze dataficatie op onze fysieke leefomgeving?

 

Mijn Paarsz