Deze Test Talk whiteboard gaat over het omgaan met “Requirements”. En dan toegespitst op ontbrekende of slechte requirements.
De volgende onderwerpen worden besproken:
– Wat kan er mis zijn met requirements
– Wat is de impact daarvan op testen
– Welke oplossingen kun je als tester gebruiken

Videotranscriptie

Welkom bij Test Talk Whiteboard

In deze whiteboard ga ik het hebben over het het omgaan met requirements.

Er zijn binnen ontwikkeltrajecten vaak problemen met requirements. Deze keer willen we daar bij stilstaan. Als eerste sta ik stil bij wat er mis kan gaan met requirements. Als tweede zal ik ingaan op de impact op testen als de requirements niet volledig zijn. En als derde ga ik in op de mogelijke oplossingen om om te gaan met onvolledige requirements. Requirements worden gebruikt door het gehele ontwikkeltraject heen. In deze whiteboard zal ik alleen stilstaan en kijken naar wat de impact is op testen.

Requirements

Missende requirements

Wat je ziet is dat er vaak functionaliteiten zijn waarvoor geen requirements zijn beschreven. Soms zijn hele functionaliteiten vergeten of dat er helemaal geen requirements zijn.

Conflicterende requirements.

Dat betekent dat er 2 requirements zijn die eigenlijk hetzelfde zeggen maar een andere afhandeling hebben. Dat betekent dat ze conflicterend zijn.

Incomplete requirements

Requirements voldoen niet aan de eisen aan een requirement. Of berekeningen zijn niet correct beschreven in een requirement of dat er beslissingen zijn met een open eind. Dat betekent dat als er een ja/nee beslissing genomen moet worden, dat de ja wel beschreven is en de nee niet beschreven is.

Onduidelijke requirements.

Dat betekent vaak dat er verboden worden worden gebruikt zoiets als tenminste. Daar kan je niet zoveel mee, is het nu meer of minder dan…

Meerledig interpreteerbaar

Dat betekent dat een interpretatie op verschillende manieren kan gebeuren. Dit gebeurt vaak bij een en/of. Iemand is 16 jaar of ouder en/of vrouw. Ja, is het nu 16 jaar of ouder en vrouw of is het 16 jaar of ouder of vrouw. Daar kan je dus allemaal andere interpretaties bij doen.

Impact op testen

Wat voor impact heeft dit nu op testen. Wat je ziet is dat je op het moment dat je een teststrategie gaat opstellen en een PRA gaat uitvoeren op het moment dat de requirements niet goed beschreven zijn dat je die dan alleen op globaal niveau kan doen. Dat betekent dat je alleen high level een PRA en teststrategie kan neerzetten. Dat betekent dat er een hoop onzekerheid in zit. Aan het einde betekent dat ook dat je maar een beperkt advies kan doen omdat je de teststrategie op een high level niveau hebt gemaakt, betekent dat ook dat je ook alleen op high level niveau een advies kan geven.

Wat je ook ziet is dat de tijdsinspanning en doorlooptijd kan veranderen. Dat kan hoger worden, dat hoger worden door een stukje rework, waarom omdat de requirements gedurende het traject duidelijk worden en dat er dus extra rework moet plaatsvinden. Dat betekent ook dat er vaak changes binnenkomen. Die leiden weer tot rework en dat betekent ook dat de kosten hoger worden, tijdsinspanning hoger wordt en de doorlooptijd langer zou kunnen worden. Wat ook gebeurt is dat de specs aangepast worden. Ontwikkelaars krijgen dezelfde zaken voor hen en betekent dus dat specificaties aangepast worden wat weer leidt tot extra tijdsinspanning en vaak een langere doorlooptijd. Het kan natuurlijk ook lager worden dat heeft te maken met dat we niet alles gaan testen. Van te voren doen we een bepaalde teststrategie, die teststrategie kunnen we niet volledig uitvoeren en dat betekent dat we minder gaan testen.

Wat er ook gebeurt is dat we vaak binnen testen onder tijdsdruk zelf ook aannames doen. Testers worden altijd getraind in vooral geen aannames doen en als je aannames doet zorg ervoor dat je die altijd verifieert maar ja, onder tijdsdruk weet iedereen ook wat er gebeurt en dat die aannames toch gedaan worden. Die aannames kunnen natuurlijk verkeerd zijn. Dat betekent ook dat daardoor een verkeerde conclusie getrokken wordt in de testgevallen. Die aannames worden op dat moment en zeker onder tijdsdruk niet gecommuniceerd en dat betekent ook dat er een stukje extra werk kan ontstaan.

Het traject wordt bijna altijd duurder, dat heeft te maken met dat we een globale teststrategie en PRA uitvoeren en dat we niet zeker weten of deze correct is. Daar komt er altijd een factor overheen, dat betekent dat het altijd duurder wordt. Tijdsinspanning en doorlooptijd wordt hoger. Hier zeggen we leuk dat het lager wordt maar we weten ook zelf wel dat we dan maar een beperkt advies kunnen geven en dat betekent ook dat daarmee eigenlijk het risico van implementatie hoger is en dat een opdrachtgever altijd zal zeggen “dan ga ik niet in productie”. Het betekent eigenlijk dat het altijd duurder wordt.

Mogelijke oplossingen

Als we dan kijken hoe zouden we dat kunnen oplossen. Er zijn wel een aantal oplossingen.

Verkennen en ontdekken.

Wat zijn nu eigenlijk de requirements wat wordt er mee bedoeld hoe ziet dat eruit. In een bestaand systeem kunnen we dat doen door een stukje regressie uit te voeren. Als we een stukje regressie uitvoeren kunnen we zien hoe is het nu opgelost, werkt alles nog steeds en zijn de requirements zoals deze gesteld zijn kloppen die ook. We kunnen ook een stukje exploratory testing uitvoeren. Dat betekent dat we daarmee alles weer kunnen zien of het correct werkt. Als we een heel nieuw systeem hebben kunnen we geen regressie uitvoeren maar wat we wel kunnen doen is van te voren een heleboel mensen erbij betrekken. We gaan de testgevallen opstellen en op dat moment betrekken we architecten, business, ontwikkelaar, bouwers, specifiers, trek ze er allemaal bij dat zorgt er voor dat duidelijk wordt wat het systeem inhoudt en dat je correct aan het specificeren bent met je testgevallen.

Common sense en ervaring.

Testers hebben vaak veel ervaring, weten vaak hoe systemen in elkaar zitten, maak daar gebruik van en zorg ervoor dat je daar ook over nadenkt van als er een requirement gesteld wordt kan ik dat ook testen ja of nee.

Prototyping

Als oplossing zou je ook kunnen doen een stukje prototyping. Prototyping helpt je aan de ene kant om inzicht te krijgen of de requirements zoals die gesteld zijn ook daadwerkelijk uitgevoerd kunnen worden. Mocht er nog geen prototyping worden gedaan, dan kun je als tester een voorstel doen om te gaan prototypen. Mocht het zou zijn dat er al wel een stukje prototyping plaatsvindt, zorgt er dan voor dat je als tester meeloopt in een stukje prototyping.

Documentatie

Het gaat niet om de testbasis, de specs zijn er allemaal maar het gaat om vergaderingen waar dingen in afgesproken worden, mensen die e-mails sturen over de reqiurements. Zorg ervoor dat je al die documentatie bij elkaar krijgt, zorg ervoor dat je dat tot je neemt en ziet van hoe de interpretatie van de requirements plaatsvindt.

Stakeholders uithoren.

Zorg ervoor dat in een metaplan sessie of in een ander soortige sessie duidelijk wordt wat er bedoeld wordt met de verschillende requirements. Zorg ervoor dat op het moment dat je testgevallen opstelt peer reviews uitvoert, richting andere testers maar ook richting business, architecten, ontwerpers, iedereen die maar iets kan zeggen over ben ik met de juiste testgevallen bezig.

Communicatie

Alles staat en valt natuurlijk met stukje communicatie. KOM VAN JE STOEL AF. Ga ervoor zorgen dat je de oplossingen allemaal inzet en maak daar ook gebruik van je communicatieve skills.

Als laatste wil ik nog meenemen op het moment dat het een verduidelijkt is, we hadden het hier net over de aannames, zorg ervoor dat als je duidelijkheid hebt over hoe het requirement er daadwerkelijk uit moet zien dat je die ook afstemt en zorg ervoor dat je die meeneemt in het changemanagement proces.

Dit was het voor vandaag. Ik dank u hartelijk voor het luisteren naar deze Test Talk Whiteboard en ik hoop u de volgende keer weer te zien Houdoooo.