STATUS. \fup\fup 1.0_NL\Disciplinen\D5\FUP-D5_Test.doc

FUP 1.0 D5- Discipline Test

Ontwikkelingsondersteuning [email protected]

D5- DISCIPLINE TEST

STATUS werkdocument voorgelegd ter acceptatie goedgekeurd

X

PUBLICATIE VAN HET DOCUMENT Starteam

1 2

\fup\FUP 1.0_NL\Disciplinen\D5\FUP-D5_Test.doc

1 De documenten betreffende de methodologie FUP kunnen plaatselijk op uw harde schijf gedownload worden door middel van de toepassing Starteam - project FUP - functionaliteit "check out all". Bij deze operatie wordt de boomstructuur van Starteam op uw harde schijf c:\ gecopieerd.

De documenten betreffende de methodologie FUP worden eveneens gepubliceerd over XWIKI van de infrastructuur, menu „SUPDEV“, rubriek „Methodologie FUP - Documenten NL en FR“, op het adres http://infrastructure.finbel.intra/xwiki/bin/view/SupDev/documents.

2

Bijwerking Februari 2007

Versie

Page

0.7

1/23



LIJST MET WIJZIGINGEN Datum

Auteur

FUP

Versie

Aard

18 mei 2005 26 mei 2005 Juli 2005 Augustus 2005

Unisys Unisys Unisys Unisys

0.1 0.2 0.2

0.1 0.2 0.3 0.4

November 2005 November 2005 Februari 2007

Unisys Unisys Unisys

0.3 0.3 0.3

0.5 0.6 0.7

Creatie van het document Release Wijzigingen na opmerkingen FOD Financiën Wijzigingen na opmerkingen FOD Financiën en kwaliteitscontrole Wijzigingen na opmerkingen FOD Financiën Herlezing SGA – Diverse wijzigingen Afstemming op teststrategie en testomgevingen

REFERENTIES


Versie

Page

0.7

2/23



INHOUDSTAFEL 1.

PRÉSENTATIE VAN HET DOCUMENT ...........................................................................................4 1.1.

INTRODUCTIE TOT DE DISCIPLINE "TESTS" ..........................................................................................4

1.2.

TOT WIE IS DIT DOCUMENT GERICHT? .................................................................................................4

2.

POSITIONERING TEN OPZICHTE VAN DE LEVENSCYCLUS ......................................................5

3.

TERMINOLOGIE................................................................................................................................6

4.

SCHEMATISCHE BESCHRIJVING VAN DE BENADERING ..........................................................9 4.1.

DE INPUTS ........................................................................................................................................9

4.2.

DE OUTPUTS ...................................................................................................................................10

4.3.

DE AANEENSCHAKELING VAN ACTIVITEITEN .......................................................................................11

4.4.

DE GEPRODUCEERDE ARTEFACTEN ..................................................................................................12

5.

BESCHRIJVING VAN DE ACTIVITEITEN ......................................................................................13 5.1.

VOORBEREIDENDE ACTIVITEITEN......................................................................................................13

5.1.1.

Definiëren van criteria voor acceptatie van de toepassing (A1)............................................13

5.1.2.

Definiëren van teststrategie (A2)...........................................................................................14

5.1.3.

Invoeren van testomgevingen (A3) .......................................................................................15

5.2.

DEFINITIE EN UITVOERING VAN DE TESTS ..........................................................................................16

5.2.1. 5.2.1.1.

Specificeren van functionele tests .....................................................................................16

5.2.1.2.

Specificeren van niet-functionele tests ..............................................................................16

5.2.1.3.

Uitvoeren van tests ............................................................................................................17

5.2.2. 5.3.

Specificeren en uitvoeren van acceptatietests (A5) ..............................................................18

ACTIVITEITEN VOOR AFSLUITING VAN EEN TESTCAMPAGNE ................................................................20

5.3.1.

Creëren van een fiche met anomalieën (A6) ........................................................................20

5.3.2.

Opmaken van Balans van Campagnes (A7) .........................................................................20

5.3.3.

Realiseren van pilootfases (A8) ............................................................................................21

6.

7.

Definiëren van plan voor integratietests (via herhalingen) (A4) ............................................16

VERANTWOORDELIJKHEDEN – GEZIEN PER FUNCTIE...........................................................22 6.1.

DE ICT-PROJECTLEIDER..................................................................................................................22

6.2.

DE BUSINESS-PROJECTLEIDER .........................................................................................................22

6.3.

DE GEBRUIKERS EN DE FUNCTIONELE ANALIST ..................................................................................22

6.4.

DE TESTER .....................................................................................................................................22 DE OPVOLGBAARHEID .................................................................................................................23


Versie

Page

0.7

3/23



1. PRÉSENTATIE VAN HET DOCUMENT 1.1. Introductie tot de discipline "Tests" Dit document presenteert een algemeen overzicht van de activiteiten van de discipline Tests van de FUP-methodologie. Het document antwoordt op de volgende vragen : Welke types van tests worden gedefinieerd in de loop van een project dat wordt gerealiseerd met FUP?

Welke verschillende actoren zijn betrokken bij het proces?

Wat zijn de belangrijkste artefacten die men moet hanteren in de benadering?

1.2. Tot wie is dit document gericht? Het richt zich tot de ICT-projectleider, de business-projectleider en de testers :


Versie

Page

0.7

4/23



2. POSITIONERING TEN OPZICHTE VAN DE LEVENSCYCLUS Binnen de levenscyclus van FUP hebben we hieronder de « workflow » weergegeven van de belangrijkste activiteiten van de discipline Tests, die moeten worden gerealiseerd tijdens een ontwikkelingsproject. Het onderstaande schema geeft een overzicht van het belang van deze discipline in de loop van een project. Men stelt vast dat de testdiscipline begint in de aanvangsfase met de identificatie van de acceptatiecriteria, dan verdergaat in de uitwerkingsfase en uiteraard een steeds belangrijkere rol gaat spelen wanneer men vordert in de fases van constructie en overgang. Het is van belang aan te tonen dat diverse tests worden uitgevoerd op het einde van de uitwerkingsfase, zodra de eerste functionaliteiten van het systeem zijn geleverd.


Versie

Page

0.7

5/23



3. TERMINOLOGIE Vooraleer de discipline Tests aan te vatten, willen we nog even het courante « vocabularium » in herinnering brengen dat men moet kennen wanneer men de problematiek van tests aankaart. Tester De tester definieert en organiseert de testcampagnes. - Hij stelt de testcases op met de steun van de gebruikers en de functionele analisten - Hij maakt de gegevensreeksen klaar - Hij voert de tests uit We merken op dat de tester ook kan toebehoren aan het projectteam ! Anomalie Een anomalie stemt overeen met een negatief resultaat dat wordt vastgesteld tijdens de uitvoering van een testcase of een probleem dat men tegenkomt in de loop van de uitvoering van een test. Een anomalie kan het volgende beschrijven : - een niet-conformiteit ten opzichte van een vereiste (niet-naleving van een specificatie), of - een probleem buiten de geteste toepassing dat de normale uitvoering van de test verhindert. Testcampagne Een testcampagne stemt overeen met de uitvoering van de tests die zijn voorzien in het testdossier, dit ten opzichte van een versie van de toepassing die in ontwikkeling verkeert. Testcase De testcase is de specificatie van alle elementen die de controle van een bepaalde vereiste mogelijk maken. De testcase wordt gekenmerkt door : een doelstelling, pre-voorwaarden, testgegevens (proefreeksen), een gedetailleerde procedure van de te realiseren acties voor het uitvoeren van de test en het controleren van één of meer functionaliteiten/vereisten, een verwacht resultaat, post-voorwaarden en eventueel manipulaties na de tests (zie volgende definitie). Het gedeelte procedure van de testcase moet in detail beschrijven hoe de tester de tests concreet gaat uitvoeren. Men moet nauwkeurig zijn in de beschrijving van dit gedeelte. Manipulaties na test Sommige tests vergen de uitvoering van manipulaties om de gevolgen van de test na zijn uitvoering weg te werken. Naargelang het geval kan men bijvoorbeeld de volgende manipulaties terugvinden: -

terugzetting tot nul van bepaalde velden die zijn toegevoegd in de database,

-

schoonmaak van gegevens die zijn toegevoegd aan sommige formulieren in de vensters van de toepassing,

-

schoonmaak van bestanden die zijn toegevoegd door de tests, en die niet langer nodig zijn,…

Testplan Het testplan bevat alle elementen die nodig zijn voor het opstarten van een testcampagne : de uit te voeren testcases, de doelstellingen, de planning, de middelen,…


Versie

Page

0.7

6/23



Testdossier Het testdossier bevat de details van de testcases en de automatische scripts Testbalans Te leveren prestatie die alle opeenvolgende balansen bevat van de testcampagnes die werden gevoerd in de loop van een project. Via deze balans kan men weten welke campagnes werden gerealiseerd in welke omstandigheden en met welke resultaten. Men kan er ook zijn voordeel mee doen bij een volgende versie van de toepassing. Criticaliteit

3

Evaluatie van de gevoeligheid van de elementen van de toepassing (functionele of technische aspecten, interfaces, …) volgens één of meer criteria (frequentie van gebruik van het element, frequentie van voorkomen van anomalieën inzake element in kwestie, impact van de nieuwe functionaliteiten, …). Testinspanningen Prioriteiten inzake tests, toegekend aan de elementen van de toepassing (functionele of technische aspecten, interfaces,…) in functie van de vereisten, de criticaliteit en de geïdentificeerde risico’s. Gegevensreeks Gegevens, vastgelegd in tabellen door de tester of geleverd door de FOD op basis van reële gegevens. Met de gegevensreeks kan men één of meer testcases laten verlopen. Testomgeving Geheel van materialen, programma’s, parameters en gegevens, noodzakelijk voor de uitvoering van een testcampagne. Gebruikersgroep In de tool Mercury Quality Center personen die hetzelfde profiel hebben (tester, projectleider, verantwoordelijke voor tests,...). Teststrategie Document met de krachtlijnen van de teststrategie; de algemene doelstellingen, de middelen om deze waar te maken en de door te voeren organisatie. Dit omvat : - de organisatie van de verschillende testfases, - de verschillende types van tests die zullen worden gerealiseerd - de te leveren documenten, - de organisatie van de tests (omgeving, tools, middelen). Eenheidstest Operatie onder de verantwoordelijkheid van de ontwikkelaar, bestaande uit het laten plaatsvinden van een geheel van tests om zich te vergewissen van de kwaliteit en de conformiteit van elke component die werd ontwikkeld.

Integratietests Geheel van tests waarmee men zich kan verzekeren van de kwaliteit van het ontwikkelde systeem ten aanzien van de vooropgestelde vereisten, de conformiteit ervan met de analyse en de integratie ervan in de externe componenten. 3

Deze terminologie wordt niet noodzakelijk gebruikt in de projecten bij de FOD Financiën, maar ze maakt deel uit van de risicoanalyse


Versie

Page

0.7

7/23



ICT-operator

Acceptatietests Contractuele operatie tijdens dewelke de toepassing wordt onderworpen aan een reeks van controles en waarvan het succes of de mislukking de acceptatie of de weigering van de toepassing bepaalt. Het is dus in de loop van deze activiteit dat de FOD Financiën kan nagaan of een toepassing die werd geleverd, overeenstemt ( « conform is ») met de vereisten en de specificaties zoals deze werden bepaald in de verschillende modellen (lijst met vereisten, model voor analyse, model voor conceptie). Functionele tests Geheel van tests waarmee men de overeenstemming van de toepassing met de functionele vereisten, beschreven in de lijst met vereisten, kan nagaan. Tests van niet-regressie Tests waarmee men kan nagaan of wijzigingen die zijn aangebracht aan het systeem, geen onvoorziene gevolgen hebben die het gedrag van het eerder gevalideerde systeem zouden kunnen aantasten. Ze hebben betrekking op de uitvoering van tests die reeds achter de rug zijn, om te verzekeren dat het systeem nog steeds voldoet aan de gespecificeerde vereisten. Tests van soliditeit Hiermee kan men het gedrag van de toepassing controleren in het licht van een belasting vanwege « abnormale » waarden of externe configuraties, zoals : o

waarden buiten de limieten en op de grens van de invoergegevens,

o

overschrijdingen van de capaciteitsnormen of de normen inzake het ritme van de belasting,

o

initialisatie in abnormale omstandigheden,

o

in een gedeeltelijk beschadigde omgeving,

o

capaciteit voor hervatting na incident,

o

maximaal aantal aangesloten terminals,

o

database bevolkt met maximum van gegevens

o

enz.

Installatietests Geheel van tests waarmee men zich kan verzekeren van de betrouwbaarheid van de procedures voor de installatie van een nieuwe versie van het systeem. Prestatietests Hiermee kan men nagaan of de vereisten inzake prestaties en capaciteiten van de toepassing om een bepaalde belasting aan te kunnen, worden gerespecteerd. De prestatietests bestaan vaak uit het meten van de responstijden, het nagaan van de bekwaamheid van een toepassing om een bepaald volume van transacties te ondersteunen, enz. Veiligheidstests De veiligheidstests concentreren zich op de controle van de mechanismen van het type SSO, de toegang tot de gegevens, enz.


Versie

Page

0.7

8/23



4. SCHEMATISCHE BESCHRIJVING VAN DE BENADERING De volgende figuur toont de inputs, de outputs en de activiteiten van de discipline Tests.

4.1. De inputs Bij wijze van input kunnen de deelnemers aan de discipline steunen op:

Het model van de gebruikscases

De vereisten

De bijkomende vereisten

De master-teststrategie voor het beschrijven van de globale teststrategie die wordt gehanteerd voor de projecten bij de FOD Financiën o Dit document wordt geleverd door de FOD Financiën ; het beschrijft de globale teststrategie van de bij de FOD Financiën gerealiseerde projecten o Beschrijft de testomgevingen o Beschrijft de testtools en de procedure voor het beheer van de anomalieën (de cyclus voor de verwerking van anomalieën) Dit document legt het verband met het document inzake de procedure voor levering van de FOD Financiën en de verschillende types testomgevingen.


Versie

Page

0.7

9/23



4.2. De outputs De verschillende artefacten die worden geproduceerd door de discipline, zijn: De acceptatiecriteria (O51) De teststrategie (O52) voor het beschrijven van de gehanteerde strategie voor een specifiek project o Dit document is uitgewerkt voor elk project op basis van de master-teststrategie ; het zet deze strategie om in testacties die zijn verspreid over de verschillende fases van het project, en definieert de verschillende testfases (eenheidstests en integratietests, acceptatie, pilootfase, enz.) die zullen worden gerealiseerd in de loop van het project. o Definieert de types van tests die zullen worden gerealiseerd in de loop van het project en de doelstellingen van de tests die zijn uit te voeren voor elke herhaling. o Definieert de noodzakelijke middelen voor de uitvoering van de strategie en de agenda voor de kwalificatie. o De eerste versie van de teststrategie moet worden gefinaliseerd bij het begin van de uitwerkingsfase (JE-M) De testdossiers (O53) o Bevat de details van de testcases, gedefinieerd op basis van de (functionele en technische) specificaties en de vereisten. o Dit document wordt geproduceerd voor elke herhaling of elke testcampagne. De testbalans (O54) voor de beschrijving van de ontmoete anomalieën en de globale resultaten, en het meten van de kwaliteit van wat werd geleverd. o

De rapporten over anomalieën die de beschrijving bevatten van de opgespoorde anomalieën ten aanzien van de testcases en de vereisten.

o

De globale testresultaten die: • In de vorm van syntheses of boordtabellen de resultaten bevatten die afkomstig zijn van de testcampagnes (het aantal uitgevoerde tests, het aantal anomalieën, hun mate van ernst, de effectief gerealiseerde reikwijdte van de tests, de gerealiseerde en niet-gerealiseerde tests, enz.. • Een kwalitatief advies over de toepassing bevatten • Een belangrijk element vormen in de beslissing om over te stappen naar de volgende herhaling/fase in de ontwikkelingscyclus. • De identificatie mogelijk maken van de terreinen van vordering die men in acht kan nemen in de volgende testfases

De balans van het prototype (O54) Dit is de testbalans die specifiek wordt toegepast op het prototype, als dat er is.


Versie

Page

0.7

10/23



4.3. De aaneenschakeling van activiteiten Het volgende diagram toont de aaneenschakeling van de activiteiten die worden ondernomen in het kader van de discipline Tests. Deze activiteiten worden vervolgens in detail beschreven in hoofdstuk Erreur ! Source du renvoi introuvable. – Beschrijving van de activiteiten :


Versie

Page

0.7

11/23



4.4. De geproduceerde artefacten In de onderstaande tabel hebben we een lijst opgemaakt met de volgens ons onontbeerlijke artefacten; we hebben ze georganiseerd op hiërarchische wijze.


Versie

Page

0.7

12/23



5. BESCHRIJVING VAN DE ACTIVITEITEN We herinneren er vooraf aan dat de eenheidstests geen deel uitmaken van de discipline Tests: ze maken deel uit van de discipline Implementering, omdat ze onlosmakelijk verbonden zijn met de constructie van de code die ze controleren. Laten we nu de belangrijkste activiteiten van het testproces in detail bekijken.

5.1. Voorbereidende activiteiten 5.1.1.

Definiëren van criteria voor acceptatie van de toepassing (A1)

Doelstelling De acceptatiecriteria zullen worden gedefinieerd in de loop van de aanvangsfase en verfijnd bij het opstarten van het project in de uitwerkingsfase. Methode De acceptatiecriteria zijn in het algemeen gebaseerd op:

de vereisten

de bijkomende vereisten

vereisten betreffende de geleverde documentatie,

...

Verantwoordelijke functie ICT- en business-projectleiders Geproduceerd artefact

Acceptatiecriteria


Versie

Page

0.7

13/23


5.1.2.


Definiëren van teststrategie (A2)

Doelstelling De teststrategie wordt ingeleid zodra de eerste elementen van de context van het project zijn verzameld, dat wil zeggen ofwel in de aanvangsfase, ofwel later in de uitwerkingsfase van het project (tussen de IJkpunten JI-0 en JE-M). Ze moet in elk geval ten laatste op het einde van de uitwerkingsfase worden geleverd VOOR het opstarten van de industrialisering van de ontwikkelingen. Methode Ze zal worden afgeleid op basis van de master-teststrategie met integratie van de specifieke elementen van het project. Ze zal vervolgens worden vervolledigd naarmate van de beschikbaarheid van verdere informatie (risico’s, criticaliteit) die uiteraard altijd kan evolueren in de loop van een project; dit document wordt dus het hele project lang gehandhaafd. De teststrategie moet de volgende punten aanpakken: De testinspanning doelgericht maken en er de eigenlijke teststrategie uit distilleren: hoe kan men een toepassing optimaal en zo efficiënt mogelijk testen. Dan identificeren van de acties die moeten worden uitgevoerd tijdens de hele levenscyclus van het project (definiëren van de testfases, …) Identificeren van de risico’s van het project en de criticaliteit van de elementen die zullen worden ontwikkeld Definiëren van de testomgevingen, Preciseren van de rollen en de verantwoordelijkheden van de betrokkenen.

Als men de realisatie van prestatietests beoogt voor het project, zal de teststrategie een hoofdstuk moeten bevatten over de te hanteren strategie op het vlak van de tests van belasting. Om een goede teststrategie uit te werken, is het noodzakelijk om een goede kennis te hebben van de functionele en technische vereisten van de toepassing, alsook van de risico’s; een kennisname van de lijst met risico’s wordt dus noodzakelijk geacht. Verantwoordelijke functie ICT-projectleider Opgelet : het feit dat de projectleider verantwoordelijk is, wil niet zeggen dat hij als enige actief is op dit niveau. Nemen eveneens deel aan deze activiteit: de business-projectleider, de architect, de functionele analisten, ... Geproduceerd artefact


Teststrategie

Versie

Page

0.7

14/23


5.1.3.


Invoeren van testomgevingen (A3)

Doelstelling Deze activiteit start bij het begin van de uitwerkingsfase, na de consolidatieherhaling, en zet zich verder tot de acceptatietests en de pilootfase, als er een pilootfase is voorzien in de teststrategie. Ze besaat uit het voorbereiden van de hardware- en softwareomgevingen (testomgevingen), de noodzakelijke gegevensreeksen voor de uitvoering van de tests, en de Mercury Test-tool om de uitvoering van de tests te kunnen volgen en de anomalieën te kunnen registreren. Men bereidt in deze activiteit ook de organisatie van de levering voor (packaging, referenties, procedure voor installatie van de toepassing, enz.) Indien dit een toegang behelst tot externe systemen, moet men de toegang tot en de installatie van testversies van deze systemen vragen voor de verschillende omgevingen, enz. Het aantal en het type van de testomgevingen wordt gedefinieerd in de master-teststrategie en eventueel aangepast in de specifieke teststrategie voor het project. Het is ook mogelijk dat de actoren contact moeten opnemen met ICT Operation om de invoering van de omgeving te finaliseren. Verantwoordelijke functie ICT-projectleider of tester


Versie

Page

0.7

15/23



5.2. Definitie en uitvoering van de tests 5.2.1. Definiëren van plan voor integratietests (via herhalingen) (A4) Het is belangrijk eraan te herinneren dat deze activiteit bij elke herhaling wordt herhaald. De integratietests zijn gespecificeerd door het projectteam. Ze bestaan uit het verzekeren van de totale dekking van de toepassing, zowel functioneel als nietfunctioneel. 5.2.1.1. Specificeren van functionele tests Doelstelling De functionele tests maken het mogelijk om te valideren dat de toepassing conform is met de functionele vereisten. Methode De tester specificeert de tests. Eventueel kan een gebruiker of iemand van de business de rol van tester spelen om meer specifieke businessaspecten of aspecten inzake het « gebruiksgemak » te valideren. De testcases moeten gedetailleerd specificeren wat er moet worden getest, met welke inputs, voor welk resultaat en onder welke voorwaarden. Om de functionele tests op te stellen, vertrekt men van de gebruikscases en de scenario’s en van de maquette van de gebruikersinterface. In de discipline Tests wordt een geheel van testcases gegenereerd op basis van de gebruikscases; hiermee kan men de conformiteit met de functionele vereisten nagaan. Verantwoordelijke functie Tester Geproduceerd artefact Testcase 5.2.1.2. Specificeren van niet-functionele tests Doelstelling Er kan ook een ander geheel van tests worden gegenereerd, ditmaal om de conformiteit van de toepassing na te gaan ten opzichte van de niet-functionele vereisten (technisch, ergonomie, veiligheid, enz.). Het is ook op dit niveau dat de uit te voeren tests van de belasting worden gedefinieerd, dit op basis van het gemiddelde gedrag van de gebruikers (eventueel gerangschikt per groep, waarbij elke groep zijn gemiddelde gedrag heeft) en de spreiding van de belasting over een bepaalde tijdsspanne. Methode Dit type van testcases wordt uitgewerkt op basis van de bijkomende specificaties. Verantwoordelijke functie Tester Geproduceerd artefact Testcase


Versie

Page

0.7

16/23



5.2.1.3. Uitvoeren van tests Doelstelling Deze activiteit bestaat uit het laten verlopen van de testcases in overeenstemming met het testdossier, het registreren van de resultaten en de opvolging in het geval van anomalieën, en het produceren van een testbalans. Hetzelfde plan voor de integratietests speelt zich in verschillende omgevingen volgens de aard van de doelstellingen: In de packaging-omgeving, onder de verantwoordelijkheid van de leverancier, gaat men over tot het eerste niveau van de test na de assemblage van de verschillende ontwikkelde componenten die uitsluitend aan een eenheidstest werden onderworpen. Wanneer de packaging-tests overtuigend zijn, speelt hetzelfde testplan zich af in verschillende integratieomgevingen, onder de verantwoordelijkheid van de FOD ; dit om de conformiteit van het systeem na te gaan ten opzichte van de interne normen en de externe componenten en toepassingen (CCFF, RDC,…). Methode Naargelang de aard van de anomalie, haar ernst en de eventuele impact van de uit te voeren correctie, zal men beslissen over de herhaling waarin de correctie moet worden opgenomen. Het einde van elke test wordt geconcretiseerd door de toekenning van een resultaat; hieronder hebben we de meest voorkomende resultaten opgesomd! Test met succes uitgevoerd Testresultaat niet correct (de test is tot het einde gegaan, maar de uitgevoerde controles in de loop van de test waren niet correct) Test niet voltooid (de test is niet tot het einde uitgevoerd) Niet uitgevoerd Voor elk incorrect resultaat wordt een anomaliefiche uitgewerkt; vervolgens wordt de procedure voor het beheer van anomalieën toegepast. Verantwoordelijke functie Tester, RDC(voor DB-aspecten) Geproduceerd artefact


Testdossier

Versie

Page

0.7

17/23


5.2.2.


Specificeren en uitvoeren van acceptatietests (A5)

Doelstelling De acceptatietests worden gerealiseerd door de partij die het systeem in ontvangst neemt wanneer het systeem in zijn totaliteit kan worden geleverd. Ze bestrijken alle aspecten van de vereisten: de functionele en de niet-functionele aspecten. Dit omvat dus de : 1. functionele tests 2. niet-functionele tests 3. installatietests 4. veiligheidstests 5. prestatietests

Het doel is niet alle tests die het projectteam tijdens deze tests heeft uitgevoerd, nog eens over te doen, maar een subgeheel van tests uit te voeren. Het gaat om het valideren van het systeem vanuit een business-oogpunt. Methode De tests worden gerealiseerd in een omgeving die de productieomgeving weerspiegelt (haar configuratie en haar omstandigheden). Het gaat dus om een specifieke omgeving die de acceptatieomgeving van de FOD Financiën vormt. Voorafgaandelijke voorwaarden : o

De specificaties van de acceptatietests zijn compleet

o

Het testdossier, gerealiseerd door het projectteam, is beschikbaar samen met zijn testbalans

o

De omgevingen, de tools, de testmiddelen en de voorzieningen zijn beschikbaar

o

De acceptatiecriteria zijn bepaald tussen de FOD Financiën en de leverancier, en ze worden nageleefd

Rol van het projectteam o

Eventueel assistentie verlenen bij de uitvoering van de tests

o

De diagnose uitvoeren bij anomalieën

o

Elke discrepantie signaleren

o

Nota nemen van de bijkomende tests die zouden moeten worden gerealiseerd om een complete testdekking te verkrijgen ten aanzien van de vereisten.


Versie

Page

0.7

18/23



Rol van de FOD Financiën o De FOD Financiën is verantwoordelijk voor de fase van de acceptatietests o Hij bepaalt op basis van het dossier met de acceptatietests en in functie van het verworven vertrouwen tijdens de constructeur-tests, de lijst met uit te voeren tests o Hij voert de tests uit o Hij stelt de lijst met anomalieën op en legt deze voor aan de leverancier o Hij maakt de balans van deze testgroep op Verantwoordelijke functie Business-projectleider Geproduceerd artefact Acceptatierapport


Versie

Page

0.7

19/23



5.3. Activiteiten voor afsluiting van een testcampagne 5.3.1.

Creëren van een fiche met anomalieën (A6)

Doelstelling Als de uitkomst van de uitvoering van een test "niet OK" is of als de in een testcase beschreven procedure foutief is, als er zich een werkingsprobleem heeft voorgedaan of als er zich hinder heeft voorgedaan tijdens de uitvoering of simpelweg als men een observatie wenst uit te voeren, dan opent men in al die gevallen een fiche voor anomalieën en beschrijft men het probleem. Methode Er is een workflow die exact definieert hoe men een anomalie moet openen, aan wie ze moet worden toegekend, welk niveau van ernst eraan moet worden toegekend, enz. Dit is gespecificeerd in de masterteststrategie. Vervolgens worden al deze anomalieën geanalyseerd door het projectteam; ze worden gecorrigeerd in een nieuwe herhaling en de correcties worden opnieuw getest. Verantwoordelijke functie Tester Geproduceerd artefact Fiche met anomalieën 5.3.2. Opmaken van Balans van Campagnes (A7) Voor elke testcampagne die werd uitgevoerd, stelt men een balans op die dit omvat: De mate van dekking De mate van succes Een boordtabel met het aantal anomalieën en hun niveau van ernst Een kwalitatief advies over de toepassing Men kan ook een globale balans opmaken van het geheel van de testfases die werden gerealiseerd via een consolidatie van alle balansen. Verantwoordelijke functie Tester Geproduceerd artefact Testbalans


Versie

Page

0.7

20/23


5.3.3.


Realiseren van pilootfases (A8)

Doelstelling De pilootfases (de zogenaamde « experimenten ») worden vaak behartigd door de gebruikers. Ze omvatten voornamelijk : 1. functionele tests 2. tests van het type « gebruiksgemak » voor het valideren van alle aspecten van de gebruikersinterface in een reële productiesituatie Methode De pilootfases dienen voor het testen van de toepassing in de productieomgeving, alsook het testen van de exploitatie van de toepassing in de productieomgeving. Rol van het projectteam o

Assisteren bij de uitvoering en de exploitatie

o

Helpen bij de diagnose

Rol van de FOD Financiën o

Is verantwoordelijk voor deze testgroep

o

Definieert de tests en voert ze uit

o

Stelt lijst met anomalieën op en legt deze voor aan het projectteam

o

Maakt balans op van deze testfase

Verantwoordelijke functie Business-projectleider


Versie

Page

0.7

21/23



6. VERANTWOORDELIJKHEDEN – GEZIEN PER FUNCTIE Dit hoofdstuk heeft tot doel voor elke actor, verantwoordelijk op een bepaald testniveau, de activiteiten en artefacten te tonen waarvoor hij verantwoordelijk is.

6.1. De ICT-projectleider - Werkt de teststrategie uit in overleg met de « business-projectleider » en met de functionele analist en de architect van het project. - Is verantwoordelijk voor de toepassing van de teststrategie die werd gedefinieerd voor het project, en dit voor alle kwalificatiefases.

6.2. De business-projectleider Neemt deel aan de uitwerking van de teststrategie met formulering van vereisten, en kondigt de acceptatie van de toepassing af.

6.3. De gebruikers en de functionele analist - Stellen de testcases op of assisteren bij de opmaak van de testcases. - Nemen deel aan of assisteren bij de uitvoering van de tests - Helpen bij de analyse van de testresultaten. - Nemen eventueel deel aan de opmaak van de testbalansen.

6.4. De tester Als hij een functie als verantwoordelijke heeft : - Stuurt de verschillende testfases en produceert de testbalans op het einde van de testfase. - Identificeert de middelen. - Evalueert de noodzakelijke dekking van de tests en definieert de uit te voeren tests voor niet-regressie. - Voert de teststrategie uit.

In elk geval : - Bouwt de testcases met de gebruikers en/of de functionele analist. - Laat de in het testdossier voorziene tests doorgaan. - Analyseert en interpreteert de resultaten. - Registreert de verkregen resultaten. - Vult de fiches met anomalieën in.


Versie

Page

0.7

22/23



7. DE OPVOLGBAARHEID Hoe ziet men op pragmatische wijze de opvolgbaarheid in het testproces? Er vallen twee voorschriften waar te nemen: Men moet de testcases opvolgen ten aanzien van de vereisten. Men moet de testresultaten opvolgen ten aanzien van de testcases.

Als men deze twee grote aanbevelingen goed in acht neemt, dan is men in staat om heel precies de reikwijdte van de tests te kennen ten opzichte van de vereisten van de toepassing. Men weet dus welke delen van de toepassing werden getest en welke nog niet. Men voldoet aan de doelstelling van volledigheid van de tests ten opzichte van de vereisten. Men voldoet aan de doelstelling van handhaving van de toepassing, omdat men in staat is een analyse te realiseren van de impact van een wijziging van de vereisten, en aldus makkelijk de tests voor niet-regressie te bepalen.


Versie

Page

0.7

23/23

FUP 1.0 D5- Test > Gebruiksaanwijzingen


D5– TEST GEBRUIKSAANWIJZINGEN


X


1 2

\FUP\FUP 1.0_NL\Gebruiksaanwijzingen\D5\FUP-GAW-D5-Tests.doc



2

Bijwerking

Versie

Page

02/2007

0.2

1/27




Auteur

FUP

Versie

Aard

Januari 2007 Februari 2007

Unisys Unisys

1.0 1.0

0.1 0.2

Oorspronkelijke versie Versie gecorrigeerd na opmerkingen van Giovanni Merlini

Bijwerking

Versie

Page

02/2007

0.2

2/27



INHOUDSTAFEL 1.

INLEIDING .........................................................................................................................................5 1.1.

DOEL VAN HET DOCUMENT.................................................................................................................5

1.2.

VOORWERP VAN HET DOCUMENT .......................................................................................................5

1.3.

GEBRUIKTE AFKORTINGEN .................................................................................................................7

1.4.

REFERENTIEDOCUMENTEN ................................................................................................................7

2.

GEBRUIKTE TOOLS.........................................................................................................................8 2.1.

TEST-PAKKET: QUALITY CENTER – QUICK TEST – LOAD RUNNER .......................................................8

2.2.

STARTEAM........................................................................................................................................8

2.3.

CALIBER RM.....................................................................................................................................8

3.

LIJST MET ARTEFACTEN EN TE LEVEREN PRESTATIES ..........................................................9

4.

DE ACCEPTATIECRITERIA (O51) .................................................................................................10

5.

DE TESTSTRATEGIE, AFGELEID VAN DE MASTER-TESTSTRATEGIE (O52).........................11

6.

DE TESTDOSSIERS (O53) .............................................................................................................12 6.1.

SYNCHRONISATIE VAN DE TOOLS .....................................................................................................12

6.2.

STRUCTUUR VAN HET TESTPLAN ......................................................................................................12

6.3.

TESTCASES (O53.1) .......................................................................................................................13

6.3.1.

Testgegevens ........................................................................................................................14

6.3.2.

Structuur van het veld beschrijving .......................................................................................14

6.4. 7.

GEAUTOMATISEERDE TESTSCRIPTS (O53.2) ....................................................................................15 DE TESTBALANS (O54) .................................................................................................................17

7.1.

UITVOERING VAN DE TESTS..............................................................................................................17

7.2.

TESTRESULTATEN (O54.1)..............................................................................................................17

7.3.

ANOMALIEËN (O54.2) .....................................................................................................................18

7.3.1.

Tests in ontwikkeling .............................................................................................................19

7.3.2.

Workflow................................................................................................................................19

8.

DE BALANS VAN HET PROTOTYPE (O55) ..................................................................................22

9.

OPVOLGBAARHEID TUSSEN CALIBERRM EN MERCURY QUALITY CENTER ......................23 9.1.

INVOEREN VAN DE VEREISTEN IN QC................................................................................................23

9.2.

UPDATEN VAN DE VEREISTEN ...........................................................................................................23

9.3.

SYNCHRONISEREN VAN DE BEELDEN IN CRM EN QC ........................................................................23

10.

AANPASSING MERCURY QUALITY CENTER .............................................................................24

10.1.

AANMAAK VAN RAPPORTEN ..........................................................................................................24

10.2.

TOEVOEGING VAN EEN VELD ........................................................................................................24

Bijwerking

Versie

Page

02/2007

0.2

3/27


10.3.

BEHEER VAN FAVORIETEN ............................................................................................................24

10.3.1.

Document Generator .........................................................................................................24

10.3.2.

Reports ..............................................................................................................................25

10.4. 11.


FILTERS ......................................................................................................................................25

GEBRUIK VAN STARTEAM ...........................................................................................................26

11.1.

BEHEER VAN DE LINKS TUSSEN ELEMENTEN VAN STARTEAM ..........................................................26

11.1.1.

Creatie van een link ...........................................................................................................26

11.1.2.

Visualisatie van een link ....................................................................................................26

11.1.3.

Toegang tot de Change Request tijdens een Check-in.....................................................26

11.2.

AANMAAK VAN RAPPORTEN ..........................................................................................................27

11.3.

W IJZIGING VAN FILTERS ...............................................................................................................27

Bijwerking

Versie

Page

02/2007

0.2

4/27



1. INLEIDING De werkwijze geeft aan hoe de tools moeten worden gebruikt en hoe de artefacten moeten worden georganiseerd in het kader van de discipline ‘Tests’.

1.1.

DOEL VAN HET DOCUMENT

Dit document heeft als hoofddoel het specificeren van de te gebruiken tools, de locatie, de structuur en het formaat van de artefacten die worden gegenereerd in de loop van de discipline ‘Tests’. De te volgen benadering voor het genereren van de artefacten wordt beschreven in het document FUP-D5-Test.doc.

1.2.

VOORWERP VAN HET DOCUMENT

De inhoud van de artefacten staat beschreven in het document dat de benadering beschrijft die men moet hanteren in de loop van de activiteiten van de discipline (FUP-D5-Test.doc.). Voor elk door de discipline geproduceerd artefact vermeldt dit document de volgende informatie: ►FUNCTIE

Welke functie is verantwoordelijk voor het artefact

►TOOL

Gebruikte tool voor productie van artefact. Het gaat hoofdzakelijk om één van de door FUP aanbevolen tools, maar ook om elk ander noodzakelijk programma (tekstverwerking, spreadsheets, …).

►FORMAAT

Hier vindt men het type van artefact. Het kan gaan om een type van diagram, een type van vereisten, het formaat van het bestand (.doc, .html,…). De benaming van het formaat van de artefacten, beheerd door Together, herneemt degene die van kracht zijn in de tool (Use Case Diagram, Sequence Diagram, …).

►MODEL

Naam van het modeldocument of het master-document waarop het artefact is gebaseerd. Vb. : FUP-Template_Visie_nl.doc

►ACTIVITEIT

Axx – Identificatie en naam van de activiteit waarnaar wordt verwezen in het document met de beschrijving van de activiteiten, gekoppeld aan de discipline ‘Tests’.

►LOCATIE

Folder / package waarin het artefact zich bevindt.

►NAAMGEVING

Na te leven afspraken inzake naamgeving. Deze conventies zijn belangrijk voor de goede werking van de FUP-standaardrapporten. Als de afspraken inzake naamgeving niet worden nageleefd, is de inhoud van de rapporten niet gegarandeerd.

►OPVOLGBAARHEID

Minimaal te respecteren links voor mogelijkheden tot opvolging. Opvolging in CaliberRM of andere elementen van de modellering.

Bijwerking

Versie

Page

02/2007

0.2

5/27


►RAPPORT


Uitleg over de hulp die door SupDev wordt verleend voor de aanmaak van het rapport inzake het artefact. In het geval van rapporten, aangemaakt door QC, neemt men hier met name de naam van de favorieten, die te gebruiken zijn voor de aanmaak van het 3 rapport . In het geval van rapporten, aangemaakt door ST, neemt men hier met name de naam van de filter, die wordt gebruikt voor de keuze van de in het rapport 4 weer te geven velden . In de andere gevallen herneemt men hier de noodzakelijke informatie voor het aanmaken of manueel creëren van de rapporten.

► TE LEVEREN PRESTATIE (MODEL)

Naam van de te leveren prestatie die verwijst naar het artefact (naam van het model van te leveren prestaties)

Andere paragrafen verrijken dit document. Een eerste paragraaf beschrijft bondig de rollen van de verschillende tools die worden gebruikt in het kader van deze discipline. Vervolgens brengen meerdere paragrafen aan het einde van het document details over de manier om de tools te gebruiken voor de realisatie van taken die worden uitgelegd in het document.

3

De procedure voor de aanmaak van rapporten met Quality Center wordt in detail uitgelegd in het gedeelte ‘Aanpassing Mercury Quality Center’.

4

De procedure voor de aanmaak van rapporten met Starteam wordt in detail uitgelegd in het gedeelte ‘Gebruik van Starteam’.

Bijwerking

Versie

Page

02/2007

0.2

6/27


1.3.

GEBRUIKTE AFKORTINGEN

QC

Quality Center

QT

Quick Test

CRM

CaliberRM

ST

Starteam

LR

Load Runner

1.4.


REFERENTIEDOCUMENTEN

FUP-D5-Test.doc : beschrijving van de te volgen benadering voor de realisatie van de artefacten. Dit document bevat ook de beschrijving van de artefacten, opgenomen in dit document.

FUP-Synthese.xls : tabel met overeenstemming tussen alle activiteiten, artefacten, te leveren prestaties, hun modellen en de rapporten voor het distilleren van de in de tools ingevoerde gegevens.

FUP-Master-teststrategie v0.3.doc : document over de master-teststrategie dat alle te overwegen elementen en alle toe te passen acties omvat opdat de ontwikkelde producten de vooropgestelde kwaliteit zouden halen.

Bijwerking

Versie

Page

02/2007

0.2

7/27



2. GEBRUIKTE TOOLS Vooraleer in detail in te gaan op de eigenlijke werkwijzen, is het nuttig om de tools te overlopen die worden toegepast in dit document.

2.1.

TEST-PAKKET: QUALITY CENTER – QUICK TEST – LOAD RUNNER

Het is belangrijk het verschil te kennen tussen deze verschillende tools voordat men start met de tests. De centrale tool van het pakket is Quality Center, toegankelijk via een webbrowser. Met deze tool kan men de volgende taken uitvoeren: -

beheren van het testplan,

-

beheren van het testlab,

-

opslaan van de tests en de automatische scripts (rol van directory),

-

afspelen van de scripts.

QC kan meerdere types van scripts beheren (manuele, QT-scripts, LR-scripts,…). De tools Quick Test en Load Runner zijn tools die kunnen worden gebruikt door QC. Hun belangrijkste rol bestaat in het registreren van de automatische scripts, elk in zijn formaat. Ze kunnen ook hun eigen scripts opnieuw afspelen. De door deze tools geregistreerde scripts kunnen worden opgeslagen, hetzij lokaal, hetzij in de directory van QC. De geautomatiseerde scripts van Quick Test zijn testscripts die kunnen worden afgespeeld op een webbrowser. Ze maken de automatisering mogelijk van de interacties van de gebruiker met een webtoepassing via zijn browser. De Load Runner-scripts worden gebruikt voor het simuleren van tests van belasting, types van niet-functionele tests. We merken ook op dat een script van om het even welk formaat kan worden gecreëerd door QC, maar dat dit wordt gecreëerd in een lege toestand. Om het te implementeren, moet men een registrator gebruiken (QT of LR). Om het af te spelen, kan om het even welke van de drie tools worden gebruikt, met de specifieke aspecten die zullen worden uitgelegd in dit document.

2.2.

STARTEAM

Deze tool is een tool voor versionning. Hij wordt gebruikt in deze werkwijzen voor het opslaan en beheren van de anomalieën in de vorm van Change Requests. Er bestaat ook een onderliggende integratie tussen ST en QC, waardoor QC de versionning van de tests kan realiseren. Op die manier kunnen meerdere gebruikers op hetzelfde moment werken aan de tests. Deze ‘ST’-laag is niet zichtbaar voor de gebruikers.

2.3.

CALIBER RM

Deze tool maakt het beheer van de vereisten mogelijk. De definitie van de vereisten moet niet gebeuren in het kader van D5. Hier zorgt men alleen voor de invoer van deze vereisten in QC. Hier wordt dus de integratie CRM – QC in detail beschreven.

Bijwerking

Versie

Page

02/2007

0.2

8/27



3. LIJST MET ARTEFACTEN EN TE LEVEREN PRESTATIES Nr. artéfact

ARTEFACT

O51

De acceptatiecriteria (A51)

O52

De teststrategie, afgeleid van de master-teststrategie (A52) De testdossiers (A54)

O53

TE LEVEREN PRESTATIES

L51-De teststrategie, afgeleid van de master-teststrategie L52-Testdossier

O53.1

-

Testcases

O53.2

-

Geautomatiseerde testscripts

O54

De testbalans (A56), (A57)

O54.1

-

Testresultaten

O54.2

-

Anomalieën

O55

L53-Testbalans

De balans van het prototype (A58)

Bijwerking

Versie

Page

02/2007

0.2

9/27



4. DE ACCEPTATIECRITERIA (O51) ►FUNCTIE

ICT- en businessprojectleider

►TOOL

Tekstverwerker

►FORMAAT

Formaat .doc of .pdf

►ACTIVITEIT

A51 – Definiëren van de acceptatiecriteria van de toepassing

►LOCATIE

05_Tests/01_Plans

►MODEL

NA

►NAAMGEVING

De naamgeving van het bestand hangt af van de afspraken inzake naamgeving die worden gehanteerd voor het project.

►OPVOLGBAARHEID

NA

►RAPPORT

SupDev stelt geen enkel basisrapport voor voor dit element.

►TE LEVEREN

NA

PRESTATIE (MODEL)

Bijwerking

Versie

02/2007

0.2

Page

10/27



5. DE TESTSTRATEGIE, AFGELEID VAN DE MASTER-TESTSTRATEGIE (O52) De master-teststrategie kan eventueel worden geïndividualiseerd voor een bepaald project. Alleen de toegevoegde en/of gewijzigde elementen zullen worden hernomen in het artefact. Voor het overige blijft de master-teststrategie impliciet van toepassing. ►FUNCTIE

ICT-projectleider

►TOOL

Tekstverwerker

►FORMAAT

Formaat .doc of .pdf

►ACTIVITEIT

A52 – Definiëren van de teststrategie

►LOCATIE

05_Tests/01_Plans

►MODEL

FUP-TPL51-D5-Afgeleide master-teststrategie.doc

►NAAMGEVING

NA

►OPVOLGBAARHEID

NA

►RAPPORT

Het rapport moet het formaat van het gegeven model hebben. Dit bevat de structuur van het master-document. Als de behoeften van het project maken dat dit document een wijziging vereist, volstaat het om dit document te wijzigen op de plaats waar het probleem zich voordoet. Het is uiteraard noodzakelijk om elke wijziging te verantwoorden en te motiveren. Een wijziging kan van de volgende orde zijn :

►TE LEVEREN

-

Een punt dat niet van toepassing is op het project. Men beschrijft dan in de paragraaf waarom dit punt niet van toepassing is.

-

Een toe te voegen punt. Men voegt dan een paragraaf toe in de basisstructuur, men verantwoordt en men legt de verschijning van deze paragraaf uit.

L51-De teststrategie, afgeleid van de master-teststrategie

PRESTATIE

Bijwerking

Versie

02/2007

0.2

Page

11/27



6. DE TESTDOSSIERS (O53) 6.1.

SYNCHRONISATIE VAN DE TOOLS

Voordat de eigenlijke artefacten worden geproduceerd, moet men CRM en QC synchroniseren. Dit komt neer op het invoeren van de vereisten van CRM in QC, opdat de in deze tool gecreëerde tests kunnen worden gekoppeld aan de vereisten. Het is ook van belang te noteren dat de synchronisatien niet continu is. Dat wil zeggen dat, wanneer een vereiste verandert in CaliberRM, deze niet automatisch wordt veranderd in Mercury. Men moet de vereisten dus updaten wanneer ze veranderen. Het gebruik van deze tools voor het uitvoeren van deze handelingen wordt uitgelegd op het einde van dit document, in het gedeelte ‘Opvolgbaarheid tussen CaliberRM en Mercury Quality Center’.

6.2.

STRUCTUUR VAN HET TESTPLAN

Voordat de eigenlijke testcases kunnen worden opgeslagen, moet men de gepaste structuur creëren in Quality Center. Deze structuur wordt gecreëerd in het testplan van QC. De structuur hangt af van de interne structuur van de projecten. Het kan evenwel interessant zijn de volgende ‘superstructuur’ te hanteren:

De folder ‘Herbruikbare acties’ kan worden gebruikt voor het opslaan van de acties die gemeenschappelijk kunnen zijn voor meerdere automatische scripts, en die geen tests op zich vormen. Hier vindt men meestal bijvoorbeeld login-acties, die kunnen worden gebruikt door veel testtypes. Deze acties stemmen uiteraard niet overeen met logische testcases. De andere folders stemmen overeen met de versies van de toepassing. Naargelang de projecten kan het gebeuren dat het testplan en/of de tests al dan niet sterk variëren van de ene versie tot de andere. Is dat het geval, dan is het nuttig om een directory per versie te hebben. Binnenin elke versie hangt de structuur af van het project. De methodologie stelt geen te volgen plan voor. Men moet ook noteren dat men in deze structuur functionele én niet-functionele tests terugvindt.

Bijwerking

Versie

02/2007

0.2

Page

12/27


6.3.


TESTCASES (O53.1)

Er kunnen verschillende benaderingen worden gehanteerd in functie van de testers en in functie van de te testen cases. QC stelt een structuur voor in de vorm van directory’s. In deze directory’s kunnen ‘testobjecten’ in de zin van QC worden opgeslagen, die elk een testscript kunnen bevatten (dat verschillende formaten kan hebben: QT, manueel, LR,…). 1. De eerste methode bestaat uit de stelling dat de testcase wordt geïmplementeerd door één enkel script. Men zal dus een QC-test hebben die een testcase vertegenwoordigt, met één enkel script. 2. De tweede methode gaat ervan uit dat de testcase kan worden geïmplementeerd door verschillende scripts. In dit geval zal men een test per testscript moeten hebben, waarbij elke test dezelfde testcase vertegenwoordigt. 3. Het kan ook voorkomen dat om een of andere reden geen enkel script een testcase implementeert. In dit geval zal er toch een test aanwezig zijn in QC. Al deze verschillende uitgangspunten zijn geldig. Maar vanuit het oogpunt van reporting moeten de gegevens over de testcase worden ingevoegd in een QC-test; anders zullen deze gegevens niet worden opgenomen in de rapporten, aangemaakt door QC. Inderdaad, de gegevens die zijn gekoppeld aan een directory, worden niet opgenomen in de rapporten. Indien men kiest voor de tweede methode, moet men dus de beschrijving van de testcase in één van de tests opnemen.

►FUNCTIE

Tester

►TOOL

Module Test Plan van Mercury Quality Center.

►FORMAAT

De in Mercury gecreëerde testcases kunnen vooraf worden geformatteerd, naargelang de test die de testcase zal implementeren (Quick Test-script, Load Runner-script, manueel script). Het formaat blijft hetzelfde naargelang het gekozen type van script. Men heeft de volgende 8 elementen nodig, die kunnen worden ingevoegd op verschillende plaatsen in de QC-test. -

In het panel ‘description’ van de test kan men doelstelling (1), pre-voorwaarden (2) en post-voorwaarden (3) invoegen, alsook de manipulaties na de test (5).

-

In de tab ‘attachement’ kan men de bestanden plaatsen die de testgegevens bevatten (4). Deze gegevens kunnen eventueel impliciet worden opgeslagen in de automatische scripts. Een beschrijving van deze gegevens kan worden toegevoegd in de tab ‘description’.

-

In de tab ‘Design steps’ kan men de gedetailleerde procedure voor de uit te voeren acties (6) plaatsen, alsook de verwachte resultaten (7) voor de verschillende stappen van de test. In de automatische scripts kunnen de verwachte resultaten impliciet worden opgeslagen in het testscript.

-

In de tab ‘Reqs Coverage’ kan men de vereisten invoegen die worden gecontroleerd door de test (8). Zo krijgt men een idee van de dekking van de vereisten door de tests.

Om zeker te zijn dat al deze informatie wordt opgenomen in de beschrijving van de testcase, is het belangrijk de structuur aan te houden die hieronder wordt vermeld in ‘Structuur van het veld beschrijving’ ►LOCATIE

De testcases bevinden zich in de structuur, bepaald in het testplan van QC.

Bijwerking

Versie

02/2007

0.2

Page

13/27



De gedefinieerde rapporten kunnen worden opgeslagen in 05_Tests/03_Dossiers. ►ACTIVITEIT

A54 – Definiëren van het plan voor de integratietests en uitvoering van de tests

►MODEL

FUP-TPL52-D5-Testdossier.doc. Dit model bevat de informatie over de testcases alsook de automatische scripts. Deze beide informaties zijn aan elkaar gekoppeld in QC.

►NAAMGEVING

Door de methodologie wordt geen enkele strategie bepaald inzake naamgeving; deze kan eigen zijn aan elk project. Er wordt echter aanbevolen een methodologie te hanteren waarmee men makkelijk het onderscheid kan maken tussen een testcase van een vereiste (requirement) en een gebruikscase (use case).

►OPVOLGBAARHEID

Integratie CRM – QC. De vereisten kunnen worden ingevoerd in QC, om te worden opgevolgd.

►RAPPORT

Het rapport wordt aangemaakt door QC, met gebruikmaking van de favoriet . Dit rapport vermeldt de informatie, hierboven beschreven in ‘formaat’, en is opgedeeld in twee stukken: -

een stuk dat dient voor de beschrijving van de testcases en de gedetailleerde procedure,

-

een stuk dat de dekking van de vereisten vermeldt, met opgave van elke vereiste, alsook de tests die de vereiste dekken.

Het is mogelijk dat men zich wil beperken tot een subgeheel van tests, bijvoorbeeld een versie van de toepassing, weergegeven door 5 een folder. Men kan tests selecteren met gebruikmaking van filters . ►TE LEVEREN

L52-Testdossier

PRESTATIE

6.3.1.

Testgegevens

De testgegevens kunnen verschillende formaten hebben. -

Eenvoudig ASCII-bestand.

-

Database.

-

Spreadsheet: dit komt het meest voor bij automatische testscripts. De excel-sheet met de gegevens kan worden opgenomen in het automatische testscript.

-

Testgegevens gegenereerd door een programma.

-

Distillatie van testgegevens vanuit bron van oorsprong (vb. : RDC-database).

Deze verschillende bestandsformaten kunnen als bijlage worden opgeslagen in een QC-testcase.

6.3.2.

Structuur van het veld beschrijving

Om alle informatie te bevatten die wordt vereist door de methodologie, moet het veld ‘Beschrijving’ van elke testcase de volgende voorgestelde structuur aanhouden :

5

-

Doelstellingen,

-

Pre-voorwaarden,

Zie gedeelte over filters

Bijwerking

Versie

02/2007

0.2

Page

14/27


-

Testgegevens,

-

Post-voorwaarden,

-

Manipulaties na de test.


Deze structuur wordt automatisch voorgesteld wanneer men een nieuwe test creëert in QC.

6.4.

GEAUTOMATISEERDE TESTSCRIPTS (O53.2)

De geautomatiseerde testscripts zijn slechts nuttig in bepaalde gevallen. -

Ze kunnen worden gebruikt wanneer een test meerdere keren opnieuw moet worden afgespeeld. Het is dus niet nodig om tijd de besteden aan het automatiseren van een script dat niet opnieuw zal worden gebruikt. Het is bijvoorbeeld interessant om een batterij van tests opnieuw af te spelen vooraleer men een levering gaat uitvoeren.

-

Ze kunnen worden gebruikt wanneer een toepassing (of een versie van de toepassing) tot volle rijpheid is gekomen. Als men immers QT-tests creëert wanneer een toepassing nog onderhevig is aan transformaties, zullen de scripts vaak moeten worden herschreven en kan het tijdverlies enorm zijn.

-

Het is efficiënter ze te gebruiken zodra een serie manuele tests werd uitgevoerd. De manuele tests brengen een aantal fouten aan het licht en de automatische scripts concentreren zich vooral op de meer gevoelige elementen van de toepassing. Dit leunt sterk aan bij de vorige opmerking. Een stabiele toepassing is inderdaad reeds enigszins manueel getest.

Tot besluit moet men de automatische tests dus op intelligente wijze gebruiken ; men moet er zeker van zijn dat ze een meerwaarde brengen.

►FUNCTIE

Tester

►TOOL

Mercury Quality Center Mercury Quick Test Mercury Load Runner

►FORMAAT

Quick Test-testscript, weergegeven door LoadRunner-testscript, weergegeven door

in Quality Center. in Quality Center.

►ACTIVITEIT

A54 – Definiëren van plan voor integratietests en uitvoering van de tests

►LOCATIE

De structuur hangt af van de tool. Omdat de QC-tests een versionning ondergingen in ST, kan men de tests zien vanuit twee verschillende invalshoeken. De tests zijn echter zichtbaar via ST, maar mogen slechts toegankelijk zijn via QC of QT. Structuur van QC De geautomatiseerde testscripts moeten de testcases implementeren die zijn bepaald in het testplan. De automatische scripts zijn dus gekoppeld aan de vooraf gedefinieerde testcases. Structuur van ST De automatische scripts bevinden zich in de folder 05.Tests/qctests. Deze tests mogen uitsluitend toegankelijk zijn via QC of QT. Toegang via ST en/of wijzigingen kunnen

Bijwerking

Versie

02/2007

0.2

Page

15/27



gegevensverlies veroorzaken. ►MODEL

FUP-TPL52-D5-Testdossier.doc. Dit model bevat de informatie over de testcase alsook de automatische scripts. Deze beide informaties zijn aan elkaar gekoppeld in QC.

►NAAMGEVING

De scripts zullen de namen van de testcases dragen. Als meerdere scripts dezelfde testcase implementeren, zal er een afspraak inzake naamgeving moeten worden gekozen die compatibel is met het project.

►OPVOLGBAARHEID

NA

►RAPPORT

NA

►TE LEVEREN

L52-Testdossier

PRESTATIE

Bijwerking

Versie

02/2007

0.2

Page

16/27



7. DE TESTBALANS (O54) 7.1.

UITVOERING VAN DE TESTS

Om de testresultaten te bekomen, moet men eerst de tests uitvoeren. De uitvoering van manuele tests hangt af van de stappen, beschreven in de testcases. De uitvoering van automatische tests vergt het gebruik van QT of de module ‘Test Lab’ van QC. -

Wanneer men een script uitvoert vanuit QT, kan men de resultaten lokaal opslaan of op de server. Als het testscript nog wordt uitgewerkt, wordt aanbevolen om de resultaten lokaal op te slaan, dit om geen parasitaire resultaten op te nemen.

-

Als men een test uitvoert via het testlab van QC, worden de resultaten opgeslagen in QC.

7.2.

TESTRESULTATEN (O54.1)

►FUNCTIE

Tester

►TOOL

Mercury Quality Center

►FORMAAT

Het rapport bevat de volgende informatie : 1. het aantal uitgevoerde tests, 2. de gerealiseerde en niet-gerealiseerde tests, 3. een kwalitatief advies over de toepassing (een globaal advies over de kwaliteit van de toepassing. Is ze geavanceerd? Zijn de ontdekte defecten blokkerend? Zijn er gekende bugs?...), 4. de mate van dekking, 5. de mate van welslagen. (2), (4) en (5) zullen worden vermeld in de vorm van grafieken in het aangemaakte rapport.

►ACTIVITEIT

A57 – De balans van de campagnes opmaken

►LOCATIE

De gedefinieerde rapporten kunnen worden opgeslagen in 05_Tests/04_Balansen.

►MODEL

FUP-TPL53-D5-Testbalans.doc

►NAAMGEVING

Er wordt geen enkele strategie inzake naamgeving bepaald door de methodologie; deze kan eigen zijn aan elk project.

►OPVOLGBAARHEID

Met de testbalans is het nuttig om na te gaan welke vereisten worden beïnvloed. Hiertoe bevat het rapport een verwijzing naar de vereisten in CRM.

►RAPPORT

De te gebruiken favoriet voor het aanmaken van het rapport is . Voordat men het rapport aanmaakt, moet men het kwalitatief advies invullen op de hiertoe voorziene plaats, in het veld Beschrijving van het panel ‘Document’ in de Document Generator.

►TE LEVEREN

L53 – Testbalans

PRESTATIE (MODEL)

Bijwerking

Versie

02/2007

0.2

Page

17/27


7.3.


ANOMALIEËN (O54.2)

►FUNCTIE

Tester

►TOOL

Starteam

►FORMAAT

Het rapport wordt geleverd door Starteam in formaat csv. Het formaat van elke anomalie wordt gedefinieerd door het Starteamformulier wanneer men een nieuwe Change Request invoert, die de volgende informatie bevat (de velden aangemerkt met (*) zijn niet verplicht): -

de use case (*) die eventueel is betrokken,

-

de testcase zoals naar wordt verwezen in QC. Er is geen integratie die een rechtstreekse verwijzing mogelijk maakt naar een QC-test in Starteam. De goede praktijk is dus de weg van de bestaande test in het testplan van QC op te nemen.

De informatie over de use cases en de testcases kan worden ingevoerd in het veld ‘External References’ in de standaardworkflow.

-

Ernst. Deze eigenschap wordt overgelaten aan degene die het defect invoert. Ze verschaft een maatstaf voor de impact van het defect op de toepassing.

-

Prioriteit. Deze eigenschap wordt gegeven door de verantwoordelijke voor de tests. Voor meer informatie kan men terecht in het document FUP-Master-teststrategie v0.3.doc.

-

beschrijving van het probleem,

-

bijlagen (*) die het probleem illustreren en die kunnen worden ingevoerd in de tab ‘Attachments’,

-

persoon die verantwoordelijk is voor de back log,

-

eventuele links (*) met andere elementen van ST.

-

hey type van Change Request : hier voegt men Change Requests in van het type ‘Defect’.

6

Naargelang de verschillende workflows en formulieren die worden gebruikt in ST, is het mogelijk dat de hierboven beschreven informatie niet overeenstemt met een precies veld. In dit geval kan men de informatie invoeren in het veld ‘Beschrijving’. ►ACTIVITEIT

A56 – Creëren van een fiche met anomalieën

►LOCATIE

04_Tests/05_BeheerAnomalieën De onderliggende structuur van de directory’s moet de structuur van het testplan respecteren, zoals voorheen ingegeven in QC.

6

►MODEL

FUP-TPL53-D5-Testbalans.doc

►NAAMGEVING

NA

►OPVOLGBAARHEID

Elk defect kan worden verbonden met de test die het heeft ontdekt, alsook met de vereiste die aan de oorsprong ligt van de test.

►RAPPORT

De door SupDev voorgestelde filter voor de standaardweergave van

Zie procedure voor links verderop in het gedeelte Gebruik van Starteam

Bijwerking

Versie

02/2007

0.2

Page

18/27



de gegevens is . Deze filter toont de volgende velden : -

CR Number : unieke ID van de change request

-

Type : ‘Defect’ in dit gedeelte.

-

Status-stf : huidige toestand in de standaardworkflow

-

Severity

-

Priority

-

Synopsis : samenvatting van de beschrijving

-

Responsible

-

Addressed by

-

Modified

-

Description

-

Entered On

-

Entered By

-

Attachment Name : lijst namen bestanden in bijlage

Bepaalde velden zijn niet verplicht voor de invoer van het defect. Als evenwel een use case en bijlagen worden ingevoerd, is het interessant ze mee te nemen in het rapport, want men kan er het defect mee verklaren. De bestanden die worden beïnvloed door het defect zijn daarentegen intern en moeten niet worden opgenomen in het rapport.

Het rapport wordt aangemaakt via Starteam. Als de workflow de 7 basisworkflow is, kan men de procedure uit volgen met de filter . ►TE LEVEREN

L53 – Testbalans

PRESTATIE (MODEL)

7.3.1.

Tests in ontwikkeling

Het is niet verboden om gebruik te maken van de module Defects van QC om de defecten te registreren die zich hebben voorgedaan in de omgeving voor ontwikkeling of packaging van de leverancier. Dit valt echter niet onder guidelines in dit document.

7.3.2.

Workflow

De workflows kunnen verschillen naargelang de projecten. Maar als de projecten besluiten om de workflow te veranderen, moeten er enkele centrale hoedanigheden (status) aanwezig zijn, zoals uitgelegd in de master-teststrategie. Zo niet, moet men de master-teststrategie wijzigen en zijn keuze verantwoorden, zoals uitgelegd in paragraaf 052. De informatie over de workflow in de master-strategie wordt hier vermeld, met een uitleg over de manier om deze uit te voeren in Starteam met de workflow, voorgesteld door SupDev.

7

Zie Gebruik van Starteam – Aanmaak van rapporten voor meer informatie

Bijwerking

Versie

02/2007

0.2

Page

19/27



Integratietests Stap

Actie/evenement

Overeenstemming Starteam

1

De tester ontdekt een fout/anomalie

Nieuwe change request van het type ‘defect’.

2

De fout wordt geregistreerd en krijgt een uniek referentienummer.

Automatisch

3

Men verzekert dat de fout voldoende wordt gedocumenteerd

Het defect wordt geanalyseerd en kan naar de status_stf ‘Open’ gaan. Als de fout niet voldoende is gedocumenteerd, de status op_stf à ‘Pending’ zetten. Men wacht dan tot de verantwoordelijke meer informatie geeft en men zet de status weer op _stf à ‘Open’.

4

Men kent een voorlopige prioriteit toe

Gebruikmaken van het veld ‘Severity’. De beschikbare opties zijn beschreven in de master-strategie.

5

Er wordt een regelmatige opvolging van de anomalieën uitgevoerd. De prioriteit wordt eventueel aangepast en het probleem krijgt een eigenaar.

Om een eigenaar te geven het veld ‘Responsibility’ wijzigen.

Acceptatietests De stappen 1 tot 3 en stap 7 zijn dezelfde als voor de integratietests Stap

Actie/evenement


4

Er wordt een kopie verstuurd naar de senior tester van de leverancier

De senior tester in het veld ‘Responsibility’ plaatsen; hij zal automatisch worden verwittigd. Hij kan dan zelf het defect dispatchen in zijn team.

5

Men reproduceert zo nodig het probleem. Men kent een voorlopige prioriteit toe

Gebruikmaken van het veld ‘Severity’. De beschikbare opties zijn beschreven in de master-strategie.

6

Men organiseert korte maar frequente vergaderingen met de betrokkenen

-

Procedure voor oplossing Stap

Actie/evenement


1

De eigenaar corrigeert de anomalie, test de correctie en wijzigt de status

Bij de oplossing overgaan van status_stf naar ‘In Progress’. Als de anomalie is gerorrigeerd, wordt de status_stf op ‘fixed’ gebracht.

Bijwerking

Versie

02/2007

0.2

Page

20/27



Stap

Actie/evenement


2

De anomalie wordt opnieuw getest tijdens de volgende integratietests

Als de anomalie niet is rechtgezet, de status weer van _stf naar ‘open’ brengen. Als ze is gecorrigeerd, ‘Closed Fixed’ gebruiken.

3

De log is geactualiseerd

-

Bijwerking

Versie

02/2007

0.2

Page

21/27



8. DE BALANS VAN HET PROTOTYPE (O55) De balans van het prototype is de testbalans die specifiek wordt toegepast op het prototype, als dit van toepassing is. Het prototype kan zich voordoen in verschillende vormen, naargelang de projecten. De prototypes kunnen al dan niet uitvoerbaar zijn. Het kan bijvoorbeeld gaan om een volwaardige toepassing, om een reeks schermimages of schermregistraties, of om statische HTML-pagina’s. Het prototype moet zodanig worden gecreëerd dat het veel minder duur wordt inzake ontwikkeling dan het systeem zelf, maar het moet daarbij voldoende functionaliteiten bieden om een betekenisvolle gebruikstest mogelijk te maken. De tests van het prototype moeten worden uitgevoerd aan businesszijde. Het testen van het prototype dient voor de validering van een mogelijke en bevredigende toepassing die de vereisten vervult en de mogelijkheid biedt om de vereisten (uitgedrukt door de vereisten) te verzoenen met de mogelijkheden. De tests kunnen van om het even welke aard zijn: manueel, automatisch,… De balans van het prototype moet in de mate van het mogelijke het artefact Testbalans volgen, maar dan toegepast op het prototype. Bij de test van het prototype zijn de meest belangrijke vereisten reeds gefinaliseerd en kan men dus normaal gezien reeds de voorgaande testbalans toepassen. Dit hangt echter af van het beleid inzake projecten.

Bijwerking

Versie

02/2007

0.2

Page

22/27



9. OPVOLGBAARHEID TUSSEN CALIBERRM EN MERCURY QUALITY CENTER 9.1.

INVOEREN VAN DE VEREISTEN IN QC

De vereisten kunnen worden ingevoerd van CRM in QC. De te volgen stappen in CRM zijn daarbij de volgende. 1. Tools -> Publish Requirements… 2. De in QC te publiceren vereisten kiezen. 3. De parameters van de QC-server ingeven : a. Server : http://fngsvsupdev04:8080/qcbin. b. Domain : SPF_FOD_FIN. c.

Het project, dat het QC-project is waar de vereisten zullen worden ingevoerd.

d. De naam van de gebruiker en het wachtwoord. 4. De velden kiezen die moeten worden getoond in de vereiste.

9.2.

UPDATEN VAN DE VEREISTEN

Het invoeren van de vereisten die reeds bestaan, heeft als gevolg dat deze vereisten worden geüpdatet.

9.3.

SYNCHRONISEREN VAN DE BEELDEN IN CRM EN QC

Men kan de velden kiezen die moeten worden getoond in QC, zodat deze volgen wat is gecreëerd in CRM. 1. Openen van Requirements. 2. Klikken op ‘Select Columns’

.

3. De te tonen elementen in de rechterkolom plaatsen.

Bijwerking

Versie

02/2007

0.2

Page

23/27



10. AANPASSING MERCURY QUALITY CENTER 10.1.

AANMAAK VAN RAPPORTEN

Er zijn twee manieren om rapporten aan te maken in QC. De eerste manier, aanbevolen door SupDev, is de Document Generator. Deze genereert bestanden in.doc-formaat. 1. Tools -> Document Generator. 2. Kiezen als één van de bestaande favorieten, voorgesteld door SupDev, of een nieuwe creëren. 3. Klikken op

en de locatie van het aangemaakte bestand kiezen.

4. Het .doc-bestand wordt aangemaakt en kan zo nodig worden gewijzigd. Men kan bijvoorbeeld het logo wijzigen dat is ingevoerd in het document; dit logo is standaard het logo van Mercury.

De tweede manier, die hier niet in detail wordt bestreken, is de aanmaak van rapporten in HTML-formaat. Ze zijn toegankelijk met gebruikmaking van het commando Analysis -> Reports ->…

10.2.

TOEVOEGING VAN EEN VELD

Men kan een gepersonaliseerd veld toevoegen in een entiteit van QC. 1. In ‘Customize’ gaan vóór de login in een project. 2. Login (als beheerder). 3. Customize projet entities. 4. New field. Van hieruit kan men de eigenschappen van het veld kiezen.

10.3.

BEHEER VAN FAVORIETEN

10.3.1.

Document Generator

Men kan de informatie in het document dat wordt aangemaakt door de Document Generator, op maat aanpassen. Hiertoe volstaat het de document generator te openen, de gewenste favoriet te openen en de parameters te wijzigen. Om de veranderingen vast te leggen : 1. ‘Add to Favorites…’ 2. Naam ingeven 3. Kiezen tussen ‘public’ en ‘private’ a. Public : de verandering zal zichtbaar zijn voor alle gebruikers van het project. b. Private : de verandering zal alleen zichtbaar zijn voor de gebruiker. Om een bestaand model te wijzigen, volstaat het dit te registreren onder zijn eigen naam. Opgelet : als u op die manier een ‘public’ model wijzigt, zullen alle andere gebruikers van het project toegang krijgen tot uw wijzigingen en zullen de oude parameters niet langer toegankelijk zijn. Het wordt dus sterk afgeraden om de bestaande favorieten te veranderen.

Bijwerking

Versie

02/2007

0.2

Page

24/27


10.3.2.


Reports

Men kan de informatie aanpassen die wordt getoond in de rapporten van Mercury. Hiertoe moet men de ‘favorieten’ van Mercury gebruiken. Het beheer van ‘private’ en ‘public’ is hetzelfde als in het vorige punt. 1. Analysis -> Report -> Aanmaken van een rapport 2. Klikken op

.

3. Programmeren zoals men wenst. 4. Klikken op

.

5. Een naam en een categorie kiezen (public of privé). De favoriet verschijnt nu in de lijst met aan te maken rapporten. Deze manipulatie kan worden uitgevoerd met het Test Lab én met het Test Plan.

10.4.

FILTERS

Wanneer men beslist een rapport aan te maken (via de functie ‘report’ of via de functie ‘document generator’), kiest QC standaard voor een herhaling van alle tests. Soms zal men natuurlijk een rapport willen uitbrengen met een subgeheel van tests (zoals bijvoorbeeld een folder die overeeenstemt met een specifieke versie). In dit geval moet men de filters gebruiken. -

Document Generator : 1. In het document generator, vinkt u ‘Selected’ aan. 2. Klik op 3. In het veld ‘Subject’, klikt u op ‘…’

4. Kies de directory die u wenst en klik op OK.

-

Report Analysis : 1. Aanmaken van het rapport. 2. Klikken op 3. Klikken op

. om een filter toe te voegen.

4. In het veld ‘Subject’, klikt u op ‘…’

5. Kies de directory die u wenst en klik op OK.

Bijwerking

Versie

02/2007

0.2

Page

25/27



11. GEBRUIK VAN STARTEAM 11.1.

BEHEER VAN DE LINKS TUSSEN ELEMENTEN VAN STARTEAM

Er kunnen links worden gecreëerd tussen verschillende items in ST. De links die ons interesseren, zijn de links tussen een Change Request en een bestand. Zo kan men, wanneer een defect wordt ontdekt, het rechtstreekse verband leggen met de bestanden die moeten worden veranderd. Wanneer deze bestanden zijn gecorrigeerd, kan de ontwikkelaar een check-in van deze bestanden doen en rechtstreeks toegang krijgen tot de Change Request en/of de status van deze Change Request meteen op ‘Fixed’ zetten.

11.1.1.

Creatie van een link

De procedure voor de creatie van een link is de volgende. Ze kan worden aangepast voor de creatie van links tussen om het even welke items in ST. 1. Selecteren van een Change Request 2. Change Request -> Links -> Create Link 3. Navigeren tot het te linken bestand 4. File -> Links -> Complete Link

11.1.2.

Visualisatie van een link

De links kunnen worden gevisualiseerd via de tab ‘Link’ die zich bevindt in het panel onderaan in ST.

11.1.3.

Toegang tot de Change Request tijdens een Check-in

Tijdens een check-in van een bestand kan men toegang krijgen tot de Change Requests die te maken hebben met dit bestand. 1. File -> Check-in 2. Show Change Requests 3. De lijst met de Change Requests inzake dit bestand verschijnt. Men kan een Change Request openen door te dubbelklikken op de gewenste uit de lijst. 4. Men kan ook de optie ‘Mark selected change requests as fixed’ aanvinken, wat tot gevolg heeft dat de status van de Change Request wordt veranderd tijdens de check-in.

Bijwerking

Versie

02/2007

0.2

Page

26/27


11.2.


AANMAAK VAN RAPPORTEN

Er zijn in ST twee manieren om rapporten aan te maken: -

de module ‘Export’ die csv-documenten genereert en die wordt aanbevolen door SupDev,

-

de module ‘Reports’ van ST, die HTML genereert

De basisredenering is dezelfde voor deze beide generators. Men moet eerst de gegevens kiezen die men wil tonen, met behulp van de filters. Zodra de gegevens zijn gefilterd, kan men makkelijk het noodzakelijke rapport genereren. 1. Als publieke filter kiezen (een andere filter kiezen als de gebruikte workflow verschillend is, of als er andere velden zichtbaar moeten zijn). 2. De Change Requests selecteren die moeten verschijnen in het rapport. 3. Change Request -> Advanced -> Export. 4. De standaard geselecteerde velden zijn die van de filter. Men kan andere velden selecteren als men dit wenst.

Opmerking : men kan een rapport aanmaken dat de links bevat tussen elementen van Starteam door gebruik te maken van de optie Change Requests -> Reports -> Links. Het document, opgemaakt in HTML-formaat, zal dan de verschillende links bevatten. Aangezien het om interne links van het project gaat, zijn ze niet verplicht in het rapport over de te leveren prestatie.

11.3.

WIJZIGING VAN FILTERS

Het is belangrijk de gebruikers te waarschuwen die de filters wensen te wijzigen. Er zijn, zoals in QC, twee types van filters, de privéfilters, weergegeven door , en de publieke filters, weergegeven door . De publieke filters zijn toegankelijk voor alle projecten. Er wordt dus aan de gebruikers gevraagd om de publieke filters NIET TE WIJZIGEN. Men kan makkelijk een publieke filter kopiëren als een privéfilter en deze lokaal wijzigen : 1. -> Filters -> Filters, 2. De te kopiëren filter kiezen, 3. Save as, 4. Het vakje ‘Public’ uitvinken en een naam geven 5. Men bekomt dan een lokale kopie van de publieke filter die men wenst te wijzigen. Bijwerking

Versie

02/2007

0.2

Page

27/27

FUP 1.0 D5- Test > Model > Masterteststrategie


MASTERTESTSTRATEGIE


X


1 2

\fup\FUP 1.0\Modellen\D5\FUP-Masterteststrategie.doc

De documenten met betrekking tot de FUP-methodologie kunnen lokaal worden gedownload op uw harde schijf met behulp van de toepassing Starteam - project FUP – functionaliteit check out all. Tijdens een exportoperatie (Check out all), wordt de boomstructuur uit Starteam overgebracht naar de lokale harde schijf c:\.

1

De documenten met betrekking tot de FUP-methodologie zijn ook gepubliceerd op de XWIKI van de infrastructuur, menu « SUPDEV », rubriek « FUP-methodologie – Documenten NL en FR », op het adres http://infrastructure.finbel.intra/xwiki/bin/view/SupDev/documents.

2

Geactualiseerd Mei 2008

Versie 0.2

Pagina 1/38



HISTORIEK VAN DE AANPASSINGEN Datum

Auteur

FUP

Versie

Aard

Januari 2006 Januari 2006

Unisys Unisys

0.3 0.3

0.1 0.2

Februari 2006 Februari 2007 Mei 2008

Unisys Unisys FOD Financiën (G.Merlini)

0.3 1.0 1.0

0.3 0.1 0.2

April 2009

FOD Financiën (G.Merlini)

1.0

0.3

Draft Toevoeging details nietfunctionele tests Diverse vertalingen Revisie testomgevingen Update FUP 1.0 Behartiging « Kwaliteit van de Code » (par. 2.3, 2.4, 2.5.1, 2.6.5, 2.7.1, 2.8, 3.1.1, 3.2, 4, 4.1.3, 4.6, 5.1) CR7946 : - Par. 3.4 Beheer van de Anomalieën in Mercury QC

REFERENTIES


Versie 0.2

Pagina 2/38



INHOUDSTAFEL 1.

PRESENTATIE VAN HET DOCUMENT ...........................................................................................6 1.1.

DOELSTELLING VAN HET DOCUMENT...................................................................................................6

1.2.

AAN WIE IS DIT DOCUMENT GERICHT ? ................................................................................................6

2.

TESTBENADERING .....................................................................ERREUR ! SIGNET NON DEFINI. 2.1.

REIKWIJDTE VAN DE TESTACTIVITEITEN .................................................. ERREUR ! SIGNET NON DEFINI.

2.2.

DEFINITIE VAN DE TESTOMGEVINGEN..................................................................................................8

2.3.

ALGEMENE AANPAK INZAKE DE TESTACTIVITEITEN .............................................................................10

2.4.

KWALITEIT VAN DE CODE / DISCIPLINE D4 ........................................................................................12

2.5.

INTEGRATIETESTS ................................................................................. ERREUR ! SIGNET NON DEFINI.

2.5.1.

Benadering en proces .................................................................. Erreur ! Signet non défini.

Doelstellingen ............................................................................... Erreur ! Signet non défini.

Input.......................................................................................................................................13

Wanneer ? .............................................................................................................................13

Hoe ? .....................................................................................................................................14 Testplan .............................................................................................. Erreur ! Signet non défini. Uitvoering van de tests ..............................................................................................................14

Wie ? .....................................................................................................................................14

Waar ............................................................................................. Erreur ! Signet non défini.

Documentatie en deliverables ...............................................................................................15

2.5.2. 2.6.

Tool voor beheer van de integratietests ................................................................................16

DE VERSCHILLENDE TYPES INTEGRATIETESTS...................................................................................17

2.6.1.

Tests op het vlak van de functionele vereisten .....................................................................17

Tool............................................................................................... Erreur ! Signet non défini.

2.6.2.

Tests op het vlak van de bijkomende vereisten ....................................................................18

2.6.3.

Tests inzake niet-regressie ...................................................................................................18

2.6.4.

Tests inzake operationele aspecten......................................................................................19

Prestatietests................................................................................ Erreur ! Signet non défini.

Veiligheidstests............................................................................. Erreur ! Signet non défini.

Tests voor installatie en configuratie .....................................................................................20

Tests voor back-up en recovery ............................................................................................20

De tests voor administratie en systeemwerking....................................................................21

Revisie van de documentatie ................................................................................................21

Tests voor migratie van gegevens ........................................................................................21

2.6.5.

Kwaliteitstests Discipline D4 (Qualité du Code) ....................................................................21

2.7.

ACCEPTATIETESTS ................................................................................ ERREUR ! SIGNET NON DEFINI.

2.7.1.

Benadering en proces .................................................................. Erreur ! Signet non défini.



Versie 0.2

Pagina 3/38



Input.......................................................................................................................................22

Wanneer ? .............................................................................................................................22

Hoe ? .....................................................................................................................................23

Wie ? .....................................................................................................................................23

Waar ............................................................................................. Erreur ! Signet non défini.

Documentatie en deliverables (door de FOD).......................................................................23

2.7.2.

Testtypes ...............................................................................................................................24

2.7.3.

Toot voor beheer van de acceptatietests ..............................................................................24

2.8.

SYNTHESE VAN DE TESTS ................................................................................................................25

2.9.

SYNTHESE VAN DE TOOLS................................................................................................................27

2.10.

DE GETESTE PLATFORMEN ...........................................................................................................27

2.11.

DE TESTS VAN DE EXTERNE PARTNERS .........................................................................................27

3.

OPVOLGING VAN DE ANOMALIEËN / BUGS ..............................................................................28 3.1.

PROCEDURES VOOR REGISTRATIE VAN ANOMALIEËN .........................................................................28

3.1.1.

Procedure voor registratie van anomalieën in integratietests ...............................................28

3.1.2.

Procedure voor registratie van anomalieën in acceptatietests .... Erreur ! Signet non défini.

3.2.

PROCEDURE VOOR ANALYSE EN OPLOSSING.....................................................................................29

3.3.

DEFINITIE VAN DE PRIORITEITEN ............................................................. ERREUR ! SIGNET NON DEFINI.

3.4.

TOOLS .................................................................................................. ERREUR ! SIGNET NON DEFINI.

4.

TESTDOCUMENTATIE ...................................................................................................................30 4.1.

DE TESTPLANNEN ................................................................................. ERREUR ! SIGNET NON DEFINI.

4.1.1.

De masterteststrategie ................................................................. Erreur ! Signet non défini.


4.1.2.

De projectteststrategie ................................................................. Erreur ! Signet non défini.


4.1.3.

Plan integratietests ................................................................................................................32


Tools ............................................................................................. Erreur ! Signet non défini.

4.1.4.

Plan acceptatietests ..............................................................................................................32


4.2.

MATRIX VOOR OPVOLGBAARHEID VAN VEREISTEN .............................................................................33



4.3.

TESTCASES .......................................................................................... ERREUR ! SIGNET NON DEFINI.



4.4.

TESTRAPPORTEN .................................................................................. ERREUR ! SIGNET NON DEFINI.




Versie 0.2

Pagina 4/38


4.5.


AANVULLENDE DOCUMENTEN................................................................. ERREUR ! SIGNET NON DEFINI.

4.5.1.

Account Relationship Matrix (ARM) ......................................................................................34

4.5.2.

Testgegevens ............................................................................... Erreur ! Signet non défini.

4.5.3.

Procedure voor registratie van fouten ...................................................................................34

4.6. 5.

VERANTWOORDELIJKHEDEN OP HET VLAK VAN DOCUMENTATIE ..........................................................35 ROLLEN EN COMMUNICATIE .......................................................................................................36

5.1.

ROLLEN ................................................................................................ ERREUR ! SIGNET NON DEFINI.

5.2.

KENNISOVERDRACHT ............................................................................ ERREUR ! SIGNET NON DEFINI.



Versie 0.2

Pagina 5/38



1. PRESENTATIE VAN HET DOCUMENT 1.1. Doelstelling van het document Het document met de masterteststrategie bevat alle elementen die in acht moeten worden genomen, en alle acties die moeten worden ondernomen, opdat de producten, ontwikkeld in het kader van het informaticaproject, de verwachte kwaliteit zouden halen. Dit omvat : - De reikwijdte van de testactiviteiten - De definitie van de testomgevingen - De algemene benadering op het vlak van de testactiviteiten - De respectievelijke functies en verantwoordelijkheden - De gebruikte tools - De types van plannen, rapporten en testbalansen die moeten worden geleverd - De beschrijving van het proces voor de opvolging van problemen

De ‘masterteststrategie’ zal zo nodig worden aangepast voor elk project en zal leiden tot de opmaak van een document ‘teststrategie’ waarvan de eerste versie zal worden geleverd op het einde van de uitwerkingsfase.

1.2. Aan wie is dit document gericht ? Het is bestemd voor de ICT-projectleider, de businessprojectleider en de testers.


Versie 0.2

Pagina 6/38



2. TESTBENADERING 2.1. Reikwijdte van de testactiviteiten De volgende tabel somt alle domeinen en componenten op die worden getroffen door de testactiviteiten.

Domein / component

Details

Business

Front-end Back-end Tools voor migratie

Procedures

Installatie, Roll-back

Documentatie

Alle deliverables

Aangezien het beheer van de database onder de verantwoordelijkheid van een derde partij valt (RDC), zijn de testactiviteiten, gerelateerd met de back-up/restore, niet opgenomen in dit document. Ook zal het Framework voor ontwikkeling (CCFF) geen specifieke testprocedures doorlopen, in de mate dat dit standaard en identiek is voor alle projecten.


Versie 0.2

Pagina 7/38



2.2. Definitie van de testomgevingen De volgende omgevingen zijn beschikbaar voor het project: Eén (of meer) ontwikkelingsomgeving(en) (Dev) Een packaging-omgeving onder de verantwoordelijkheid van de leverancier voor de tests voor assemblage en gedeeltelijke integratie Eén (of meer) omgeving(en) voor integratie onder de verantwoordelijkheid van de FOD voor de tests inzake de conformiteit van de architectuur, de tests gerelateerd met de DB en de tests voor volledige integratie in de externe componenten en toepassingen. De tests van de externe leveranciers worden eveneens uitgevoerd in een omgeving van dit type Eén (of meer) omgeving(en) voor levering onder de verantwoordelijkheid van de FOD voor de acceptatietests Een omgeving voor de opleiding (Train) Een productieomgeving (Prod)

Enkele opmerkingen betreffende het gebruik van deze omgevingen : De omgevingen voor ontwikkeling en packaging vallen onder de verantwoordelijkheid van de leverancier De integratieomgeving valt onder de verantwoordelijkheid van de FOD, maar de uitvoering van de tests zelf valt onder de verantwoordelijkheid van de leverancier. RDC en de externe leveranciers zullen eveneens beschikken over één of meer instanties van deze omgeving om hun eigen tests uit te voeren Er zal geen enkele testactiviteit zijn in de omgevingen voor opleiding en productie. De leverancier zal geen enkele test uitvoeren in de omgevingen voor levering maar zal de klant en/of de externe derde partij assisteren wanneer dit nodig blijkt.


Versie 0.2

Pagina 8/38



Algemeen schema van de testomgevingen


Versie 0.2

Pagina 9/38



2.3. Algemene aanpak inzake de testactiviteiten De testbenadering wordt op de volgende wijze schematisch weergegeven:

Test d’acceptation

Exigences Vérif ie

Sous-ensemble

Plan de test

Analyse et conception

Vérifie

Test d’intégration (fonctionnels et supplémentaires)

Exécution tests

Vérifie Tests Discipline D4 (Qualité du Code

Conception détailée

Coding

Er zijn drie testniveaus voorzien om na te gaan of het ontwikkelde systeem werkt zoals gespecificeerd in de functionele en bijkomende vereisten. De finale acceptatie door de FOD zal zijn gebaseerd op: -

De correcte werking van het ontwikkelde systeem ten opzichte van elk van deze vereisten.

-

Het Rapport inzake Kwaliteit Discipline D4 (Kwaliteit van de Code)

De Tester van de FOD voert het finale testniveau uit op basis van een subgeheel van integratietests, gedefinieerd tijdens de uitwerkingsfase en goedgekeurd door de business- en ICT-projectleiders. Vóór deze finale acceptatietests zich afspelen, moet de ontwikkelaar de Tests voor de Kwaliteit van de Code hebben uitgevoerd in de ontwikkelingsomgeving en moet de Tester van de leverancier alle integratietests hebben uitgevoerd in de omgevingen voor integratie en le packaging, en dit voor elk van de constructieherhalingen. Op het einde van elke grote herhaling zal er eveneens een ‘businessvalidering’ van de belangrijkste scenario’s worden uitgevoerd door de Tester van de FOD. De deliverables ‘Testbalans’ en ‘Rapport inzake Kwaliteit Discipline D4’ (Kwaliteit van de Code) zullen de kwaliteit van de producten aantonen die naar de transitiefase moeten.


Versie

Pagina

0.2

10/38



De aangehaalde processen worden weergegeven in de volgende schema’s:


Versie

Pagina

0.2

11/38



2.4. Kwaliteit van de Code / Discipline D4 De tests met betrekking tot de verificatie van de Kwaliteit van de Discipline D4 (of Kwaliteit van de Code) worden uitgevoerd door de leverancier in zijn ontwikkelingsomgeving. De bijbehorende principes, procedures, tools en artefacten worden gespecificeerd in het kader van de discipline D4. Meer specifiek : -

De doelstellingen en de principes van deze controles worden beschreven in het document « FUPMO-D4-QualityOfCode ».

-

De strategie, het uitvoeringsplan en de criteria die worden gehanteerd door elk project, worden beschreven door het artefact « Plan Kwaliteit Discipline D4 ».

-

De resultaten van deze tests worden gepresenteerd door de leverancier in het artefact « Rapport Kwaliteit Discipline D4 ».

Het « Plan Kwaliteit Discipline D4 » wordt op het gepaste moment goedgekeurd door de FOD vóór het gebruik ervan door het ontwikkelingsteam in het raam van alle constructieactiviteiten.


Versie

Pagina

0.2

12/38



2.5. Integratietests 2.5.1. Benadering en proces De integratietests hebben als doel zich te vergewissen dat het globale, opgebouwde systeem voldoet aan de vereisten, geformuleerd in de definitie van de behoeften, en aan de kwaliteitscriteria, gedefinieerd in overleg met de FOD. Het uitgewerkte testarsenaal moet in staat zijn om technische fouten op te sporen (bugs, betrouwbaarheid,…) en de geschiktheid van het systeem na te gaan ten opzichte van de functionele en bijkomende vereisten (prestatieniveau, meertaligheid,…).

Doelstellingen Nagaan of het systeem correct functioneert als een geheel Grondig controleren van alle toegangen tot de externe componenten en toepassingen Nagaan of het systeem voldoet aan de functionele vereisten, geformuleerd door middel van de gebruikscases Nagaan of het systeem beantwoordt aan de bijomende vereisten (prestatievermogen, User interface, meertaligheid,…) Zich verzekeren van de kwaliteit van het systeem en van het feit dat alle geïdentificeerde problemen werden opgelost

Input Alle inputs zijn diegene die werden goedgekeurd door de FOD tijdens de voorgaande fases: De functionele vereisten, beschreven via de gebruikscases De lijst met bijkomende (technische en/of transversale functionele) vereisten Het dossier voor analyse en conceptie Het Plan inzake Kwaliteit van de Discipline D4 (Kwaliteit van de Code), goedgekeurd door de FOD

Wanneer ? De opmaak van de testcases vangt aan rond het midden van de uitwerkingsfase, na de definitie van de behoeften en de gedetailleerde analyse. De integratietests vangen eveneens aan in de uitwerkingsfase zodra de eerste functionaliteiten werden geleverd (prototype,…). Ze worden met regelmaat uitgevoerd (te bepalen per project) en vóór elk verzoek tot acceptatie van een nieuwe versie van het systeem.


Versie

Pagina

0.2

13/38



Hoe ? Testplan Het Plan met de integratietests dat de testcases bevat, wordt uitgewerkt voor elke herhaling en is gebaseerd op de gebruikscases voor de functionele aspecten en op de lijst met bijkomende en operationele vereisten voor alle andere aspecten. In het algemeen moeten de volgende voorwaarden worden vervuld: Elke gebruikscase moet aanleiding geven tot minstens een testcase De belangrijkste testcase zal worden verrijkt met scenario’s naargelang de evolutie van de herhalingen Elke bijkomende vereiste moet aanleiding geven tot minstens een testcase Door de FOD moeten significante testgegevens worden verschaft (in een te bepalen formaat) De testtools moeten gebruiksklaar zijn. Uitvoering van de tests De eigenlijke testactiviteiten kunnen aanvangen wanneer de code van het te leveren systeem (of een gedeelte van het systeem) de status ‘op unitaire wijze getest’ heeft gekregen en zodra er een eerste revisie van deze code is uitgevoerd. Voor elke testcase uit het plan met de integratietests, moet men de volgende elementen nagaan : Het feit dat een test werd uitgevoerd Het resultaat van de test en zijn status De anomalieën (die zullen worden geïnventariseerd in StarTeam) Na afloop van elke formele uitvoering van tests worden de verkregen resultaten besproken tijdens een vergadering waarin de te ondernemen acties en de prioriteiten voor elk van de problemen worden vastgelegd : onmiddellijke rechtzetting, rechtzetting uitgesteld tot de volgende versie, … Er zal een globaal testrapport worden uitgebracht bij elke herhaling om de kwaliteit van het geleverde systeem te meten. Het niveau van welslagen van de tests wordt behaald als de gedefinieerde SLA wordt gehaald.

Wie ? De leverancier is verantwoordelijk voor het:

Definiëren van de testcases en de testscenario’s

Sturen van de tests in de omgeving voor packaging en integratie, en het leveren van de resultaten die eruit voortvloeien

Verzekeren van de opvolging van de ontdekte anomalieën

Verschaffen van een globale balans van de integratietests

Voorzien van het Plan inzake Kwaliteit Discipline D4 (Kwaliteit van de Code) vóór de aanvang van alle testactiviteiten.

Verschaffen van een Rapport over de Kwaliteit van de Discipline D4 in overeenstemming met het Plan van de Discipline D4 voor elke testcampagne

De FOD is verantwoordelijk voor het :


Valideren van de gekozen testcases en scenario’s

Versie

Pagina

0.2

14/38


Installeren van de integratieomgevingen

Creëren van de test-DB

Verschaffen van relevante gegevens


Assisteren van de leverancier bij de tests van de belangrijkste scenario’s

Goedkeuren van het Plan inzake Kwaliteit Discipline D4 (Kwaliteit van de Code) vóór de aanvang van alle testactiviteiten

Nagaan van de conformiteit van het Rapport over de Kwaliteit van de Discipline D4 (Kwaliteit van de Code) met de kwaliteitscriteria, gedefinieerd in het Plan inzake Kwaliteit Discipline D4.

Waar Dezelfde integratietests worden uitgevoerd in twee afzonderlijke omgevingen: De eerste tests verlopen in de omgeving voor packaging onder de volledige verantwoordelijkheid van de leverancier. Deze omgeving biedt niet noodzakelijk een mogelijkheid voor integratie in alle externe componenten van het project Wanneer deze tests afdoend blijken, wordt er aan de FOD een installatie-package geleverd, dat een volledige installatie simuleert in de omgeving voor integratie die op haar beurt het exacte beeld weerspiegelt van de beoogde productie. Op dit niveau gaat de FOD over tot de validering van de CCFF-conformiteit, waarna de leverancier een volledige campagne met integratietests gaat uitvoeren. De leverancier moet aandacht hebben voor de integratietests die hij niet heeft kunnen uitvoeren in de omgeving voor packaging. Vóór de integratietests creëert RDC op fysieke wijze de test-DB door de gegevens te benutten die werden gedistilleerd uit Together door de leverancier op basis van het model entiteit-relatie, en door ze in overeenstemming te brengen met de interne normen. Parallel worden door RDC prestatietests uitgevoerd in een parallelle integratieomgeving. De integratietests van leverancier en RDC moeten worden beëindigd en moeten afdoend zijn vóór de leveringsfase.

Documentatie en deliverables Een ‘plan met integratietests’ per herhaling. Dit document beschrijft de testcases (georganiseerd per gebruikscase), de scenario’s die ermee gerelateerd zijn, alsook de verwachte resultaten Een gedetailleerd testdossier per testcase Een rapport met gecorrigeerde anomalieën en lopende anomalieën Een globale testbalans Het Plan inzake Kwaliteit van de Discipline D4 (Kwaliteit van de Code) Het Rapport inzake Kwaliteit van de Discipline D4, gerelateerd met de lopende herhaling.


Versie

Pagina

0.2

15/38



2.5.2. Tool voor beheer van de integratietests Mercury Quality Center is de tool die wordt gebruikt om alle documenten en activiteiten, gekoppeld aan de integratietests, te centraliseren. Er wordt een project aangemaakt in dit center om de informatie te verzamelen over de tests die werden uitgevoerd tijdens de hele ontwikkelingsfase van het systeem. De tool Mercury Quality Center beheert de organisatie van de testactiviteiten en biedt de mogelijkheid om volgende zaken te definiëren: • “Testplan” folders: de module ‘testplan’ zorgt voor de organisatie van de definitie van de testcases en –scenario’s • “Testsets”: de module ‘Testlab’ beheert de organisatie van de uitvoering van de tests. De module bestaat uit een hiërarchie van directory’s met ‘testsets’ die een geheel van tests bundelen die in één keer kunnen worden opgestart. Er zal een directory worden bepaald per herhaling en deze zal meerdere testsets omvatten (één per subdomein). Het geheel van de testsets, gedefinieerd in deze directory, zal de testcases bestrijken die zijn gerelateerd met de lopende constructieherhaling, alsook een subgeheel van de voorgaande herhalingen, zodat men kan overgaan tot de tests voor niet-regressie. De testsessie kan rechtstreeks worden opgestart vanuit Qualiy Center Mercury en omvat manuele en/of automatische tests op basis van scripts, ontwikkeld in QuickTest. Quality Center omvat functionaliteiten voor reporting waarmee men grafieken en rapporten kan opstellen zoals het ‘Test planning report’ of het ‘Test set report’ die een overzicht geven van de testcases, hun beschrijving, de bijbehorende scenario’s en hun status.


Versie

Pagina

0.2

16/38



2.6. De verschillende types van integratietests De tests worden gebundeld per categorie, beantwoordend aan eenzelfde type van doelstelling. 2.6.1. Tests op het vlak van de functionele vereisten Deze tests willen nagaan of de geleverde functionaliteiten overeenstemmen met de door de FOD goedgekeurde functionele vereisten. Ze bieden ook de kans om zich te vergewissen van het correcte beheer van fouten in het gebruik van het systeem. De definitie van deze tests is rechtstreeks afgeleid van de gebruikscases.

Tool De benadering bestaat erin de tests zoveel mogelijk te automatiseren. Hiertoe implementeert men scripts, dat wil zeggen een geheel van acties die het systeem de uit te voeren instructies aangeven. Het opstarten van een script leidt tot het automatische verloop van de tests die ermee zijn gerelateerd, en de registratie van de resultaten in een log file. De keuze om een test al dan niet te automatiseren zal afhangen van het aantal keren dat een test moet worden uitgevoerd, en van de noodzakelijke tijd voor het schrijven en onderhouden van het overeenstemmende script. Voor de tests voor niet-regressie zal het bijvoorbeeld beslist interesssanter zijn om te beschikken over de overeenstemmende scripts, want ze moeten herhaaldelijk worden uitgevoerd. De tools voor automatisering van de tests zijn verschillend voor de front-end en de back-end. 1) Front-end: De gekozen tool voor het automatiseren van de tests voor de front-end is Mercury QuickTest Professional. Deze tool biedt de mogelijkheid om de tests te automatiseren door het gebruik van functionaliteiten van het type ‘record and play-back’. De gebruiker voert de acties uit die zijn gerelateerd met zijn testscenario’s en selecteert de te controleren punten (”verification points” genoemd). Met deze controlepunten kan men de eigenschappen van een webobject nagaan of van een gegeven, opgeslagen in de database. De tool registreert de acties, uitgevoerd door de gebruiker, en vertaalt ze in een VB Script-programma. Wanneer het script wordt opgestart, speelt de tool de geregistreerde acties opnieuw af en produceert hij de resultaten in een log file. De scripts, geregistreerd in het VB Script-programma, kunnen zo nodig worden aangepast om te worden gepersonaliseerd of om er bijkomende controlepunten aan toe te voegen. Deze tool wordt geïntegreerd in het Mercury Quality Center: De scripts kunnen worden opgestart vanuit het Quality Center, De logs zijn ook beschikbaar vanuit het Quality Center, wat de mogelijkheid biedt om er rapporten uit te voeren, op basis van de resultaten van de geautomatiseerde tests, De VB Script-bestanden met de nuttige functies, kunnen worden opgeslagen in het Quality Center en worden gebruikt in QuickTest met het oog op hun eigenlijke aanpassing op maat.


Versie

Pagina

0.2

17/38



Het testen van de back-end bestaat over het algemeen uit : Het verzenden van de bestanden of de berichten naar het back-endsysteem, Het registreren van de berichten die worden teruggestuurd door het back-endsysteem, Het controleren van deze berichten en/of nagaan dat de geschikte acties werden uitgevoerd in de database. Om dit type van tests te automatiseren, is het noodzakelijk om een specifieke toepassing te voorzien, waarvan de ontwikkeling onder de verantwoordelijkheid van de leverancier valt. In functie van de back-endcontext moet men ofwel een algemene toepassing die meerdere functionaliteiten bestrijkt, ontwikkelen, ofwel een specifieke toepassing voor elke functionaliteit. 2.6.2. Tests op het vlak van de bijkomende vereisten Deze tests die eveneens zijn opgemaakt in de vorm van testcases, moeten de mogelijkheid bieden om de realisatie aan te tonen van elk van de vereisten, beschreven in de lijst met bijkomende vereisten (ergonomie, meertaligheid,…). Voor de vereisten met een meer functionele aard zal men dezelfde benadering hanteren als voor de gebruikscases. Voor de meer technische vereisten zal men terugvallen op de tests op het vlak van de operationele aspecten. 2.6.3.

Tests inzake niet-regressie

De doelstelling van deze tests bestaat er niet in nieuwe functionaliteiten te controleren, maar zich te vergewissen dat de oude functionaliteiten, na correcties of aanpassingen, nog steeds correct blijven functioneren. Bij elke nieuwe versie is het noodzakelijk de scenario’s over te doen waarmee de oude functionaliteiten kunnen worden getest. Hiertoe moet men een geheel van tests kiezen die representatief zijn voor de essentiële functies van de voorgaande versies.


Versie

Pagina

0.2

18/38


2.6.4.


Tests inzake operationele aspecten

De operationele tests zijn opgedeeld in meerdere categorieën : De prestatietests De veiligheidstests De tests voor installatie en configuratie De tests voor back-up en recovery De tests voor systeemadministratie en -besturing Revisie van de documentatie De tests voor herneming van gegevens

Prestatietests Het doel van deze tests is het controleren van het prestatievermogen en de beschikbaarheid van het systeem. Het testplan omvat een gedeelte over de verschillende soorten prestatietests die moeten worden uitgevoerd, zijnde : Tests betreffende de reactietijd van het systeem, geëvalueerd onder normale omstandigheden, Stresstests, gericht op de evaluatie van de reactietijd onder abnomale omstandigheden. Dit omvat de capaciteit van het systeem om grote volumes gegevens en een groot aantal gebruikers te beheren, Tests aangaande de duur, om na te gaan of het systeem blijft werken met acceptabele prestaties na een lange periode van ononderbroken gebruik. Dit soort tests kan een eventueel tekort aan geheugen aan het licht brengen. Er moeten testscenario’s worden voorzien voor elk type van prestatietests. De resultaten van deze tests moeten voldoen aan de eisen, gedefinieerd in het projectdossier. Als er geen enkele precieze meting wordt vermeld in de vereisten, blijft het doel niettemin om ‘redelijke ‘ reactietijden en prestaties te kunnen aantonen voor de gebruiker. De resultaten van deze tests worden opgenomen in het rapport over de integratietests. Eventueel wordt ook een foutenrapport geproduceerd. Gebruikte tools Voor de prestatietests van de front-end gebruikt men Mercury LoadRunner. Voor de back-end moet de voor de tests ontwikkelde toepassing ook in staat zijn om de reactietijden te meten. Voor de stresstests moet men een intensief gebruik van het systeem simuleren. Voor de front-end kan dat gebeuren door er gelijktijdig een groot aantal gebruikers bij te betrekken. Men maakt eveneens gebruik van Mercury LoadRunner. Voor de back-end kan men bijvoorbeeld een groot aantal tegelijkertijd verzonden berichten/bestanden simuleren. De toepassing, ontwikkeld voor de back-endtests, moet in staat zijn om deze verzendingen automatisch te beheren.


Versie

Pagina

0.2

19/38



Veiligheidstests Het systeem moet worden beschermd tegen al dan niet opzettelijke veiligheidsinbreuken. De veiligheidstests moeten de logische beveiliging van informatie en de fysieke beveiliging van de hardware en het netwerk omvatten. De doelstellingen van deze tests zijn: Nagaan of de gegevens ‘logisch’ worden beschermd volgens de in de projectdocumentatie geformuleerde eisen Nagaan of de hardware fysiek wordt beschermd volgens de in de projectdocumentatie geformuleerde eisen Zich vergewissen dat de ontdekte veiligheidsproblemen worden opgelost. De leverancier draagt niet de verantwoordelijkheid voor de fysieke tests, noch deze die is gerelateerd met de procedures zelf voor authenticatie en autorisatie, die zijn geïntegreerd in de CCFF-componenten. De veiligheidstests van de leverancier moeten zich voornamelijk concentreren op: De aspecten inzake logische veiligheid, inbegrepen in de functionele vereisten (vb : toegang tot bijzonder vertrouwelijke gegevens voor een gebruikerstype) De integratie van de CCFF-veiligheidscomponenten in het ontwikkelde systeem

Tests voor installatie en configuratie Het doel van deze tests is zich te verzekeren dat het systeem kan worden geïnstalleerd volgens de voorziene configuratie. Om de installatie of herinstallatie van een toepassing uit te voeren, is het noodzakelijk te kunnen beschikken over procedures die stap voor stap de acties voor installatie en configuratie beschrijven, ongeacht of ze betrekking hebben op het gedeelte van de client, de server of de database. De taken voor installatie en configuratie moeten maximaal worden geautomatiseerd om manipulatiefouten te vermijden, installatietermijnen te optimaliseren en mogelijke nadelen op het vlak van de gebruikers te beperken. Er moeten dus tests, gerelateerd met elk van de releases, worden uitgevoerd met simulatie van een complete en/of gedeeltelijke installatie en met de verzekering dat de laatste acties van deze procedures de mogelijkheid bieden om na te gaan of het systeem volledig operationeel is. Als het systeem dat niet is, moet men er zeker van zijn dat men zonder fouten kan terugvallen op de vorige release.

Tests voor back-up en recovery De procedures voor backup/recovery zijn cruciaal voor het businesssucces en om het vertrouwen van de gebruikers in het systeem te handhaven. Het is dus van primordiaal belang om na een onderbreking snel te kunnen heropstarten zonder gegevensverlies. De taken in verband met deze tests vallen onder de verantwoordelijkheid van de ICT FOD Financiën en niet van de leverancier.


Versie

Pagina

0.2

20/38



De tests voor systeemadministratie en -besturing Deze tests betreffen de taken op het vlak van systeemadministratie en systeembesturing. Ze bestaan uit het volgende : Nagaan of de operaties zoals opstarten en shutdown van het systeem correct werken zoals gevraagd Nagaan of de systeemadministratie worrect werkt zoals gevraagd, met omvatting van de administratie van de gebruikers, de opvolging van de prestaties en de vaststelling van problemen. De tests op het vlak van de administratie van de gebruikers vallen niet onder de verantwoordelijkheid van de leverancier in de mate dat deze administratie wordt uitgevoerd in een externe tool, zoals LDAP. Zo is ook de tracking/logging die wordt behartigd door het CCFF-framework, niet inbegrepen in de leverancierstests. De leverancier draagt als enige de verantwoordelijkheid voor de tests van ‘shutdown and restart’. Er moeten scenario’s worden voorzien om de goede werking van de procedures voor uitschakelen en opstarten te kunnen aantonen. De resultaten van deze tests moeten worden opgeslagen in het gedeelte betreffende dit testtype. Zo nodig moet men een bug report opmaken en/of de aanpassingen vermelden die moeten worden aangebracht aan de bestaande procedures.

Revisie van de documentatie Het doel van deze activiteit is het controleren van de volledigheid, de duidelijkheid en de nauwkeurigheid van de geleverde documentatie, alsook het respect voor de standaarden en het formalisme, zoals vermeld in het document met de kwaliteitseisen. Deze kwaliteitsrevisie moet worden uitgevoerd bij elke documentlevering.

Tests voor gegevensmigratie Het doel van deze tests is nagaan of de gemigreerde gegevens correct en coherent zijn ten opzichte van het nieuwe systeem. De migratietool bestaat uit twee toepassingen: De extractie van de gegevens uit de bestaande basis in een formaat, gepreciseerd in de analyse, wat onder de verantwoordelijkheid van de FOD Financiën valt. De transformatie van deze gegevens en hun invoer in de nieuwe basis, wat onder de verantwoordelijkheid van de leverancier valt De automatische stap voor transformatie van deze gegevens zal een reeks businesscontroles omvatten om de kwaliteit van de hernomen gegevens te garanderen; deze controles zullen aanleiding geven tot een lijst met anomalieën, die manueel of automatisch kan worden verwerkt. Bovendien moet de leverancier zich vergewissen van de coherentie en de volledigheid van de finale gegevens en van hun compatibiliteit met het systeem, dit door enkele representatieve testcases te doen draaien. De tests betreffende de gegevensmigratie zullen erg vroeg in de ontwikkelingscyclus worden uitgevoerd, omdat ze het mogelijk maken fouten of lacunes in de gegevensverwerking aan het licht te brengen. Bij elke gegevensmigratie moet het geheel van de tests en controles worden herhaald.

2.6.5.

Tests inzake Kwaliteit Discipline D4 (Kwaliteit van de Code)

Op basis van de inhoud van het « Rapport inzake Kwaliteit van de Discipline D4 », geleverd door de leverancier, en op basis van kwaliteitscriteria, gedefinieerd en goedgekeurd in het « Plan inzake Kwaliteit Discipline D4 », kan de FOD aan de leverancier vragen om correctieve acties toe te passen met het oog op de rechtzetting van vastgestelde en niet-gecorrigeerde anomalieën of gebreken. Geactualiseerd Mei 2008

Versie

Pagina

0.2

21/38



2.7. Acceptatietests 2.7.1. Benadering en proces De acceptatietests worden uitgevoerd door de FOD (klant) om het ontwikkelde systeem te kunnen opleveren, met de verzekering dat het beantwoordt aan de functionele en bijkomende vereisten, gedefinieerd in de projectdocumentatie. De acceptatietests zijn gelijkaardig aan de integratietests, omdat ze dezelfde aspecten bestrijken. Er zijn niettemin twee grote verschillen: Het is de FOD die verantwoordelijk is voor de uitvoering van deze testactiviteiten, de keuze van de scenario’s (uit degene die zijn gedefinieerd door de leverancier voor de integratietests) en de levering van een rapport over de acceptatietests. De leverancier moet in dit stadium enkel de supportactiviteiten verzekeren en moet de nodige documentatie leveren om de tests in goede banen te leiden. De hoofddoelstelling is hier niet het specifiek zoeken naar bugs, maar het verwerven van het vertrouwen van de FOD inzake de capaciteit van het systeem om te voldoen aan zijn behoeften, om operationeel te zijn en om te kunnen evolueren in functie van zijn strategie. De acceptatietest beperken zich niet tot alleen maar de functionele tests. Ze moeten ook de andere testtypes bestrijken die worden beschreven voor de integratietests, met inbegrip van de Tests inzake Kwaliteit Discipline D4.

Doelstellingen Nagaan of het systeem overeenstemt met de businesseisen, vermeld in de projectdocumentatie Nagaan of de functionaliteiten, beschreven in de vereisten en gebruikscases, correct werken Nagaan of het systeem voldoet aan de bijkomende vereisten (prestatieniveau, User interface, meertaligheid,…) Nagaan of het systeem overeenstemt met de gedefinieerde kwaliteitscriteria (Kwaliteit van de Code / Discipline D4).

Input De acceptatietests worden verricht door de FOD met uitvoering van een subgeheel van de integratietests, gedefinieerd door de leverancier. Dit subgeheel moet vooraf zijn gedefinieerd in het Plan met de acceptatietests. Wanneer ? De acceptatietests worden uitgevoerd in de transitiefase, bij de levering van een officiële versie. Er zullen echter tussentijdse valideringstests worden voorzien op het einde van elke grote constructieherhaling, zodat de klant erg vroeg in de ontwikkelingscyclus concreet kan oordelen of zijn behoeften correct werden geïnterpreteerd. Deze milestones voor validering worden gedefinieerd in het projectplan en dit in gezamenlijk overleg tussen de FOD en de leverancier.


Versie

Pagina

0.2

22/38



Hoe ? Om de acceptatie van het systeem te verrichten, moeten de volgende taken worden voorzien: De planning van de activiteiten voor de acceptatietests De definitie van het testplan, met omvatting van de scenario’s, gekozen uit die van de integratietests De uitvoering van de testscenario’s Rapporten over eventuele anomalieën De evaluatie van de resultaten en het rapport dat de globale balans beschrijft De officiële oplevering van het systeem Het niveau van welslagen van de tests zal worden gemeten ten aanzien van de SLA, gedefinieerd in het project.

Wie ? De FOD is verantwoordelijk voor De keuze van de scenario’s met de acceptatietests De levering van de relevante gegevens De installatie van de leveringsomgeving De uitvoering van de tests De opmaak van de verschillende rapporten en de balans Het overgaan tot de acceptatie De leverancier is verantwoordelijk voor De installatie van het systeem Het hernemen van de noodzakelijke gegevens voor de werking van de toepassing De voorziening van een minimale documentatie, noodzakelijk voor de uitvoering van de tests De assistentie aan de FOD wanneer nodig De levering van de gevraagde kwaliteitsrapporten (Rapport Kwaliteit van de Code / Discipline D4)

Waar De acceptatietests worden uitgevoerd in een specifieke omgeving, een spiegelbeeld van de productieomgeving (Test Acc)

Documentatie en deliverables (door de FOD) Een Plan met de acceptatietests, afgeleid van het Plan met de integratietests Een rapport over de anomalieën Een globale testbalans Een acceptatiedocument


Versie

Pagina

0.2

23/38



2.7.2. Testtypes De testtypes zijn gelijkaardig aan degene die zijn gedefinieerd voor de integratietests. 2.7.3. Tool voor beheer van de acceptatietests De tools en scripts, gebruikt in het kader van de integratietests, kunnen ook worden benut voor de acceptatietests, maar de FOD kan ook een andere keuze maken.


Versie

Pagina

0.2

24/38



2.8. Synthese van de tests Type van test

Doelstelling

Wie

Wanneer

Integratietests

Omgevingen voor packaging en integratie

Gerelateerd met functionele vereisten

Nagaan van geschiktheid van systeem ten opzichte van functionele vereisten

Tester (Lever.)

Minstens op het einde van elke herhaling

Gerelateerd met bijkomende vereisten

Nagaan van geschiktheid van systeem ten opzichte van bijkomende vereisten

Tester (Lever.)

Minstens op het einde van elke herhaling

Tests voor nietregressie

Nagaan of een nieuwe versie geen neatieve gevolgen heeft voor de voorgaande versies

Tester (Lever.)

Op het einde van elke herhaling (vanaf de 2de)

Prestaties

Zich verzekeren dat de prestaties conform zijn met de SLA

Tester (Lever.)

Op het einde van elke release

Veiligheid

Zich verzekeren dat de functies van het systeem slechts toegankelijk zijn voor geautoriseerde actoren

Tester (Lever.)


Zich verzekeren dat de functies voor installatie en desinstallatie correct werken en dat het nog altijd mogelijk is om terug te keren naar de vorige versie

Tester (Lever.)


Zich verzekeren dat de functies voor backup/recovery correct werken

ICT FOD

Zich verzekeren dat de functies voor de administratie van het systeem correct werken

Tester (Lever.)


Documentatie

De volledigheid en de kwaliteit van de documentatie controleren

Tester (Lever.)

Bij de productie van elke documentatie

Gegevensmigratie

Nagaan of de gegevens die moeten worden gemigreerd in het correcte formaat zijn

Tester (Lever.)


Test Kwaliteit D4 (Kwaliteit van de Code)

Controle van het Rapport inzake Kwaliteit Discipline D4 (zie artefacten FUP/D4) op basis van de criteria, gedefinieerd in Plan Kwaliteit D4.

ICT FOD

Minstens bij het einde van elke herhaling

Installatie & Configuratie

Backup & Recovery Administratie & besturing


Versie

Pagina

0.2

25/38


Type van test

Doelstelling

Acceptatietests

Leveringsomgeving(en)

Gerelateerd met de functionele vereisten

Gerelateerd met de bijkomende vereisten


Wie

Wanneer

Nagaan van geschiktheid van systeem ten opzichte van functionele vereisten

Tester (FOD)

Bij het einde van een belangrijke constructieherhaling Bij het einde van elke release

Nagaan van geschiktheid van systeem ten opzichte van bijkomende vereisten

Tester (FOD)

Bij het einde van elke release

Tests voor nietregressie

Nagaan of een nieuwe versie geen neatieve gevolgen heeft voor de voorgaande versies

Tester (FOD)

Bij het einde van elke release (vanaf de 2de)

Prestaties

Zich verzekeren dat de prestaties acceptabel zijn

Tester & ICT (FOD)


Veiligheid

Zich verzekeren dat de functies van het systeem slechts toegankelijk zijn voor geautoriseerde actoren

ICT (FOD)


Zich verzekeren dat de functies voor installatie en desinstallatie correct werken en dat het nog altijd mogelijk is om terug te keren naar de vorige versie

ICT (FOD)


Zich verzekeren dat de functies voor backup/recovery correct werken

ICT (FOD)


Zich verzekeren dat de functies voor de administratie van het systeem correct werken

ICT (FOD)


Documentatie

De volledigheid en de kwaliteit van de documentatie controleren

Tester & ICT (FOD)


Gegevensmigratie

Nagaan of de gegevens die moeten worden gemigreerd in het correcte formaat zijn

Tester & ICT(FOD)


Test Kwaliteit D4 (Kwaliteit van de Code)

Controle van het Rapport inzake Kwaliteit Discipline D4 (zie artefacten FUP/D4) op basis van de criteria, gedefinieerd in Plan Kwaliteit D4.

ICT FOD


Installatie & Configuratie

Backup & Recovery Administratie & besturing


Versie

Pagina

0.2

26/38



2.9. Synthese van de tools Tool

Types van tests

Gebruik / Doelstellingen

Mercury Quality Center

Tests voor integratie en acceptatie

Mercury QuickTest Professional

Functionele tests voor integratie en acceptatie frontend

- Organisatie van de tests, - Definitie/creatie van het testplan, - Koppelingen met de vereisten, - Opstarten van de testsessies, - Reporting inzake uitvoering en resultaten Creatie en playback van de testscripts front-end.

Mercury LoadRunner

Prestatie- en stresstests frontend (integratie en acceptatie)

Test inzake gedrag en prestaties.

Functionele en niet-functionele tests back-end (integratie en acceptatie).

Test back-end

Mise en forme : Puces et numéros

Beheer fouten

Mise en forme : Puces et numéros

Specifieke testtoepassingen, ontwikkeld door de leverancier StarTeam

2.10. De geteste platformen De tests van de front-end moeten kunnen worden uitgevoerd op de volgende browsers: I.E 5.0 , 5.5, 6.0 Netscape 7.1, 7.2 Concreet en formeel worden alle tests uitgevoerd op I.E 6.0. Er kunnen enkele bijkomende tests worden uitgevoerd op andere versies, en dit op specifiek verzoek van de FOD, die dan de nodige omgevingen voor de tests moet voorzien op deze andere browsers. Er valt echter te noteren dat Mercury QuickTest noch Netscape 7.2, noch Mozilla ondersteunt. Er kan dus geen enkele automatische test mee worden uitgevoerd met betrekking tot deze browsers in het bijzonder.

2.11. De tests van externe partners Er kunnen speciale tests worden verricht door externe partners. Deze tests worden uitgevoerd in een specifieke integratieomgeving. De leverancier is niet betrokken bij deze tests maar moet de laatste versie van het systeem leveren en moet nagaan of het operationeel is. Deze testactiviteiten moeten worden gepland in gezamenlijk overleg met de leverancier zodat deze zich kan organiseren en het systeem beschikbaar kan maken op het juiste moment. De eventuele fouten die worden vastgesteld tijdens deze tests, moeten aan bod komen in een rapport dat wordt verzonden aan de testverantwoordelijke.


Versie

Pagina

0.2

27/38



3. OPVOLGING VAN ANOMALIEËN / BUGS 3.1. Procedures voor registratie van anomalieën De verschillen tussen de reële resultaten van de tests en de verwachte moeten worden geregistreerd. De persoon die de anomalie vaststelt, moet zich identificeren en moet zijn probleem beschrijven met voldoende details om iemand anders in staat te stellen dit te reproduceren. Elke anomalie, vastgesteld tijdens de integratie- of acceptatietests, moet worden geregistreerd en een referentienummer krijgen. Wanneer de anomalie het voorwerp uitmaakt van een correctie, moet deze referentie worden hernomen in de overeenstemmende release note. 3.1.1.

Procedure voor registratie van anomalieën in integratietests

Stap

Actie/evenement

Betrokken actor

1

De tester ontdekt een fout/anomalie

Tester

2


Tester

3

Men verzekert zich dat de fout voldoende is gedocumenteerd

Senior tester

4

Men kent een voorlopige prioriteit toe

Senior tester

5

Er wordt een regelmatige opvolging van de anomalieën toegepast ; de prioriteit wordt eventueel aangepast en het probleem krijgt een eigenaar

Senior tester Verantwoordelijke tests Verantwoordelijke ontw.

3.1.2. Procedure voor registratie van anomalieën in acceptatietests Een contactpersoon, afkomstig van het businessteam van de FOD Financiën, zal belast worden met het beheer van de anomalieën, ontdekt tijdens de acceptatietests, hun opvolging en hun voorlegging aan de leverancier. Stap

Actie/evenement

Betrokken actor

1

De tester ontdekt een anomalie.

Tester FOD

2


Tester FOD

3

Men verzekert zich dat de fout voldoende is gedocumenteerd

Contactpersoon FOD

4

Een kopie wordt verstuurd naar de senior tester leverancier

Contactpersoon FOD

5

Men reproduceert het probleem zo nodig. Men kent een voorlopige prioriteit toe

Senior tester leverancier

6

Men organiseert korte, maar frequente vergaderingen met de betrokken personen

Verantwoordelijke tests FOD

7

Er wordt een regelmatige opvolging van de anomalieën toegepast; de prioriteit wordt eventueel aangepast en het probleem krijgt een eigenaar

Senior tester Verantwoordelijke tests Verantwoordelijke ontwik. Contactpersoon FOD


Versie

Pagina

0.2

28/38



3.2. Procedure voor analyse en oplossing Wat de integratieen acceptatietests betreft, zijn dit de stappen: Stap

Evenement/Actie

Betrokken personen

1

De eigenaar corrigeert de anomalie, test zijn correctie en wijzigt het statuut

Ontwikkelaar

2

De anomalie wordt opnieuw getest tijdens de volgende integratietests

Tester

3

De log wordt geactualiseerd

Tester

3.3. Definitie van prioriteiten Prioriteit

Beschrijving

Critical

Het systeem is niet operationeel (vb: probleem met toegang tot database, geen communicatie met de server,…)

High

Een specifieke functionaliteit is niet operationeel

Medium

Een specifieke functionaliteit is niet correct geïmplementeerd, maar men kan anders te werk gaan in afwachting van een rechtzetting

Low

De functionaliteiten zijn operationeel maar er zijn kleine fouten (presentatie, spelling,…)

3.4. Tools De anomalieën en hun opvolging worden beheerd in Mercury QC op basis van de inhoud van het gedeelte « Anomalieën » in het document « Werkwijzen » van de discipline D5 Test (FUP-MO-D5Tests.doc). De eventuele Change Requests die overeenstemmen met de anomalieën, ontdekt tijdens de uitvoering van de verschillende testcampagnes, worden beheerd in Starteam op basis van de discipline voor Change management die buiten de FUP-methodologie en dit document valt.


Versie

Pagina

0.2

29/38


4.


TESTDOCUMENTATIE

Er is een documentatie nodig om alle stappen van het testproces correct te kunnen uitvoeren: planning, ontwikkeling, uitvoering en afwerking. De kansen op welslagen van de tests worden duidelijk verbeterd door het feit te kunnen beschikken over een gedetailleerde documentatie betreffende de te volgen procedures, de verwachte resultaten, de noodzakelijke testgegevens, … De documentatie ‘leeft’, wat inhoudt dat ze zal evolueren, zal worden aangepast en aangevuld in de loop van het hele project. De belangrijkste elementen van deze documentatie zijn: De masterteststrategie De projectteststrategie Het plan met de integratietests Het plan met de acceptatietests De matrix voor de opvolgbaarheid van de vereisten


Versie

Pagina

0.2

30/38


4.1.


De testplannen

4.1.1. De masterteststrategie De masterteststrategie is het (onderhavige) document dat de strategie definieert die moet worden gehanteerd door alle ontwikkelingsprojecten, zodat men zich kan verzekeren dat het geleverde systeem overeenstemt met alle geformuleerde vereisten.

Doelstellingen Definitie van de reikwijdte van de testactiviteiten, Detail van de types van testactiviteiten, Beschrijving van de methodologie, de technieken en de gebruikte tools, Definitie van rollen en verantwoordelijkheden, Beschrijving van de documentatie, Beschrijving van de procedures voor opvolging van fouten. 4.1.2. De projectteststrategie De projectteststrategie heeft als basis de masterteststrategie maar ze zal voor elk project zo nodig worden aangevuld en/of eventueel aangepast in gezamenlijk overleg met de FOD.

Doelstellingen Definitie van de reikwijdte, bestreken door de eenheidstests, Beschrijving van het testframework, Identificatie van de componenten die moeten worden getest, Identificatie van de noodzakelijke testgegevens, Beschrijving van de nodige standaarden/procedures, Beschrijving van de nodige tools en hoe ze te gebruiken


Versie

Pagina

0.2

31/38



4.1.3. Plan met integratietests Dit plan beschrijft wat moet worden getest en hoe in het kader van de activiteiten van de integratietests.

Doelstellingen Definitie van de reikwijdte van de integratietests, Identificatie van de componenten die moeten worden getest, Identificatie van de testcases en -gegevens, Beschrijving van standaarden en procedures, De werkwijze Toekenning van rollen Detail van de activiteiten Draft van de testplanning.

Tools Dit document is een worddocument gebaseerd op de teststrategie en aangepast aan het project. De elementen van dit plan die betrekking hebben op de testcases, zijn geïntegreerd in Mercury Quality Center. 4.1.4. Plan met acceptatietests Dit plan beschrijft wat moet worden getest en hoe in het kader van de acceptatietests van het systeem. Dit document valt onder de verantwoordelijkheid van de FOD.

Doelstellingen Definitie van de reikwijdte van de acceptatietests, Identificatie van de componenten die moeten worden getest, Identificatie van de testcases en -gegevens, Beschrijving van standaarden en procedures De werkwijze Toekenning van rollen Detail van de activiteiten Draft van de testplanning


Versie

Pagina

0.2

32/38


4.2.


Matrix voor opvolgbaarheid van de vereisten

Deze matrix biedt een totaalkijk op alle functionele en niet-functionele vereisten en de opvolging van de testscenario’s die ermee zijn gerelateerd.

Doelstellingen Zich verzekeren dat elke vereiste minstens één keer werd getest, Helpen bij de identificatie van de reikwijdte van de testactiviteiten en de gegevens die daarvoor noodzakelijk zijn.

Tools Deze matrix wordt beheerd door middel van de koppelingen tussen de testcases en de vereisten, opgeslagen in Quality Center Center. 4.3.

Testcases

Elke testcase bevat een beschrijving, de gebruikscases die ermee zijn gerelateerd, en het uitvoeringsstatuut ervan. Een testscript kan bestaan: Voor een manuele test: een gedetailleerd testscenario met een beschrijving van de manueel uit te voeren acties en de criteria om de resultaten te evalueren. Voor een automatische test: een script in een geprogrammeerde taal (Java of VB script) ondersteund door een tool die wordt gebruikt voor de automatische testing (Java of VB script).

Doelstellingen Ter beschikking stellen van het materiaal om te testen aan het testteam, Het testteam begeleiden bij de uitvoering van de tests, De uitvoering van de testcases opvolgen. De testmethode moet het volgende ondersteunen: De activiteiten voor de integratietests, De activiteiten voor de acceptatietests, uitgevoerd door het team van de leverancier

Tools Al wat te maken heeft met de manuele definities van de testcases, wordt rechtstreeks vastgelegd in Mercury Quality Center. De geautomatiseerde tests van de front-end sont worden geïnitialiseerd in Quality Center en de scripts worden vervolgens aangevuld in Mercury QuickTest Professional.. .


Versie

Pagina

0.2

33/38


4.4.


Testrapporten

De rapporten en balansen die de resultaten van de integratieen acceptatietests bundelen.

Doelstellingen Synthese van de testresultaten, Synthese van de uitgevoerde testcases, Identificatie van de problemen, vastgesteld tijdens de tests, Globale balans van de tests van een release

Tools De rapporten en balansen over de uitvoering van de tests zullen worden gegenereerd op basis van de informatie van Quality Center. De balans met de anomalieën is afkomstig van Starteam. 4.5.

Bijkomende documenten

De volgende informatie is noodzakelijk om de tests in goede banen te leiden. 4.5.1. Account Relationship Matrix (ARM) Lijst met de accounts/loggings die moeten worden gebruikt tijdens de tests. Het aantal beschikbare logins moet toereikend zijn om alle mogelijke rollen te dekken. Elke testcase moet worden gekoppeld aan verschillende rollen. Deze matrix wordt opgeslagen in Mercury Quality Center. 4.5.2. Testgegevens Lijst met noodzakelijke testgegevens voor de testcases. 4.5.3. Procedure voor registratie van fouten Document met beschrijving van manier voor beheer en opvolging van fouten, ontdekt tijdens de tests.


Versie

Pagina

0.2

34/38


4.6.


Verantwoordelijkheden op het vlak van de documentatie

Document

Verantwoordelijke

Formaat

Masterteststrategie

FOD

Document

Projectteststrategie

Verantwoordelijke Tests (lev)

Document

Plan Kwaliteit Discipline D4


Document

Rapport Kwaliteit Discipline D4

Senior ontwikkelaar (lev)

Document

Plan(nen) met integratietests


Document

Plan(nen) met acceptatietests

FOD

Document

Matrix opvolgbaarheid vereisten

Senior tester (lev)

Implementering in Mercury Quality Center

Definitie testcases

Senior tester / FOD

Implementering in Mercury Quality Center

Rapporten en balansen integratietests

Tester / Senior tester

Rapporten in Mercury Quality Center

Rapporten en balansen acceptatietests

FOD

Account Relationship Matrix

Verantwoordelijke tests / FOD

Document stocké dans le Mercury Quality Center

Testgegevens

Senior tester /FOD

Document stocké dans le Mercury Quality Center


Versie

Pagina

0.2

35/38


5. 5.1.


ROLLEN EN COMMUNICATIE Rollen

Een rol vertegenwoordigt een geheel van verantwoordelijkheden. Het is niet uitgesloten dat voor kleine projecten eenzelfde persoon meerdere rollen kan cumuleren. Van de kant van de leverancier Rol Verantwoordelijke tests

Verantwoordelijkheden De rol van de testmanager bestaat erin de testactiviteiten te definiëren en te beheren, wat het volgende omvat: De dagelijkse begeleiding en coördinatie van het testteam De opmaak van het plan met de integratietests De verantwoordelijkheid voor het welslagen van de activiteiten voor de integratietests De controle van de kwaliteit van de tests en de naleving van de standaarden De controle en opvolging van de logging van anomalieën De communicatie naar de projectleider

Senior tester

De rol van de senior tester bestaat uit het assisteren van de teams van testers en Het initiëren van de opmaak van de testcases Het verzekeren van de relatie met de contactpersoon van de FOD Het verzekeren van de relatie met de FOD tijdens de integratieen acceptatietests Het adviseren van de teams op het vlak van test en kwaliteit Het deelnemen aan de analyse van anomalieën

Tester

De rol van de tester bestaat uit Het implementeren en uitvoeren van de scenario’s met integratietests Het inventariseren en communiceren van ontdekte fouten

Senior ontwikkelaar


De rol van de senior ontwikkelaar bestaat uit het verzekeren van de kwaliteit van discipline D4 (« Implementering ») en het produceren van het Rapport inzake Kwaliteit D4 op basis van het Plan inzake Kwaliteit D4.

Versie

Pagina

0.2

36/38



Van de kant van de klant-FOD Rol Verantwoordelijke tests

Verantwoordelijkheden De rol van de testmanager is het definiëren en beheren van de testactiviteiten, wat omvat: De dagelijkse begeleiding en coördinatie van het testteam De opmaak van het plan met de acceptatietests De verantwoordelijkheid voor het welslagen van de activiteiten voor de acceptatietests De controle van de kwaliteit van de tests en de naleving van de standaarden De controle en opvolging van de logging van anomalieën De communicatie naar de projectleider

Contactpersoon tests

De rol van de contactpersoon tests bestaat uit het assisteren van de teams van testers en Het verzekeren van de relatie tussen de testteams van de FOD en de leverancier Het verzekeren van de support aan de leverancier in de loop van de integratietests Het verzekeren van de relatie met de leverancier in de loop van de acceptatietests Het adviseren van de teams op het vlak van test en kwaliteit Het communiceren aan de leverancier van de testresultaten, het opvolgen van de evolutie van fouten, … Het verzekeren van de voorziening van de testgegevens

Tester

De rol van de tester bestaat uit Het implementeren en uitvoeren van de scenario’s met acceptatietests Het inventariseren en communiceren van ontdekte fouten Dit beperkt zich niet tot de functionele tests, maar is ook van toepassing op alle gedefinieerde testtypes (zie deel 2.8).


Versie

Pagina

0.2

37/38


5.2.


Kennisoverdracht

Vóór de eerste acceptatietests zal er een vergadering worden georganiseerd om aan het testteam van de FOD het systeem, de testtools en de scenario’s, gebruikt voor de integratietests, te presenteren.

Doelstellingen Het testteam van de FOD voorbereiden op de verschillende activiteiten die hen toekomen, Het nieuwe systeem presenteren, De doelstellingen en de teststrategie uitleggen, De testmethodologie uitleggen, De te volgen procedure voor de opmaak van testrapporten en –balansen uitleggen, Het traject beschrijven voor de communicatie en opvolging van anomalieën, ontdekt tijdens de activiteiten van de acceptatietests.

Geactualiseerd

Versie

Pagina 38/38

FUP 1.0 D5- Test > Modellen > Afgeleide Master-Teststrategie


AFGELEIDE MASTER-TESTSTRATEGIE


X


1 2

\fup\FUP 1.0_NL\Modellen\D5\FUP-TPL51-D5-Afgeleide master-teststrategie.doc



2

Bijwerking

Versie

Page

0.1

1/23




Auteur

FUP

Versie

Aard

REFERENTIES

Bijwerking

Versie

Page

0.1

2/23



INHOUDSTAFEL 1.

PRÉSENTATIE VAN HET DOCUMENT ...........................................................................................5 1.1.

DOELSTELLING VAN HET DOCUMENT...................................................................................................5

1.2.

TOT WIE IS DIT DOCUMENT GERICHT? .................................................................................................5

2.

TESTBENADERING ..........................................................................................................................6 2.1.

BEREIK VAN DE TESTACTIVITEITEN .....................................................................................................6

2.2.

DEFINITIE VAN DE TESTOMGEVINGEN..................................................................................................6

2.3.

ALGEMENE AANPAK INZAKE TESTACTIVITEITEN ....................................................................................6

2.4.

EENHEIDSTESTS ...............................................................................................................................6

2.5.

INTEGRATIETESTS .............................................................................................................................8

2.5.1.

Benadering en proces .............................................................................................................8

2.5.2.

Tool voor beheer van integratietests .....................................................................................10

2.6.

DE VERSCHILLENDE TYPES VAN INTEGRATIETESTS ............................................................................11

2.6.1.

Tests in verband met functionele vereisten...........................................................................11

2.6.2.

Tests in verband met bijkomende vereisten..........................................................................11

2.6.3.

Tests van niet-regressie ........................................................................................................11

2.6.4.

Tests in verband met operationele aspecten ........................................................................11

2.7.

ACCEPTATIETESTS ..........................................................................................................................12

2.7.1.

Benadering en proces ...........................................................................................................12

2.7.2.

Testtypes ...............................................................................................................................12

2.7.3.

Tool voor beheer van acceptatietests ...................................................................................12

2.8.

SYNTHESE VAN TESTS .....................................................................................................................13

2.9.

SYNTHESE VAN TOOLS ....................................................................................................................14

2.10.

DE GETESTE PLATFORMEN ...........................................................................................................14

2.11.

DE TESTS VAN EXTERNE PARTNERS ..............................................................................................14

3.

OPVOLGING VAN ANOMALIEËN / BUGS ....................................................................................15 3.1.

PROCEDURES VOOR REGISTRATIE VAN ANOMALIEËN .........................................................................15

3.1.1.

Procedure voor registratie van anomalieën bij eenheidstests ..............................................15

3.1.2.

Procedure voor registratie van anomalieën bij integratietests ..............................................15

3.1.3.

Procedure voor registratie van anomalieën bij acceptatietests.............................................16

3.2.

PROCEDURE VOOR ANALYSE EN OPLOSSING .....................................................................................16

3.3.

DEFINITIE VAN PRIORITEITEN............................................................................................................16

3.4.

TOOLS ............................................................................................................................................16

4.

DOCUMENTATIE VAN TESTS .......................................................................................................17 4.1.

DE TESTPLANNEN ...........................................................................................................................18

4.1.1.

De master-teststrategie .........................................................................................................18

4.1.2.

De projectteststrategie ..........................................................................................................18

Bijwerking

Versie

Page

0.1

3/23



4.1.3.

De instructies voor de eenheidstests ....................................................................................18

4.1.4.

Plan voor integratietests........................................................................................................18

4.1.5.

Plan voor acceptatietests ......................................................................................................18

4.2.

MATRIX VOOR OPVOLGING VAN VEREISTEN .......................................................................................19

4.3.

TESTCASES ....................................................................................................................................19

4.4.

TESTRAPPORTEN ............................................................................................................................20

4.5.

BIJKOMENDE DOCUMENTEN .............................................................................................................20

4.5.1.

Account Relationship Matrix (ARM) ......................................................................................20

4.5.2.

Testgegevens ........................................................................................................................20

4.5.3.

Procedure voor registratie van fouten ...................................................................................20

4.6. 5.

VERANTWOORDELIJKHEDEN INZAKE DOCUMENTATIE .........................................................................20 ROLLEN EN COMMUNICATIE .......................................................................................................21

5.1.

ROLLEN ..........................................................................................................................................21

5.2.

KENNISOVERDRACHT ......................................................................................................................23

Bijwerking

Versie

Page

0.1

4/23



1. PRESENTATIE VAN HET DOCUMENT 1.1. Doelstelling van het document [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

1.2. Tot wie is dit document gericht? [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

Bijwerking

Versie

Page

0.1

5/23



2. TESTBENADERING 2.1. Bereik van de testactiviteiten [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

2.2. Definitie van de testomgevingen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

2.3. Algemene aanpak inzake testactiviteiten [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

2.4. Eenheidstests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Doelstellingen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Input [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Wanneer ? [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Hoe ? Tests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Revisie van code [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Wie ? [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Bijwerking

Versie

Page

0.1

6/23



Waar [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Documentatie en te leveren prestaties [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

Bijwerking

Versie

Page

0.1

7/23



2.5. Integratietests 2.5.1. Benadering en proces [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Doelstellingen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Input [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Wanneer ? [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

Bijwerking

Versie

Page

0.1

8/23



Hoe ? Testplan [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Uitvoering van de tests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Wie ? [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Waar [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Documentatie en te leveren prestaties [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

Bijwerking

Versie

Page

0.1

9/23



2.5.2. Tool voor beheer van integratietests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

Bijwerking

Versie 0.1

Page 10/23



2.6. De verschillende types van integratietests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 2.6.1. Tests in verband met functionele vereisten [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Tool [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 2.6.2. Tests in verband met bijkomende vereisten [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 2.6.3. Tests van niet-regressie [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 2.6.4. Tests in verband met operationele aspecten [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Prestatietests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Gebruikte tools [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Veiligheidstests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Tests voor installatie en configuratie [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Tests voor back-up en recovery [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Tests voor administratie en besturing van het systeem [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Bijwerking

Versie 0.1

Page 11/23



Inspectie van de documentatie [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Tests voor migratie van gegevens [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

2.7. Acceptatietests 2.7.1. Benadering en proces [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Doelstellingen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Input [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Wanneer ? [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Hoe ? [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Wie ? [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Waar [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Documentatie en te leveren prestaties (door de FOD) [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 2.7.2. Testtypes [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 2.7.3. Tool voor beheer van acceptatietests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Bijwerking

Versie 0.1

Page 12/23



2.8. Synthese van tests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

Bijwerking

Versie 0.1

Page 13/23



2.9. Synthese van tools [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

2.10. De geteste platformen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

2.11. De tests van externe partners [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

Bijwerking

Versie 0.1

Page 14/23



3. OPVOLGING VAN ANOMALIEËN / BUGS 3.1. Procedures voor registratie van anomalieën [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 3.1.1. Procedure voor registratie van anomalieën bij eenheidstests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

3.1.2.

Procedure voor registratie van anomalieën bij integratietests

[Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

Bijwerking

Versie 0.1

Page 15/23



3.1.3. Procedure voor registratie van anomalieën bij acceptatietests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

3.2. Procedure voor analyse en oplossing [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

3.3. Definitie van prioriteiten [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

3.4. Tools [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

Bijwerking

Versie 0.1

Page 16/23


4.


DOCUMENTATIE VAN TESTS


Bijwerking

Versie 0.1

Page 17/23


4.1.


De testplannen

4.1.1. De master-teststrategie [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Doelstellingen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 4.1.2. De projectteststrategie [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 4.1.3. De instructies voor de eenheidstests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Doelstellingen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 4.1.4. Plan voor integratietests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Doelstellingen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Tools [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 4.1.5. Plan voor acceptatietests [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Doelstellingen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

Bijwerking

Versie 0.1

Page 18/23


4.2.


Matrix voor opvolging van vereisten

[Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Doelstellingen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Tools [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

4.3.

Testcases

[Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Doelstellingen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Tools [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] .

Bijwerking

Versie 0.1

Page 19/23


4.4.


Testrapporten

[Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Doelstellingen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Tools [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

4.5.

Bijkomende documenten

[Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 4.5.1. Account Relationship Matrix (ARM) [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 4.5.2. Testgegevens [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] 4.5.3. Procedure voor registratie van fouten [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

4.6.

Verantwoordelijkheden inzake documentatie


Bijwerking

Versie 0.1

Page 20/23


5.


ROLLEN EN COMMUNICATIE

5.1.

Rollen

[Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Van de kant van de leverancier


Bijwerking

Versie 0.1

Page 21/23



Van de kant van de FOD [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

Bijwerking

Versie 0.1

Page 22/23


5.2.


Kennisoverdracht

[Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.] Doelstellingen [Voeg hier een tekst in als deze paragraaf in het document van de master-test niet overeenstemt met de specifieke behoeften van het project.]

Bijwerking

Versie 0.1

Page 23/23

FUP 1.0 D5- Test > Modellen > Testdossier


TESTDOSSIER Versie 1.0 [Opmerking: de tekst die wordt afgebakend met haakjes en blauw cursief wordt weergegeven (style=InfoBlue), is bedoeld als gids voor de auteur van het document. Deze laatste moet erop toezien deze tekst te schrappen vóór de uitgave van het document. De paragrafen die aanvangen na deze opmerkingen, zullen automatisch worden ingeleid in de normale stijl (style=standaard).] [Om de velden automatisch aan te passen in Microsoft Word (dat een grijze achtergrond toont wanneer het veld is geselecteerd), kiest u Bestand >Eigenschappen en vervangt u de velden Titel, Onderwerp en Bedrijf door de informatie die geschikt is voor uw document. Om het document vervolgens te actualiseren, selecteert u de hele tekst (Ctrl+A) en vernieuwt u vervolgens het document (F9). Dit moet los van elkaar gebeuren voor de hoofdtekst en voor de koptekst en de voettekst.]


X


1 2

\fup\FUP 1.0_NL\Modellen\D5\FUP-TPL52-D5-Testdossier.doc



2


Versie

Page

0.1

1/7




Auteur

FUP

Versie

Aard

Februari 2007

Unisys

1.0

0.1

Oorspronkelijke versie

REFERENTIES


Versie

Page

0.1

2/7



INHOUDSTAFEL 1.

INLEIDING .........................................................................................................................................5 1.1.

VOORWERP VAN HET DOCUMENT .............................................................................................. 5

1.2.

DEFINITIES EN AFKORTINGEN .................................................................................................... 5

2.

DEKKING VAN DE VEREISTEN.......................................................................................................6

3.

TESTCASE ........................................................................................................................................7


Versie

Page

0.1

3/7



GEBRUIK VAN DIT DOCUMENT

Opmerking : dit punt moet enkel worden behouden in het documentmodel, niet in de te leveren prestatie

Doelstelling van dit documentmodel Het doel van dit document bestaat erin een model en een gids te vormen voor de realisatie van de te leveren prestatie « Testdossier ». Dit document moet worden aangevuld met informatie uit Quality Center die wordt gedistilleerd met behulp van vooraf bepaalde rapporten (zie hierna). Men dient het onderscheid te maken tussen een te leveren prestatie en een rapport, afkomstig van de tools. Een te leveren prestatie is een communicatietool voor de validering van één of meer artefacten. Een te leveren prestatie is dus een document dat elementen bevat die afkomstig zijn van verschillende rapporten op basis van de tools, maar kan niet rechtstreeks worden geproduceerd door de tools zelf.

Gebruik van dit model Sommige elementen (teksten, tabellen en schema’s) in dit model worden verschaft bij wijze van voorbeeld en dienen als hulp bij de opmaak. De gegevens zijn gedistilleerd uit Quality Center met behulp van vooraf bepaalde rapporten. In functie van de gewenste granulariteit kan een te leveren prestatie verschillende subgehelen van tests bestrijken. Men zal bijvoorbeeld een Testdossier kunnen uitbrengen voor verschillende versies van de toepassing. Voor het gedeelte ‘rapporten’ dat wordt gegenereerd door Quality Center, kan men makkelijk de tests filteren die moeten worden gebruikt in een rapport ; dit wordt in detail uitgelegd in de werkwijzen.

Rapporten, aangemaakt door Quality Center. De door Quality Center aangemaakte rapporten vormen het informatiebestand waarmee dit document moet worden vervolledigd. Eén enkel rapport maakt het mogelijk om het geheel of een gedeelte van de testcases te bestrijken, naargelang de behoeften van de gebruiker. Dit rapport kan worden gegenereerd via Quality Center, met gebruikmaking van de interne favorieten in Quality Center. Dit wordt in detail uitgelegd in de werkwijzen van D5. Het rapport dat de gedeelten bevat die moeten worden ingevoegd in deze template, wordt aangemaakt, zoals uitgelegd in de werkwijzen voor het Testdossier, door de favoriet in QC.

Typografische afspraak In het vervolg van dit document zijn de begeleidende elementen beschreven in blauwe cursieve tekst.


Versie

Page

0.1

4/7


1.


INLEIDING 1.1.

VOORWERP VAN HET DOCUMENT

Het document bevat de volgende gedeelten : -

-

Dekking van de vereisten. Dit gedeelte geeft een overzicht van alle vereisten. De volgende informatie is hier opgenomen. o

De data van creatie en wijziging.

o

Coverage. Met de tests die te maken hebben met de vereiste.

o

Description. Beschrijving, ingevoerd uit CaliberRM.

o

CaliberRM ID. ID van de vereiste in CaliberRM.

Testcase. De testcases bevinden zich in het hoofdstuk ‘Test List’. Elke testcase vermeldt de volgende informatie:

1.2.

o

De data van creatie en wijziging.

o

Beschrijving. Doelstellingen, pre-voorwaarden, post-voorwaarden, testgegevens en manipulaties na de tests.

o

Type. Beschrijft het testtype. Als het gaat om een geautomatiseerd script, is dit van het type QuickTest of LoadRunner. In de andere gevallen gaat het om het type Manual.

o

De gedetailleerde procedure. In het gedeelte ‘Steps’ van elke testcase kan men de verschillende stappen van elke test zien, alsook de verwachte resultaten.

DEFINITIES EN AFKORTINGEN

[De definitie voorzien van alle begrippen en afkortingen die worden gehanteerd in dit document. Deze informatie kan eventueel voorkomen in de Woordenlijst.]


Versie

Page

0.1

5/7


2.


DEKKING VAN DE VEREISTEN

[Hier het hoofdstuk ‘Chapter 1.Requirements’ invoegen van het rapport in .doc-formaat, aangemaakt door QC , dat u eventueel kunt opmaken.]


Versie

Page

0.1

6/7


3.


TESTCASE

[Hier het hoofdstuk ‘Chapter 2.Test List’ invoegen van het rapport in .doc-formaat, aangemaakt door QC , dat u eventueel kunt opmaken.]


Versie

Page

0.1

7/7

FUP 1.0 D5- Test > Model> Testbalans


Ontwikkelingsondersteuning Testbalans Versie

[Opmerking: de cursieve, blauwe tekst tussen haakjes (style=InfoBlue) dient als gids voor de auteur van het document. Deze laatste moet erop toezien dat deze tekst verdwijnt vóór de editie van het document. De paragrafen die worden begonnen na deze opmerkingen, zullen automatisch worden geïnitialiseerd in het normale stijl (style=lettergrootte tekst). [Om de velden automatisch aan te passen in Microsoft Word (dat een grijze achtergrond weergeeft wanneer het veld wordt geselecteerd), selecteert u Bestand>Eigenschappen en vervangt u de velden Titel, Onderwerp en Bedrijf door de informatie die geschikt is voor uw document. Om het document nadien te actualiseren, selecteert u de hele tekst (Ctrl+A) en vernieuwt u nadien het document (F9). Dit kan los van elkaar voor de hoofdtekst en voor de kop- en voetteksten gebeuren.]


X


1 2

\fup\FUP 1.0\Modellen\D5\FUP-TPL53-D5-Testbalans.doc

De documenten met betrekking tot de FUP-methodologie kunnen lokaal worden gedownload op uw harde schijf met behulp van de toepassing Starteam - project FUP – functionaliteit check out all. Tijdens een exportoperatie (Check out all), wordt de boomstructuur uit Starteam overgebracht naar de lokale harde schijf c:\. 1

De documenten met betrekking tot de FUP-methodologie zijn ook gepubliceerd op de XWIKI van de infrastructuur, menu « SUPDEV », rubriek « FUP-methodologie – Documenten NL en FR », op het adres http://infrastructure.finbel.intra/xwiki/bin/view/SupDev/documents.

2

Geactualiseerd

Versie

Februari 2007

0.1

Pagina 1/10



HISTORIEK VAN DE AANPASSINGEN Datum

Auteur

FUP

Versie

Aard

Februari 2007 April 2009

Unisys FOD Financiën (G.Merlini)

1.0 1.0

0.1 0.2

Initiële versie CR7945 : Beheer van de anomalieën in Mercury en niet in Starteam - Gedeelte « Gebruik van dit document » : verwijdering van alle referenties naar Starteam - Par. 1.1 : beschrijving van het formaat van het rapport met de anomalieën. - Par. 5 : verwijzing naar het rapport met de anomalieën van Mercury QC CR7964 : Controle MERCURY QC Filters en Rapporten - Gedeelte « Gebruik van dit document » : waarschuwing voor eventueel configuratieprobleem

REFERENTIES

Geactualiseerd

Versie

Februari 2007

0.1

Pagina 2/10



INHOUDSTAFEL 1.

INLEIDING ....................................................................................ERREUR ! SIGNET NON DEFINI. 1.1.

VOORWERP VAN HET DOCUMENT .......................................................................................................5

1.2.

DEFINITIES EN AFKORTINGEN.............................................................................................................6

2.

KWALITATIEF ADVIES OVER DE TOEPASSING .....................ERREUR ! SIGNET NON DEFINI.

3.

DEKKING VAN DE VEREISTEN..................................................ERREUR ! SIGNET NON DEFINI.

4.

TESTCASES.................................................................................ERREUR ! SIGNET NON DEFINI.

5.

RAPPORT MET ANOMALIEËN......................................................................................................10

Geactualiseerd

Versie

Februari 2007

0.1

Pagina 3/10



GEBRUIK VAN DIT DOCUMENT Opmerking : dit punt moet enkel worden behouden in het documentmodel, niet in de deliverable.

Doelstelling van dit documentmodel De bedoeling van dit document is een model en een gids te verschaffen voor de realisatie van de deliverable « Testbalans ». Dit document moet worden aangevuld met de informatie, vervat in Quality Center en gedistilleerd met behulp van vooraf bepaalde rapporten (zie verderop). Men dient goed het onderscheid te maken tussen deliverable en rapport, afkomstig uit de tools. Een deliverable is een communicatietool voor de validering van één of meer artefacten. Een deliverable is dus een document met elementen, afkomstig uit verschillende rapporten die vanuit de tools komen, maar kan niet rechtstreeks worden geproduceerd door de tools zelf.

Gebruik van dit model Sommige elementen (teksten, tabellen en schema’s) in dit model worden voorzien bij wijze van voorbeeld om te helpen bij de redactie. De gegevens zijn gedistilleerd uit Quality Center met behulp van vooraf bepaalde rapporten. In functie van de gewenste granulariteit kan een deliverable verschillende subgehelen van tests dekken. Men kan bijvoorbeeld een Testdossier genereren voor verschillende versies van de toepassing. Voor het gedeelte ‘rapporten’, gegenereerd door Quality Center, kan men makkelijk de tests filteren die moeten worden gebruikt in een rapport; dat wordt in detail uitgelegd in de operationele modellen.

Rapporten, gegenereerd door Quality Center. De rapporten, gegenereerd door Quality Center, vormen één van de informatiebestanden waarmee huidig document moet worden aangevuld. Eén enkel rapport biedt de mogelijkheid om het geheel of een gedeelte van de testcases te dekken, naargelang de behoeften van de gebruiker. Dit rapport kan worden gegenereerd via Quality Center, met gebruikmaking van de interne favorieten in Quality Center. Dit wordt in detail uitgelegd in de werkwijzen van D5. Het rapport met de gedeelten die in deze template moeten worden ingevoegd, wordt aangemaakt, zoals uitgelegd in de werkwijzen voor het Testdossier, door de favoriet in QC (*).

Typografische afspraken In het vervolg van dit document zijn de begeleidende stukken in het blauw en cursief weergegeven.

(*) Warning : als het hier gespecificeerde formaat of type van rapporten niet voorkomt in uw MERCURY QC-project, kunt u de interventie van het team van SUPDEV vragen op het adres « support.supdevéminfin.fed.be» om de correcte configuratie te herinstalleren.

Geactualiseerd

Versie

Februari 2007

0.1

Pagina 4/10


1.


INLEIDING 1.1. Voorwerp van het document

Het document bevat de volgende gedeelten : -

Kwalitatief advies over de toepassing.

-

Dekking van de vereisten. Dit deel geeft een overzicht van alle requirements. De volgende informatie wordt vermeld.

-

o

De data van creatie en aanpassing.

o

Direct Cover Status. Geeft de status van de requirement in functie van de tests die ermee zijn gerelateerd: Not Covered – geen enkele test dekt deze requirement.

No Run – er werd geen enkele test opgestart.

Not Completed – minstens één test ging niet helemaal tot het einde.

Failed – minstens één test is niet geslaagd.

Passed – alle tests in verband met deze requirement zijn geslaagd.

o

Beschrijving. Beschrijving, ingevoerd uit CaliberRM.

o

CaliberRM ID. ID van de requirement in CaliberRM.

o

Grafiek. Op het einde van de requirements herneemt een overzichtsgrafiek de dekking van de requirements. Hij bevat het totale aantal requirements en klasseert de requirements in functie van hun ‘Direct Cover Status’.

Testcase. De testcases bevinden zich in het hoofdstuk ‘Test List’. Elke testcase bevat de volgende informatie: o

De data van creatie en aanpassing.

o

Beschrijving. Doelstellingen, pre-voorwaarden, post-voorwaarden, testgegevens en manipulaties na test.

o

Type. Beschrijft het type van de test. Als het gaat om een geautomatiseerd script, heeft hij het type QuickTest of LoadRunner. Hij heeft het type Manual in alle andere gevallen.

o

Execution Status. Beschrijft de huidige status van de test vanuit een uitvoeringsoogpunt.

o -

No Run – er werd geen enkele test opgestart.

Not Completed – minstens één test ging niet helemaal tot het einde.

Failed – minstens één test is niet geslaagd.

Passed – alle tests in verband met deze requirement zijn geslaagd.

Grafiek. Een grafiek herneemt alle tests, geklasseerd per status. De grafiek biedt ons informatie over het totale aantal tests, alsook hun graad van welslagen en uitvoering.

Anomalieën. Het Rapport met de Anomalieën bevat de volgende gegevens (formaat « Defects with Associated Tests and Run ») o

Defect ID :

o

Status :

New: de fout is geregistreerd

Open: de correctie is gepland en toegewezen

Geactualiseerd

Versie

Februari 2007

0.1

Pagina 5/10



Rejected: de correctie is niet gepland

Fixed: de correctie is uitgevoerd en gecontroleerd door de verantwoordelijke

Closed : de correctie is aanvaard tijdens de nieuwe campagne met integratie/acceptatietests

ReOpen : de correctie is niet aanvaard

o

Priority : inschatting van de dringendheid van de correctie

o

Severity : ernst van de impact van de anomalie

o

Summary : korte beschrijving van de anomalie

o

Assigned To : verantwoordelijke voor de geplande rechtzetting van de anomalie

o

Detected By : verantwoordelijke voor de aangifte van de anomalie

o

Description : gedetailleerde beschrijving van de anomalie

o

Related Test : test gerelateerd met de detectie van de anomalie

1.2. Definities en afkortingen. [De definitie voorzien van alle termen en afkortingen, gebruikt in dit document. Deze informatie kan eventueel voorkomen in de Woordenlijst.]

Geactualiseerd

Versie

Februari 2007

0.1

Pagina 6/10


2.


KWALITATIEF ADVIES OVER DE TOEPASSING

[Voeg hier het kwalitatief advies in dat voorkomt op de eerste pagina van het rapport, aangemaakt door QC , dat u eventueel zelf kunt opmaken.]

Geactualiseerd

Versie

Februari 2007

0.1

Pagina 7/10


3.


DEKKING VAN DE VEREISTEN

[Voeg hier het hoofdstuk ‘Chapter 1. Requirements’ in van het rapport, aangemaakt door QC , dat u eventueel zelf kunt opmaken.]

Geactualiseerd

Versie

Februari 2007

0.1

Pagina 8/10


4.


TESTCASE

[Voeg hier het hoofdstuk ‘Chapter 2. Test List’ in van het rapport, aangemaakt door QC , dat u eventueel zelf kunt opmaken.]

Geactualiseerd

Versie

Februari 2007

0.1

Pagina 9/10

FUP 1.0 Discipline

5.

Support au développement [email protected]

RAPPORT MET ANOMALIEËN

[Voeg hier het rapport met de anomalieën in, aangemaakt door de module « Deferre » van Mercurey QC. Het formaat «Defects with Associated Tests and Run » is aanbevolen. ]

Geactualiseerd

Versie

Pagina

Oktober 2007

0.5

10/10

STATUS. \fup\fup 1.0_NL\Disciplinen\D5\FUP-D5_Test.doc

Recommend Documents