Sjabloon testplan op basis van SYSQA -teststrategieaanpak. <<Organisatie>>

Transcriptie

1 Sjabloon testplan op basis van SYSQA -teststrategieaanpak <<Organisatie>> SYSQA B.V. Almere Datum : <<datum>> Status : <<status>> Opgesteld door : <<naam>>

2 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 2 van 17 Inhoudsopgave 1 Inleiding Doel van het testplan Gebruikte afkortingen en overige terminologie Achtergrond Opdracht Scope Acceptatie Testbasis Documenten Normen, standaards en procedures Teststrategie Generieke test strategie mastertestplan Productrisico s Testorganisatie Rollen Taken en verantwoordelijkheden Producten Infrastructuur Testomgeving Hardware Testtools Begroting Planning Planning Project beheersing Risico s en tegenmaatregelen Voortgangsbewaking Rapportage Overlegstructuren Bevindingenbeheer Beheer testproducten Quality Assurance...17 Versiebeheer Versie Datum Opmerkingen Auteur Verzendlijst Versie Ontvanger

3 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 3 van 17 1 Inleiding 1.1 Doel van het testplan Omschrijf hier het doel van dit testplan. Bijv.: Het doel van dit detail testplan (DTP) voor de (kies hier de relevante testsoort: unit test, systeem test, functionele acceptatie test of andere) test is de opdrachtgever en andere stakeholders te informeren over de aanpak, de activiteiten en de op te leveren (eind)producten met betrekking tot het testtraject. Dit plan geeft inzicht in de diverse uit te voeren tests zodanig dat de juiste kwaliteitsattributen met de afgesproken diepgang zoals vastgelegd in het mastertestplan (MTP) worden getest. Let wel: het doel wordt in samenspraak met de opdrachtgever opgesteld. 1.2 Gebruikte afkortingen en overige terminologie Vermeld hier de afkortingen die je gebruikt in het plan Afkorting DTP MTP GAT Betekenis Detailtestplan Mastertestplan Gebruikersacceptatietest 1.3 Achtergrond Geef aan wat de aanleiding, strategisch belang en de doelstelling zijn van het project. 1.4 Opdracht Opdrachtformulering Laat het doel van de testopdracht en het te bereiken resultaat duidelijk naar voren komen. Het te bereiken resultaat moet meetbaar zijn. De opdracht moet voldoen aan het SMART principe: de opdracht moet Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdsgebonden. Voorbeeld doel van de testopdracht: - Controleren in hoeverre de opgeleverde software voldoet aan opgestelde specificaties. Om aan deze opdracht te kunnen voldoen zullen de benodigde testen uitgevoerd en voorbereid worden. Ander voorbeeld van de mogelijke omschrijving van de opdracht: SYSQA BV, hierna te noemen SYSQA, voert in opdracht van <naam opdrachtgever>, de functionele acceptatietest van het systeem <systeemnaam> uit Een onderdeel van de opdrachtomschrijving is de afbakening; wat hoort wel en wat hoort niet tot de opdracht. Dit wordt verder in paragraaf 1.5 gedetailleerd Opdrachtgever Vermeld hier de opdrachtgever, veelal de Projectmanager of de Business Owner Opdrachtnemer Dit is meestal de testcoördinator. Indien noodzakelijk, hanteer dan het volgende format: Organisatie, Project, Vertegenwoordigd door naam contactpersoon. De naam van SYSQA wordt alleen genoemd als het gaat om een opdracht waar SYSQA resultaat verantwoordelijk is.

4 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 4 van Betrokkenen bij het opstellen van het testplan Hier vermeld je de personen die je hebt geconsulteerd, personen van wie je input nodig hebt, personen die op basis van dit plan iets moeten doen, etc. Naam Rol Verantwoordelijkheid Overige stakeholders Naam Rol Relatie 1.5 Scope Projectafbakening Geef aan wat het beschouwinggebied van de test is. Met andere woorden geef aan op welk (deel-) systeem getest wordt. Geef in een plaatje weer, waar en hoe het (deel-) systeem zich in de totale omgeving bevindt. Geef aan welke activiteiten wel / niet tot de scope behoren. Geef aan welke testsoorten wel / niet tot de scope van het detailtestplan behoren Randvoorwaarden Randvoorwaarden worden in principe extern aan het testproject opgelegd. Zij liggen over het algemeen op het terrein van limieten en voorwaarden met betrekking tot benodigde middelen, mensen, budget en tijd. Voorbeelden van randvoorwaarden zijn: 1. Vaste einddatum, de test dient uiterlijk op een vastgestelde einddatum te zijn beëindigd; 2. Bij het uitvoeren van de diverse testen geldt de actuele versie van de Project Brief of het PID als randvoorwaarde; 3. De software/ deelopleveringen worden op vastgestelde data opgeleverd; 4. Het testtraject krijgt vaak als randvoorwaarde een budget toegewezen. Soms kan niet voldaan worden aan het noodzakelijke aantal medewerkers voor het testproject maar door het budget bepaald, en niet zozeer door de feitelijke behoefte Uitgangspunten Uitgangspunten worden door de testmanager bepaald in overleg met de verantwoordelijken van het project / programma. Voorbeelden van uitgangspunten zijn: 1. Opleveringen software: beschrijf hier wie welke software moet opleveren voor het kunnen uitvoeren van de diverse testscripts; 2. Scope testbasis: beschrijf hier de testbasis welke gebruikt moet worden door het test team (denk eraan ook technische en overige documentatie, bijvoorbeeld: testresultaten uit vorige testsoorten, te noemen, en niet alleen het FO!); 3. Wijzigingen testbasis: bepaal hier hoe de wijzigingen in de software en de test basis aangeleverd moeten worden aan het testteam. Gebruik indien aanwezig een standaard wijzigingprocedure en/of een releasemanagement tool; 4. Beschikbaarheid medewerkers vanuit bouw, support testomgeving en gebruiker organisatie: vermeld hier wat voor afspraken er gemaakt (moeten) worden over de beschikbaarheid van de diverse disciplines die nodig zijn gedurende het testtraject.

5 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 5 van Relatie met andere projecten Beschrijf hier de relatie met de overige testsoorten, zowel voorgaande als opvolgende Testsoort Testcoördinator Omschrijving afhankelijkheid Noodzakelijke actie (omschrijving) 1.6 Acceptatie Acceptanten Beschrijf wie de acceptant voor dit testtraject is (meestal de opdrachtgever) Entry en exit criteria Vermeld hier welke Entry criteria en welke Exit criteria er voor deze testsoort zijn. Houd de criteria specifiek. Als het bijzonder generiek, en niet specifiek voor deze testsoort is, laat het criterium dan in het MTP zetten. Voorbeelden: Entry criteria: - De voorgaande testsoort is afgerond; - Bevindingen van een voorgaande testsoort zijn opgelost of geaccepteerd; - Testomgeving is beschikbaar. Exit criteria: - Alle geplande testen zijn succesvol uitgevoerd; - Nog openstaande bevindingen zijn geaccepteerd, niet blokkerend voor de volgende fase; - Alle testresultaten en bevindingen zijn geregistreerd; - Alle testware is geconserveerd; - Het eindrapport van de testsoort is opgesteld Acceptatiecriteria Aan het eind van het testtraject wordt een vrijgaveadvies opgesteld waarin de resultaten van het testtraject worden beschreven. In het vrijgaveadvies is een advies over het al dan niet in productie nemen van de applicatie opgenomen. Dit advies wordt onderbouwd met een overzicht van de openstaande bevindingen en weergave van het testtraject. De risico s van een eventuele implementatie worden benoemd. Een positief advies voor het accepteren van de programmatuur zal gegeven worden als: - De programmatuur na de testronde geen blokkerende bevindingen bevat. - Aan alle acceptatiecriteria voldaan is. De eindrapportage is een acceptatiedocument waarmee opdracht officieel wordt afgesloten en door ondertekening van het document wordt de inhoud en beschreven bevindingen van het testresultaat geaccepteerd en het testteam decharge verleent Decharge van de testopdracht Vermeld hier wanneer de opdrachtgever decharge gaat verlenen voor de testopdracht: onder welke voorwaarden, wat de procedure daarvoor is etc..

6 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 6 van 17 2 Testbasis 2.1 Documenten Vermeld hier welke documenten de basis voor deze testsoort vormen. Vermeld hier alle relevante documenten. De tabel is hier nu gevuld met voorbeelden. Document Versie Datum Auteur Requirements Functioneel ontwerp interface Technisch ontwerp rapport AO procedure Datamodel Projectplan 2.2 Normen, standaards en procedures Vermeld hier de normen en standaards welke naast de documentatie gebruikt worden om de test basis op te stellen. Voorbeelden: TMap Next, ISO 9126 en Prince2. Denk ook aan bedrijfsstandaards.

7 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 7 van 17 3 Teststrategie De teststrategie geeft aan hoe de testinspanning verdeeld wordt over de testsoorten en de kwaliteitsattributen. Vermeld hier hoe je tot deze strategie gekomen bent. Indien dit in het MTP uitgewerkt is: verwijs naar het MTP. Wijs specifiek op de teststrategie in het kader van de in het DTP beschreven testsoort. 3.1 Generieke teststrategie mastertestplan Indien er geen MTP geschreven is, volg dan onderstaande werkwijze. Beschrijf daarbij de algemene teststrategie, gefocust op de scope van dit detailtestplan. Een belangrijk doel van het toewijzen van risico's en kwaliteitsattributen aan testsoorten is ervoor te zorgen dat er niet onbedoeld tests dubbel of juist niet worden uitgevoerd. Vanzelfsprekend kan er in bepaalde situaties bewust voor gekozen worden om vergelijkbare tests door meerdere partijen gedurende meerdere testronden te laten uitvoeren. Dit is bijvoorbeeld zinvol als een bepaald testaspect vanuit verschillende kanten belicht kan worden. Zo kan bijvoorbeeld het kwaliteitsattribuut beveiliging zowel in de GAT als in de PAT worden meegenomen. In de GAT worden dan de autorisaties getest, terwijl in de PAT gekeken wordt naar de technische werking van de firewalls. In de onderstaande tabel staat een aanzet tot een verdeling van verschillende kwaliteitsattributen met bijbehorende risicoklasse over de verschillende testsoorten. Opmerkingen bij deze tabel: - In de tabel kunnen ook toetssoorten meegenomen worden, omdat die in veel organisaties ook onder verantwoordelijkheid van het MTP vallen. - De risicoklasse in de tabel is niet ingevuld aangezien de tabel een aanzet is om inzicht te geven in welke testsoort of toetssoort welke kwaliteitsattributen getest kunnen worden. In de praktijk wordt deze tabel alleen ingevuld voor de kwaliteitsattributen met een risicoklasse. De overige kwaliteitsattributen worden buiten beschouwing gelaten. - De tabel is een aanzet die per project verder uitgewerkt moet worden. UT ST IT GAT PAT Risicoklasse Beheerbaarheid Beveiliging Bruikbaarheid Connectiviteit Continuïteit Enz... Toelichting bij de bovenstaande tabel: UT unittest ST systeemtest IT integratietest GAT gebruikersacceptatietest PAT productieacceptatietest beperkte dekking van de dynamische test gemiddelde dekking van de dynamische test grote dekking van de dynamische test Als in een cel niets staat, betekent dit dat de betreffende toets- of testsoort geen aandacht hoeft te besteden aan het kwaliteitsattribuut. Een ' ' in de UT kolom wil zeggen dat er extra inspanning ten opzichte van de standaard testaanpak van realisatie wordt verwacht. Hierbij kan bijvoorbeeld gedacht worden aan het

8 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 8 van 17 expliciet loggen van testresultaten. De 'standaard' inspanning voor de UT is veelal onderdeel van de realisatieplanning en daarmee niet afzonderlijk zichtbaar. De boven beschreven strategiematrix is zonder meer bruikbaar bij nieuwbouwtrajecten. Het voornaamste verschil tussen nieuwbouw en onderhoud voor de teststrategie is de foutkans. Er wordt bij onderhoud een aantal aanpassingen, meestal naar aanleiding van probleemrapporten of wijzigingsvoorstellen, gedaan op een al bestaand systeem. Deze wijzigingen dienen te worden getest. Bij het aanpassen is het mogelijk dat er onbedoeld fouten in ongewijzigde delen van het systeem worden geïntroduceerd, waardoor het systeem in kwaliteit achteruit gaat. Dit verschijnsel van kwaliteitsachteruitgang heet regressie en is de reden dat ook de ongewijzigde delen van het systeem getest worden. Deze verdeling van foutkansen bij onderhoud betekent voor de strategiebepaling dat voornamelijk de belangen van de deelobjecten anders komen te liggen dan bij een nieuwbouwsituatie. Een deelobject dat bij de nieuwbouw heel veel testbelang had, blijft bij de onderhoudsrelease misschien wel ongewijzigd. Omdat de kans op regressie dan het enige risico is, is het testbelang veel kleiner. Om die reden kan voor onderhoud de strategiebepaling voor een testsoort worden aangepast door in de stappen van de strategiebepaling wijzigingen als deelobjecten te kiezen. Een dergelijke vorm van strategiebepaling wordt ook wel (test)impactanalyse genoemd. Per wijziging (een geaccepteerd wijzigingsvoorstel of een opgelost probleemrapport) wordt geïnventariseerd welke delen van het systeem worden gewijzigd, welke delen van het systeem mogelijk worden beïnvloed door de wijziging en welke kwaliteitsattributen relevant zijn. Er zijn diverse variaties mogelijk voor het testen van elke wijziging, geheel afhankelijk van de gelopen risico s: - Een beperkte test, alleen gericht op de wijziging; - Een volledige (her)test van de functie waarin de wijziging is aangebracht; - Het testen van de samenhang tussen de gewijzigde functie en de functies er direct omheen. Tevens wordt de regressietest van het systeem als geheel onderkend. De regressietest richt zich voornamelijk op de samenhang tussen de gewijzigde en ongewijzigde delen van het systeem, omdat hier de kans op regressie het grootst is. Indien de strategiebepaling voor de nieuwbouw beschikbaar is, kunnen de hier toegekende belangen aan deelobjecten een rol spelen bij de samenstelling van deze regressietest. Een regressietest kan beperkt of volledig worden uitgevoerd, afhankelijk van de risico s én van de benodigde testinspanning. 3.2 Productrisico s Neem hier het resultaat voor de te testen testsoort over vanuit het MTP. Indien er geen MTP is, dan dient dit onderdeel hier beschreven te worden. De teststrategie begint met het in kaart brengen van de productrisico s. Vervolgens worden deze productrisico s door verschillende testsoorten afgedekt, waarbij de risico s voor de onderhanden testsoort in dit DTP opgenomen moeten worden conform de hieronder beschreven methode. Ook dient weergegeven te worden in welk ander DTP de overige geconstateerde productrisico s opgenomen worden. Tijdens het opstellen van de teststrategie komt men o.a. tot de volgende (voorbeeld) tabel. Vermeld deze in het plan conform de hieronder getoonde tabel. Voor een beschrijving hoe de risico s kunnen worden verzameld zie par van de Handleiding Teststrategie. Subproduct Kwaliteitsattribuut Productrisico Risico Klasse Maken van Functionaliteit Verkeerde klant wordt vereffend A Betaalstapel Nauwkeurigheid Klant ontvangt onterecht herinnering B Maken van Functionaliteit Betaling komt onterecht in nabewerking, veel A A Cluster Risico Klasse A

9 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 9 van 17 Betaalstapel Geschiktheid handmatig werk Functie Y uit vorige voorbeeld Veel werk om verkeerde matching ongedaan te maken B A Koppelen van risico s aan requirements van het informatiesysteem Vervolgens kunnen de requirements/systeemeisen die binnen de scope vallen van dit testplan worden gelinkt met de benoemde risico s. Op deze wijze worden er combinaties van risico s en requirements gevormd (RRC s). Productrisico s Requirements A X X X B X C X X X D X E X F X G X X H X X Het koppelen van risico s en requirements tot RRC s kan tot gevolg hebben dat er requirements en/of risico s overblijven, oftewel deze kunnen niet gekoppeld worden. In principe is een requirement zonder risico een overbodig requirement (als er niets gebeurt wanneer het er niet is of wanneer het foutief is, wat voegt dit requirement dan toe?) en is een risico zonder requirement een signaal dat het requirements development proces onvoldoende is uitgevoerd. Met deze overgebleven risico s en/of requirements dienen de betreffende stakeholders opnieuw aan de slag te gaan. Dit geheel is dus een iteratief proces. Om het testtraject beter te beheersen kunnen de de RRC s geclusterd worden in logische groepen (bijvoorbeeld: op basis van overeenkomstige Kwaliteitsattributen). Dit is in de tabel weergegeven met de rode cirkels. Dit is indicatief, en kan in praktijk alleen op deze manier (met cirkels) gebeuren als de risico s én de requirements gesorteerd worden op (hier) Kwaliteitsattributen! De RRC s dienen vervolgens een classificatie te krijgen op basis van de factoren impact en faalkans (zie ook paragraaf van de Handleiding Teststrategie). Dit kan per RRC worden uitgevoerd of per cluster indien er clusters worden gebruikt. Dit is afhankelijk van de projectfactoren (zoals bijv. tijd en geld) en van het antwoord op de vraag of dit toegevoegde waarde biedt. Op basis van de risicoclassificatie wordt vastgesteld welke testtechnieken worden gehanteerd. De testsoort en het betreffende aandachtsgebied bepalen op deze wijze de test specificatietechnieken die gebruikt kunnen worden. Door deze informatie uit te zetten in een tabel krijg je een overzicht van de RRC s, de eventuele clusters en de te gebruiken testtechnieken. Bijvoorbeeld: Risico/requirement combinaties Cluster Risico classificatie Testtechnieken

10 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 10 van ; 4.4; 5.2; 5.3; 6.2; 7.9; 7.11 Invoeren en muteren B Semantische test Berekenen A EVT Databewerking en verzending Geef een korte conclusie. Noem met name de meest risicovolle punten.

11 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 11 van 17 4 Testorganisatie 4.1 Rollen Geef aan per functie wie die functie vervult, eventueel van welke afdeling deze persoon afkomstig is, en zijn/haar inzet uitgedrukt in FTE. Functie Naam Afdeling Inzet (in FTE) Testmanager Testcoördinator <testsoort> Tester Taken en verantwoordelijkheden Hier worden per geïdentificeerde rol de taken en verantwoordelijkheden weergegeven, zowel op uitvoeringsniveau als op managementniveau. De beschikbaarheid van mensen in dit overzicht is specifiek toegespitst op het testtraject. Het aantal uur per week en per taak zijn gedetailleerde inschattingen. Rol Afdeling / Naam medewerker(s) Omschrijving taken en verantwoordelijkheden

12 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 12 van 17 5 Producten Vermeld hier de producten die vanuit het DTP worden opgeleverd. Onderstaande tabel is gevuld met voorbeelden. Verwijs vervolgens ook naar de planning (hoofdstuk 8) daar waar het gaat over het opleveren van mijlpaalproducten. Producten OG ON PM PL GO OT PG FO TO BE QA PB DB Detail Testplan Testscripts ST Testevaluatierapport... Legenda: R Review OG Opdrachtgever G Goedkeuring ON Opdrachtnemer K Kennisgeving PM Projectmanager PL Projectleider GO Gebruikersorganisatie OT Overall Testcoördinator Cluster PG Projectgroep FO Functionele ondersteuning TO Technische ondersteuning BE Beheer & Exploitatie QA QA-groep PB Project Bureau (DB) (Database administrator)

13 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 13 van 17 6 Infrastructuur Vermeld hier de globale infrastructuur welke nodig is voor het uitvoeren van de voorgenomen tests. Ook voor het totale project geldende afspraken dienen hier overgenomen te worden uit het MTP, en anders hier specifiek genoemd te worden. 6.1 Testomgeving Beschrijf hier de benodigde testomgevingen voor de applicaties, eventuele interfaces tussen de omgevingen, benodigde stubs en drivers, etc. 6.2 Hardware Indien er hardware nodig is (bijv. werkstations, stand alone PC s, servers, internet toegang, etc. vermeld dat hier. Geef duidelijk aan wat je nodig hebt, wie dit moet leveren, aan welke eisen het moet het voldoen, wanneer je het nodig hebt, etc. 6.3 Testtools Beschrijf in deze paragraaf welke testtools je gebruikt en waarom (denk aan tools voor automated testing, bevindingenregistratie, testmanagement, requirements management tool, etc.), wie het beheer van de tools verzorgt, eventuele licenties en daaraan verbonden kosten (vergeet niet deze mee te nemen in hoofdstuk 7), etc.

14 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 14 van 17 7 Begroting Maak hier de begroting op conform de standaards van de opdrachtgever. Deze begroting geldt voor de onderhanden testsoort, en dient de globale begroting uit het MTP in details uiteen te zetten.

15 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 15 van 17 8 Planning 8.1 Planning Neem in dit hoofdstuk de gedetailleerde planning op voor de onderhanden testsoort. Op basis van ervaringscijfers van SYSQA wordt de volgende verdeling van het totaal aantal uren van de planning / begroting voorgesteld: Fase Testplan Testvoorbereiding Testuitvoering Testafronding Totaal Tijdsplanning 10% uur 45% uur 40% uur 5% uur 100% uur Functionaris Functienaam Functienaam Functienaam doorlooptijd Fase Testplan Dagen/Uur Dagen\Uur Dagen\Uur Dagen\Uur Testvoorbereiding Dagen/Uur Dagen\Uur Dagen\Uur Dagen\Uur Testuitvoering Dagen/Uur Dagen\Uur Dagen\Uur Dagen\Uur Testafronding Dagen/Uur Dagen\Uur Dagen\Uur Dagen\Uur De bovengenoemde inspanning- en doorlooptijd planning geeft nog geen indruk van de feitelijke doorlooptijd van het traject welke van een aantal variabele (bijv.: testomgeving) afhankelijk is. Hiervoor kan door middel van de volgende GANTT chart inzicht gegeven worden: In week [x] wordt een start gemaakt met de testvoorbereiding en kan het volgende tijdschema als planning worden gebruikt: Week Fase Testplan Testvoorbereiding Testuitvoering Testafronding X X+1 X+2 X+3 X+4 X+5 X+6 X+7 X+8 Mijlpaal Datum Datum Datum Datum Bij bovengenoemde planning gaan we uit van een testomgeving welke wordt opgeleverd in week [x] zodat pre-tests uitgevoerd kunnen worden. Om de voortgang van het project te kunnen beoordelen zijn in de planning mijlpalen opgenomen. De vermelde mijlpalen zijn gebaseerd op inzichten welke op het moment van vervaardigen van het testplan aanwezig waren. Toekomstige veranderingen kunnen invloed hebben op de bovenstaande planning en mijlpalen. Indien noodzakelijk zal in overleg met de projectleider de gevolgen worden besproken en de mijlpaal worden aangepast.>

16 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 16 van 17 9 Projectbeheersing 9.1 Risico s en tegenmaatregelen Hieronder wordt een aantal risico s voor het testproject aangegeven. Bij elk risico wordt de consequentie en de oplossing of maatregel genoemd indien dit risico zich voor zou doen. Productrisico s zijn al in hoofdstuk 3.2 aan de orde gekomen, en dienen niet in onderstaand overzicht opgenomen te worden. Nr. Risico Consequentie Risico Klasse 1. Te late oplevering testobject 2. Kwaliteit testbasis Maatregelen Vertraging Hoog Mogelijkheid bekijken van deelopleveringen. Hierdoor ontstaat het risico dat bij oplevering van het geheel fouten in de delen ontstaan. Regressie testgevallen moeten (en kunnen) bij deelopleveringen als laatste worden uitgevoerd. Onvolledige testset (dekking niet optimaal) Laag Overwogen moet worden in hoeverre opstellers van blauwdrukken ingezet kunnen worden bij het opstellen van de testgevallen. Inzet materiedeskundigen voor het opstellen van testgevallen. 9.2 Voortgangsbewaking Geef hier aan hoe de voortgang wordt bewaakt. Denk daarbij aan zaken als: is er een uren registratie systeem, etc. 9.3 Rapportage Vermeld hier welke rapportages er gemaakt gaan worden, aangevuld met bijvoorbeeld: Indien in tussenliggende periodes zich zaken voordoen, waardoor de voortgang van het project wordt bedreigd, wordt met de testcoördinator afgestemd welke maatregelen worden genomen om vertraging te voorkomen c.q. tot het minimum te beperken. Soort rapportage Doel Frequentie Wie Voortgangsrapportage Geeft inzicht in de Wekelijks Testlead aan voortgang van de tests testmanager Eindrapportage Geeft de resultaten van 1x Testmanager het testtraject en advies. 9.4 Overlegstructuren Geef aan welke overlegstructuren er zijn voor het testteam. Soort overleg Doel Frequentie Wie Bevindingenoverleg Acties bepalen Dagelijks Testlead, beheer of bouw Testteamoverleg Stand van zaken Wekelijks Testmanager en Projectoverleg bespreken. Voortgang project overall bespreken testteam Wekelijks Projectleider bouw, projectleider business, testmanager

17 Organisatie Sjabloon detailtestplan op basis van SYSQA -teststrategieaanpak Pagina 17 van Bevindingenbeheer Vermeld hier hoe er met bevindingen omgegaan wordt. Verwijs naar de procedure. Vermeld indien noodzakelijk wie de prioriteit en de zwaarte van een bevinding bepaalt. Laat in ieder geval zaken opgenomen zijn als: - De resultaten van het testtraject worden vastgelegd in de testrapportages. - Afwijkingen in de respons van het systeem ten opzichte van de verwachting wordt vastgelegd in een bevindingenrapport. - In het bevindingenrapport wordt onder meer de urgentie vastgelegd. Om deze urgentie per bevinding te kunnen prioriteren is een verdeling gemaakt, namelijk: 1. Testblokkerende bevinding = testwerkzaamheden kunnen niet worden gecontinueerd, bijvoorbeeld de database functioneert niet naar behoren 2. Ernstige bevinding = testwerkzaamheden kunnen worden gecontinueerd het systeem kan met deze bevinding niet in productie 3. Kleine bevinding = het systeem werkt niet conform de testbasis, maar met een beperkt aantal van deze bevindingen kan in productie worden gegaan. Per bevinding wordt een duidelijke omschrijving van de afwijking gegeven. Hierin wordt o.a. gemeld in welke situatie de fout optreedt, wat de fout exact is en wat de verwachte respons van het systeem is. Bevindingen kunnen van allerlei aard zijn en kunnen betrekking hebben op: - De testbasis; - Het testobject (verschillen tussen specificaties en testresultaten); - De testomgeving (netwerkstoringen, computerstoringen, verkeerde versie software staat klaar, databestanden kloppen niet ); - De testspecificaties zelf (de eigen testgevallen zijn niet correct). De bevindingen worden naar gelang van hun urgentie regelmatig gerapporteerd aan de projectleider van het [naam] project. 9.6 Beheer testproducten Geef hier aan hoe het beheer van de testproducten geregeld is of moet worden. 9.7 Quality Assurance Beschrijf hier welke kwaliteitsmaatregelen er worden genomen worden tijdens het testtraject. Denk hierbij aan review van de testplannen, audits op testscenario s, etc.