Het acceptatietestrapport

Bij de oplevering van verschillende systeem aanpassingen vindt meestal eerst een acceptatietest plaats. De resultaten van deze testen dienen aan de belanghebbende afdelingen i.q. de Applicatie-eigenaar te worden gemeld. Om de resultaten van de verschillende testen goed te kunnen vergelijken en te waarborgen dat aan alle belangrijke aspecten aandacht wordt besteed is er een vast kader gecreëerd voor het maken van de acceptatie­-testrapportage. Een rapportage standaard is hieronder nader uitgewerkt.

Een testrapport bestaat uit een aantal verplichte hoofdstukken. Als het niet mogelijk is om invulling te geven aan een hoofdstuk (bijvoorbeeld omdat de gebruikers niet mee testen bij bulkproces­sen) dient dit toch in het hoofdstuk te worden aangegeven, zodat bekend is waarom dat hoofdstuk niet verder is uitgewerkt. De volgende hoofdstukken dienen in het testrapport aanwezig te zijn:

Beschrijving testobjecten

Aangegeven dient te worden welke opdracht de grondslag is voor de aanpassing van het product en welke situatie a.g.v. de opdracht bereikt moet worden.

Aangegeven dient te worden welke producten getest worden, welke functie deze producten hebben en om welke reden ze in de test betrokken zijn. Het kan voorkomen dat er producten in de test betrokken zijn die niet zijn aangepast maar nodig zijn om de gewijzigde producten goed te kunnen beoordelen. Het gaat hierbij bijvoorbeeld om raadpleegschermen of lijsten. Dit dient tevens in de rapportage te worden aangegeven.

Uitvoering testplan

Aangegeven dient te worden in hoeverre het testplan uitgevoerd kon worden en om welke redenen van het testplan is afgeweken. Tevens dient per teststap uit het testplan aangege­ven te worden wat de resultaten zijn. Een en andere dient in een logboekvorm te worden vastgelegd zodat de activiteiten per dag per testobject zichtbaar zijn en duidelijk is welke inspanningen er nodig waren om bepaalde problemen op te lossen. De datum waarop het probleem opgelost is dient naast de constateringsdatum te worden gezet.

Voor de inzichtelijkheid dient per teststap beschreven te worden om welke activiteit het gaat, waarbij ook de modulenamen moeten worden genoemd. Tevens dient er te worden aangegeven door wie de teststap is uitgevoerd.

Indien er testgevallen nodig zijn om de test uit te kunnen voeren dient er te worden aangegeven om hoeveel testgevallen het gaat met hun diversiteit en wat de resultaten zijn per testgeval (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 kan gebruik worden gemaakt van de daarvoor bedoelde checklisten.

Conclusies en aanbevelingen van de test

Aan de hand van de resultaten van de uitvoering van het testplan worden in het kort de belangrijkste conclusies en aanbevelingen beschreven.

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

Leereffecten voor opstellen testplannen
– Aangegeven dient te worden in hoeverre het testplan aan de verwachtingen heeft vol­daan.
– Aangegeven dient te worden hoe de organisatie rond de acceptatietest gewerkt heeft en voldoet aan de verwachtingen.

Acceptatiegraad gebruikers
– Aangegeven dient te worden welke gebruikers bij de test betrokken waren.
– Aangegeven dient te worden in hoeverre de introductie van het systeem bij de gebruikers succesvol is geweest en hoe verbeteringen kunnen plaatsvinden.
– Aangegeven dient te worden dat de testen hebben aangetoond dat de  controleerbaarheid van het systeem gewaarborgd blijft.
– Aangegeven dient te worden dat de testen hebben aangetoond dat het management hoe de grip op de gegevensverwer­king blijft houden.
– Aangegeven dient te worden hoe de introductie bij de indirecte gebruikers is verlopen

Inpasbaarheid in de administratieve organisatie
– Aangegeven dient te worden of de administratieve organisatie voldoende door het informatie­ systeem wordt ondersteund en dat het informatiesysteem voldoende door de administratieve organisatie wordt ondersteund.
– Aangegeven dient te worden of aan de eisen van functiescheiding door het systeem is voldaan.

Bijzonderheden

Binnen het kader van de testrapportage is apart ruimte gereserveerd voor aanvullende bijzonder­heden. Zoals (in een release) de relatie met producten uit het regulieronderhoud, de invloed die de definiëring van een nieuw traject heeft enzovoorts.
Tevens kan indien mogelijk alvast een indicatie worden gegeven over het gedrag van het informatiesys­teem in de productie-omgeving. Met name dient duidelijk te worden aangegeven of en hoe de in de testomgeving vastgestelde performance ook in de productie-omgeving wordt gehaald.

Eindoordeel en advies

In dit hoofdstuk wordt nader beschreven wat de algemene indrukken van het opgeleverde product zijn en of een aanvaardbaar niveau van kwaliteit bereikt is. Er dient een opsomming te zijn van producten die in productie genomen kunnen worden en van producten die (nog) niet gereed zijn.
Aangezien het acceptatie-testrapport altijd na het afronden van de test gemaakt, wordt dient bij een gedeeltelijke in productie name aangegeven te worden waarom producten wel of niet in productie worden genomen.

Akkoord management acceptatietest

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

Alternatief voor testrapport?

Van het maken van een testrapport wordt de noodzaak niet altijd ingezien, het kost tijd en het systeem is immers akkoord. Een paraaf op het module formulier moet voldoende zijn, wordt soms gedacht.

D.m.v. het testrapport leggen de testers echter verantwoording af over de werkzaamhe­den die zij hebben verricht. Het maken van een omvangrijk verslag kan echter worden voorko­men door het gebruik van een formulier en te verwijzen naar de registra­ties in ITpedia. Om deze redenen is getracht om het formulier tot één blad te beperken. Tij­dens het testen kan blijken dat ter ondersteuning van het formulier bijlagen nodig zijn. Het gebruik van het formulier is mede afhankelijk van de organisatie­vorm waarbinnen het wordt gebruikt. Enkele rubrieken worden nader toegelicht :

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 verder naar gevraagd moet worden. 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 wordt dan afgekeurd. Door voor elke test binnen de opdracht nu een nieuw testnummer uit te geven kan worden bepaald hoe vaak een programmamodule tijdens het acceptatietesten wordt afgekeurd. Als dat vaak voor komt kan worden geconcludeerd dat er iets fout is. Er kan bijvoor­beeld een communicatie probleem zijn, of de kwaliteit van de programmuur laat te wensen over.

Test objecten: Per testobject (meestal programmamodule) wordt de naam ingegeven, het soort module wordt aangeduid, de testdatum geregistreerd, de verwachte werking aangetekend en de uitslag vastgelegd.

Bevindingen: Bij bevindingen worden niet allen afwijkingen opgetekend maar tevens wordt aangegeven of de werking conform de verwachting is. Zodoende is vast te stellen of de test wel volledig wordt uitgevoerd en dat er niet alleen wordt 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 in dit blok een aantal vragen te worden beantwoord.

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

Applicaties in productie: Al de goed gekeurde testobjecten worden in dit blok ter in productie name aangeboden.

Applicaties nog niet in productie: Alle testobjecten die nog niet in productie genomen kunnen worden, worden in dit blok opgenomen. Het is niet aan te raden om opdrachten gedeeltelijk in productie te nemen. Dit leidt namelijk tot misverstanden. Alleen als op zichzelf staande problemen worden opgelost kan bij een voortijdige in productie name van een deel ook eerder van de oplossing worden geprofiteerd.

Akkoord: De applicatiebeheerder tekent voor accoord zodat de in productiename doorgang kan vinden.

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

Klik hier (Acceptatietestrapport.pdf) voor een voorbeeld Accpetatietestrapport (formulier).

Boeken over dit onderwerp

Aan de slag met software testen

Auteur: Hossein Chamani
‘Aan de slag met software testen’ helpt ICT-studenten om al tijdens hun studie testexpertise te ontwikkelen voor de beroepspraktijk.
Europrijs: 32,5
Bestellen

Teksten Vreemdelingenrecht – 2016-2017

Auteur: Paul Vos
Dit boek bevat de belangrijkste wetgeving met betrekking tot het nationale vreemdelingenrecht, alsmede de Procesregeling bestuursrecht 2013.
Europrijs: 56,52
Bestellen

Meer boeken over testen vinden.


-- Printbare PDF-versie --


No votes yet.
Please wait...

Aanvullingen

Geef zelf een aanvulling.

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten:
Rapportage acceptatietest 56 vragen.
Sidebar