Overzicht TMap

Fase: planning

Doel: conform BDTM een testplan opzetten

Als iets niet uit het mastertestplan aanwezig is moet dit alsnog worden gedaan vooral de PRA!

Verder moet alles uit met MTP worden aangescherpt

Uitvoerder: testmanager (werkwijze iteratief) i.s.m. opdrachtgever

Randvoorwaarden (zie blz 156):

• OG moet beschikbaar zijn
• Doel en belang moet van systeem voor de organisatie moet bekend zijn
• Globale eisen en requirements
• Bij voorkeur masterplan aanwezig
• Het ontwikkelproces
• Opleverdatum
• Inzicht in de omgevingen
• Bereidheid in de organisatie of info te verschaffen

Activiteiten	Doel	Product
Vaststellen opdracht	Duidelijke TVB, inzicht in opdracht, goede afbakening (wel of geen procedures, conversies, enz)	Opdrachtformulering
Orienteren opdracht	Inzicht in project, doelstelling, opzet, systeemontwikkeling, systeem, FO, specs, enz.	Opdrachtformulering
Bepalen testbasis	Zo vroeg mogelijk eenduidig definieren	Aanpak
PRA	Tot gezamenlijk beeld komen van wat de risicovolle delen van het systeem zijn	PRA
Bepalen teststrategie	Op basis van de hiervoor verzamelde info keuzes maken voor testvormen, testzwaarte voor alle te testen onderdelen, zie voorbeeld blz 176	Teststrategie
Bepalen begroting	Op basis van de strategie een begroting opstellen per testsoort ter voorlegging aan de OG	Begroting
Bepalen planning	Vastleggen uit te voeren act, tijdsbesteding, benodigde resources en op te leveren producten	Planning
Toewijzen testeenh en testtechnieken	Op basis van teststrategie bepalen van testeenheden en testteschnieken zodat de test beheersbaar wordt. Lees blz 190 tm 195	Aanpak
Definieren testproducten	Definieren op te leveren testware, bijv, testplan, testspecs,testinvoerbestanden, test uitvoeringsdossier (zie blz 198)	Aanpak
Definieren organisatie	TVB voor de testmanager, testteamleider, tester, beheerder, toolspecialist	Organisatiestructuur
Definieren infrastructuur	Bepalen benodigde testomgeving, testtools, kantoorinrichting en planning wanneer dit nodig is	Infrastructuur
Inrichten beheer	Vastleggen van de wijze waarop het beheer van het testproces, de infrastruct, de testproducten en bevindingen wordt geregeld	Beheer
Bepalen testproject risico’s en maatregelen	Benoemen van risico’s per testsoort (bijv. ingangskwaliteit, infrastruct voldoet niet, resources niet beschikbaar) en voorgestelde maatregelen	Bedreigingen, risico’s en maatregelen
Terugkoppelen en fixeren plan	Verkrijgen van goedkeuring van de OG	Testplan

PRA toegelicht:

Analyseren van het te testen product met als doel tot een gezamenlijk beeld te komen met de OG (belanghebbenden) van wat de meer en minder risicovolle kenmerken en delen van het product zijn zodat de grondigheid van testen hieraan gerelateerd kan worden.

Essentie is testinspanning relateren en verwachte productrisico’s.

Productrisico = faalkans * schade

Faalkans = foutkans * frequentie van gebruik

Foutkans: complexe functies, nieuwe functies, veelvuldig aangepaste functies, functies die gebouwd zijn met nieuwe tools of technieken, functies die gedurende de ontwikkeling aan anderen zijn overgedragen, functies waarin al eerder veel fouten zijn gevonden, functies met veel interfaces.

Schade: omzet verlies, schade aan derden, economisch verlies, fysieke schade, milieuschade, imagoschade, klantverlies, verlies van vertrouwen, overbelasting helpdesk, enz.

Stappen:

• Bepalen deelnemers
• Bepalen aanpak
• Voorbereiden sessie of interviews
• Verzamelen en analyseren
• Volledigheidscontrole

Technieken:

• Strategiebepaling
• PRA
• Kwaliteitsattributen
• Begrotingstechnieken
• Stappenplan opstellen begroting
• Checklist randvoorwaarden en uitgangspunten
• Checklist orienteren testopdracht
• Checklist testomgevingen
• Checklist kantoorinrichting
• Checklist risico’s testproces

Tools:

• Testware beheertool
• Bevindingen beheertool
• Plannings- en voortgangsbewakingstool
• Workflowtool

Fase: Beheer

Doel: geven van inzicht en sturingsmogelijkheden aan OG over voortgang, kwaliteit testobject en kwaliteit testproces

Uitvoerder: testmanager rapporteert aan OG

Randvoorwaarden:

Start na opstellen testplan

Activiteiten	Doel	Product
Uitvoeren beheer	Beheren proces, bevindingen en testproducten om voortdurend inzicht te kunnen verschaffen in de voortgang en kwaliteit	Beheerd testproces,
Bewaken	Bewaking t.a.v. duivelsvierkant tegen scopecreep	Kosten batenanalyse
Rapporteren	Opstellen van (BDTM) rapportages om inzicht te verschaffen zodat sturing door OG mogelijk is. Voorbeeld op blz  242	Rapportages (voortgang, risico’s vrijgave, enz), bijgesteld plan
Bijsturen	Indien nodig na overleg OG bijsturen van het testproces	Voorgesteld sturingsmaatregelen, sturingsmaatregelen

Technieken:

• metricslijst
• checklist evaluatie

Tools:

• Testwarebeheertool
• Bevindingenbeheertool
• Plannings en voortgangsbewakingstool
• Workflowtool

Fase: Inrichten beheer en infrastuur

Doel: beschrijven, realiseren en beheren van de testinfrastructuur tbv de verschillende fasen

Uitvoerder: testmanager of test-infrastructuur-coordinator

Randvoorwaarden:

Beschrijving van de infrastructuur op overkoepelend niveau moet bekend zijn

Activiteiten	Doel	Product
Specificeren infrastructuur	Denk aan backup, benodigde interfaces, autorisaties, kunnen wijzigen van systeemdatum, enz, maar ook beheerafspraken.	Detailspecs werkplek, Detailspecs testomgeving, PVA testtools,Werkplekken, testomving, geinstalleerde testtools, ckl intake werkplek ckl intake testomg, ckl intake testtools, procedureintake, testbevindingen, bruikbare werkplek, bruikbare testomg.,bruikbaretesttools, intakeverslag, beheerde infrastruct., Bevindingen testinfrastruct. Geconserveerde testinfrastructuur
Realiseren infrastructuur	Realiseren infrastructuur
Specificeren intake infrastructuur	Opstellen diverse ckl’s
Intake testinfrastructuur	Uitvoeren van de intake van de operationele infra, werkplek, enz.
Beheren infrastructuur	Beschikbaarheid op een bepaald niveau garanderen
Conserveren infrastructuur	Identificeren, actualiseren en overdragen zodat het in de toekomst hergebruikt kan worden.

Technieken:

n.v.t.

Tools:

• Testwarebeheertool
• Bevindingen beheertool

Fase: Voorbereiding

Doel: beschikken over een met de OG overeengekomen testbasis van voldoende kwaliteit voor het ontwerpen van testgevallen (inzicht in de testbaarheid van het systeem).

Besparing vroege foutdetectie = 50 tot 80 % besparing

Opmerking bijvoorbeeld bijsturen van plannen hoort altijd bij de fase beheer! Dus niet in de fase waar het ontdekt wordt!

Uitvoerder: testmanager of testcoordinator

Randvoorwaarden:

Zo snel mogelijk starten na fixatie van het testplan en n het beschikbaar zijn van de gefixeerde testbasis

Activiteiten	Doel	Product
Verzamelen testbasis	Verzamelen van definitieve (geactualiseerde) testbasis.Alternatieve testbasis kan zijn: huidig syst als referentiesysteem, prototype als testbasis, infosessie, systeemdocumentatie uit voorlaatste iteratie (zie ook blz. 281, 282)	Gefixeerde testbasis
Opstellen checklists	Opstellen CKL adhv testplan en teststrategie	Diverse checklists
Beoordelen testbasis	Vaststellen van de testbaarheid, dwz volledigheid, consitentie, toegankelijkheid, vertaalbaarheid van testgevallen van de testbasis.	Testbasis bevindingen
Opstellen rapport detailintake	Terugkoppeling over kwaliteit testbasis, stelt zwakke plekken in het systeemontwerp ter discussie en informeert op projectrisico’s	Rapport detailintake

Technieken:

• HICCUPP
• 18 attacks van Whittaker
• 480 bugs van Kaner
• CKL beoordelen testbasis
• CKL testontwerptechnieken
• Toetstechnieken

Tools:

• Bevindingenbeheertool

Fase: Specificatie

Doel: het specificeren van de tests en uitgangssituatie zodat tijden de uitvoering alles zo vlot mogelijk kan verlopen

Uitvoerder: testers

Randvoorwaarden:

Testbasis is beschikbaar en staat onder configuratiebeheer

Bevindingen uit de detailtestintake testbasis zijn verwerkt.

Activiteiten	Doel	Product
Opstellen testspecificaties identificeren testsituaties opstellen logische testgevallen opstellen fysieke testgevallen vaststellen uitgangssituatie opstellen testscript	Per testeenheid opstellen van testspecificaties met gebruikmaking van testontwerptechnieken gericht op het bereiken van de gewenste dekking en testzwaarte.Zie blz. 295 voor generieke inhoudsopgave testscript.	Bevindingen op de testbasis, testspecificaties (CKL, testgevallen, testscripts), testbasisbevindingen, testscript pre-test
Definieren centrale uitgangssituaties (bijv. kopie prod.omg)	Opstellen van 1 of meer uitgangssituaties waar testers gegevens voor hun testspecs kunnen uithalen  zoals de vulling van stambestanden zoals kortings tabellen, klanten, producten. (denk daarnaast ook aan systeemtoestand (bijv. bepaalde systeemdatum, of batches die gedraaid moeten hebben)	Beschrijving centrale uitgangsituatie
Specificeren intake testobject	Opstellen CKL intake testobject tbv de betreffende versie van het testobject en opstellen testscript pre-test (vaststellen of het of het object wel goed genoeg is om te testen, voorbeeld MDL test) Controle of alle functies aanwezig zijn, representatieve functies met een eenvoudig geval testen en enkele op integratie gerichte testgevallen.	CKL intake testobject,

Nb. Testgeval = initiele situatie > actie > resultaatvoorspelling

Nb. Actie = input > processing > output

Dekking = dekkingsvorm en dekkingsgraad

Dekkingsvorm = welke mogelijkheden worden onderscheiden

Dekkingsgraad = hoeveel van die mogelijkheden wordt er getest

Opbouwen van testgegevens: (bestudeer blz 302 t/m 303 voor voor- en nadelen)

• Opbouwen met reguliere systeemfuncties (voorkeur)
• Opbouwen met aparte laadprogrammatuur
• Gebruik van productiegegevens

Ook mogelijk om deze 3 te combineren.

Gebruik van uitgangssituaties gedurende de test: (bestudeer 305 t/m 306 voor- en nadelen)

• Cumulatief opbouwen van de centrale uitgangssituatie
• Periodiek verversen met de centrale uitgangssituatie.
• Parallel gebruiken van meerdere versies

Technieken:

• Testontwerptechnieken
• CKL diverse kwaliteitsattributen

Tools:

• Testwarebeheertool
• Bevindingenbeheertool
• Testdatatool
• Testontwerptool
• Model based testing tool
• Geautomatiseerde testuitvoering tool
• Performance-,  load- en stresstesttool

Fase: Uitvoering

Doel: het verkrijgen van inzicht in de kwaliteit van het testobject dmv het uitvoeren van tests

Uitvoerder: alle teamleden, alleen de controle op volledigheid van het testobject gebeurd door de testmanager.

Randvoorwaarden:

• Testobject moet opgeleverd zijn
• Testscripts hiervoor moeten beschikbaar zijn
• Intake testinfrastructuur moet succesvol zijn

Activiteiten	Doel	Product
Intake testobject	Vaststellen of zinvol getest kan worden	Geinstalleerd en testbaar testobject
Klaar zetten uitgangs situatie	Alles klaar zetten voor de uitvoering.	Centrale uitgangssituatie, initiele situatie
Uitvoeren (her)tests	Uitvoeren dynamisch expliciete en impliciete tests, Uitvoeren statische tests. (lezen 318, 319 en 320)	Bevindingen, testresultaten
Controleren en beoordelen testresultaten	Vaststellen van de overeenkomsten en het analyseren van de verschillen tussen de verkregen resultaten en de voorspelde resultaten. (vergelijken, analyseren (zie blz 323) en bepalen hertests). Rapporteren volgens H12 rapporteren bevindingen in de fase beheer.	Loggen van testresultaten,

Technieken:

• Exploratory testing
• Error guessing

Tools:

• Testwarebeheertool
• Bevindingenbeheertool
• Testdatatool
• Monitor tool
• Comparator
• Simulator
• Performance
• Driver en stubs
• Enz. zie boek

Fase: Afronding

Doel: leren van de ervaringen en het conserveren van de testware voor een volgende test

Uitvoerder: alle teamleden

Randvoorwaarden:

De testuitvoering is in een afrondend stadium

Activiteiten	Doel	Product
Evalueren testproces	Leren van ervaringen (doe dit niet alleen op het eind maar regelmatig vanaf het begin van het project)	Evaluatie testproces
Conserveren testware	Selecteren en actualiseren van de vervaardigde testware	Paklijst testware, herbruikbare testware

NB. In de fase beheer wordt door de testmanager een eindrapport opgesteld

Technieken:

• CKL evaluatie testproces

Tools:

• Testwarebeheertool
• Bevindingen beheertool

Hoe dan ook H14 supergoed bestuderen!!!!!

Testontwerptechniek = gestandaardiseerde werkwijze om vanuit de testbasis testgevallen af te leiden die tot een bepaalde dekking leiden.

Op basis van:

-          opdrachtformulering

-          risicoanalyse

-          teststrategie

Vertalen naar juiste dekking dmv testontwerptechniek in testgevallen.

Zie blz 592, figuur testontwerptechnieken

Belang van testontwerp

Technieken:

• onderboude invulling van de teststrategie
• leidt tot efficiente  en per geval tot gerichte opsporing van fouten
• tests zijn reproduceerbaar
• gestandaardiseerde werkwijze maakt de uitvoering onafhankelijk van de opsteller
• overdraagbaarheid en onderhoudbaarheid van de testgevallen
• testproces is beter planbaar en beheersbaar

Testsituatie >< logisch testgeval/fysiek testgeval > testscript

Testgeval =  fig blz 596

Testsituatie = bestelling van een of meer  boeken

Logisch testgeval =

• bestelling van precies 1 boek
• bestelling van meer dan 1 boek
• orderbedrag boven drempelwaarde
• orderbedrag onder drempelwaarde

Fysiek testgeval=

• Drempelbedrag  = 50
• Korting = 10%
• Prijs boek 1 = 25
• Prijs boek 2 = 19
• Prijs boek 3 = 61
• TG1 = Actie: bestel boek 1 en boek 2
  • Resultaatvoorspelling is …….
• TG2 = Actie= bestel boek 3
  • Resultaatvoorspelling is……

Testscript: meerder soortgevallen van practisch oogpunt samenvoegen omdat:

• ze gebruiken dezelfde initiele situatie
• ze vereisen dezelfde tijdrovende voorbereiding
• ze gaan over dezelfde situatie (klanten buitenland)
• er is een afhankelijkheid in tijdsvolgorde

Dekking is

• dekkingsvorm: welke mogelijkheden worden onderscheiden (paden, beslispunten, CRUD, grenswaarden, enz)
• dekkingsgraad: hoeveel van die mogelijkheden wordt er getest en hoe zwaar worden ze toegepast

Mogelijkheden:

• een zwaardere dekkingsvorm
• meerdere dekkingsvormen
• hogere dekkinggraad van een bepaalde vorm

Dekkingsvormen:

• paden = dekken van de variaties in het procesverloop, vereiste testbasis is processchema, verzwaren via testmaat-N, zie 610
• beslispunten = dekken van de verschillende mogelijkheden van een beslispunt, testbasis is formele beschrijving beslispunt, verzwaren condition/deccision, modified en multiple condition, zie 615
• Equivalentieklassen = waardebereik opdelen in klassen waarbij systeem ander gedrag vertoond, zie 624
• Pairwise testing = combineren van alle mogelijkheden van iedere set van 2 parameters, zie 625
• Grenswaardenanalyse = testen van de grenswaarde, de waarde eronder en de waarde erboven, verzwaren door meerdere waarden rond de grens te testen, zie 636
• CRUD = dekken van de basis bewerkingen op alle entiteiten, zie 638
• Statisch gebruik = simuleren realistisch gebruik, zie 641
• Goedpaden, foutpaden = dekken van goedpad en foutpad bij iedere gedefinieerde foutsituatie, zie 646
• Afvinklijst = ieder element testen via in ieder geval 1 testgeval, zie 648

Ontwerptechniek: BTT

Bevindingenbeheer:

Bevinding is geconstateerd verschil tussen de verwachting/voorspelling en de feitelijke uitkomst.

Let wel: fout heeft een negatieve klank. Testers moeten zich realiseren dat ze andermans werk beoordelen dat het resultaat is van samenwerking tussen alle partijen.

Testmanager communiceert de bevindingen buiten het testteam.

Stappen van een bevinding doen:

• Verzamel bewijsmateriaal (memorydump, screenprint)
• Reproduceer de bevinding
• Controleer op eigen fouten (let op fouten in de testspecificatie, uitgangssituatie, testomgeving, testuitvoering of beoordeling)
• Bepaal vermoedelijke externe oorzaak (bijv. testbasis, testobject, documentatie)
• Isoleer zo mogelijk de oorzaak
• Generaliseer de bevinding (kijk of op soortgelijke plekken zich dezelfde fout voordoet)
• Vergelijk met andere bevindingen (kijk of de bevinding al bestaat in bijv. eerdere release)
• Schrijf bevindingenrapport (stijl neutraal, helder, eenduidig, to the point, inclusief de gevolgen)
• Laat reviewen ( op volledigheid, juistheid en toonzetting)

Bevindingenrapport (bij voorkeur in velden). Zie blz. 572 e.v. voor de minimale velden.

Zie blz. 579 voor de levenscyclus van een bevinding.