Het acceptatie testrapport

Bij de oplevering van verschillende systeem aanpassingen vindt meestal eerst een acceptatietest plaats. De resultaten van deze testen dienen we vast te leggen in een testrapport. De rapportage is aan de belanghebbende opdrachtgever i.q. de Applicatie-eigenaar. Om de resultaten van de verschillende testen goed te kunnen vergelijken en te waarborgen dat we aan alle belangrijke aspecten aandacht hebben besteed is er een vast kader voor het maken van een acceptatie testrapport. Een rapportage standaard is hieronder nader uitgewerkt.

Een acceptatie testrapport bestaat uit een aantal verplichte hoofdstukken. Als het niet mogelijk is om invulling te geven aan een hoofdstuk dienen we dit toch aan te geven. Een voorbeeld hiervan is als de gebruikers niet mee testen bij bulkproces­sen. Zodoende is bekend waarom dat hoofdstuk niet verder is uitgewerkt. De volgende hoofdstukken dienen in het acceptatie testrapport aanwezig te zijn:

Beschrijving testobjecten in het testrapport

We moeten aangegeven welke opdracht de grondslag is voor de aanpassing van de software. Tevens geven we aan welke situatie we met behulp van de opdracht moeten bereiken.

Ook moeten we aangeven:

• Welke software we testen.
• Welke functies deze producten hebben.
• Waarom ze in de test betrokken zijn.

Het kan voorkomen dat producten in de test betrokken zijn die niet zijn aangepast. Ze zijn echter nodig zijn om de gewijzigde producten goed te kunnen beoordelen. Het gaat hierbij bijvoorbeeld om raadpleegschermen of lijsten. Dit dienen we ook in de rapportage te vermelden.

Uitvoering testplan

We moeten aangegeven in hoeverre we het testplan konden uitvoeren en om welke redenen van het testplan is afgeweken. Tevens dienen we per testcase aan te ge­ven wat de resultaten zijn. Een en andere moeten we in een logboekvorm vast te leggen zodat de activiteiten per dag per testobject zichtbaar zijn. Zo maken we duidelijk is welke inspanningen er nodig waren om bepaalde problemen op te lossen. De datum waarop het probleem opgelost is zien we graag naast de constateringsdatum staan.

Voor de inzichtelijkheid dienen we per testcase te beschreven om welke activiteit het gaat, waarbij we ook de modulenamen noemen. Tevens willen we graag weten wie de testcase heeft uitgevoerd.

Testgevallen

Indien er testgevallen nodig zijn om de test uit te kunnen voeren dienen we deze aan te geven. Ook hun diversiteit en de resultaten zijn per testgeval rapporteren we. Bij de aanwezig­heid van een accepta­tiedatabase is dit niet altijd nodig. Tevens dient het duidelijk te zijn welke methode is toegepast om de testgevallen te bepalen.

Voor het samenstellen van de testset van testgevallen en het daadwerkelijk uitvoeren van de test kunnen we gebruik maken van de daarvoor bedoelde checklisten van ITpedia.

Conclusies en aanbevelingen van de acceptatietest

Aan de hand van de testresultaten beschrijven we de belangrijkste conclusies en aanbevelingen in het kort. Het testplan kunnen we er als leidraad bijhouden.

Onderwerpen die in dit hoofdstuk als paragraaf naar voren dienen te komen zijn:

Leereffecten voor opstellen testplannen

• We geven aan in hoeverre het testplan aan de verwachtingen heeft vol­daan.
• Tevens geven we aan hoe de organisatie rond de acceptatietest gewerkt heeft en voldeed aan de verwachtingen.

Acceptatiegraad gebruikers

• We geven aan welke gebruikers bij de test betrokken waren.
• Vastgelegd moet worden in hoeverre de introductie van het systeem bij de gebruikers succesvol is geweest. Tevens geven we aan waar nog verbeteringen kunnen plaatsvinden.
• Uit het rapport blijkt dat de testen hebben aangetoond dat de  controleerbaarheid van het systeem gewaarborgd blijft.
• We rapporteren of de testen hebben aangetoond dat het management de grip op de gegevensverwerking blijft houden.
• We geven aan hoe de introductie bij de indirecte gebruikers is verlopen

Inpasbaarheid in de administratieve organisatie

• Uit de test moet blijken of de software de bedrijfsprocessen voldoende ondersteund. Vise versa moet blijken of het informatiesysteem wel voldoende door de bedrijfsprocessen wordt ondersteund.
• We moeten aangeven of aan de eisen van functiescheiding door het systeem is voldaan.

Bijzonderheden vastleggen in het testrapport

Binnen het kader van de testrapportage is apart ruimte gereserveerd voor aanvullende bijzonder­heden. Denk hierbij aan:

• De relatie met modules in het regulieronderhoud versus de release.
• De invloed die de definiëring van een nieuw traject heeft.
• Enzovoorts.

Tevens kunnen we indien mogelijk alvast een indicatie gegeven over het gedrag van het informatiesys­teem in de productie-omgeving. Misschien is al duidelijk of en hoe de in de testomgeving vastgestelde performance ook in de productie-omgeving te halen is.

Eindoordeel en advies in het testrapport

In dit hoofdstuk beschrijven we het volgende:

• Wat de algemene indruk van het opgeleverde product is.
• Of er een aanvaardbaar niveau van kwaliteit bereikt is.
• Er dient een opsomming te zijn van producten die we in productie kunnen nemen
• En een opsomming van producten die (nog) niet gereed zijn (Backlog).

Aangezien we het acceptatie testrapport altijd na het afronden van de test maken, moeten we bij een gedeeltelijke in-productie-name aangeven waarom we producten wel of niet in productie nemen.

Akkoord van het management op de acceptatietest

Het paraferen en dateren van het testrapport door verantwoordelijken. Dit bekrachtigt de goedkeu­ring van de producten die we in het hoofdstuk ‘Eindoordeel en advies’ als gereed hebben aangemerkt. Tevens ontslaat het de testers van hun verantwoordelijkheden en verder testwerk.

Alternatief voor het testrapport?

De noodzaak van het maken van een testrapport zien we niet altijd in, het kost tijd en het systeem is al akkoord. Een paraaf op het module formulier moet voldoende zijn, denkt men soms.

D.m.v. het acceptatie testrapport leggen de testers echter verantwoording af over de werkzaamheden die zij hebben verricht. Het maken van een omvangrijk verslag kunnen we echter voorkomen. Maak daarvoor gebruik van een formulier en te verwijzen naar de registraties in ITpedia. Om deze redenen is getracht om het formulier tot één blad te beperken. Tijdens het testen kan blijken dat ter ondersteuning van het formulier bijlagen nodig zijn. Het gebruik van het formulier is mede afhankelijk van de organisatievorm waarbinnen we het gebruiken.

Wat rapporteren in het testrapport?

• Opdracht/probleemnummer: Het opdrachtnummer c.q. probleemnummer komt overeen met de nummers zoals die aan het project of de release zijn toegekend. Door dit nummer over te nemen ontstaat een koppeling van het testresultaat aan de opdracht waaronder het resultaat tot stand is gekomen.

• Testteam: Het is van belang om altijd bekend te maken wie de test heeft uitgevoerd. Er kunnen namelijk onduidelijkheden zijn in het rapport waar we verder naar moeten vragen. Het testteam kan uit één of meer personen bestaan.

• (Her)testnummer: Bij complexe systemen zal vaak blijken dat de programmamodules niet in één keer goed door de test komen. Het testobject keuren we dan af. Door voor elke test binnen de opdracht nu een nieuw testnummer uit te geven kunnen we bepalen hoe vaak een programmamodule tijdens het acceptatietesten is afgekeurd. Als dat vaak voor komt kunnen we concluderen dat er iets fout is. Er kan bijvoorbeeld een communicatie probleem zijn, of de kwaliteit van de programmatuur laat te wensen over.

• Test objecten: Per testobject (meestal programmamodule) geven we de naam op, duiden het soort module, registreren de testdatum, tekenen de verwachte werking aan en leggen de uitslag vast.

• Bevindingen: Bij bevindingen teken we we niet allen afwijkingen op maar tevens geven we aan of de werking conform de verwachting is. Zodoende is vast te stellen of de test wel volledig is uitgevoerd en dat er niet alleen is getest op de gewijzigde punten.

Evaluatie van de Testronde

Om meer zekerheid te kunnen krijgen over de diepgang en de uitvoering van de acceptatietest dienen we in dit blok een aantal vragen te beantwoorden:

• Eindoordeel en advies: geeft de uiteindelijke uitslag en het vervolg op de test aan.

• Applicaties in productie: Al de goed gekeurde testobjecten bieden we in dit blok aan voor de in-productie-name aangeboden.

• Applicaties nog niet in productie: Alle testobjecten die we nog niet in productie kunnen nemen, zetten we in dit blok. Het is niet aan te raden om opdrachten gedeeltelijk in productie te nemen. Dit leidt namelijk tot misverstanden. Als er echter op zichzelf staande problemen zijn opgelost kunnen we bij een voortijdige in-productie-name van dat deel ook eerder van de oplossing profiteren.

• Akkoord: De applicatiebeheerder tekent voor akkoord zodat de in-productie-name doorgang kan vinden.

• Management: Het management stelt vast dat de acceptatietest met goed gevolg is doorlopen. Met de ondertekening van dit document ontvangt het testteam decharge. De testers kunnen weer met hun dagelijkse werkzaamheden verder gaan.
  

Klik hier (Acceptatietestrapport.pdf) voor een voorbeeld Accpetatie testrapport (formulier).

Discussieer mee op LinkedIn.