Testservices Testsoorten, -vormen en -

Transcriptie

1 Testservices Testsoorten, -vormen en - processen Van Auteur Testservices Service Groep Standaards & technieken Kenmerk Versie 1.5 Datum Bestand TS Testprocessen 1.5 Status definitief

2 Inhoudsopgave 1 Inleiding WAU-testmodel Testvormen Unittesten (module testen) Unitintegratie-testen Subsysteem kwalificatietest (optioneel) Service Integratietest (optioneel) Functionele kwalificatietest of Systeem kwalificatietest Non-functionele tests (als onderdeel Systeem kwalificatietest) Regressietests (als onderdeel Systeem kwalificatietest) Validatietest Mega-integratietest Locatie Specifieke Test Gebruikers Acceptatie Test (GAT) Generieke testproces Fase Planning Fase Beheer Fase Inrichting en beheer infrastructuur Fase Voorbereiding Fase Specificatie Fase Uitvoering Fase Afronding Relatie met SEIN Testservices Testsoorten, -vormen en -processen Status: definitief x p.2 / 21 x

3 1 Inleiding Dit document geeft een overzicht van de gehanteerde testsoorten en vormen binnen ProRail en meer specifiek de testvormen die vallen onder de verantwoordelijkheid van Testservices. De testvormen worden hierbij geplaatst in de context van het totale systeemontwikkelingsproces van ProRail. Het proces van testen, inclusief deliverables, is generiek en is in een apart hoofdstuk beschreven. In het laatste hoofdstuk wordt de relatie tussen deze testvormen en -processen en het SEIN procesmodel beschreven. groep van dit document zijn personen die op een of andere manier bij het testen betrokken zijn, zoals testers, functioneel beheerders en projectmanagers. Bij de lezer wordt basiskennis verondersteld van testen en van de MIL-498 standaard. De aanpak is gebaseerd op de testmethode TMapNext. Testservices Testsoorten, -vormen en -processen Status: definitief x p.3 / 21 x

4 2 WAU-testmodel Het testproces en systeemontwikkelproces zijn nauw met elkaar verweven. De één levert de producten, die door de ander getoetst en getest worden. Binnen ProRail wordt de relatie tussen deze processen sinds 2013 gevisualiseerd in het zogenaamde WAU-testmodel, dat staat voor Waterval Agile United. In dit hoofdstuk wordt het WAU-model toegelicht. In het hoofdstuk erna worden de testvormen behandeld waarbij aangegeven wordt waaruit de testbasis voor een specifieke testvorm bestaat. Onderstaande schema toont het model. De betekenis van de kleuren is globaal als volgt, maar is bewust niet scherp afgekaderd, omdat de grenzen in de praktijk ook niet zo scherp zijn: Geel - ProRail architecten, ontwerpers, beheerders of andere ProRail onderdelen, in ieder geval buiten het werkgebied van TS. Roze - Leverancier / Eigen Ontwikkel Team Blauw - Testservices, Integrator Toelichting: Het WAU-testmodel begint linksboven met de fasen waarin het systeem wordt bedacht en ontworpen, van wens, wet, beleid, kans en/of probleem naar (globale) eisen, architectuur en ontwerp. Momenteel gebeurt dit hoofdzakelijk op sequentiële (waterval) wijze. Daarna wordt het systeem gerealiseerd (gebouwd), normaal gesproken door een leverancier (uitbesteding) en bij uitzondering door een Eigen Ontwikkel Team (EOT). Dit traject is weergegeven als een itererend proces waar vaak met de methode van scrum wordt gewerkt. In het model is een aantal van de belangrijkste activiteiten weergegeven Testservices Testsoorten, -vormen en -processen Status: definitief x p.4 / 21 x

5 (opstellen van gedetailleerde requirements of user stories, softwareontwerp, realisatie) met nadruk op de mogelijke testvormen die hierin toegepast kunnen worden. De acceptatietest wordt aangestuurd en uitgevoerd door Testservices. Na oplevering vanuit de leverancier aan de acceptatietest zijn ook hier een aantal mogelijke testvormen weergegeven. Ook de acceptatietest heeft een itererend karakter. Zo kan bijvoorbeeld worden afgesproken dat elke leveranciersoplevering (sprint) voor acceptatietesten wordt opgeleverd, of om de zoveel sprints, of alleen de laatste 2 of 3 sprints, of zelfs één keer helemaal tegen het einde. Dit onderscheid in (test)verantwoordelijkheden wordt in de praktijk vertaald in het groeperen van testactiviteiten in testsoorten, waarbij een testsoort staat voor een groep van testactiviteiten die gezamenlijk wordt uitgevoerd en aangestuurd. Deliverables van de verschillende testsoorten zijn de STP, STD en STR. Gezien bovenstaande zijn dus twee testsoorten te onderscheiden: het leverancierstesten en het acceptatietesten. Tests zoals unittesten, performancetesten, functionele (kwalificatie)testen, regressietesten, validatietesten zijn daarmee testvormen (=gericht op een of meer kwaliteitsaspecten) binnen één of beide testsoorten. Nu de keuze voor een agile ontwikkelingsaanpak steeds vanzelfsprekender wordt, moet de vraag worden gesteld of een separate acceptatietest(fase) nog wel nodig is. Immers, vanuit de agile/scrum gedachte worden alle ontwerp-, bouw- en testactiviteiten met zeer grote voorkeur uitgevoerd binnen de agile/scrum-teams zelf. Binnen ProRail is momenteel een separate acceptatietest nog wel de standaardregel, al mag hier beargumenteerd van af worden geweken. Belangrijkste redenen voor deze keuze zijn: o De acceptatietest wordt uitgevoerd in een representatieve testomgeving die bij ProRail staat en die niet aanwezig is bij de verschillende leveranciers. Deze omgeving staat onder beheer van ProRail (Testservices) en kan niet zomaar door projecten gebruikt worden om dingen uit te proberen o Testen van non-functionals (met name hoog-beschikbaarheid), testen van de keten van systemen en operationeel beheertesten zijn normaal gesproken erg belangrijk en vereisen een representatieve omgeving en specifieke kennis, die beide bij Testservices aanwezig zijn o De capaciteit van Testservices is onvoldoende om haar testers voor alle lopende projecten gedurende het hele agile/scrum-traject in te zetten bij deze teams. o De testeisen aan de leveranciertests zijn (momenteel) niet heel hoog en betreffen meestal enkel het opleveren van deliverables zoals testplan, -design en rapport. o Bij de leveranciers is minder systeem- en bedrijfskennis beschikbaar waardoor er een grotere kans is dat de kwaliteit in bepaalde aspecten onvoldoende is. Wegens onvoldoende capaciteit bij Testservices is dit niet op te heffen door inzet van haar testers op de teams. o Met veel leveranciers, veel projecten en veel scrum teams is de (test- en software)kwaliteit niet altijd even voorspelbaar. Een oordeel vanuit ProRail o Testservices blijft daarom belangrijk. Configuratiebeheer van de software en de omgevingen is niet altijd zoals het hoort, zodat het formeel overdragen naar de A-omgeving een test op zichzelf blijft. Na acceptatietesten vindt implementatie plaats. Ook dit heeft steeds vaker een itererend karakter, in de vorm van pilots, schaduwdraaien of daadwerkelijke (al of niet stapsgewijze) in-productie-name. Het model als totaal heeft ook een itererend karakter, om duidelijk te maken dat het traject doorlopen wordt om een release in productie te brengen, maar daarna vaak gelijk alweer start met een volgende release. Zowel bij de leverancierstests als bij de acceptatietests wordt nadrukkelijk gesteld dat de genoemde testvormen mogelijkheden zijn, maar niet per se voorgeschreven. De reden hierachter is om flexibiliteit in de totale testaanpak te verkrijgen. Als stelregel geldt dat des te vroeger iets getest kan worden, des te efficiënter dit is. Echter, dit is niet altijd mogelijk, bijvoorbeeld omdat de testomgeving niet representatief genoeg is, omdat het systeem nog niet volwassen genoeg is, of omdat getest moet worden met andere systemen, die niet Testservices Testsoorten, -vormen en -processen Status: definitief x p.5 / 21 x

6 beschikbaar zijn bij de leverancier. Ook kan het gewenst zijn vanuit risico- en efficiëntieoverwegingen bepaalde testvormen dubbel uit te voeren. Bijvoorbeeld een performancetest kan bij de leverancier worden uitgevoerd in een minder representatieve testomgeving om vroegtijdige signalen te ontdekken, terwijl een representatievere performancetest in de acceptatietest wordt uitgevoerd om zoveel mogelijk zekerheid te hebben dat er straks in productie geen problemen zullen ontstaan. Ook kan het gewenst zijn andere testvormen te hanteren dan de in het model genoemde voorbeelden. Dit is zonder meer toegestaan. Een speciale categorie vormen de tests die als gevolg van SIL-classificatie uitgevoerd moeten worden, zoals bijvoorbeeld een Factory Acceptance Test. De SIL-classificatie stelt voornamelijk eisen aan (de onafhankelijkheid van) de partij die de test uitvoert. Daarom moet goed worden nagedacht over welke partij (leverancier of acceptanten) de test uitvoert, aangezien deze aan de SIL-eisen moet voldoen. Om over het gehele ontwikkel-/ testtraject efficiënt te kunnen testen, is flexibiliteit in de keuze van welke testvormen wanneer worden toegepast noodzakelijk. Maar tevens moet geborgd worden dat uiteindelijk (bij het in productie gaan) de kwaliteitsattributen de testaandacht gehad hebben die de stakeholders noodzakelijk achten. Daarom is aansturing van de keuze van testvormen via een mastertestplan essentieel. TS voert de regie over het opstellen en bewaken van het mastertestplan. De 4RR figuren staan voor momenten waarop 4 Richtingen Reviews uitgevoerd moeten worden. Dit zijn reviews waarbij verschillende rollen een deliverable vanuit 4 richtingen beoordelen: o Omhoog: Voldoet het aan normen, standaarden, referentie-architectuur? o Links: Is het consistent met andere documentatie (in dezelfde laag/fase)? o Rechts: Is het bruikbaar (voor gebruikers)? o Omlaag: Is het (ontwerpbaar), bouwbaar, testbaar, implementeerbaar? Rollen zijn bijvoorbeeld architect, ontwerper, ontwikkelaar, tester, QA. Het model geeft een aantal voorbeelden van deliverables (PSA, STP, STD, STR) maar probeert vooral niet volledig te zijn en legt nadruk op testdeliverables. Bij scrum wordt veel gebruik gemaakt van een Definition of Done (DoD), waarin staat wat allemaal opgeleverd en uitgevoerd moet zijn voordat een sprint klaar ( done ) is. Dit is een goede kapstok om eisen aan leverancierstesten aan op te hangen. In blauw zijn tenslotte de partijen getekend die globaal verantwoordelijk zijn voor de verschillende fasen en activiteiten. Testservices Testsoorten, -vormen en -processen Status: definitief x p.6 / 21 x

7 3 Testvormen De in het WAU-testmodel genoemde testvormen worden in deze paragraaf toegelicht. De (naamgeving van de) testvormen is deels conform MIL-standaard en conform Testservices. Per testvorm is vermeld: Wat is het doel van de test, waarom wordt deze uitgevoerd, wat moet de test aantonen Welke partij heeft welke verantwoordelijkheden. Hierbij is (conform de RACI-matrix) onderscheid gemaakt in: R (Responsible) - Degene(n) die het werk doet/doen. Verantwoording wordt afgelegd aan de persoon die accountable is. A (Accountable) - Degene die (eind)verantwoordelijk, bevoegd is. Als het erom gaat, moet hij/zij het eindoordeel kunnen vellen, veto-recht hebben. 1 Bij deze verantwoordelijkheden moet benadrukt worden dat dit om verantwoordelijkheden voor het testproces gaat. Het is heel goed mogelijk dat een test wordt uitgevoerd onder verantwoordelijkheid van Testservices en dat op basis van de testresultaten een andere partij, zoals Projectmanagement, Functioneel Beheer of Implementatie, besluit om de geteste software niet naar de volgende fase te laten gaan. Dit zegt niets over de kwaliteit van de test, hoogstens wat over de kwaliteit van het testobject. Testbasis Bijzonderheden Ook wordt vermeld welke relevante partijen betrokken zijn, zoals eindgebruikers. De testbasis is de informatie die het gewenste systeemgedrag definieert. Op basis van deze informatie kunnen tests ontworpen en uitgevoerd worden. Normaal gesproken heeft een testvorm de tussenproducten van de corresponderende bouwfase als testbasis. 3.1 Unittesten (module testen) In MIL beschreven onder 5.7 Software implementation and unit testing. Verifieert de correcte werking van geïsoleerde software units / modules Leverancier (ontwikkelaar) (RA) Testbasis SDD,DBDD, IDD Bijzonderheden Bij ontwikkelen onder Service Oriented Architecture (SOA) is deze test grotendeels geautomatiseerd (xunit frameworks, continuous integration). 3.2 Unitintegratie-testen In MIL beschreven onder 5.8 Unit integration and testing. Verifieert of de software units / modules correct met elkaar samenwerken Ontwikkelaar (RA) 1 Overige RACI-termen zijn C (Consulted) en I (Informed). Deze zijn hier niet verder uitgewerkt. Voor uitleg van RACI wordt verwezen naar Testservices Testsoorten, -vormen en -processen Status: definitief x p.7 / 21 x

8 Testbasis SDD,DBDD, IDD Bijzonderheden Zie unittesten 3.3 Subsysteem kwalificatietest (optioneel) In MIL beschreven onder 5.9 CSCI qualification testing. De test wordt uitgevoerd op het zelfstandige subsysteem zonder dat nog sprake is van een systeem vanuit gebruikersoogpunt. Het testen van bijvoorbeeld non-functionals kan hier ook plaatsvinden. Deze testvorm is optioneel en wordt met name uitgevoerd wanneer er meerdere leveranciers van subsystemen zijn, wanneer de subsystemen complex zijn, of wanneer er speciale eisen aan subsystemen gesteld worden, zoals bij SOA. Bij SOA wordt in plaats van subsysteem ook wel de term service-component gebruikt. Verifieert of het subsysteem voldoet aan de specificaties (requirements en service-contracten, zoals software requirements specifications (SRSs) en bijbehorende interface requirements specifications (IRSs)). Testbasis Leverancier (R) ProRail (A) SRS, IRS subsystemen Bijzonderheden Voorgestelde organisatievorm Dit is de organisatievorm waar TS de voorkeur voor heeft. Een alternatief zou bijvoorbeeld kunnen zijn dat ProRail de gehele opzet en uitvoering van de kwalificatietest voor haar rekening neemt: a) Subsysteem kwalificatietest leverancier Het testen van het subsysteem om te demonstreren dat dit voldoet aan de specificaties. Het testteam is onafhankelijk van de ontwikkelaars. Werkwijze en deliverables zijn overeengekomen met en gecontroleerd door ProRail. b) Subsysteem kwalificatietest Testservices Belangrijkste taak is het voorschrijven/monitoren/controleren van de voorgaande Subsysteem kwalificatietest leverancier. Optioneel en afhankelijk van risico: kleine demonstratietest op de ProRail-omgeving. Met grote voorkeur draagt de leverancier een geautomatiseerde regressietest over. Specifiek voor SOA is dat een servicecomponent aan de buitenkant testbaar is op 3 manieren: 1) Testen van de MMI-dialogen die de service component levert 2) Testen van de leverende Services (de providing rol) 3) Testen van het gebruik van Services (de consuming rol) Binnen SOA is sprake van een mediator, ook wel de bus genaamd. Deze mediator is op zichzelf ook als service-component te beschouwen en moet ook dienovereenkomstig getest worden. Wel gelden hiervoor een aantal afwijkingen. De mediator bestaat grotendeels uit te parametriseren standaard software. Het grootste risico op fouten voor de mediator zit in de parametrisering van de communicatie met de aanhangende servicecomponenten. Om de mediator als op zichzelf staande component te testen, zou voor elke aanhangende service-component een simulator gebouwd moeten worden. Dit is kostbaar en tijdrovend, hoewel tools als Greenhat hier soelaas kunnen bieden. Het is in de praktijk handiger om de mediator te testen met de echte (en gekwalificeerde) service-componenten, die daarmee feitelijk de taak van de simulatoren overnemen. Testservices Testsoorten, -vormen en -processen Status: definitief x p.8 / 21 x

9 3.4 Service Integratietest (optioneel) In MIL beschreven onder 5.10 CSCI/HWCI integration and testing. Uitvoering van deze test is afhankelijk van het risico (in het begin en/of bij nieuwbouw: zeker uitvoeren). Testbasis Bijzonderheden Verifieert of het samenstel van subsystemen (op niveau systeem ) correct werkt. Nadruk ligt op testen van integratie. Integrator (RA) De integrator voert de test uit, waarbij onderliggende servicecomponenten van verschillende leveranciers afkomstig kunnen zijn. De rol van integrator kan door een (hoofd)leverancier ingevuld worden, maar zal in onderhoudssituaties vermoedelijk ook vaak ProRail zijn, omdat het door een leverancier opgeleverde subsysteem ingepast moet worden in een bestaand landschap van subsystemen, afkomstig van diverse leveranciers SSDD, IRS subsystemen 3.5 Functionele kwalificatietest (als onderdeel Systeem kwalificatietest) In MIL beschreven onder 5.11 System qualification testing. Verifieert of het systeem, als samenstel van subsystemen, voldoet aan de specificaties (requirements in system/subsystem specifications (SSSs) en bijbehorende interface requirements specifications (IRSs)). Testbasis Leverancier (R) Testservices (A) SSS, SRS, IRS externe systemen, IRS subsystemen Bijzonderheden Voorgestelde organisatievorm: Dit is de organisatievorm waar TS de voorkeur voor heeft. Een alternatief zou bijvoorbeeld kunnen zijn dat ProRail de gehele opzet en uitvoering van de kwalificatietest voor haar rekening neemt: 1) Systeem kwalificatietest leverancier Het testen van het systeem om te demonstreren dat dit voldoet aan de specificaties. Het testteam is onafhankelijk van de ontwikkelaars. Werkwijze en deliverables zijn overeengekomen met en gecontroleerd door ProRail. 2) Systeem kwalificatietest ProRail Belangrijkste taak is het voorschrijven/monitoren/controleren van de voorgaande Systeem kwalificatietest leverancier. Daarnaast wordt een demonstratietest uitgevoerd in ProRail-omgeving en vindt een geautomatiseerde regressietest plaats (bij voorkeur gebruikmakend van geautomatiseerde tests van leveranciers). De grondigheid van deze test is afhankelijk van het risico (in het begin en/of bij nieuwbouw: grondiger uitvoeren, bijvoorbeeld op basis van (hoog-niveau) use cases). 3.6 Non-functionele tests (als onderdeel Systeem kwalificatietest) In MIL beschreven onder 5.11 System qualification testing. Testservices Testsoorten, -vormen en -processen Status: definitief x p.9 / 21 x

10 Testbasis Verifieert of het systeem, als samenstel van subsystemen, voldoet aan de non-functionele specificaties (requirements in system/subsystem specifications (SSSs) en bijbehorende interface requirements specifications (IRSs)). Leverancier (R) + Testservices (A) en/of Testservices (RA) SSS, IRS externe systemen, IRS subsystemen Bijzonderheden Testen op bijvoorbeeld robuustheid of performance. Waar deze tests het meest zinvol uitgevoerd kunnen worden is een balans tussen enerzijds de voorkeur om de tests zo vroeg mogelijk uit te voeren, dus bij leverancier, en anderzijds de gewenste representativiteit van de testomgeving, wat vaak de modelpost zal zijn. Overigens hoeft er niet per se gekozen te worden, maar kan ook bij beiden getest worden. Verantwoordelijk: Leverancier en/of Acceptatietest 3.7 Regressietests (als onderdeel Systeem kwalificatietest) In MIL beschreven onder 5.11 System qualification testing. Testbasis Verifieert of het systeem, als samenstel van subsystemen, voldoet aan de specificaties (requirements in system/subsystem specifications (SSSs) en bijbehorende interface requirements specifications (IRSs)). Leverancier (R), Testservices (A) SSS, SRS, IRS externe systemen, IRS subsystemen Bijzonderheden De (bij voorkeur geautomatiseerde) Regressietest helpt om te borgen dat het systeem tijdens alle sprints geen regressie gaat vertonen. Overigens zijn regressietests bij voorkeur ook een onderdeel van de acceptatietest. 3.8 Validatietest Testbasis Bijzonderheden Valideert of de systeemfunctionaliteit werkbaar is in het beoogde werkproces. De VT is bedoeld voor nieuwe functionaliteit en nieuwe werkprocessen. Testservices (RA), met betrokkenheid van (vertegenwoordigers van) eindgebruikers en (functionele en/of applicatie en/of operationele) beheerders SSS, IRS externe systemen, OCD, (bestaande) Beheerprocedures, Project Brief, Processen (nieuw) 3.9 Mega-integratietest Valideert of het systeem correct werkt in samenhang met andere ProRailsystemen (zoals bijvoorbeeld die van Post21) en met externe systemen Testservices (RA), met betrokkenheid van (vertegenwoordigers van) eindgebruikers en functioneel beheerders Testservices Testsoorten, -vormen en -processen Status: definitief x p.10 / 21 x

11 Testbasis Bijzonderheden SSS, IRS externe systemen, OCD, (bestaande) Beheerprocedures, Project Brief, Processen (nieuw en oud), huidige productierelease 3.10 Locatie Specifieke Test Testbasis Bijzonderheden Valideert of het systeem ook nog steeds correct werkt met de specifieke configuratie van de pilot post, waar de Acceptatie Test wordt uitgevoerd. Testservices (RA), met betrokkenheid van applicatiebeheerders en operationele beheerders SSS, IRS externe systemen, OCD, (bestaande) Beheerprocedures, Project Brief, Processen (nieuw en oud), huidige productierelease 3.11 Gebruikers Acceptatie Test (GAT) Verifieert of het systeem bruikbaar is voor (eind)gebruikers en beheerders. (Eind)gebruikers en beheerders (R), Testservices (RA) Testbasis SSS, IRS externe systemen, OCD, (bestaande) Beheerprocedures, Project Brief, Processen (nieuw en oud), huidige productierelease Bijzonderheden Deze test kan onderdeel zijn van de validatietest of kan apart ingericht worden. Testservices Testsoorten, -vormen en -processen Status: definitief x p.11 / 21 x

12 4 Generieke testproces De onder TS vallende testvormen (VT, MIT en LST) hebben weliswaar allemaal andere doelen en andere organisatie, maar hanteren wel hetzelfde generieke proces. Dit proces is gebaseerd op TMap. Om die reden is het maar beperkt uitgewerkt en ligt de focus voornamelijk op de zaken die specifiek voor ProRail zijn. Voor een uitgebreide beschrijving van de activiteiten wordt verwezen naar het boek TMap Next 2. Binnen TMap zijn de testactiviteiten verdeeld over een zevental fasen (zie onderstaande figuur TMap faseringsmodel ). Dit zijn de fasen Planning, Beheer, Inrichting en beheer infrastructuur, Voorbereiding, Specificatie, Uitvoering en Afronding. Figuur TMap faseringsmodel De fasen hoeven niet altijd geheel sequentieel te worden uitgevoerd. Het is bijvoorbeeld heel goed mogelijk dat testgevallen voor een deel van de test nog gespecificeerd worden (fase Specificatie), terwijl de testuitvoering (fase Uitvoering) voor een ander deel van de test al is gestart. Binnen agile/scrum zijn de fasen niet expliciet te herkennen. Wel moeten de activiteiten binnen de fasen dan herkenbaar binnen de agile/scrum aanpak aan bod komen. Per fase wordt aangegeven: van de fase ProRail specifieke aandachtspunten ten opzichte van standaard TMap De uit te voeren activiteiten Deliverables Technieken / tools / overige hulpmiddelen De beschreven verwijzingen zijn ter indicatie en niet meer dan een momentopname. Het extranet bevat de actueel beschikbare informatie. 2 TMap Next voor resultaatgericht testen, 1ste druk, 2006, Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon, Uitgeverij Tutein Nolthenius, Den Bosch, Nederland ISBN: TMap is een geregistreerd handelsmerk van Sogeti B.V. Testservices Testsoorten, -vormen en -processen Status: definitief x p.12 / 21 x

13 4.1 Fase Planning Het formuleren van een samenhangende en gedragen aanpak waarmee de testopdracht goed uitgevoerd kan worden. Een belangrijk onderdeel van de planning is het opstellen van het (master)testplan, om de opdrachtgever en andere betrokkenen te informeren over de aanpak, planning, begroting, activiteiten en de op te leveren (eind)producten met betrekking tot het testproces ProRail specifieke aandachtspunten Binnen ProRail wordt dezelfde template gebruikt voor zowel een mastertestplan als een detailtestplan. Het mastertestplan omvat als regel de leverancierstest en de acceptatietest. Een mastertestplan heeft vaak voldoende detail om afzonderlijke testplannen per testsoort overbodig te maken. Alleen als dat niet het geval is, dient de testmanager later alsnog detailtestplannen op te stellen. Een ander aandachtspunt voor de testmanager is dat deze zowel een relatie heeft naar de projectmanager als naar de manager van TS. Afhankelijk van de contractvorm tussen TS en het project (detachering of resultaatverantwoordelijk) is de projectmanager of de TS-manager als primaire opdrachtgever te beschouwen. Een belangrijk onderdeel van het plan is de afstemming met andere betrokkenen, zowel wat betreft planning als benodigde resources. Voorbeelden hiervan zijn: Inzet van eindgebruikers, functionele en operationele beheerders in het testtraject; Ondersteuning vanuit systeemontwikkeling of infrastructuurbeheer; Reviewen van testproducten door diverse partijen Betrokkenheid bij het opstellen van de productrisicoanalyse en teststrategie: projectmanager, ontwikkelaars, beheerders, BNS, eindgebruikers, securitymanager, implementatiemanager, enzovoort Activiteiten Het opstellen van het testplan omvat de volgende activiteiten: 1. Vaststellen opdracht; 2. Oriënteren opdracht; 3. Bepalen testbasis; 4. Analyseren productrisico s; 5. Bepalen teststrategie; 6. Bepalen begroting; 7. Bepalen planning; 8. Toewijzen testeenheden en testtechnieken; 9. Definiëren testproducten; 10. Definiëren organisatie; 11. Definiëren infrastructuur; 12. Inrichten beheer; 13. Bepalen testprojectrisico s en maatregelen; 14. Terugkoppelen en fixeren plan Deliverables Software Test Plan (STP, voor één of meerdere testsoorten) Testservices Testsoorten, -vormen en -processen Status: definitief x p.13 / 21 x

14 4.1.5 Technieken / tools / overige hulpmiddelen Template STP QRC002 PRL26 MIT Opzetten QRC006 PRL26 MIT - Mega Integratie Test Default TS bevindingenadministratie Checklist Kwaliteitsattributen 4.2 Fase Beheer Het aan de opdrachtgever geven van voldoende inzicht in én sturingsmogelijkheden over: - de voortgang van het testproces, - de kwaliteit en risico s van het testobject - de kwaliteit van het testproces. Hiervoor dient de testmanager het testproces op optimale wijze te beheersen en hierover te rapporteren ProRail specifieke aandachtspunten De testmanager rapporteert zowel aan projectmanager als aan TS-manager, waarbij één van beiden de primaire opdrachtgever is. Binnen TS worden KPI s bijgehouden, waarvoor de testmanager gegevens moet aanleveren Activiteiten Het beheer van het testproces omvat de volgende activiteiten: 1. Uitvoeren beheer; 2. Bewaken; 3. Rapporteren; 4. Bijsturen Deliverables Software Test Tussenrapport (STTr, periodiek, bijvoorbeeld maandelijks, op te leveren) Vrijgaveadvies (optioneel, indien er veel tijd tussen einde testuitvoering en opstellen STR zit) Software Test Report (STR) Technieken / tools / overige hulpmiddelen Template STTr Template Vrijgaveadvies (optioneel) Template STR PVCS 4.3 Fase Inrichting en beheer infrastructuur Het beschrijven, realiseren en beheren van de testinfrastructuur die wordt gebruikt bij de verschillende fasen en activiteiten binnen TMap. Testservices Testsoorten, -vormen en -processen Status: definitief x p.14 / 21 x

15 De testinfrastructuur bestaat uit de faciliteiten en middelen die nodig zijn om de test adequaat te kunnen uitvoeren. Er wordt onderscheid gemaakt tussen de faciliteiten voor testuitvoering (testomgevingen), voor de ondersteuning van het testen (testtools) en voor het dagelijkse werk van de testers (werkplekken) ProRail specifieke aandachtspunten Het inrichten en beheren van een testomgeving, met name de modelpost, is een activiteit die veel aandacht vraagt. Projecten lopen vaak uit op de planning, waardoor reserveringen mislopen, inrichten van een testomgeving met een bepaalde configuratie kost (doorloop)tijd, evenals het maken van backups. Hoewel de modelpost zo representatief mogelijk is voor productie, is het daarmee nog niet gelijk aan productie. Bepaalde situaties, zoals veel drukte op het systeem of treinverkeer over posten heen, zijn slechts met beperkingen te simuleren in de testomgeving. Configuraties van bepaalde posten kosten tijd om te verkrijgen en zijn niet altijd actueel of consistent Activiteiten De basis voor de fase Inrichting en beheer infrastructuur wordt gelegd in de fase Planning. Hier wordt in de activiteit Definiëren infrastructuur een beschrijving gemaakt van de benodigde infrastructuur op overkoepelend niveau, inclusief planning. Deze beschrijving (uit het mastertestplan of testplan) dient als input voor de eerste activiteit in deze fase. De fase Inrichting en beheer infrastructuur bestaat uit de volgende 6 activiteiten: 1. Specificeren infrastructuur; 2. Realiseren infrastructuur; 3. Specificeren intake infrastructuur; 4. Intake infrastructuur; 5. Beheren infrastructuur; 6. Conserveren infrastructuur Deliverables Ingerichte en beheerde testomgeving (vaak op de modelpost) Ingerichte en beheerde testtooling Ingerichte kantoorinfrastructuur Technieken / tools / overige hulpmiddelen QRC inrichting modelpost LCM Testtools GreenHat QualityCenter PVCS (inrichting default TS bevindingenadministratie) Testservices Testsoorten, -vormen en -processen Status: definitief x p.15 / 21 x

16 4.4 Fase Voorbereiding Het kunnen beschikken over een, met de opdrachtgever van de test overeengekomen, testbasis die voldoende van kwaliteit is voor het ontwerpen van de testgevallen. Voor het bepalen hiervan wordt in deze fase de detailintake van de testbasis uitgevoerd. Bij ProRail wordt de detailintake als onderdeel van de formele review van de testbasis uitgevoerd. Deze fase geeft inzicht in de testbaarheid van het systeem. Naast vaststellen van testbaarheid van de testbasis is er nog een andere belangrijke reden voor de beoordeling van de testbasis: het in een vroegtijdig stadium van het ontwikkelings- en testproces vinden van potentieel kostbare fouten ProRail specifieke aandachtspunten Het beoordelen van de testbasis vindt plaats als onderdeel van de formele review van de testbasis. Afhankelijk van de testsoort betreft dit andere tussenproducten. Omdat de activiteiten onderdeel zijn van het formele review-traject, wordt normaal gesproken geen apart detailintake-rapport opgesteld. Indien nodig worden trends of adviezen ( De tussenproducten zijn nog niet geschikt om als testbasis te dienen, wegens... ) in de STTr gecommuniceerd. De fase Voorbereiding start bij het ter review opleveren van het tussenproduct dat als testbasis dient voor de betreffende testsoort. Dit vindt met grote voorkeur plaats voor de start van de bouw van de software Activiteiten De fase Voorbereiding bestaat uit de volgende activiteiten: 1. Verzamelen testbasis; 2. Opstellen checklists; 3. Beoordelen testbasis; 4. Opstellen rapport detailintake (optioneel) Deliverables Reviewcommentaar op testbasis Samenvattend advies over de geschiktheid van de testbasis voor testen (onderdeel van de STTr) Technieken / tools / overige hulpmiddelen QRC Overzicht review procedure Review Planning Formulier (RPF) template Review Commentaar Formulier (RCF) template Review Instructie Formulier (RIF) template 4.5 Fase Specificatie Het specificeren van de benodigde tests en uitgangssituatie(s). Het doel is zoveel mogelijk voorbereid te hebben om de testuitvoering zo snel mogelijk te laten verlopen wanneer de ontwikkelaars het testobject opleveren. Testservices Testsoorten, -vormen en -processen Status: definitief x p.16 / 21 x

17 4.5.2 ProRail specifieke aandachtspunten De koppeling tussen enerzijds de teststrategie en geselecteerde testvormen en technieken uit het STP en anderzijds de uitwerking hiervan in het STD moet transparant en verklaarbaar zijn. Binnen het ProRail IT-landschap zijn veel tests gericht op technische aspecten in plaats van op functionaliteit. Een traceerbaarheidsmatrix tussen testbasis (bijvoorbeeld requirements) en testgevallen is vanuit oogpunt van herbruikbaarheid en onderhoudbaarheid sterk aan te raden. Indien de testbasis nog instabiel is of de testconfiguratie nog onbekend is, kan ervoor gekozen worden om de testgevallen minder gedetailleerd uit te werken, bijvoorbeeld enkel op logisch niveau, of nog hoger, enkel op testsituatie-niveau. Keerzijde van deze keuze is de langere doorlooptijd tijdens de fase Uitvoering. Als uitgangssituatie voor de test is vaak een bepaalde configuratie nodig (post Amersfoort, Amsterdam,...). De tester maakt hierin een keuze. De testinfrastructuurcoördinator (vaak de testmanager) regelt vervolgens dat dit op de testomgeving geïnstalleerd wordt Activiteiten Binnen de fase Specificatie worden de volgende activiteiten onderkend: 1. Opstellen testspecificaties; 2. Definiëren centrale uitgangssituatie(s); 3. Specificeren intake testobject; Deliverables Software Test Description (STD) Technieken / tools / overige hulpmiddelen STD template QRC Detailleringgegevens uit Globe halen QRC Configuratiebestanden verkrijgen QRC Opzetten van een STD voor de VT Traceability matrix 4.6 Fase Uitvoering Het verkrijgen van inzicht in de kwaliteit van het testobject door het uitvoeren van de afgesproken tests ProRail specifieke aandachtspunten Aan de volgende voorwaarden dient te zijn voldaan alvorens kan worden gestart met de fase Uitvoering: Het testobject, of een afzonderlijk testbaar deel van het testobject, moet conform gemaakte kwalitatieve afspraken opgeleverd zijn; Testservices Testsoorten, -vormen en -processen Status: definitief x p.17 / 21 x

18 Het STD voor de uit te voeren test moet beschikbaar zijn; Van de bijbehorende testinfrastructuur, inclusief configuratie, moet de intake succesvol zijn verlopen. Aan (de oplevering van) het testobject dienen ook kwalitatieve eisen gesteld te worden, zogenaamde entry-criteria. Hierbij kan men denken aan voorwaarden zoals een maximaal aantal openstaande bevindingen (van bepaalde prioriteit), eisen aan de door leverancier uitgevoerde tests en op te leveren testproducten (STP, STD, STR) of aan een succesvolle demonstratietest door leverancier in ProRail testomgeving. Controle op het voldoen aan deze eisen vindt plaats tijdens activiteit Intake testobject. In de ProRail praktijk zijn er vaak problemen met de combinatie van testobject op testinfrastructuur Activiteiten Binnen de fase Uitvoering worden de volgende activiteiten onderkend: 1. Intake testobject; 2. Klaarzetten uitgangssituatie; 3. Uitvoeren (her)tests; 4. Controleren en beoordelen testresultaten Deliverables STD (bijgewerkt) Technieken / tools / overige hulpmiddelen QRC Test Readiness checklist 4.7 Fase Afronding Het leren van de ervaringen die zijn opgedaan in deze test; Het conserveren van testware om bij een volgende test deze te kunnen hergebruiken ProRail specifieke aandachtspunten Onderdeel van de evaluatie kunnen ook de gebruikte hulpmiddelen zijn, zoals tools, templates, procedures en QRC s. Feedback op deze hulpmiddelen kan aan de betreffende Servicegroepen teruggekoppeld worden. Daarnaast kunnen geslaagde voorbeelden van testdeliverables op het extranet worden gezet. Het conserveren van testware vindt met name plaats door actualisering van het STD. Testservices heeft nog geen centrale registratie en beheer van testware ingericht,hergebruik van testware vindt daarom momenteel nog weinig plaats Activiteiten De fase Afronding bestaat uit de volgende activiteiten: 1. Evalueren testproces; Testservices Testsoorten, -vormen en -processen Status: definitief x p.18 / 21 x

19 2. Conserveren testware Deliverables STD (bijgewerkt) Technieken / tools / overige hulpmiddelen N.v.t. Testservices Testsoorten, -vormen en -processen Status: definitief x p.19 / 21 x

20 5 Relatie met SEIN Werkgroep SEIN heeft een "V" model TRACKs opgesteld waarvoor ook TS input heeft gegeven. Het totale systeemontwikkelingsproces wordt in TRACKS weergegeven in stages, met per stage diverse deliverables. In onderstaande tabel zijn de deliverables vanuit testen gerelateerd aan bovenstaande testvormen en generieke proces. TRACKS test deliverable Teststrategie en eisen gereed TRACKS Testvormen stage 1 Bij voorkeur alle, maar tenminste KT, VT, MIT, LST Mastertestplan gereed 2 Bij voorkeur alle, maar tenminste KT, VT, MIT, LST Requirements cfrm testeisen gereed Op testbaarheid gevalideerd ontwerp Detail testplannen KT, VT, MIT, LST gereed Generieke proces, fase(n) Fase Planning, met teststrategie en -eisen als onderdeel van een concept mastertestplan Fase Planning, met als deliverable het definitieve mastertestplan 2 (KT), VT, MIT, LST Fase Voorbereiding* 3 KT, VT, MIT, LST Fase Voorbereiding* 3 KT, VT, MIT, LST Fase Planning, de detailtestplannen VT/MIT/LST kunnen geïntegreerd zijn in het mastertestplan Kwalificatie test akkoord 4 KT Fase Specificatie t/m Testuitvoering Bouw cfrm testeisen akkoord Test Ontwerpen VT, MIT, LST gereed Afronding* 4 KT Fase Uitvoering (intake)* 4 VT, MIT, LST Fase Specificatie* Testuitvoering VT, MIT, LST incl. rapportage gereed 5 VT, MIT, LST Fase Uitvoering t/m Afronding* * Tijdens deze primaire fasen vinden ook activiteiten plaats in de ondersteunende fasen Beheer en Inrichting & Beheer Infrastructuur. Testservices Testsoorten, -vormen en -processen Status: definitief x p.20 / 21 x

21 Colofon Testservices Testsoorten, -vormen en -processen TS-TSTPROC Versie/Datum 1.5/ Status definitief Titel Documentnummer ProRail ICT-Services Service Groep Standaards & technieken Bob Harnisch Testservices Document TS Testprocessen 1.5 Van Auteur Projectleider Distributie Autorisatie paraaf datum Gecontroleerd prl goedgekeurd/vrijgegeven prm Testservices Testsoorten, -vormen en -processen Status: definitief x p.21 / 21 x