Ordina !Effective Projects Bv

ORDINA
!EFFECTIVE PROJECTS BV


Ordina !Effective
Testprocedure
0.1, 24-04-03

© Ordina !Effective, 2003

Titel / Testporcedure
Ondertitel / Increment 1
Versie, datum / 0.1, 24-04-03
Status / concept
Referentie
Samengesteld door
Project
Laatste versie bewerkt door
Bestandsnaam / \\Westersingel\Projecten Data\Projecten\MIB\4 Producten\Acceptatietest\Testprocedure.doc

.

7

ORDINA
!EFFECTIVE PROJECTS BV


Versiehistorie

Versie / Datum / Auteur / Opmerking
0.1 / 24-04-2003 / Sandra van Tilburg / Initiële versie


1 Inleiding 5

2 Testinrichting 6

2.1 Communicatie 6

2.2 Categorisering bevindingen 6

3 Rapportage testbevindingen 8

3.1 Doorlopen testscripts 8

3.2 Opslaan bevindingen 10

1  Inleiding


De inzet van gebruikers gedurende de acceptatietest is van groot. Zij zijn de gebruikers van het systeem en voeren handelingen uit in een produktie like testomgeving met data die ze in het ‘gewone’ gebruik ook tegenkomen. Met het doorlopen van de testscripts zullen zij meten of het opgeleverde systeem aan hun verwachtingen voldoet. Zoniet dan zullen zij hun bevindingen kenbaar moeten maken zodat ontwikkelaar de bevindingen kunnen oplossen, waarna er weer een hertest door de gebruikers kan plaatsvinden.

Om het bevindingen vast te kunnen stellen en deze op een heldere manier te registreren is deze testprocedure opgesteld. Hierin wordt beschreven welke stappen moeten worden doorlopen om tot een duidelijk en helder testrapport te komen en hoe hierover te communiceren.

Hoofdstuk 1 gaat daarom in over de organisatie en afspraken om het testen heen. Hoofdstuk 2 gaat over het rapporteren van de testbevindingen.

2  Testinrichting

In dit hoofdstuk wordt een beschrijving gegeven van de communicatie zoals deze zal plaatsvinden gedurende het testen. Daarnaast is een beschrijving gegeven van de categoriseren waarbinnen de bevindingen van het testen kunnen vallen.

2.1  Communicatie

De projectleider zal het testteam aansturen Tijdens de GAT start de testdag om 9.00 uur met een korte bijeenkomst waarin de doelstelling en werkzaamheden voor die dag worden doorgesproken met alle teamleden. Hierna kunnen de testen van start gaan

Aan het einde van de dag om 16.00 uur zal er nogmaals een overleg plaats vinden waarin aan de projectleider testen over de voortgang van de testen gerapporteerd wordt.

De projectleider testen rapporteert over bevindingen aan de projectleider development. Indien nodig rapporteert hij ook aan de over all?? projectleider over bevindingen van organisatorische aard.

2.2  Categorisering bevindingen

Tijdens de in dit traject uitgevoerde testen worden de gedane bevindingen op identieke wijze geregistreerd. Besluitvorming hierover is een onderdeel van de projectdocumentatie.

Er zal gebruik worden gemaakt van de tool JIRA om bevindingen te registreren en monitoren. Aan de hand van overleg met gebruikers, hoofdacceptant en ontwikkelaars worden deze geprioriteerd, toegewezen, en vervolgens verspreid naar de actiehouders.

Bevindingen zijn onder te verdelen in 5 categorieën:

Blocker / Blocks development and/or testing work. (Testblokkerend)
Critical / Crashes, loss of data, severe memory leak. (Produktieblokkerend)
Major / Major loss of function.
Minor / Minor loss of function, or other problem where easy workaround is present.
Trivial / cosmetic problem like misspelled words or misaligned text.

Hierbij geldt als kanttekening, dat een onacceptabel groot aantal nieuwe bevindingen in de categorie minor als geheel productieblokkerend kunnen zijn. Hiervoor dienen normen te worden afgesproken met de accepterende partij.

Voorstel:

Major: Een maximum van 10 categorie Major bevindingen is acceptabel. Is dit hoger dan dient er dus een of meerdere Major problemen opgelost te worden om niet productieblokkerend te zijn.

Minor: Een maximum van 15 categorie Minor bevindingen is acceptabel. Is dit hoger dan dient er dus een of meerdere Major problemen opgelost te worden om niet productieblokkerend te zijn.

Trivial: Een maximum van 20 categorie Trivial bevindingen is acceptabel. Is dit hoger dan dient er dus een of meerdere Major problemen opgelost te worden om niet productieblokkerend te zijn.

Blockers (testblokkerend) en Criticals (productieblokkerend), de zgn. showstoppers, dienen tijdens de GAT zo spoedig mogelijk opgelost te worden. Herstel van andere bevindingen dient verricht te worden in de daarvoor beschikbare tijd tussen test en hertest.

3  Rapportage testbevindingen

Door bij te houden welke testscripts zijn doorlopen en wat de bevindingen zijn, kan de projectleider de voorgang van het testen monitoren en kan hij samen met de projectleider ontwikkeling ook zicht houden op de voortgang van verbeteringen tussen de verschillende testruns (versies). Het is van groot belang dat Om dit proces goed te kunnen uitvoeren en monitoren is het belangrijk dat er eenheid is in de manier van rapporteren en duidelijkheid over het moment waarop en de omstandigheden waaronder bevindingen zijn gedaan.

3.1  Doorlopen testscripts

Elke tester krijgt een Word document. In dit document staan testscripts. Elk testscript is weer opgebouwd uit één of meerdere teststappen. Een teststap is een actie die de tester uit moet voeren met daarbij het verwachte resultaat. Door het verwachte resultaat te vergelijken met het werkelijke resultaat krijgt elke stap (en daarmee ook het totale testscript) een eindresultaat mee.

De teststappen en scripts kunnen de volgende resultaten hebben:

·  Niet Getest (NG): Teststap is nog niet uitgevoerd (bij het begin hebben dus alle teststappen en scripts dit resultaat)

·  Niet OK (NOK): Teststap is uitgevoerd, maar het resultaat voldoet niet aan het verwachte resultaat

·  OK : Teststap is uitgevoerd en het resultaat is conform het verwachte resultaat

·  NKT (Niet Kunnen Testen): Er is een poging gedaan om de teststap uit te voeren, maar er is een belemmering waardoor de teststap niet is uit te voeren

Wanneer elke stap in het testscript het resultaat OK heeft, is het eindresultaat van het totale script ook OK. Wanneer minimaal één teststap binnen het script het resultaat NOK of NKT heeft is het eindresultaat van het script NOK, tenzij alle stappen binnen het script NKT zijn, dan is het eindresultaat NKT

Het eindresultaat van een totaal script wordt in een Excel sheet geplaatst bij de juiste testrun en testscriptID.

Hoe het doorlopen van de teststappen in zijn werk gaat en hoe te komen tot een bepaald eindresultaat wordt beschreven in Figuur1.

Figuur 1 Beslissingen diagram testscripts

Begin met het invullen van de Datum van de test en je naam

1. Lees het gehele script goed door

2. Begin met het uitvoeren van de eerste teststap.

3 en 4. Is er direct sprake van een situatie dat het uitvoeren van de teststap niet mogelijk maakt, vul dan NKT.

3 en 5. Is het wel mogelijk om de teststap uit te voeren. Controleer dan het resultaat van de zojuist uitgevoerde stap met die beschreven staat als verwacht resultaat bij de betreffende stap.

6 en 7. Komen verwacht en werkelijk resultaat niet met elkaar overeen, noteer dan NOK als resultaat bij deze stap

6 en 8. Komen verwacht en werkelijk resultaat wel met elkaar overeen, noteer OK als resultaat bij deze stap

9. Herhaal bovenstaande stappen 2 t/m 8 totdat de laatste stap is uitgevoerd.
10. Noteer het eindresultaat van het totale script in de Excelsheet en geef bij de opmerkingen zo nauwkeurig mogelijk weer (indien van toepassing) hoe bevindingen waargenomen zijn (foutmelding, geen actie bij het selecteren van een button etc)

3.2  Opslaan bevindingen

Excel bestand opslaan onder de reeds opgeslagen naam.

Word bestand opslaan onder: gebruikersnaam en datum en volgnummer van de dag

<gebruikersnaam>_<ddmmjj>_<vv>

Gebruikersnaam: eerste letter van de voornaam en eerste 5 letters van de achternaam (tussenvoegsels worden niet meegenomen). Bestaat de achternaam uit minder dan 5 letters dan worden deze aangevuld met letters uit de voornaam tot 6

Bv Mark Winters: mwinte

Mark van der Kraan: mkraan

Sandra van Tilburg: stilbu

Robert Pauw: ropauw

Voorbeeld bestandsnaam: mwinte_27032003_01

mkraan_27032003_01

mwinte_27032003_02

mwinte_28032003_03

7