Wat te doen met wollige beschrijvingen in ontwerpen?

Tester leest in ontwerp documentatie:

Binnen de organisatie is er een grote groep van medewerkers die al langere tijd betrokken zijn en altijd hun best gedaan hebben om hun werk tot het uiterste uit te voeren en 100% inzet te tonen. Voor deze collega's zijn diverse voorzieningen opgenomen in het arbeidsvoorwaardenpakket en een belangrijk deel is, zoals besloten door de directie in 2005, ook terug te vinden in art. 123 van het OR besluit van 2006, versie 3.98. Een extra vakantiedag is dan ook opgenomen en geldt dan ook voor medewerkers die ouders zijn dan 40 jaar. Het besluit is eveneens van toepassing op parttime medewerkers, maar dit is niet gelieerd aan de leeftijd bij deze medewerkers. Bij parttime medewerkers is besloten om één extra vakantiedag uit te keren na 10 jaar dienstverband. De discussie over medewerkers van 50 jaar en ouder die ook meer dan 10 jaar dienstverband hebben is ook gevoerd in het jaar 2006, maar later opgenomen in een nieuw akkoord van de OR met de directie. Dit besluit heeft geresulteerd in het opnemen van een extra vakantiedag voor deze medewerkers en de directie heeft hierbij alle goedkeuringen verwerkt in een nieuwe rapportage die uitgekomen is in 2007, OR besluit versie 4.01. Het nalezen van deze documentatie helpt erbij om deze gegevens ook te kunnen verwerken in de personeelsadministratie en wordt dan ook verwerkt in een automatische berekening.

Euh? Het volgende beeld verschijnt in mijn gedachten:

Wollige taal in ontwerp...

Als tester kom je wel eens software ontwerpen tegen die wel erg "wollig" beschreven zijn. In onze testcursussen leer je om bijvoorbeeld een beslissingstabel of een andere testtechniek te gebruiken om je testgevallen op te stellen aan de hand van een tekst die al zo duidelijk is dat een beginnende tester hier redelijk gemakkelijk mee om kan gaan. Het doel in zo’n cursus is dan ook om een testtechniek te leren. In de praktijk kom je vervolgens een tekst als bovenstaand tegen.

Wat te doen? Een tester met veel jaren ervaring met testtechnieken zou al snel de essentie eruit kunnen filteren en ook al een testtechniek kunnen toepassen om dit stuk tekst te kunnen omzetten naar testgevallen via een testtechniek. Maar heb je weinig ervaring met testtechnieken dan kan je nogal verrast worden.

Wat doe je dan?

•  Jezelf doodstaren voor een uurtje op de tekst en je afvragen waar je in hemelsnaam moet beginnen?
• De betreffende OR besluiten die genoemd worden opzoeken, printen en klaarleggen om deze te bestuderen.
• Eerst proberen om dit duidelijk te krijgen bij de ontwerper en te vragen of hij dit anders kan opschrijven?
• Het jezelf gemakkelijk maken door gewoon een paar testgevallen uit je hoofd te verzinnen. Later zie je wel hoe je dat gaat testen als je eenmaal in de testuitvoer fase begint.

Het eerste punt geeft al een beetje het gevoel van “verloren” zijn, de tweede optie is een goed punt, wordt wel veel leeswerk en leidt misschien wel weer tot de eerste aktie.

De derde optie heeft vaak het probleem dat de ontwerper er al niet meer is, of hier geen tijd voor heeft.

De vierde optie maakt de testuitvoer inefficiënt; je moet al senior tester zijn in het “Exploratory Testing” vakgebied en in je organisatie waar je werkt zullen test (analyse) technieken dan niet verplicht moeten zijn.

Het beste wat je kan doen in deze situatie is het schaap te scheren. Niet beginnen met nog meer leeswerk, eerst dit stuk begrijpen. Maak je eigen MS-Word versie van dit ontwerp (copy paste) en begin alle onzin weg te strepen, te verwijderen.

Binnen de organisatie is er een grote groep van medewerkers die al langere tijd betrokken zijn en altijd hun best gedaan hebben om hun werk tot het uiterste uit te voeren en 100% inzet te tonen. Voor deze collega's zijn diverse voorzieningen opgenomen in het arbeidsvoorwaardenpakket en een belangrijk deel is, zoals besloten door de directie in 2005, ook terug te vinden in art. 123 van het OR besluit van 2006, versie 3.98. Een extra vakantiedag is dan ook opgenomen en geldt dan ook voor medewerkers die ouder zijn dan 40 jaar. Het besluit is eveneens van toepassing op parttime medewerkers, maar dit is niet gelieerd aan de leeftijd bij deze medewerkers. Bij parttime medewerkers is besloten om één extra vakantiedag uit te keren na 10 jaar dienstverband. De discussie over medewerkers van 50 jaar en ouder die ook meer dan 10 jaar dienstverband hebben is ook gevoerd in het jaar 2006, maar later opgenomen in een nieuw akkoord van de OR met de directie. Dit besluit heeft geresulteerd in het opnemen van een extra vakantiedag voor deze medewerkers en de directie heeft hierbij alle goedkeuringen verwerkt in een nieuwe rapportage die uitgekomen is in 2007, OR besluit versie 4.01. Het nalezen van deze documentatie helpt erbij om deze gegevens ook te kunnen verwerken in de personeelsadministratie en wordt dan ook verwerkt in een automatische berekening.

Dit maakt:

Een extra vakantiedag geldt voor medewerkers die ouder zijn dan 40 jaar. parttime medewerkers, maar dit is niet gelieerd aan de leeftijd bij deze medewerkers. Bij parttime medewerkers is besloten om één extra vakantiedag uit te keren na 10 jaar dienstverband. medewerkers van 50 jaar en ouder die ook meer dan 10 jaar dienstverband. opnemen van een extra vakantiedag 

En dan kan je effectief een techniek (EVT bijvoorbeeld) gebruiken om dit uit te werken.

Ben je nu bezig met het herschrijven van het ontwerp? Misschien wel, maar hierdoor kan je tenminste wel snel voortgang maken. Ook kom je er op deze manier achter of het ontwerp überhaupt wel testbaar is, dus het is wel zaak om zo snel mogelijk je besluit te nemen of je een ontwerp gaat "uitkleden", van zijn wol ontdoen.

• Dit lijkt omslachtig, maar helpt je om een goed overzicht te krijgen
• Je leert hiervan om ontwerpen goed te leren lezen, je verbetert jezelf als tester
• Veel werk? Meerdere rapportages van een OR lezen is ook veel werk en geeft vaak meer verwarring
• Je bent op zoek naar condities en keuzes, niet naar leuke verhalen of ellenlange rapportages en notulen.
• Goede basis om review commentaar te leveren binnen een project op dit soort ontwerpen
• Verwijder geen hoofdstuk nummeringen, dit heb je nodig voor eventuele verwijzingen vanaf je testgeval

Ik heb zelf dit vaker uit moeten voeren en ook wel eens mijn teststrategie moeten aanpassen van "testgevallen maken aan de hand van..." naar "testen uitvoeren met behulp van Exploratory Testing".

• Soms blijkt er geen schaap onder te zitten maar alleen wol en dan heb je wel wat terug te koppelen naar je projectteam.
• Kom je zo'n geval tegen, dan heb je nu er een simpele en praktische tip bij: scheren dat schaap en hopen dat er nog een beestje onder zit.

Ik hoop dat ik hier iemand mee heb kunnen helpen. Heb je dit al eens gebruikt, gebruik je het nu of later in de toekomst? Ik zou het leuk vinden als je dat even laat weten en je ervaring verder deelt. Laat een boodschap achter bij dit blog.