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