Procesvisie op Maat. Op basis van het Master Test Plan wordt een gedetailleerd testplan voor elke fase opgesteld.

Transcriptie

1 Inleiding Doel In de discipline vindt de validatie van datgene wat binnen het project is gerealiseerd plaats. Dit bestrijkt het gebied van unittest tot en met acceptatie door gebruikers en beheerorganisatie. Hierbij wordt getoetst en getest of datgene wat wordt ontwikkeld voldoet aan de vooraf vastgelegde specificaties en acceptatiecriteria. Rollen Keyrollen binnen deze discipline zijn de Manager en Analist. De Manager is verantwoordelijk voor alle testactiviteiten binnen project en wordt hierbij ondersteund door de rollen Coördinator, Analist/Designer en er. De Analist heeft een inhoudelijke focus en analyseert, vanuit doelstellingen, acceptatie criteria, specificaties en oplossingsrichting, de te hanteren testdoelen, testvormen en testtechnieken en passende focus voor de verschillende testsoorten. Tevens ontwerpt de Analist de (test)scenario s en identificeert de te hanteren testgevallen ( Cases). Vanuit de analyse voedt de Analist de Manager voor het opstellen van de teststrategie en de omvang van de total test effort in het Master Plan. Vanuit de keyrollen kan de organisatorische voorbereiding van het testtraject worden uitbesteed aan een Coördinator. Identificatie en uitwerking van testgevallen kan desgewenst worden uitbesteed aan een Designer. Aanpak Op basis van de vastgestelde Vision wordt door de Manager een Master Plan (met daarin de teststrategie) opgesteld. Op basis van testdoelen die worden vastgesteld vanuit acceptatiecriteria en de aanpak van het project wordt een teststrategie vastgesteld. Het vaststellen van de teststrategie gebeurt iteratief vanuit een interactie tussen de verschillende disciplines Op basis van het Master Plan wordt een gedetailleerd testplan voor elke fase opgesteld. Dit testplan wordt geïntegreerd in het faseplan (Stage Plan) en beschrijft alle benodigde activiteiten in het kader van de voorbereiding en de uitvoering van de testen. Vanuit de faseplannen vindt de uitvoering van de testactiviteiten plaats. Hierbij wordt ook steeds een gedetailleerd testplan voor de volgende fase opgesteld. Steeds worden de testvoorbereiding en -uitvoering gerealiseerd om de toetsing uit te voeren die bij de betreffende fase gewenst is. De voorbereiding om de volgende fase te kunnen plannen wordt uitgevoerd. Resultaten van testen worden in een bevindingenadministratie vastgelegd op basis waarvan steeds testrapportages worden opgesteld. De bevindingen uit de test worden gerapporteerd aan de Manager, die de afstemming met andere keyrollen in het project verzorgt (System Analist, Project Architect en Project Manager). Diepgang De betrokkenheid van de discipline begint al in de Conception- en lnception-fase met het valideren van vastgestelde acceptatiecriteria en het op basis daarvan vaststellen van testdoelen. Dit geheel is in die fasen met name gericht op het vaststellen van strategie en omvang ten behoeve van een Master Plan. Indien noodzakelijk voor het bepalen van de omvang, wordt een analyse uitgevoerd en worden Scenario's vastgesteld. De strategie en omvang in het Master Plan dient ols input voor de Project Brief, PID en Product Acceptance Plan. Infocon Versie 0.1 Pagina 1 van 6

2 Daar waar een Proof of Concept wordt uitgevoerd, worden concrete testactiviteiten benoemd en opgenomen in het betreffende faseplan. Alhoewel dit binnen de kaders van een project meestal in Elaboration het geval is kan dit ook in Inception of zelfs Conception het geval zijn. In de volgende paragrafen wordt allereerst ingegaan op de taken en verantwoordelijkheden van de belangrijkste rollen binnen deze discipline. Vervolgens wordt nader ingegaan op de belangrijkste concepten en begrippen die binnen een rol spelen. Als laatste wordt de rol van in de diverse fasen nader beschreven Rollen Binnen deze discipline spelen de volgende rollen een belangrijke rol: Manager: Is verantwoordelijk voor planning, resourcing, aansturing en de testrapportage. Stelt het Master Plan (MTP) op en is namens de discipline verantwoordelijk voor de afstemming met andere disciplines. De Manager is tevens verantwoordelijk voor operationele aansturing van het testen, registratie van de bevindingen en het inrichten van de omgeving. Operationele taken in voorbereiding en aansturing worden doorgaans gedelegeerd aan een Coördinator die per aandachtsgebied of leverancier aangesteld kan worden. analist: Biedt ondersteuning bij het opstellen van teststrategie en bepalen van de testomvang. Voert de analyse uit van de specificaties, ontwerpt de test ( Scenario's) en identificeert de benodigde testgevallen (identificeren Cases). Designer: Ontwerpt testgevallen ( Cases) en maakt fysieke testgevallen. er: Voert testen uit en meldt bevindingen (logboek). Afhankelijk van het project kunnen rollen worden gecombineerd. In de praktijk worden de rollen Coördinator en Analist vaak gecombineerd binnen Change Management. Waar ervaren gebruikers (specialisten) worden ingezet, wordt ook vaak het maken van fysieke testgevallen uitbesteed aan de er Samenhang begrippen V-model Het V-model vormt een standaard uitgangspunt voor het testen binnen de procesvisie. In het V-model wordt nadrukkelijk uitgegaan van een verband tussen de mate van detaillering in de ontwikkeling van het systeem en de teststages (unittest, integratietest, systeemtest en acceptatietest). Samenhang deliverables Infocon Versie 0.1 Pagina 2 van 6

3 Op basis van een bepaald probleem of een wens wordt tijdens het traject een Visiondocument opgesteld. Dit document wordt vervolgens uitgewerkt in specificaties (SAD en SRS), waarna het betreffende systeem geïmplementeerd kan worden. Parallel aan dit ontwikkeltraject wordt er op basis van het Visiondocument en het PID een Product Acceptance Plan (PAP) opgesteld. Het Product Acceptance Plan (behorende bij de discipline Projectmanagement) beschrijft het wat en hoe van testen. Daarnaast beschrijft het Product Acceptance Plan het proces van acceptatie (werkwijze) en de criteria op basis waarvan zal worden geaccepteerd. De acceptatiecriteria worden vervolgens vertaald naar testdoelen en een teststrategie die wordt vastgelegd in het Master Plan. De teststrategie geeft zicht in de wijze waarop de verschillende stages worden ingevuld, de soorten tests die gaan worden uitgevoerd en de werkwijze. Daarmee ontstaat ook inzicht in de benodigde middelen en resources en wordt input geleverd voor het overall projectplan. Scenario's Binnen Use Cases worden Use Case Scenario's onderkend. Deze beschrijven de verschillende manieren (zowel goed ols fout situaties) waarop een taak kon worden doorlopen. Op basis van Use Case Scenario s worden Scenario's vastgesteld: welke scenario s worden allemaal doorlopen op basis van welke soort testgevallen ( Cases) om de correcte werking aan te tonen. Het analyseren van Use Cases vanuit scenario's vormt tevens een waardevolle toets op de juistheid/correctheid van de Use Case Specifications. Deze analyse en toets kan worden gestart op basis van globale specificaties zodra Use Case Scenario s duidelijk zijn geworden. cases Op basis van de analyse van Use Cases om Scenario's vast te stellen zijn soorten testgevallen geïndentificeerd. Op basis daarvan kunnen de testgevallen worden ontworpen en fysieke testgevallen worden uitgewerkt. Bij het ontwerpen van Cases worden behalve de Scenario s ook de (Use Case) Specifications gebruikt. Ook hier dient het ontwerpen van testgevallen als toets van de specificaties. soorten Unit- en Integratietesten hebben doorgaans meer een 'whitebox'-insteek; er wordt (ook) gekeken naar de interne werking van het systeem. Vanaf systeemtest krijgt de 'blackbox'-insteek de overhand, waarbij vanuit de buitenkant de correcte werking wordt getoetst. Infocon Versie 0.1 Pagina 3 van 6

4 Toelichting: Whitebox en blackbox. Bij een whitebox-test wordt bij het testen gebruik gemaakt van de kennis hoe het betreffende programma is gebouwd. De interne werking van de 'box' is bekend. Bij een Blackbox-test ligt de focus op het resultaat. Op basis van de gegeven input wordt de verwachte output vergeleken met de werkelijke output. De interne werking van de 'box' is niet bekend. Unit/programmatest. Deze test wordt binnen het project door de Ontwikkelaar van de programmatuur uitgevoerd. Het doel van deze test is het vaststellen of de betreffende unit correct werkt. Integratietest. Deze test wordt binnen het project uitgevoerd onder verantwoording van de Project Architect. Het doel van deze test is het vaststellen of een logische verzameling van units/programma's correct en conform design werkt. Systeemtest. Deze test wordt binnen het project onafhankelijk van de Ontwikkelaars en Architecten door testers uitgevoerd. Het doel van deze test is het vaststellen dat het systeem conform requirements correct werkt. Acceptatietest. Deze test wordt door de business (opdrachtgever) uitgevoerd. Het doel van deze test is het vaststellen dat het systeem aansluit op business processen. Bij deze test wordt ook aandacht besteed aan de uiteindelijke overdracht naar functioneel, applicatie en technisch beheer. omgevingen en vinden veelal in verschillende omgevingen plaats (OTAP-principe). De ontwikkel- en systeemtestomgeving worden gebruikt voor unit- en integratietesten. Dit vereist ook dat er meer mogelijkheden aanwezig en instelbaar zijn om in die omgeving de interne werking te monitoren. De acceptatietestomgeving is in principe een blackbox-omgeving. Bepaalde testvormen vragen een omgeving die productie-like is. Leverancier Klant Ontwikkelingomgeving. Dit is primair de omgeving waarin de software ontwikkeld en voor het eerst getest wordt (unit-test). Dit is de enige omgeving binnen het OTAP-principe waar veranderingen aan de software mogen worden aangebracht. In deze omgeving wordt de integratietest uitgevoerd. omgeving. Dit is de omgeving waarin het softwareproduct door SO en de opdrachtgever samen wordt getest op een goede functionele werking. Acceptatie-omgeving. In deze omgeving worden de Functionele Acceptatietest (FAT) en de Gebruikers Acceptatietest (GAT) uitgevoerd. De acceptatieomgeving is een zo natuurlijk mogelijke nabootsing van de productie-omgeving waarin het Infocon Versie 0.1 Pagina 4 van 6

5 volgende wordt getest: de opdrachtgever toetst of de software aan de door hem/hoor gestelde normen voldoet; de beheerorganisatie toetst of de software aan de door hen opgestelde normen voldoet. Productie-omgeving. Als de acceptatietest bewijzen dat het geteste product voldoet aan de eisen van de gebruikersorganisatie van de beheerorganisatie, wordt het product verplaatst naar de productieomgeving. Dit is de zogenaamde life-omgeving waarin daadwerkelijk door de gebruikersorganisatie met het product wordt gewerkt. vormen Binnen de hierboven benoemde testsoorten worden o.o. de volgende testvormen onderkend: Securitytest. Hierbij wordt getest of ongeautoriseerden toegang kunnen krijgen tot een systeem, een applicatie en de bijbehorende data. ln het bijzonder wordt gekeken welke acties bij eventuele ongeautoriseerde benadering op de data kunnen worden uitgevoerd. Op basis van de resultaten van deze test kan worden voorspeld wat eventueel de schade is die door ongeautoriseerd gebruik kan worden aangericht en kan worden beoordeeld of de rollen binnen de applicatie juist zijn ingericht (mag een ieder waarvoor hij/zij is geautoriseerd?) Performancetest. Hierbij wordt getest of de applicatie voldoet aan de performance eisen. Bij deze test is het van belang om met verschillende werkbelastingen te testen. Regressietest. Hierbij wordt getest of een wijziging in de programmatuur geen ongewenste neveneffecten teweegbrengt in andere delen van de applicatie. Dit kunnen zowel functionele als technische neveneffecten zijn. lnstallatietest. Hierbij wordt getest of de software middels het installatieprogramma kan worden geinstalleerd op de verschillende platforms die worden ondersteund zonder dat de functionaliteit geweld wordt aangedaan. GUI/User lnterfacetest. Hierbij wordt getest of de User lnterface voldoet aan de eisen die hieraan zijn gesteld. Documentatietest. Hierbij wordt getest of de documentatie voldoet aan de eisen die hieraan zijn gesteld en voldoende toegevoegde waarde heeft. Het gaat hierbij o.a. om online help, gebruikershandleidingen en installatiehandleidingen. Portabilitytest. Deze test focust zich op de diversiteit van de hardware en software waarop het systeem moet kunnen draaien en het gemak waarmee een systeem op een ander platform draaiend kan worden gemaakt. technieken Binnen de hierboven benoemde testvormen worden o.a. de volgende testechnieken onderkend: Grenswaardenanalyse. Dit is een testtechniek waarbij de overgangen in grenswaarden van bijvoorbeeld een invoerveld worden getest. Equivalentieklasse. Deze testtechniek richt zich op het testen van klassen van mogelijke invoerwaarden die leiden tot dezelfde verwerking of resultaat. Grafentechniek. Deze testtechniek wordt gebruikt om de routes door programma's en systemen te onderkennen en testen. Procescyclustest. Deze testtechniek heeft tot doel de inpasbaarheid van een geautomatiseerd deel van het informatiesysteem binnen de administratieve organisatie (AO)-procedures te controleren. Aanpak en diepgang De betrokkenheid van de testdiscipline kan al in de Conception-fase beginnen met het vaststellen van acceptatiecriteria en het uitvoeren van een eerste test bij het gebruik van nieuwe technologie. ln de volgende fase (lnception) wordt de overall teststrategie uitgewerkt in een Master Plan. Vonuit de -discipline valideren Manager (en Analist) de, in het Product Acceptance Plan vastgelegde, acceptatiecriteria en wordt een bijdrage geleverd aan de acceptatiestrategie die in het Product Acceptance Plan wordt vastgelegd. De verantwoordelijkheid voor het Product Acceptance Plan ligt bij de Project Manager. Het plan combineert acceptatiecriteria uit de Requirementsdisipline met invoeringsaspecten uit de Business Modeling discipline aangevuld met (acceptatie)testaspecten vanuit zowel gebruikers- als beheerinvalshoek. Infocon Versie 0.1 Pagina 5 van 6

6 Input voor het Master Plan zijn ook iteraties die gedurende het project worden gerealiseerd en waarvoor testactiviteiten worden uitgevoerd. Het Master Plan beslaat het gehele gebied van unittest tot en met acceptatie door gebruikers en beheer. Ook beslaat het de toetsing van gerealiseerde iteraties in Elaboration (of mogelijk al lnception). Naast het Master Plan wordt in de lnception-fase een detailtestplan voor de lnception- en Elaboration-fase opgesteld. Het testplan voor de lnception-fase richt zich met name op het prototype dat in deze fase wordt ontwikkeld. Ten aanzien van het prototype zijn de integratie- en systeemtest van belang, hetgeen niet betekent dat de unittest niet uitgevoerd hoeft te worden. De unittest is in de fase echter minder belangrijk. In de Elaboration-fase is de doelstelling om zoveel mogelijk inhoudelijke risico's te elimineren middels het realiseren van het systeemskelet. Dit betekent ten aanzien van het testen dat in deze fase met name de onderdelen die risico's met zich meebrengen uitgebreid worden getest. Deze risico's kunnen te maken hebben met de inzet van nieuwe technologie of functionele complexileit (bijvoorbeeld complexe berekeningen). ln de Elaboration-fase doorloopt het systeemskelet alle onderkende testsoorten (inclusief de acceptatietest). Naast het testen van het systeemskelet wordt in de Elaboration-fase ook een detailtestplan voor de Construction-fase opgesteld. ln de Construction-fase wordt het systeem verder in detail ontwikkeld en getest. Alle onderdelen worden getest waarbij het complete traject van unittest tot en met acceptatietest wordt doorlopen. Aan het einde van deze fase is het systeem door de opdrachtgever geaccepteerd. ln de laatste fase (Transition) zijn de testactiviteiten beperkt tot de acceptatietest, waarbij met name wordt gekeken naar performance. Infocon Versie 0.1 Pagina 6 van 6