TESTING POLICY. Van Caneghem Wouter Functionele Analist - Fedict. Dussart Dirk Architect - Fedict

Transcriptie

1 TESTING POLICY Van Caneghem Wouter Functionele Analist - Fedict Dussart Dirk Architect - Fedict

2 Contents 1. Inleiding Doel van dit document Waarom testen? Wat is testen Basisprincipes Het testproces en algemene verantwoordelijkheden Het Fedict V-model Testlevels Reviews Unittest level Integratietestlevel Systeemtestlevel Acceptatietestlevel Test types Functionele tests Niet functionele tests Tests gelinkt aan wijzigingen (confirmatietests en regressietests) Classificatie van Testtechnieken Test Proces Risico gebaseerd Verantwoordelijkheden Algemeen Lagere test levels Systeem Integratietests Acceptatietests Severity (Ernst) Vereisten voor de leverancier Algemeen Inhoud van de op te leveren werkproducten Op te leveren werkproducten (Deliverables) Algemene documenten Unittests Integratietests Systeemtests Acceptatietests

3 3.4. Staging Criteria Dekkingsgraad Criteria om naar TEST te gaan Criteria om naar ACCEPTATIE te gaan Criteria om naar PRODUCTIE te gaan Aanbevelingen voor de leverancier Test Matrix Scenario coverage Rollen en verantwoordelijkheden Test Manager Test Architect Test Designer Tester Test Automation Engineer Test Methodologist Tools Selenium JUnit Hudson Jenkins Testproces Testspecificatie Testuitvoering Test Reporting Test Documentatie Testplan Testdesign specificatie Testcase specificatie Testlog Test Incident Rapport Test Summary Rapport Annexen Annex 1 Templates Gebruik van de templates Lijst van templates

4 Datum Versie Beschrijving Auteur 11/10/ Eerst draft versie Wouter Van Caneghem 17/10/ Toevoeging hoofdstuk Tools Wouter Van Caneghem 21/10/ Toevoeging rollen en Wouter Van Caneghem verantwoordelijkheden 17/11/ Toevoeging unittesting Diederik Delen 12/12/ Toevoeging testmatrix Wouter Van Caneghem 13/12/ Toevoeging staging criteria Wouter Van Caneghem 27/02/ Update staging criteria en toevoeging Wouter Van Caneghem annexe 05/03/ Update testmatrix Dirk Dussart 13/04/ Review Coralius nv Coralius nv 14/05/ Wijzigen van de severities Wouter Van Caneghem 4

5 1. Inleiding 1.1. DOEL VAN DIT DOCUMENT Dit document heeft tot doel duidelijk te maken welke eisen Fedict stelt inzake het testproces voor software en af te lijnen wie voor welke delen van dit proces verantwoordelijk is. De in dit document gestelde vereisten zijn van toepassing voor alle projecten. In de specifieke lastenboeken of requirementsdocumenten kunnen zij echter worden aangepast aan de behoeften van het project of product. Verder is het de bedoeling dat dit document de leverancier helpt om vanaf de eerste oplevering een zo goed mogelijk product op te leveren en zodanig een win-win situatie te creëren voor beide partijen. Hierbij willen we ervoor zorgen dat de inspanning voor testen en hertesten langs de kant van Fedict alsook het herwerken van het product bij de leverancier minimaal is. Hoofdstuk 2 geeft een algemeen overzicht van het testproces op basis van het V-model. Hierin geven we aan welke testlevels onder de verantwoordelijkheid van Fedict vallen en voor welke de software leverancier verantwoordelijk is. In hoofdstuk 3 geven we een overzicht van de op te leveren werkproducten (deliverables) en de vereisten waaraan deze moeten voldoen. In hoofdstuk 4 geven we bijkomende aanbevelingen over hoe een leverancier kan voldoen aan de gestelde eisen, zonder evenwel een bepaalde ontwikkelingscyclus of methodiek willen op te leggen. In Annex 1 geven we een lijst van templates die bij deze policy horen en leggen we uit hoe men deze kan gebruiken WAAROM TESTEN? Testen is een noodzakelijke voorwaarde voor het succesvol bouwen en implementeren van informatiesystemen. De complexiteit van hedendaagse software is zodanig dat het zo goed als onmogelijk is om deze van de eerste keer en zonder verificatie correct te implementeren. Testen is nodig om zo vroeg mogelijk problemen in de software te ontdekken zodanig dat deze tegen een minimale kostprijs kunnen gecorrigeerd worden. Een tweede reden om te testen is om vertrouwen en kennis in het opgeleverde product op te bouwen. Defecten in een software product kunnen zware gevolgen hebben voor de business en voor de gebruikers. Naast het zo veel mogelijk vermijden van fouten is testen ook zinvol om aan het management en de gebruikers aan te tonen dat het opgeleverde product voldoet aan hun vereisten ( fit-for-purpose ). 5

6 Hierbij dienen we op te merken dat zowel de functionaliteit als de niet-functionele softwarekarakteristieken van belang zijn om te kunnen stellen dat een product voldoet aan de gestelde vereisten en bruikbaar is in zijn operationele context WAT IS TESTEN Software testen is het proces om te verifiëren en te valideren dat een software programma, applicatie of product: voldoet aan de business en technische vereisten zoals beschreven in het lastenboek, de vereisten (requirements), analyse en design documenten. werkt zoals verwacht en bruikbaar is in zijn operationele omgeving. geïmplementeerd is met de vooropgestelde niet-functionele software karakteristieken. Hierbij dienen verificatie en validatie geïnterpreteerd worden in de zin van de ISO-9000 standaard: verificatie: bevestiging, door middel van het opleveren van objectieve bewijzen dat de gestelde vereisten vervuld zijn. validatie: bevestiging, door middel van het opleveren van objectieve bewijzen dat de gestelde vereisten, voor een specifiek verwacht gebruik of toepassing, vervuld zijn. Men kan dit interpreteren door te stellen dat verificatie inhoudt dat men de software juist gebouwd heeft terwijl validatie inhoudt dat men de juiste software heeft gemaakt BASISPRINCIPES Er zijn een aantal principes die gelden voor alle testen: - Principe 1: Testen brengt defecten naar boven. Testen toont defecten die aanwezig zijn aan, maar kan niet bewijzen dat er geen defecten zijn. Testen verlaagt de kans van niet ontdekte defecten in de software, maar indien geen defecten gevonden worden kan dit niet aanzien worden als bewijs dat er geen defecten zijn. - Principe 2: Exhaustief testen is onmogelijk. Alles testen (alle combinaties van inputs/outputs en pre-condities) is niet haalbaar behalve in triviale gevallen. In plaats van doorgedreven te testen moeten risicoanalyse en prioriteiten gebruikt worden om de testinspanning te beperken tot de juiste testen. - Principe 3: Vroeg testen. De testactiviteiten moeten zo vroeg mogelijk starten in de ontwikkelingscyclus van software. Dit zorgt er voor dat de defecten vroeg gedetecteerd worden wat tot gevolg heeft dat het minder kost om ze op te lossen. 6

7 - Principe 4: Clustering van defecten. Een klein aantal van de modules bevat de meeste defecten die ontdekt worden tijdens de pre-release tests en/of zijn verantwoordelijk voor de meeste operationele fouten. - Principe 5: Pesticidenparadox. Als dezelfde set van testcases telkens opnieuw worden uitgevoerd, zal deze uiteindelijk geen nieuwe defecten meer aantonen. Daarom moeten de testcases regelmatig herbekeken worden. Nieuwe tests moeten geschreven worden om andere delen van de software te verifiëren om zo nieuwe defecten te vinden. - Principe 6: Testen is context afhankelijk. De manier van testen is afhankelijk van de context waarin het product uiteindelijk gebruikt zal worden. Bijvoorbeeld een beveiligingssoftware wordt anders getest dan een e-commerce website. - Principe 7: Absence-of-errors fallacy. Het vinden en oplossen van defecten helpt niet als het systeem niet bruikbaar is en/of niet voldoet aan de noden en verwachtingen van de eindgebruikers. 7

8 2. Het testproces en algemene verantwoordelijkheden 2.1. HET FEDICT V-MODEL Het Fedict V-model illustreert de gebruikte testlevels en de algemene verantwoordelijkheden van Fedict en van de leverancier TESTLEVELS Testlevels zijn groepen van testactiviteiten die tezamen beheerd worden en die in directe relatie staan tot de verantwoordelijkheden zoals gedefinieerd binnen een project. Fedict hanteert de testlevels zoals beschreven in de rest van deze sectie. Wanneer een leverancier andere benamingen of andere testlevels gebruikt moet hij kunnen aangeven wat de relatie is tussen de door hem gebruikte terminologie en deze van Fedict en moet hij kunnen aantonen dat zijn aanpak minstens evenwaardig is aan de door Fedict beschreven aanpak. 8

9 Merk op dat een testlevel niet hetzelfde is als een testfase. In een incrementeel of iteratief ontwikkelingsmodel zal men bijvoorbeeld in verschillende fasen van een project telkens opnieuw taken uitvoeren die behoren tot een welbepaald testlevel. Het V-model wordt in deze policy gebruikt om aan te geven wie welke activiteiten uitvoert en niet om een specifieke softwaredevelopment lifecycle op te leggen Reviews Reviews vormen een uitstekend middel om vroeg en kost-efficiënt fouten te detecteren. Wanneer de leverancier echter een review door Fedict van één of meerdere documenten verwacht, dient hij dit aan te geven in de offerte, met vermelding van de te reviewen documenten en een schatting van de nodige inspanning hiervoor langs de kant van Fedict. Hierbij kan men er vanuit gaan dat een review snelheid van 6 pagina's per uur zorgt voor een goede detectie van fouten Unittest level Unittests (ook wel componenttests genoemd) zoeken naar defecten in, en verifiëren het functioneren van apart testbare software modules, programma s, objecten, klassen, etc. Unittests kunnen zowel functionaliteiten alsook specifieke niet-functionele karakteristieken verifiëren. De testcases zijn gebaseerd op werkproducten zoals de specificaties van een component, het software design of het data model. Unittests worden gebruikt om zeker te zijn dat de individuele componenten correct werken. Unittesten maakt vooral gebruik van de whiteboxtesttechniek en gebeurt dus met kennis van de code die wordt getest en eventueel met de ondersteuning van de ontwikkelingsomgeving (unittest framework, debugging tool, etc.). Deze tests worden daarom dan ook vaak uitgevoerd door de ontwikkelaar die de code heeft geschreven of een gelijkwaardig profiel. De gevonden defecten worden opgelost zodra ze gedetecteerd worden. Voor Fedict vormen de unittests een goed alternatief voor commentaar in de code voor zover ze goed gestructureerd en leesbaar zijn opgesteld. Een unittest beschrijft meestal meer de details dan tekst in commentaar stijl. Unittests worden ook mee onderhouden samen met de code waar commentaar vaak wordt vergeten en op deze manier zal commentaar dan ook snel gedateerd raken. Unittests hebben ook een aantal karakteristieken die invloed hebben op de onderhoudsbaarheid van de applicatie. Tests zouden een eenvoudige structuur moeten hebben en dienen makkelijk op te zetten zijn. Afhankelijkheden moeten beperkt worden; door gebruik te maken van stub- en driverframeworks kan men een testsetup eenvoudig houden. Indien het schrijven van een test complex is, moet men als ontwikkelaar nadenken om de functionaliteit anders te implementeren. Moeilijk te testen code is dikwijls te complex, hetgeen de kans op fouten vergroot. Een richtlijn hierbij is om de cyclomatische complexiteit van individuele functies of methoden zo veel mogelijk beneden de 15 te houden. 9

10 Tests hebben een duidelijke naamgeving. In de methode of testnaam beschrijven we wat de test gaat doen. Namen zoals test1, test2 zijn ontoelaatbaar. Denk er aan dat ook de unittests door Fedict moeten kunnen geverifieerd worden. Unittests zijn ook onafhankelijk van elkaar en moeten dan ook allen afzonderlijk kunnen lopen Integratietestlevel Bij de integratietests worden de interfaces tussen de verschillende componenten en de interacties met verschillende delen van een systeem (zoals besturingssysteem, bestandssysteem, hardware, etc.) getest. Er kunnen meer dan één niveau van integratietesten zijn en ze kunnen uitgevoerd worden op testobjecten van diverse grootte. We maken een onderscheid tussen 2 aparte integratietest levels: - Component integratietests: testen van de interactie tussen software componenten. Zij worden uitgevoerd na de unittests. - Systeem integratietests: testen van de interactie tussen verschillende systemen. Zij worden uitgevoerd na de systeemtests. Hoe groter de scope van de integratie, hoe moeilijker het wordt om defecten te isoleren in een specifieke component of systeem. Op elk moment van de integratie, concentreren de testers zich enkel op de integratie zelf. Bijvoorbeeld: een nieuwe module A wordt geïntegreerd met een module B. Bij de integratietests is men hoofdzakelijk geïnteresseerd in de communicatie tussen de modules en niet in de functionaliteit van de modules zelf Systeemtestlevel Bij de systeemtests willen we het gedrag van een volledig systeem, zoals gedefinieerd in het project, testen. Voor systeemtests is, a priori, geen kennis vereist van het inwendige design of logica van het systeem; er worden hierbij dan ook vooral blackboxtesttechnieken gebruikt. Bij de systeemtests moet de omgeving zoveel mogelijk overeenkomen met de finale productieomgeving om het risico op omgeving specifieke defecten te minimaliseren. Systeemtests worden afgeleid van risicospecificaties, requirementspecificaties, business-processen, use-cases of andere high level omschrijvingen. Ze worden uitgevoerd binnen de context van functionele requirements. Systeemtests zullen daarnaast ook de niet functionele requirements onderzoeken (kwaliteitsattributen). Systeemtests bevatten typisch de volgende soorten tests: GUI-tests, usability tests, regressietests, performancetests, error-handlingtests, maintenance tests, compatibility tests, load tests, security tests, scalability tests, etc. Het is de bedoeling dat op het einde van de systeemtestuitvoering de leverancier ervan overtuigd is dat het systeem voldoet aan alle gestelde vereisten en klaar is om aan de klant overgedragen te worden (eventueel met uitzondering van de interactie met peer- systemen). 10

11 Acceptatietestlevel Acceptatietests zijn vaak de verantwoordelijkheid van de klanten of (eind)gebruikers van een systeem. Andere stakeholders kunnen hier ook bij betrokken worden. Het doel van acceptatietesten is om vertrouwen in het systeem, delen van het systeem of specifieke niet functionele eigenschappen te krijgen. Het vinden van defecten is niet het hoofddoel van acceptatietesten. Met de acceptatietests kunnen we de gereedheid voor gebruik van een systeem nagaan. Acceptatietests kunnen voorkomen als méér dan één enkelvoudige testlevel. Bijvoorbeeld: - Acceptatietesten van de bruikbaarheid van een component kan gebeuren tijdens het unittesten. - Acceptatietesten van een nieuwe functionele verbetering kan gebeuren voor de systeemtests. Acceptatietests bevatten typisch volgende elementen die eventueel als aparte testlevel kunnen worden beschouwd: - Gebruikersacceptatietests: de paraatheid verifiëren van het gebruik van een systeem door business gebruikers. - Operationele acceptatietests: de acceptatie van het systeem door de systeem administrators, bevat tests van backup/restore, disaster recovery, user management, maintenance tasks, etc. - Contract- en richtlijntests (conformantietest): de acceptatiecriteria moeten afgesproken worden tijdens de contractbesprekingen. De acceptatie wordt dan gedaan tegenover deze criteria voor het produceren van software. Hierin zijn ook standaarden (government, legal, security, etc.) inbegrepen. - Zonder specifieke afspraken moet het systeem voldoen aan alle gestelde vereisten zoals beschreven in het (ondertekende)lastenboek en bijhorende documenten evenals aan de vereisten beschreven in alle meer technische documenten die door Fedict zijn goedgekeurd. - Alfa- en betatests: het krijgen van feedback van potentiele of bestaande klanten vooraleer het product op de markt komt. Alfa testen gebeurt binnen de organisatie van de ontwikkelaar. Betatesten (field testen) gebeurt door de mensen op hun eigen locatie TEST TYPES Functionele tests Functionele tests verifiëren de functies die een systeem, subsysteem of component moeten uitvoeren. Deze kunnen beschreven worden in zogenaamde werkproducten zoals requirementspecificaties, use-cases, functionele specificaties, etc. Ze beschrijven wat het systeem doet. De functionele tests zijn gebaseerd op de functionaliteiten en hun interoperabiliteit met specifieke systemen. Functionele tests kunnen uitgevoerd worden op elk testlevel. Bijvoorbeeld, tests voor componenten kunnen gebaseerd zijn op componentspecificaties. 11

12 Functionele tests beschouwen het externe gedrag van de software en worden bijgevolg hoofdzakelijk opgesteld met behulp van blackboxtesttechnieken Niet functionele tests Niet functionele tests omvatten (niet-exhaustieve lijst) performance tests, load tests, stresstests, usability tests, maintainability tests, reliability tests, etc. Ze testen hoe het systeem werkt. Niet functionele tests kunnen uitgevoerd worden op elk test level. De niet functionele tests verifiëren de niet-functionele karakteristieken van systemen. Dikwijls doen ze dit door kwantificeerbare informatie te meten die kan vergeleken worden met vooropgestelde grenzen. Bijvoorbeeld, de response tijden voor performance tests Tests gelinkt aan wijzigingen (confirmatietests en regressietests) Wanneer een defect gevonden en opgelost is moet de software opnieuw getest worden om te bevestigen dat het oorspronkelijke defect succesvol verwijderd is. Dit noemt men confirmatietesten. Men spreekt in dit verband ook van hertesten. Opmerking: Het debuggen van code is een ontwikkelingsactiviteit, geen testactiviteit. Regressietesten is het opnieuw testen van een reeds geteste programmacode na wijzigingen om zo defecten te ontdekken (in niet gewijzigde aspecten van de software) die veroorzaakt worden door wijzigingen aan de software of aan de omgeving. Deze tests worden telkens uitgevoerd wanneer de omgeving of de software verandert. Regressietests kunnen ook uitgevoerd worden op elk testlevel en zijn toepasbaar voor zowel functionele, niet functionele als structurele tests. Regressietests worden vaak uitgevoerd en richten zich op de meest kritische functionaliteiten waardoor ze een geschikte kandidaat zijn voor automatisatie CLASSIFICATIE VAN TESTTECHNIEKEN Testtechnieken zijn formele werkwijzen om test gevallen af te leiden van documenten, van modellen van de software of van code. We kunnen de verschillende soorten testtechnieken opdelen in 2 groepen. De zogenaamde whiteboxtests en de blackboxtests. De whiteboxtests zijn gebaseerd op de programmacode, de programmabeschrijvingen of het technisch ontwerp. Er wordt nadrukkelijk gebruik gemaakt van kennis over de interne structuur van het systeem. Deze tests worden typisch uitgevoerd door de ontwikkelaars en het gaat hierbij om een door de ontwikkelaar uitgevoerde test die dient om aan te tonen dat een programma (of 12

13 module) of een serie programma s (of modules) voldoet aan de in de technische specificaties gestelde eisen. De blackboxtests zijn gebaseerd op de functionele specificaties en kwaliteitseisen. Bij deze tests wordt het systeem beschouwd in de verschijningsvorm zoals die ook gedurende het uiteindelijke gebruik zal functioneren. De software wordt gezien als een zwarte-doos zonder enige kennis van de interne implementatie noch van de interne structuur. Typisch worden hierbij meerdere testcases opgesteld gebaseerd op de functionele specificaties en requirements. Alhoewel beide groepen van testtechnieken op alle levels kunnen gebruikt worden, zet men hoofdzakelijk op de lagere testlevels whiteboxtesttechnieken in en op de hogere levels blackboxtesttechnieken. De acceptatietests uitgevoerd door Fedict zullen hoofdzakelijk gebruik maken van blackboxtesttechnieken TEST PROCES Het staat de leverancier vrij om een test proces te kiezen dat overeenkomt met zijn ontwikkelingsmethodiek voor zover hij daarmee voldoet aan de vereisten zoals gesteld in hoofdstuk 3. In hoofdstuk 4 geven we enige richtlijnen hierover zonder echter een specifiek proces op te leggen RISICO GEBASEERD Risico gebaseerd testen houdt in dat men op basis van een (product) risicoanalyse de testinspanning focust op de delen of aspecten van een applicatie die het grootste risico inhouden. Het wordt gezien als een goede praktijk om de teststrategie minstens gedeeltelijk te bepalen op basis van een risicoanalyse. In deze zijn er twee mogelijkheden: Fedict heeft een risicoanalyse bijgevoegd in het lastenboek of de bijhorende documenten. Fedict heeft geen risicoanalyse bijgevoegd in het lastenboek of de bijhorende documenten. In het eerste geval raden we de leverancier aan om deze analyse te gebruiken en indien nodig te verfijnen wanneer de technische aspecten van het systeem onder test duidelijker worden. In het tweede geval kan de leverancier zelf een analyse uitvoeren. Fedict kan hierbij eventueel input geven inzake de impact van de risico's. Wanneer de leverancier van Fedict een inspanning verwacht in verband met de risicoanalyse dient hij in de offerte op te nemen: 13

14 Een beschrijving van zijn aanpak rond risicoanalyse en de rol van Fedict hierin. Een inschatting van de tijd nodig voor Fedict om deze rol te vervullen VERANTWOORDELIJKHEDEN In deze sectie geven we aan waar de verantwoordelijkheid van de leverancier en Fedict liggen Algemeen We gaan er van uit dat de leverancier een professional is in het ontwikkelen van software en over de nodige domeinkennis beschikt. Wanneer de leverancier dankzij deze kennis tekortkomingen zou ontdekken in de specificaties die ertoe zouden kunnen leiden dat het systeem onder test niet fit-for-purpose is, gaan we er vanuit dat hij Fedict daarvan onverwijld op de hoogte stelt zodat hiervoor tijdig een oplossing kan gevonden worden. Het is duidelijk dat de voorgaande bewering soms contractuele bepalingen kan overschrijden, maar het is steeds in het belang is van beide partijen dat er een bruikbaar systeem wordt opgeleverd. Het is de bedoeling dat de leverancier een volledig getest en correct werkend systeem oplevert aan Fedict. Hierbij hoort ook de oplevering van de testdocumentatie zoals beschreven in het volgende hoofdstuk en eventueel verder gespecifieerd in een lastenboek of requirementsdocument. Fedict zal dan op dit systeem acceptatietests uitvoeren om na te gaan of alle vereisten effectief zijn vervuld Lagere test levels De testlevels unit (component tests), integratietests, en systeemtests of de daarmee overeenkomstige levels,zoals gebruikt door de leverancier vallen volledig onder de verantwoordelijkheid van de leverancier. Fedict zal steekproefsgewijs nagaan of de werkproducten voldoen aan de gestelde vereisten Systeem Integratietests Bij de systeem integratietests is het mogelijk dat systemen van de leverancier moeten geïntegreerd worden met systemen van andere leveranciers of van de overheid. In deze is samenwerking noodzakelijk. Fedict zal in deze een faciliterende rol spelen, maar de eindverantwoordelijkheid ligt bij de leverancier van het systeem onder test. Fedict zal steekproefsgewijs nagaan of de werkproducten voldoen aan de gestelde vereisten. 14

15 Acceptatietests De testanalyse, het testdesign en de testimplementatie van een basis set acceptatietests gebeurt door de leverancier. Fedict zal steekproefsgewijs nagaan of deze werkproducten voldoen aan de gestelde vereisten en kan ook additionele testscenario's voorzien. Fedict zal de tests uitvoeren en de test resultaten gebruiken voor het accepteren van het systeem of desgevallend het vragen van correcties SEVERITY (ERNST) De severity (ernst) van een defect is dikwijls een bron van discussie bij acceptatie van een systeem. [Normatieve sectie] Fedict hanteert volgende definities inzake severities. Elke afwijking hiervan dient contractueel vastgelegd te worden voor de start van een project. Critical Een testcase kan op geen enkele manier beëindig worden. Bv: een submit van gegevens geeft een foutboodschap, de applicatie crasht, etc High Een testcase kan beëindigd worden maar het gedrag van de applicatie is niet conform de specificaties. Bv: een cancel knop doet een submit, een lijst met gegevens wordt niet correct weergegeven, etc Medium Een testcase kan beëindigd worden conform de specificaties maar er zijn fouten die door manuele interventies (zonder de source code te wijzigen) kunnen omzeild worden. Bv: een foute controle van een veld, etc Low Nice to have Er zijn cosmetische problemen (spelling, lay-out, kleuren) die het functioneren van de applicatie weinig beïnvloeden. "niet conform specificaties" moet hierbij geïnterpreteerd worden als: werkt niet zoals beschreven in het lastenboek, het requirementsdocument of andere door Fedict goedgekeurde specificaties. In 15

16 geval verschillende specificaties niet consistent zijn, zal de voor Fedict meest gunstige interpretatie gebruikt worden. [Einde normatieve sectie] 16

17 3. Vereisten voor de leverancier 3.1. ALGEMEEN Deze sectie bevat de standaard op te leveren werkproducten, de daaraan gekoppelde kwaliteitscriteria en de vereisten om het systeem onder test te installeren in de verschillende omgevingen. Dit hoofdstuk is normatief, behalve waar expliciet is vermeld dat dit niet het geval is. In de lastenboeken en bijhorende requirements documenten of in de contracten tussen de leverancier en Fedict kunnen de hier beschreven vereisten wijzigen, zowel in de zin van het stellen van meer of strengere vereisten als in het opleggen van minder strenge vereisten. Voor alle aspecten van het test proces die niet expliciet veranderd worden in contractueel relevante documenten moet de inhoud van dit hoofdstuk gezien worden als test requirements INHOUD VAN DE OP TE LEVEREN WERKPRODUCTEN De op te leveren werk producten dienen in principe minstens de gegevens te bevatten zoals vermeld in de templates (sjablonen) beschreven in annex 1. Individuele lastenboeken, requirementsdocumenten of contracten kunnen bijkomende vereisten stellen aan de inhoud. Indien hiervan wordt afgeweken dient de leverancier hier de reden voor te documenteren ofwel in de testplannen ofwel in de documenten waarin wordt afgeweken, telkens met vermelding van de reden voor de afwijking. Wanneer de leverancier zijn eigen templates gebruikt dient hij zich ervan te vergewissen dat ze de nodige informatie bevatten en dient hij op vraag van Fedict een mapping tussen zijn structuur en deze in de templates in annex voor te leggen. Het verstrekken van deze templates houdt NIET in dat Fedict vraagt om deze templates te gebruiken om effectief documenten te genereren. [niet normatief] Het zij duidelijk dat ze vooral dienen als checklist. In een aantal gevallen is het zeker aan te raden om de gevraagde informatie op te slaan in een tool, eerder dan in MS Office documenten.[einde niet normatieve sectie] 17

18 3.3. OP TE LEVEREN WERKPRODUCTEN (DELIVERABLES) Algemene documenten Offerte De leverancier zal de testaanpak en het testproces dat hij zal gebruiken voor de opdracht beschrijven in de offerte. De verwachtingen van Fedict in dit verband zijn dat het gaat om een gestructureerd en gecontroleerd proces dat de gevraagde deliverables tijdig en correct kan opleveren Test plan(nen) De leverancier zal een testplan opleveren waarin hij de testdoelen en de verschillende testobjectieven per testlevel uiteenzet. Dit plan kan bestaan uit 1 document of uit een master testplan en een level testplan (per test level). De oplevering van het testplan dient ten laatste voor de eerste oplevering van de software plaats te vinden. Het Master testplan dient onderhouden te worden tot de finale oplevering van de software. De inhoud omvat minstens de elementen genoemd in de overeenkomende template in annex. Fedict zal controleren of de geleverde plannen voldoen aan de eisen van deze policy en eventueel bijkomende eisen en standaarden opgelegd in het lastenboek, het requirementsdocument of andere contractuele overeenkomsten. Het is in het belang van beide partijen dat de plannen zo snel mogelijk opgeleverd en gecontroleerd worden om herwerking en eventuele vertragingen bij de acceptatiefase te vermijden Master test summary report Bij elke oplevering van software aan Fedict zal de leverancier een (master) test summary report voegen. De inhoud omvat minstens de elementen genoemd in de overeenkomende template in annex en rapporteert over elk testlevel dat reeds is uitgevoerd Unittests Bij elke oplevering van software aan Fedict zal de leverancier een overzicht van de unittest gevallen alsook enkele relevante gevallen zelf mee opleveren. De andere testgevallen moeten ter beschikking gesteld worden indien en wanneer Fedict daar om vraagt. Het kan hier gaan om code of om manuele testgevallen. De unittest gevallen omvatten minstens een geautomatiseerde test suite die in elke testomgeving en in de productieomgeving kan worden uitgevoerd en die minstens een dekkingsgraad (statement coverage) van 75% heeft. Deze coverage moet aangetoond worden op de opgeleverde versie van de 18

19 software. Dit gebeurt met behulp van een tool die eventueel ter beschikking gesteld wordt voor Fedict. Een test summary report (of geautomatiseerd test dashboard) wordt mee opgeleverd. [niet normatief] We raden de leverancier aan om hierbij een systeem van continue integratie of een daily build met geïntegreerde test cases te hanteren.[einde niet normatief gedeelte] Fedict zal steekproefsgewijs controleren of de geleverde unittests voldoen aan de eisen van deze policy en eventueel bijkomende eisen en standaarden opgelegd in het lastenboek, het requirementsdocument of andere contractuele overeenkomsten. [niet normatief] Voor complexe of kritieke projecten zal de dekkingsgraad verhoogd worden of kan er worden overgegaan naar een strengere dekkingsvorm zoals bijvoorbeeld decision of condition coverage. [einde niet normatief gedeelte] Input Functionele documenten Technisch design documenten Code van individuele componenten Acties Testen van de individuele componenten Output (deliverables) Testgevallen (test case specificatie), inclusief een geautomatiseerde test suite Testresultaten Test summary rapport (of dashboard) Rol Fedict Steekproefsgewijze controle Integratietests Bij elke oplevering van software aan Fedict zal de leverancier de component integratietestgevallen mee opleveren. Het kan hier gaan om code of om manuele testgevallen. Bij elke oplevering van software aan Fedict zal de leverancier de systeem integratietestgevallen mee opleveren voor zover de systeem integratie al is uitgevoerd en van toepassing is. Het kan hier gaan om geautomatiseerde of om manuele testgevallen. De leverancier zal aantonen (bijvoorbeeld door oplevering van een traceerbaarheidsmatrix) dat: alle interne componenten geïntegreerd zijn. elke externe interface is getest op volgende aspecten: o de communicatie over deze interface functioneert. o de interpretatie van de uitgewisselde data is dezelfde voor beide systemen. Zo dit relevant is en van zodra de systeem integratie heeft plaatsgevonden zal de leverancier ook aantonen dat de end-to-end flow van de applicatie functioneel is door getest (end-to-end tests op basis van de business analyse, chain-testing). 19

20 [niet normatief] We raden de leverancier aan om minstens een deel van de component integratietests op te nemen in een systeem van continue integratie of een daily build. [einde niet normatief gedeelte] Fedict zal steekproefsgewijs controleren of de geleverde integratietests voldoen aan de eisen van deze policy en eventueel bijkomende eisen en standaarden opgelegd in het lastenboek, het requirements document of andere contractuele overeenkomsten. Input Business analyse (voor de systeem integratietests) Functionele documenten Design documenten Source code van de te integreren componenten Artefacten van de te integreren componenten Acties Testen van de interfaces tussen de componenten Testen van het de interfaces tussen het systeem en zijn peer-systemen End-to-end testen van functionele en niet functionele kwaliteitsattributen Output Testgevallen (test case design en test case specificatie) Testresultaten Test summary report Traceerbaarheidsmatrices Rol Fedict Steekproefsgewijze controle Systeemtests Bij elke oplevering van software aan Fedict zal de leverancier de systeemtest gevallen mee opleveren voor zover dit al van toepassing is. Het kan hier gaan om geautomatiseerde of om manuele testgevallen. De leverancier zal aantonen (bijvoorbeeld door oplevering van een traceerbaarheidsmatrix) dat de volledige functionaliteit zoals beschreven in door Fedict goedgekeurde functionele documenten is afgedekt en de risicoanalyse effectief gerespecteerd is. De leverancier zal aantonen (bijvoorbeeld door oplevering van een traceerbaarheidsmatrix) dat de niet-functionele kwaliteitsattributen voorzien om te testen op systeemtestniveau in het desbetreffende testplan effectief zijn afgedekt. Fedict zal steekproefsgewijs controleren of de geleverde systeemtests voldoen aan de eisen van deze policy en eventueel bijkomende eisen en standaarden opgelegd in het lastenboek, het requirementsdocument of andere contractuele overeenkomsten. Input Functionele documentatie Acties Testen van de functionaliteit van het geïntegreerde systeem Testen van niet functionele kwaliteitsattributen van het geïntegreerde systeem 20

21 Output (Deliverables) Test gevallen (test case design en test case specificatie) Test resultaten, inclusief lijst van alle gekende nog openstaande defecten Test summary report Traceerbaarheidsmatrices Rol Fedict Steekproefsgewijze controle Acceptatietests Ten laatste twee weken voor de start van de uitvoering van de acceptatietests zal de leverancier de acceptatietest gevallen opleveren. Het gaat hier in principe om blackboxtests. Zo deze geautomatiseerd zijn moet zeer goed gedocumenteerd worden hoe deze gevallen uitgevoerd kunnen worden. Deze documentatie maakt dan ook deel uit van de op te leveren werkproducten. De leverancier zal aan Fedict de nodige training, demonstraties of uitleg geven zoals beschreven in de staging criteria zodanig dat Fedict de acceptatietests kan uitvoeren. [niet normatief] Het is de bedoeling dat de leverancier een correcte en volledige set van acceptatietests oplevert. Fedict zal deze grondig controleren en hoofdzakelijk zelf uitvoeren. Het is mogelijk dat Fedict additionele tests vraagt of zelf aanmaakt na deze controle. Om de controle en eventuele correcties toe te laten moet de oplevering gebeuren ruim voor de start van de acceptatietest uitvoering. [einde niet normatief gedeelte] De leverancier zal aantonen (bijvoorbeeld door oplevering van een traceerbaarheidsmatrix) dat de volledige functionaliteit zoals beschreven in de requirement documenten en/of het lastenboek en eventuele andere contractuele verbintenissen zijn afgedekt door de opgeleverde testset. Fedict zal steekproefsgewijs controleren of de geleverde acceptatietests voldoen aan de eisen van deze policy en eventueel bijkomende eisen en standaarden opgelegd in het lastenboek, het requirements document of andere contractuele overeenkomsten. Fedict kan, gebaseerd op hun domein kennis additionele validatietests toevoegen tenzij dit expliciet is verboden (in de context van de acceptatie) door contractuele overeenkomsten. Fedict zal deze additionele test gevallen voor de start van de test uitvoering ter beschikking stellen aan de leverancier. [niet normatief ] Eventuele bijkomende tests hebben tot doel de validatie te vervolledigen op basis van de kennis van domein experten. Het is ook hier in het voordeel van beide partijen dat dit zo vroeg mogelijk gebeurt. [einde niet normatief gedeelte] Fedict zal de tests uitvoeren, zo nodig met de hulp van de leverancier. Fedict zal ook een test summary report maken van dit test level. 21

22 De leverancier zal dit level test summary report integreren in het finale master test summary report. In het geval dat de tests zeer complex zijn of doorgedreven kennis van interne aspecten van de applicatie vereist, bestaat de mogelijkheid dat Fedict de uitvoering van de tests observeert terwijl de leverancier deze uitvoert. Gezien requirements echter een blackbox beschrijving geven van het systeem onder test moet deze situatie echter zeer uitzonderlijk blijven en is hiervoor alleszins voorafgaandelijke goedkeuring van Fedict nodig Incident- en defectmanagement bij de acceptatietests. De leverancier zal vanaf de start van de acceptatietestuitvoering ervoor zorgen dat Fedict een tool en/of procedure heeft om defecten en incidenten te registreren. Voor niet-triviale projecten gaat de voorkeur uit naar een defectmanagementtool (zoals bijvoorbeeld JIRA, Mantis of Bugzilla) eerder dan naar een document of mail gebaseerde procedure. Hoe dan ook zal de leverancier er zorg voor dragen dat defecten en incidenten niet verloren gaan en opgevolgd worden tot ze zijn afgesloten. Defecten gevonden door Fedict kunnen enkel met instemming van Fedict afgesloten worden. Van zodra de applicatie in de acceptatieomgeving is geïnstalleerd en daar ter beschikking is gesteld van Fedict kan geen enkel defect nog afgesloten worden zonder instemming van Fedict. Dit geldt dan zowel voor defecten gevonden door Fedict als deze gevonden door andere partijen (bijvoorbeeld de leverancier zelf of een eindgebruiker) als voor de defecten die nog open stonden van vroegere testlevels of fasen. Bij het begin van de acceptatietests in de acceptatietestomgeving zal de leverancier expliciet een lijst van alle nog openstaande defecten als deel van het test summary rapport van het vorige testlevel opleveren. Input Business analyse Domeinkennis Contractspecificaties Standaarden en richtlijnen (government, legal, security) zoals vermeld in het lastenboek of bijhorende documenten Acties Gebruikersacceptatietesten Operationele acceptatietesten Contractuele acceptatietesten Conformantietesten tegenover de standaarden en richtlijnen zoals vermeld in het lastenboek of bijhorende documenten Output (Deliverables) van de leverancier Testgevallen (test case design en test case specificatie) Traceerbaarheidsmatrices Master test summary report Output (Deliverables) Testresultaten Level test summary report 22

23 van Fedict Fedict Steekproefsgewijze controle van de test gevallen en de traceerbaarheidsmatrices Test uitvoering, inclusief registratie van de test resultaten en eventuele anomalieën Opstellen van een level test summary report 3.4. STAGING CRITERIA Staging criteria zijn de vereisten waaraan een releasekandidaat moet voldoen alvorens deze op een hoger liggende omgeving wordt geïnstalleerd. In deze paragraaf beschrijven we algemene staging criteria, maar de exacte criteria dienen vastgelegd te worden tijdens het project zelf ofwel in het lastenboek, ofwel later in overleg met de leverancier. Indien er geen andere overeenkomsten of vereisten gespecifieerd zijn gelden onderstaande criteria. We kunnen volgende toepassingsomgevingen onderscheiden: - Ontwikkeling: hier gebeurt de ontwikkeling en worden de unit- en componentintegratietests uitgevoerd. - Test: hier gebeurt het systeemtesten. - Acceptatie: hier gebeurt het acceptatietesten. - Productie: live omgeving van de toepassing. Of de systeemintegratietests gebeuren op de acceptatie dan wel op de testomgeving dient project per project bepaald te worden Dekkingsgraad Wanneer we in de staging criteria zeggen dat een functionaliteit of niet-functioneel kwaliteitscriterium is afgedekt, bedoelen we hiermee: Er zijn één of meerdere tests geschreven voor deze functionaliteit of niet-functioneel kwaliteitscriterium. Deze tests zijn effectief uitgevoerd en indien ze zijn gefaald is er een defect voor aangemaakt. De tests verifiëren adequaat de te testen functionaliteit of niet-functioneel kwaliteitscriterium in die zin dat ze zijn ontwikkeld met behulp van de technieken beschreven in een testplan dat is geïnspecteerd en goedgekeurd door Fedict. Gezien het soms niet haalbaar is om redenen van tijd en budget om 100% van de functionaliteiten of niet-functionele kwaliteitscriteria adequaat af te dekken kunnen er in het lastenboek lagere minimale dekkingsgraden worden vermeld. De leverancier kan verder in de testplannen lagere dekkingsgraden voorstellen, bij voorkeur gekoppeld aan de blootstelling aan risico's van de desbetreffende kwaliteitscriteria. 23

24 De testplannen zullen steeds vermelden hoe de dekkingsraad gemeten wordt. We illustreren de verwachtingen van Fedict met een niet normatief voorbeeld in sectie 4.2. De dekkingsgraad moet steeds expliciet door Fedict goedgekeurd worden en het is dus aangewezen om deze dekkingsgraden tijdig te negotiëren met Fedict Criteria om naar TEST te gaan - Een dekking van 75% (statement coverage) van de code door een geautomatiseerde unittestset - 100% van de unittests moet slagen De IT-provider van de applicatie moet deze cijfers duidelijk rapporteren bij elke oplevering. Om de dekkingsgraad te meten dient de IT provider gebruik te maken van een tool. Op vraag van Fedict moet de leverancier deze meting expliciet demonstreren. - Het testplan dat de unit- en componentintegratietests beschrijft is geïnspecteerd en goedgekeurd door Fedict. - Het test summary report en/of dashboard met betrekking tot de unit- en componentintegratietests is opgeleverd aan Fedict Criteria om naar ACCEPTATIE te gaan Bugs Er mogen geen onopgeloste bugs zijn die de uitvoering van de testcase blokkeren en waarvoor geen tijdelijke oplossing (workaround) bestaat. Dit zijn bugs met severity (ernst) Major of Critical. Er zijn minder dan 5 onopgeloste bugs van severity "medium" en deze zijn gekend en geaccepteerd (voor de installatie in de acceptatie omgeving) door Fedict. Er zijn minder dan 20 onopgeloste bugs van severity "Low" en deze zijn gekend en geaccepteerd (voor de installatie in de acceptatie omgeving) door Fedict Dekkingsgraad De volledige functionaliteit zoals beschreven in door Fedict goedgekeurde functionele documenten is afgedekt. De niet-functionele kwaliteitsattributen voorzien om te testen op systeemtestniveau in het desbetreffende testplan zijn afgedekt. De geautomatiseerde unittest set is uitgevoerd in de testomgeving op de laatste versie van de software. Deze uitvoering heeft aangetoond dat: de dekkingsgraad (statement coverage) nog steeds 75% is. elk van de unittests geslaagd is. 24

25 Andere - Het testplan dat de systeemtests beschrijft is geïnspecteerd en goedgekeurd door Fedict. - Het test summary report met betrekking tot de systeemtests is opgeleverd aan Fedict. - De leverancier heeft de acceptatietests overgedragen aan Fedict en heeft aan Fedict de nodige training, demo of uitleg gegeven om Fedict toe te laten de acceptatietests uit te voeren. Dit kan eventueel gebeuren na installatie in de acceptatieomgeving, maar voor de formele overdracht van de applicatie voor acceptatie naar Fedict toe Criteria om naar PRODUCTIE te gaan Bugs Er mogen geen onopgeloste bugs zijn met severity (ernst) Major of Critical. Er zijn minder dan 5 onopgeloste bugs van severity "medium" en deze zijn gekend en geaccepteerd (voor de installatie in de productieomgeving) door Fedict. Er zijn minder dan 20 onopgeloste bugs van severity "Low" en deze zijn gekend en geaccepteerd (voor de installatie in de productieomgeving) door Fedict. Een plan om de overblijvende defecten op te lossen is opgesteld door de leverancier en goedgekeurd door Fedict. Wanneer er in samenspraak tussen de leverancier en Fedict is beslist om bepaalde defecten niet op te lossen dient dit expliciet gedocumenteerd en goedgekeurd te zijn door Fedict, bijvoorbeeld in bovenstaand plan Dekkingsgraad De volledige functionaliteit en de niet-functionele kwaliteitsattributen zoals beschreven in het lastenboek en/of de requirement documenten zijn afgedekt. Fedict kan echter beslissen om slechts een gedeelte van de voorziene tests effectief uit te voeren. De geautomatiseerde unittest set is uitgevoerd in de acceptatie omgeving op de laatste versie van de software. Deze uitvoering heeft aangetoond dat: de dekkingsgraad (statement coverage) nog steeds 75% is. elk van de unittests geslaagd is. Andere - Het testplan dat de acceptatietests beschrijft is geïnspecteerd en goedgekeurd door Fedict. - Het test summary report met betrekking tot de acceptatietests is opgeleverd en is geïntegreerd in het master test summary report. - De leverancier heeft de testware (alle opgeleverde werkproducten gerelateerd aan het testen van de applicatie) overgedragen aan het team dat de applicatie moet beheren of onderhouden voor zover dit niet de leverancier zelf is. 25

26 4. Aanbevelingen voor de leverancier Deze sectie bevat niet normatieve informatie die de leverancier kan helpen om te voldoen aan de vereisten van Fedict, zeker zo de leverancier weinig ervaring heeft met gestructureerd testen TEST MATRIX Deze sectie illustreert hoe test taken passen in een ontwikkelingscyclus en illustreert welke tools men hierbij kan gebruiken. 26

27 BUSINESS ANALYSE FUNCTIONELE ANALYSE DESIGN BUILD CI TEST ACCEPTATIE U n i t t e s t e n Test Process: Test Design Test Execution Templates: Test Design Specifications Test Case Specifications Tools: JUnit4, Jmock, easymock XML unit Roles&Responsibilities: Test Designer Test Automation Engineer Supplier Test Process: Test Execution Test Reporting Test Controle Templates: Test Log Test Incident Report Tools: Maven SonarJ Roles&Responsibilities: Tester Supplier I n t e g r a t i e t e s t e n S y s t e e m t e s t e n Test Process: Test Design Templates: Test Design Specifications Test Case Specifications Tools: Selenium IDE Selenium Bromine Roles&Responsibilities: Test Designer Test Automation Engineer Supplier Test Process: Test Design Templates: Test Design Specifications Test Case Specifications Tools: Selenium IDE Selenium Bromine Roles&Responsibilities: Test Designer Test Automation Engineer Supplier Test Process: Test Execution Test Reporting Test Controle Templates: Test Log Test Incident Report Tools: Maven Roles&Responsibilities: Tester Supplier Test Process: Test Execution Test Reporting Test Controle Templates: Test Log Test Incident Report Tools: Selenium RC Selenium Grid Roles&Responsibilities: Tester Supplier Test Process: Test Execution Test Reporting Test Controle Templates: Test Log Test Incident Report Tools: Selenium RC Selenium Grid Roles&Responsibilities: Tester Supplier A c c e p t a t i e t e s t e n Test Process: Test Design Templates: Test Design Specifications Test Case Specifications Tools: Roles&Responsibilities: Test Designer Test Automation Engineer Supplier Test Process: Test Execution Test Reporting Test Controle Templates: Test Log Test Incident Report Tools: Roles&Responsibilities: Tester Fedict

28 4.2. SCENARIO COVERAGE Deze sectie geeft een voorbeeld van de verwachtingen van Fedict inzake dekkingsgraad, zowel voor wat betreft het detailniveau van de uitleg over de meting van dekking als voor wat de dekkingsgraad zelf betreft. Een scenario is een instantie van een use-case, het toont en beschrijft een specifiek pad door een flow van events. In de functionele documentatie wordt elke use-case voorgesteld door een activity diagram. Naast de basisflow zijn er verschillende alternatieve flows en error flows. Om alle mogelijke scenario s op te sommen dient men alle mogelijke lijnen door de graaf te tekenen. In onderstaande figuur staat een hypothetische graaf die een use-case met basisflow B en alternatieve flows A1, A2, A3 en A4 voorstelt. Er zijn duidelijk meer scenario s dan alternatieve flows omdat er één is voor A1, een ander voor A2 en een scenario voor de combinatie van de 2. Terugkerende lussen zouden in theorie oneindig veel scenario s opleveren. Vandaar dat we ervoor kiezen om de basis flow 1 keer te doen. Dan de lus 1 keer en tenslotte de lus een 2 e keer. Als het programma werkt voor beide instanties van de lus nemen we aan dat het ook zal werken als de lus meerdere keren wordt doorlopen.

29 Het is niet de bedoeling om al deze flows te testen maar een deelverzameling ervan. - De basisflow moet minstens afgedekt zijn door een testscenario. - Daarnaast moet er een testscenario zijn voor elke alternatieve flow. - Elke lus in het scenario wordt 0, 1 en 2 keer doorlopen in een testscenario ROLLEN EN VERANTWOORDELIJKHEDEN Doorheen het testproces zullen de verschillende activiteiten uitgevoerd worden door personen met een specifieke rol. Dit omdat elke activiteit specifieke competenties vereist. In deze sectie beschrijven we de meest relevante rollen. Dit geeft de leverancier een idee van de competenties en profielen nodig om adequaat en gestructureerd te testen. Het moge duidelijk zijn dat één persoon meerdere rollen kan opnemen Test Manager Een testmanager is verantwoordelijk voor het gehele test proces. Hij moet ervoor zorgen dat de verschillende testfasen correct worden uitgevoerd. Dat de verschillende resources optimaal worden gebruikt en de juiste beslissingen worden genomen op basis van de reporting. In de praktijk is hij verantwoordelijk tot het uitschrijven en implementeren van het Test Plan Test Architect Een test architect moet een geïntegreerde test architectuur formuleren die het volledige testproces ondersteunt en gebruik maakt van de test infrastructuur. In de praktijk zal hij input geven omtrent de test environments, tools qua automatisatie, etc Test Designer Een test designer dient de test cases te documenteren. Hij doet dit op basis van de requirements en vormt deze om tot concrete testcases die kunnen uitgevoerd worden door de tester of omgevormd tot automatische scripts Tester Een tester zal de verschillende testcases uitvoeren, rapporteren van de resultaten, defecten loggen en test coverage analyse uitvoeren. In de praktijk zal dit voor elke testlevel een andere persoon zijn. Dit zijn meestal business analisten, functionele analisten, architecten en ontwikkelaars of test experten Test Automation Engineer Een test automation engineer moet de test cases beschreven door de test design automatiseren met behulp van de tools voorgesteld door de test architect. In de praktijk zullen dit de analisten, architecten en ontwikkelaars zijn. 29

30 Test Methodologist De test methodologist is verantwoordelijk voor het definiëren en up-to-date houden van de gebruikte methodologie voor testing. Op basis van de resultaten van een test proces wordt de methodologie bijgestuurd waar nodig. Hij zal de test strategie evalueren, templates voorzien en erop toezien dat de methodologie in de praktijk wordt toegepast TOOLS We illustreren hieronder een aantal tools die kunnen gebruikt worden om het testen te vereenvoudigen en te versnellen. We raden de leveranciers aan om voor elk van de tools die ze inzetten rekening te houden met de return on investment en hierbij de nodige opleidingen en leertijd te verrekenen. Deze sectie is gebaseerd op de informatie in Wikipedia Selenium De selenium suite bestaat uit meerdere onderdelen. Selenium IDE: een geïntegreerde ontwikkelomgeving voor Selenium scripts. Het is geïmplementeerd als een firefox extensie en laat toe om testcases te recorden, editeren en debuggen. Selenium RC: een test tool die toelaat om automatische web applicatie UI testen te schrijven in gelijk welke programmeertaal. Dit voor gelijk welke http website gebruik makende van een willekeurige javascript-enabled browser. Selenium Grid: een tool die toelaat om meerdere testcases parallel op meerdere machines en in een heterogene omgeving uit te voeren. Selenium Bromine: een web based QA tool voor Selenium. Het laat toe om Selenium RC testen uit te voeren en het resultaat ervan te analyseren. Als we al deze componenten samenvoegen bekomen we volgende logische architectuur waarbij 1/ de automatische uitvoering van de testen is en 2/ de manuele uitvoering van de testen: 30

31 JUnit JUnit is een unittest framework voor de Java ontwikkelingstaal. Het is belangrijk bij test-driven ontwikkeling. JUnit is een instantie van de xunit architectuur voor unittest frameworks Hudson Hudson is een continuous integration tool geschreven in Java wat draait in een servlet container zoals Apache Tomcat of GlassFish application server. Het ondersteunt SCM tools zoals CVS, Subversion, Git en Clearcase. Het kan ook Apache Ant en Apache Maven gebaseerde projecten uitvoeren Jenkins Jenkins is een open source continuous integration tool geschreven in Java. Jenkins biedt continuous integration services aan voor software ontwikkeling, voornamelijk in Java geschreven. Het is een server gebaseerd systeem wat draait in een servlet container zoals Apache Tomcat. Het ondersteund SCM tool zoals CVS, Subversion, Git, Mercurial, Perforce en Clearcase. Het kan ook Apache Ant en Apache Maven gebaseerde projecten uitvoeren. 31

32 4.3. TESTPROCES In deze sectie illustreren we een eenvoudig test proces gebaseerd op IEEE-829 dat de leverancier kan gebruiken om te voldoen aan de vereisten gesteld in dit document. We onderscheiden 3 fasen binnen het test proces: «Testspecificatie» «Testuitvoering» «Testrapportering» Het is de bedoeling om deze 3 fasen te doorlopen. Elke fase heeft zijn eigen activiteiten en zal specifieke documenten genereren Testspecificatie Testspecificatie kan opgesplitst worden in 2 delen. Enerzijds is er de «Planning en controle» en anderzijds hebben we de «Analyse, design en implementatie». De planning en controle is de activiteit van het verifiëren van de missie, het definiëren van de objectieven en de specificaties van de testactiviteiten om de objectieven tegemoet te komen. De controle is een continu proces van het vergelijken van de huidige vorderingen ten opzichte van het testplan en het rapporteren van de status, inclusief de wijzigingen van het test plan. Planning en controle kan de volgende activiteiten bevatten: - Het bepalen van de scope en risico s en het definiëren van de objectieven van de tests. - Het vastleggen van de strategie. - Beslissingen nemen over wat te testen, welke rollen er zijn, hoe gebeuren de test activiteiten en hoe zullen de testresultaten geïmplementeerd worden. - Planning van de test design activiteiten. - Planning van de uitvoering en evaluatie. Tijdens de analyse, design en implementatie zullen de testobjectieven omgevormd worden naar concrete testcondities en testcases. Dit kan de volgende activiteiten bevatten: - Review van de testbasis (zoals requirements, architectuur, design, interfaces). - Evaluatie van de testbaarheid van de testbasis en de testobjecten. - Identificeren en prioritiseren van de testcondities. - Ontwerpen van de testcases. - Identificeren van de nodige test data om de testcases te ondersteunen. - Ontwerpen van de testomgeving en identificeren van de infrastructuur en tools Testuitvoering Testuitvoering is de fase waarbij de testprocedures en scripts worden uitgevoerd en de resultaten ervan (inclusief incidenten) worden gelogd. Dit kan de volgende activiteiten bevatten: 32 - Uitvoeren van de tests, manueel of via een tool. - Loggen van de resultaten van de uitvoering.

33 - Vergelijken van de resultaten met het verwachte resultaat. - Rapporten van de tegenstellingen in de vorm van incidenten en deze analyseren om de oorzaak ervan te kennen. - Herhalen van de tests als een gevolg van gevonden incidenten Test Reporting Test Reporting is de fase waarbij de uitvoering van de tests vergeleken wordt met de objectieven. Dit kan de volgende taken bevatten: - Controle van de testlogs en de lijst van defecten tegenover de exit criteria gespecificeerd in het testplan. - Nagaan of er bijkomende tests nodig zijn. - Het schrijven van een summary rapport TEST DOCUMENTATIE Doorheen het doorlopen van het testproces dienen verschillende documenten aangemaakt worden. We beschrijven welke documenten hieronder. Voor elk document is er ook een template beschikbaar die kan dienen als leidraad Testplan Het testplan bevat een beschrijving van hoe de tests beheerd, gepland en uitgevoerd zullen worden. Een testplan is een document dat doorheen de volledige testcyclus wordt aangepast en beschrijft wat er moet gebeuren, volgens welke kwaliteitsstandard, met welke resources, volgens welke tijdschaal, en geeft weer wat de risico s zijn en hoe deze kunnen worden opgelost. We verwachten minstens de volgende informatie in een testplan: - S Scope: wat moet er getest worden en wat niet. - P People: training, verantwoordelijkheden en planning. - A Approach: aanpak gevolgd om te testen. - C Criteria: entry/exit criteria en suspension/resumption criteria. - E Environment: test environments vereisten. - D Deliverables: wat wordt er geleverd als deel van het testproces. - I Incidentals: inleiding, identificatie en goedkeuring. - R Risks: risico s die kunnen voorvallen. - T Tasks: test activiteiten. Het is mogelijk om een Master Testplan te definiëren die geldt voor de volledige scope van de testing. Maar men kan er ook voor kiezen om per testlevel een testplan te definiëren. Bijvoorbeeld een testplan voor unittesting, systeemtesting, etc. De keuze hierin is vrij. Uiteraard moet ongeacht bovenstaande keuze het duidelijk zijn wat er precies getest wordt op elk test level. 33

34 Testdesign specificatie Het testdesign specificatiedocument beschrijft op een logisch niveau wat moet getest worden aan de hand van de requirements. Deze requirements worden omgevormd in concrete test condities. Dit document bevat nog geen test data of een beschrijving van hoe de test condities kunnen getest worden. Het beschrijft de vereisten voor deze test data en is louter een link tussen de requirements en de testcases Testcase specificatie De testcase specificaties vormen de test condities om tot concrete test cases door er test data, precondities en verwachte resultaten aan toe te voegen. De test cases kunnen gemaakt worden als het test design compleet is. Een test case kan één of meerdere testcondities omvatten. Een test case moet bevatten: - De test data nodig om de test uit te voeren. Dit is een combinatie van input data, applicatie data en systeem data. - Het verwachte resultaat en uitkomst. - De pre-condities die het startpunt bepalen van elke test. - Het stappenplan dat moet gevolgd worden om de test uit te voeren Testlog Het testlog houdt de details bij van welke test cases uitgevoerd zijn en de resultaten ervan. Dit kan enerzijds betekenen dat een test cases geslaagd is, wat betekent dat het verwachte resultaat en echte resultaat gelijk zijn. Anderzijds kan het betekenen dat een test case gefaald heeft en er een tegenstelling is gevonden. Dit heeft tot gevolg dat een Test Incident Report wordt aangemaakt en de details van de tegenstelling daarin worden beschreven. Een test log volgt de evolutie van de testuitvoering en geeft ook informatie over de oorzaak van de incidenten Test Incident Rapport Het Test Incident Rapport documenteert elke incident dat verder moet onderzocht worden. De incidenten komen voor uit het Test Log. Het Test Incident Report moet alle details bevatten van het incident zoals het verwachte en echte resultaat, wanneer het gefaald is en elke andere informatie die kan helpen om het incident op te lossen. Eventueel kan dit report ook een impact bevatten op het testen van het incident Test Summary Rapport Het Test Summary Rapport bevat de resultaten van de test activiteiten en de evaluatie van de resultaten ervan. Het geeft een globaal zicht op de testactiviteiten en de kwaliteit van de software. 34

35 5. Annexen 5.1. ANNEX 1 TEMPLATES Een aantal templates horen bij deze policy. Ze worden als aparte bestanden geleverd en zijn in het Engels opgesteld. Zie punt voor de lijst van templates Gebruik van de templates Het is de bedoeling om de templates te gebruiken als checklist om te verifiëren dat de opgeleverde documenten voldoende en de juiste informatie bevatten. De wat lichtere, blauwe tekst in de templates bevat aanwijzingen (guidance) en dient pragmatisch geïnterpreteerd te worden. Vermijd redundantie en overbodige breedsprakigheid in alle documenten. Als een volledige sectie niet van toepassing is, volstaat een vermelding "niet van toepassing " of NVT, gevolgd door een korte (typisch 1 lijn of minder) uitleg waarom dit zo is. Het is toegelaten, maar niet verplicht om deze templates te instantiëren om de bijhorende documenten op te stellen. In vele gevallen (bijvoorbeeld voor incident rapporten, testcase specificatie en test log) is het waarschijnlijk efficiënter om adequate tools in te zetten dan om deze informatie in documentvorm te behandelen Lijst van templates Test Case Specification Template. Test Design Specification Template. Test Incident Report Template. Test Log Template. Test Summary Report Template. Testplan Template. 35