Lees onze blogs over AFAS koppelingen

Test ordelijk en planmatig vanaf de start van een project

4876

Testen concentreert zich op de werking van de nieuwe of een aangepaste applicatie. Vanuit de waterval methodiek concentreert zich dit aan het eind van het traject. Want dan komt de functionaliteit beschikbaar en daarmee is het testen 'tastbaar'.

Hierdoor is er te laat in het project aandacht voor testen waardoor een gedegen voorbereiding lastig wordt. Met alle gevolgen voor de kwaliteit van het testen en daarmee van het op te leveren product. Wat dan weer resulteert in een slepende afronding, uitlopende planningen en vooral veel ergernis.

Testen is toetsen

Simpel gezegd is testen het controleren van een product aan de hand van een aantal criteria. Dit heeft weinig zin zonder vooraf gestelde normen en kwalificaties om de resultaten te beoordelen. En dit geldt ook voor afspraken van geconstateerde afwijkingen: wanneer is het goed (genoeg)? Dit geldt voor het fabriceren van meubels, het bouwen van huizen én het ontwikkelen van software.

Betrek uw gebruikers vanaf de start

Het grote voordeel hiervan is dat een aantal gebruikers zich niet vanuit het niets ineens moeten buigen over het testen van de functionaliteit, maar dat deze gebruikers vanaf het begin betrokken zijn bij de uitwerking van het product. Aangezien functionaliteit deel voor deel beschikbaar komt, is het functioneel testen niet alleen een activiteit aan het einde, maar op elk moment dat een deelproduct wordt opgeleverd. 

Groot voordeel daarbij is dat fouten eerder aan het licht komen en herstel daarmee minder ingrijpend. En dit leidt sneller tot een goed resultaat.

Test planmatig

Testen is vooral een ordelijke planmatige activiteit. Dit betekent dat de projectleider/testmanager moet letten op de randvoorwaarden bij het testen. Wanneer komen de modules beschikbaar, zijn de testcases met juiste testdatasets tijdig voorhanden en zijn de resources ingepland. En vooral, hoeregistreren en rapporteren we de resultaten zodat er conclusies uit getrokken kunnen worden.

Testen vereist een gedegen voorbereiding

Niet alle normen zijn vooraf duidelijk en daarnaast vaak per geval anders. En start daarom al bij het maken van het eerste projectvoorstel. Met vragen als: wanneer is het voorstel goed? Dit kent een inhoudelijke component: zijn alle onderwerpen van een projectvoorstel voldoende geadresseerd zodat we de juiste afwegingen kunnen maken. Maar ook een kwalitatieve component: wanneer besluiten we of de business case goed genoeg is. 

Dit beoordelen is ook een vorm van testen.

Testen op elk onderdeel van het project

De producten die tijdens het project worden opgeleverd, moeten getest: projectplan, ontwerpen, software modules, beheerdocumenten etc. In een wat omvangrijker project komt de opzet en de organisatie van het beoordelen, toetsen en het omgaan met afwijkingen aan de orde in een apart opgesteld kwaliteitsplan. Dit kwaliteitsplan vormt de basis voor de uitwerking van de testen tijdens het hele project.

Requirements voor het testen

Het onderwerp dat het meest geassocieerd wordt met 'testen' is het beoordelen van de functionaliteit van een module of applicatie,. Ook dit begint bij het opstellen van de functionele requirements (functionele eisen). Aan de hand hiervan wordt later de functionaliteit van het product getoetst.

Testen door Used Cases 

Wanneer er gebruik wordt gemaakt van used cases dan vormen die de bron voor latere testen. Zoals de requirements stap voor stap van grof naar fijn worden uitgewerkt tijdens het project, geldt dat ook voor de bijbehorende testcases

In eerste instantie is alleen de hoofdfunctionaliteit bekend: mutatiemogelijkheid van persoonsgegevens, artikel-opvoer, een prijsberekening enz. Hoe rekenregels en invoerschermen er exact uitzien is onbekend en in dat stadium ook niet nodig. Duidelijk is wel dat nagedacht moet worden over wat gemuteerd moet worden, om welke artikelgegevens gaat het, wat moet het resultaat zijn van die 'handeling'. 

Bovendien kan een prioriteit worden aangegeven: wat is essentieel voor de werking, wat weerhoudt (in een later stadium) een acceptatie en in gebruik name.

Functionaliteit uitwerken en testcases

Bij uitwerking van de functionaliteit ontstaat ook meer en meer detaillering van de werking, de schermafhandelingen, en de businessrules. Het bepalen wat de juiste werking is, en onder welke condities, wordt daarmee steeds concreter. Zo beschouwd ontstaat gelijktijdig met het beschrijven van de functionaliteit een beeld van de validatie: de verzameling testcases.

Er zijn talloze andere aspecten van testen: wie testen er, waar ligt verantwoordelijkheid, de tools, de verschillende soorten testen (naast de functionele), en hoe komen we tot een acceptatie(test).

Onderwerpen die vaak onvoldoende uit de verf komen of zelfs leiden tot misverstanden tussen opdrachtgever en opdrachtnemer. In latere blogs meer hier over.

Testen een lastig onderwerp? Hulp nodig bij het organiseren of uitwerken? Ik hoor het graag.
Reageren kan via mijn mail.