Standaard verklarende woordenlijst van software testtermen

Standaard verklarende woordenlijst van software testtermen Vertaling Engels – Nederlands Originele versie 2.0 (dd. 2 december 2007) Geproduceerd door de Werkgroep Glossary International Software Testing Qualifications Board Versie: Status: Originele versie bron: Gemaakt door: Versie: Status: Originele versie bron: Gemaakt door: Versie: Status: Originele versie bron: Gemaakt door: Versie: Status: Originele versie bron: Gemaakt door: Versie: Status: Originele versie bron: Gemaakt door:

1.0 (dd. 31 januari 2007) Definitief 1.2 Working Party-Glossary van de: Belgium & the Netherlands Testing Qualifications Board 1.2 (dd. 22-06-08) Concept 2.0 Working Party-Glossary van de: Belgium & the Netherlands Testing Qualifications Board 1.3 (dd. 15-07-08) Concept 2.0 Working Party-Glossary van de: Belgium & the Netherlands Testing Qualifications Board 1.4 (dd. 12-08-08) Concept 2.0 Working Party-Glossary van de: Belgium & the Netherlands Testing Qualifications Board 2.0 (dd. 18-10-08) Concept 2.0 Working Party-Glossary van de: Belgium & the Netherlands Testing Qualifications Board

Redacteur:

Meile Posthuma (Nederland)

Verklaring betreffende auteursrecht:

Dit document kan in al zijn onderdelen, geheel of gedeeltelijk worden gekopieerd, indien de bron wordt erkend.

Pagina 1 van 42

Medewerkers: Medewerkers aan oorspronkelijke woordenlijst: Rex Black (USA) Sigrid Eldh (Sweden) Isabel Evans (UK) Dorothy Graham (UK) Julian Harty (UK) David Hayman (UK) Juha Itkonen (Finland) Vipul Kocher (India) Fernando Lamas de Oliveira (Portugal) Tilo Linz (Germany) Peter Morgan (UK) Thomas Müller (Switseland) Avi Ofer (Israel) Dale Perry (USA) Horst Pohlmann (Germany) Meile Posthuma (The Netherlands) Erkki Pöyhönen (Finland) Maaret Pyhäjärvi (Finland) Andy Redwood (UK) Stuart Reid (UK) Piet de Roo (The Netherlands) Shane Sauders (UK) Steve Sampson (UK) Shane Sanders (UK) Hans Schaefer (Norway) Jurriën Seubers (The Netherlands) Dave Sherratt (UK) Mike Smith (UK) Andreas Spillner (Germany) Richard Taylor (UK) Geoff Thompson (UK) Stephanie Ulrich (Germany) Matti Vuori (Finland) Gearrel Welvaart (The Netherlands) Pete Williams (UK)

Pagina 2 van 42

Vertaald en gereviewed door: Paul Beekman Alain Bultink Erwin Engelsma Ralph Eyckerman Kaj Feis Gerard Kruijff Ine Lutterman Jurian van de Laar Rik Marselis Anke van der Moer Iris Pinkster Meile Posthuma Ewald Roodenrijs Marjolein Steyerberg Erik van Veenendaal

Change History Version 1.3 d.d. May, 31st 2007 New terms added:  action word driven testing  bug tracking tool  coverage measurement tool  modelling tool  monkey testing  scripted testing  specification-based technique  stress testing tool  structure-based technique  unit test framework  White-box technique Version 2.0 d.d. December, 2nd 2007 New terms added:  attack  buffer  buffer overflow  bug taxonomy  classification tree  continuous representation  control flow analysis  cost of quality  defect based technique  defect based test design technique  defect taxonomy  error seeding tool  Failure Mode, Effect and Criticality  Analysis (FMECA)  false-fail result  false-pass result  false-negative result  false-positive result  fault attack  fault seeding  fault seeding tool  hazard analysis  hyperlink  hyperlink tool  load profile  operational acceptance testing  operational profile  orthogonal array  orthogonal array testing  pair wise testing

Pagina 3 van 42

Terms changed:  basic block  control flow graph  defect management tool  independence of testing  project risk  risk-based testing  test comparator  test process

Terms changed:  bebugging  error seeding  Failure Mode and Effect Analysis  (FMEA)  Fault Tree Analysis (FTA)  modified multiple condition testing  process cycle test  root cause  specification-based technique  stress testing  test charter

                             

performance profiling pointer procedure testing process improvement production acceptance testing qualification reliability growth model retrospective meeting risk level risk type root cause analysis safety critical system software attack Software Failure Mode and Effect Analysis (SFMEA) Software Failure Mode Effect and Criticality Analysis (SFMECA) Software Fault Tree Analysis (SFTA) software life cycle staged representation system of systems test design test estimation test implementation Test Maturity Model Integration (TMMi) test progress report test rig test schedule test session wild pointer

Pagina 4 van 42

Inhoudsopgave Standaard verklarende woordenlijst van software testtermen...................................................1 Vertaling Engels – Nederlands ............................................................................................1 Medewerkers: .........................................................................................................................2 Inhoudsopgave .......................................................................................................................5 Voorwoord .............................................................................................................................6 1. Introductie ..........................................................................................................................6 2. Toepassingsgebied ..............................................................................................................6 3. Rangschikking ....................................................................................................................6 4. Normatieve referenties ........................................................................................................7 5 Handelsmerken ....................................................................................................................7 6. Definities ............................................................................................................................8 A ............................................................................................................................................8 B ............................................................................................................................................9 C .......................................................................................................................................... 11 D .......................................................................................................................................... 14 E .......................................................................................................................................... 17 F ........................................................................................................................................... 18 G .......................................................................................................................................... 20 H .......................................................................................................................................... 20 I............................................................................................................................................ 20 K .......................................................................................................................................... 22 L .......................................................................................................................................... 22 M ......................................................................................................................................... 23 N .......................................................................................................................................... 24 O .......................................................................................................................................... 25 P ........................................................................................................................................... 26 Q .......................................................................................................................................... 28 R .......................................................................................................................................... 28 S ........................................................................................................................................... 30 T .......................................................................................................................................... 34 U .......................................................................................................................................... 39 V .......................................................................................................................................... 39 W ......................................................................................................................................... 40 Bijlage A (Informatief) ......................................................................................................... 41 Bijlage B (Methode om commentaar op deze woordenlijst aan te leveren) ............................ 42

Pagina 5 van 42

Voorwoord Bij het maken van deze verklarende woordenlijst heeft de werkgroep gestreefd om naar de commentaren en meningen van een zo breed mogelijk publiek uit de industriële-, handels en overheidssector en naar professionele en academische instellingen te luisteren, met als doel een internationale teststandaard neer te zetten die zo breed mogelijk gedragen wordt. Complete overeenstemming zal zelden, of nooit bereikt worden bij het maken van een document van deze aard. Testgemeenschappen die aan deze woordenlijst hebben bijgedragen zijn: Australië, België, Finland, Duitsland, India, Israël, Nederland, Noorwegen, Portugal, Zweden, Zwitserland, het Verenigd Koninkrijk, en de VS. Vele (software) testers hebben de BS 7925-1 sinds zijn oorspronkelijke publicatie in 1998 gebruikt. Het heeft ook als belangrijke referentie gediend voor de Information Systems Examination Board (ISEB) op zowel Foundation- als Practitioner-niveau. De standaard werd aanvankelijk ontwikkeld met de nadruk op componenttesten, maar sinds zijn publicatie zijn vele commentaren en voorstellen voor nieuwe definities ingediend om de standaard te verbeteren en uit te breiden naar een bredere dekking van software testen. In deze nieuwe versie van de verklarende woordenlijst zijn veel van deze commentaren en voorstellen opgenomen. Het zal door de International Software Testing Qualifications Board (ISTQB) binnen haar certificeringprogramma als referentiedocument worden gebruikt.

1. Introductie Er is veel tijd en moeite verspild aan het doorbreken van ambiguïteiten, zowel binnen als tussen de industriële-, handels en overheidssector en professionele en academische instellingen. Dit komt door het onvermogen om voldoende onderscheid te maken tussen termen als `- coderegeldekking ' en `- besluitdekking '; ` test set ', ` testspecificatie ' en `testplan ' en soortgelijke termen die een brug moeten slaan tussen diverse sectoren van de maatschappij. Verder worden deze termen in een professionele of technische context vaak gebruikt in tegenspraak met de verschillende betekenissen die aan hen worden toegeschreven.

2. Toepassingsgebied Dit document vertegenwoordigt concepten, termen en definities die dienen als ondersteuning voor communicatie in (software) testen en verwante disciplines.

3. Rangschikking De verklarende woordenlijst is gerangschikt in één enkele sectie in alfabetische volgorde. Sommige termen hebben de voorkeur gekregen op synoniemen van deze term. De definitie verschijnt naast de voorkeursterm en vanuit de synoniemen wordt verwezen naar de voorkeursterm. Bv.: „gestructureerd testen‟ verwijst naar „White-box‟ testen. Voor het synoniem, wordt de “Zie" indicator gebruikt. "Zie ook" verwijzingen worden gebruikt voor relaties in het geval een term met een bredere betekenis naar een term met een engere betekenis verwijst en in het geval twee termen een overlappende betekenis hebben. Zij helpen de gebruiker om snel naar de juiste indexterm te navigeren.

Pagina 6 van 42

4. Normatieve referenties De aangegeven editie was geldig ten tijde van publicatie. Alle standaarden kunnen een revisie hebben ondergaan, en partijen bij overeenkomsten die op deze Standaard zijn gebaseerd worden aangemoedigd om de mogelijkheid te onderzoeken om de meest recente editie van de standaards die hieronder staan vermeld toe te passen. Leden van de IEC en ISO onderhouden registers van de huidig geldige Internationale Standaards. 1. BS 7925-2:1998. Software Component Testing. 2. DO-178B:1992. Software Considerations in Airborne Systems and Equipment 3. Certification, Requirements and Technical Concepts for Aviation (RTCA SC167). 4. IEEE 610.12:1990. Standard Glossary of Software Engineering Terminology. 5. IEEE 829:1998. Standard for Software Test Documentation. 6. IEEE 1008:1993. Standard for Software Unit Testing. 7. IEEE 1012:1986. Standard for Verification and Validation Plans 8. IEEE 1028:1997. Standard for Software Reviews and Audits. 9. IEEE 1044:1993. Standard Classification for Software Anomalies. 10. IEEE 1219:1998. Software Maintenance. 11. ISO/IEC 2382-1:1993. Data processing - Vocabulary - Part 1: Fundamental terms. 12. ISO 9000:2000. Quality Management Systems – Fundamentals and Vocabulary. 13. ISO/IEC 9126-1:2001. Software Engineering – Software Product Quality – Part 1: Quality characteristics and sub-characteristics. 14. ISO/IEC 12207:1995. Information Technology – Software Life Cycle Processes. 15. ISO/IEC 14598-1:1996. Information Technology – Software Product Evaluation - Part 1: General Overview.

5 Handelsmerken In dit document worden de volgende handelsmerken gebruikt:  CMM en CMMI zijn geregistreerde handelsmerken van de Carnegie Mellon University  TMap, TPA and TPI zijn geregistreerde handelsmerken van Sogeti Nederland BV  TMM is een geregistreerd service merk van de Illinois Institute of Technology  TMMi is een geregistreerd handelsmerk van de TMMi Foundation

Pagina 7 van 42

6. Definities Engelse term

Nederlandse term

Omschrijving

Abstract test case: Acceptance: Acceptance criteria:

Logisch testgeval: Acceptatie: Acceptatie criteria:

Acceptance testing:

Acceptatietest:

Accessibility testing:

Toegankelijkheidstest:

Accuracy:

Nauwkeurigheid:

Action word driven testing: Actual outcome: Actual result:

Actiewoord gedreven testen Feitelijke uitkomst: Feitelijk resultaat:

Zie: high level test case - (logisch testgeval) Zie: acceptance testing – (acceptatietest). De eindcriteria waaraan een component of systeem moet voldoen teneinde geaccepteerd te worden door een gebruiker, klant of andere geautoriseerde entiteit. [IEEE 610]. Een formele test met betrekking tot gebruikersbehoeften, eisen (requirements) en bedrijfsprocessen, die worden uitgevoerd om vast te stellen of een systeem al dan niet aan de acceptatie criteria voldoet, en om de gebruiker, klant of een andere geautoriseerde entiteit informatie te geven voor het besluit om het systeem wel of niet te accepteren. [Naar IEEE 610]. Een test om te bepalen hoe makkelijk het is voor gebruikers met een handicap om een component of systeem te gebruiken. [Gerrard]. De mate waarin een softwareproduct de resultaten of effecten correct en juist kan geven. [ISO 9126]. Zie: ook: functionality testing - (functionaliteitstest) Zie: keyword driven testing - (actiewoordtest).

Ad hoc review: Ad hoc testing:

Ad hoc review: Ad hoc test:

Adaptability:

Aanpasbaarheid:

Agile testing:

Agile test (behendig testen):

Algorithm test:

Algoritmetest:

Alpha testing:

Alfatest:

Analyzability:

Analyseerbaarheid:

Analyzer:

Analyse software:

A

Pagina 8 van 42

Zie: actual result – (feitelijk resultaat). Het geproduceerde dan wel geobserveerde gedrag tijdens de test van een component of systeem. Zie: informal review – (informele review). Een informele test; er vindt geen specificatie van de test plaats, er wordt geen geaccepteerde testontwerptechniek gebruikt, er zijn geen verwachte testresultaten opgesteld en willekeur bepaalt de test uitvoeringsactiviteit. De mogelijkheid van een softwareproduct om aangepast te worden aan verschillende gespecificeerde omgevingen zonder andere acties of middelen dan diegenen die geleverd zijn voor dit doel en voor de desbetreffende software [ISO 9126]. Zie ook: portability – (portabiliteit) Testaanpak voor een project dat „agile‟ (= behendig) methodieken gebruikt, zoals Extreem Programmeren (XP), die ontwikkeling beschouwt als de klant van testen en die de nadruk leggen op het ontwerp paradigma om eerst te testen. Zie ook: test driven development - (test gedreven ontwikkeling). [TMap®]. Zie: branch testing – (programmapadtest) Gesimuleerd of feitelijk operationeel testen door potentiële gebruikers / klanten of door een onafhankelijk testteam op de locatie van de ontwikkelaars, maar buiten de ontwikkelorganisatie. Een alfatest wordt vaak toegepast voor standaard software als een vorm van interne acceptatietesten. De mate waarin een softwareproduct middelen heeft om gebreken of foutoorzaken in de software te diagnosticeren, ofwel om de delen die moeten worden gewijzigd te identificeren. [ISO 9126]. Zie ook: maintainability – (onderhoudbaarheid). Zie: static analyzer – (statische analyse software)

Engelse term

Nederlandse term

Omschrijving

Anomaly:

Anomalie:

Arc testing:

Arctest:

Attack:

Aanval:

Attractiveness:

Aantrekkelijkheid:

Audit:

Controle:

Audit trail:

Audit trail:

Automated testware:

Geautomatiseerde testware: Beschikbaarheid:

Elke conditie die afwijkt van verwachtingen gebaseerd op eisen (requirements) specificaties, ontwerp documenten, gebruikers documenten, standaarden enz. of vanuit iemands perceptie of ervaring. Anomalieën kunnen gevonden worden, tijdens (maar niet alleen tijdens), reviewen, testen, analyse, compilatie, gebruik van softwareproducten of van toepassing zijnde documentatie. [IEEE 1044]. Zie ook: defect, deviation, error, fault, failure, incident, problem - (defect, afwijking, menselijke fout (error), fout, fout, bevinding, probleem). Testen gebaseerd op de verwerkingslogica van het programma of het systeem. Zie: branch testing – (programmapadtest) Een gerichte en bewuste poging om de kwaliteit, vooral betrouwbaarheid, van een testobject te evalueren door specifieke fouten te forceren. De mogelijkheid van een softwareproduct om aantrekkelijk te zijn voor een gebruiker [ISO 9126]. Zie ook: usability – (bruikbaarheid) Een onafhankelijk evaluatie van softwareproducten of processen om zeker te zijn dat ze voldoen aan standaarden, richtlijnen, specificaties, en / of procedures, die zijn gebaseerd op objectieve criteria, inclusief documenten die specificeren: 1. wat de vorm of inhoud is van de producten die moeten worden gemaakt 2. welk proces moet worden gevolgd om de producten te maken 3. hoe zal worden vastgesteld dat standaarden of richtlijnen worden nageleefd. [IEEE 1028]. Een pad via welke het spoor van de originele invoer voor een proces (b.v. gegevens) kan worden gevolgd door het proces, met het procesresultaat als beginpunt. Dit ondersteunt foutanalyse en maakt het mogelijk een procescontrole uit te voeren. [Volgens TMap®]. Testware gebruikt bij geautomatiseerd testen zoals scripts in een test-tool.

Availability:

De mate waarin een component of systeem operationeel is en toegankelijk wanneer er gebruik van gemaakt moet worden. Veelal uitgedrukt als een percentage. [IEEE 610].

B Back-to-back testing:

Back-to-back-test:

Baseline:

Uitgangspunt:

Basic block:

Basisblok:

Basis test set:

Basis testset:

Bebugging:

Bebugging:

Behavior:

Gedrag:

Pagina 9 van 42

Testen waarbij twee of meer varianten van een component of systeem worden uitgevoerd met dezelfde invoer, waarna de resultaten worden vergeleken en geanalyseerd in het geval van afwijkingen. [IEEE 610]. Een specificatie of softwareproduct dat formeel is beoordeeld of overeengekomen en daarna dient als basis voor verdere ontwikkeling, en dat alleen gewijzigd kan worden middels een formeel wijzigingsproces. [Naar IEEE 610]. Een reeks van één of meer opeenvolgende uit te voeren programmaregels zonder vertakkingen. [Noot] Een knooppunt in een programmastroomdiagram representeert een basisblok. Een verzameling van testgevallen, afgeleid van de interne structuur van een component of specificatie om het 100% gespecificeerde dekkingcriterium te verzekeren. Zie: fault seeding – (foutzaaien). [Abbott]. De gedragingen van een component of systeem op een verzameling van invoerwaarden en randvoorwaarden

Engelse term

Nederlandse term

Omschrijving

Benchmark test:

Referentietest:

Bespoke software:

Maatwerk software:

Best practice:

Beste praktijkervaring:

Beta testing:

Bètatest:

Big-bang testing:

Big-bang-test:

Black-box technique: Black-box testing:

Black-box techniek: Black-box test:

Black-box test design technique:

Bottom-up testing:

Black-box testspecificatietechniek: Geblokkeerd testgeval: Bottom-up-test:

Boundary value:

Grenswaarde:

Boundary value analysis:

Grenswaarde analyse: Grenswaarde dekking: Grenswaardetest: Programmapad:

1) Een standaard tegen welke metingen of vergelijkingen kunnen worden gemaakt 2) Een test die gebruikt moet worden om componenten of systemen met elkaar te vergelijken of met een standaard zoals in (1). [Naar IEEE 610]. Software specifiek ontwikkeld voor een verzameling gebruikers of klanten. Het tegenovergestelde is standaard software. Een superieure methode of vernieuwende ervaring, die bijdraagt aan een betere prestatie van een organisatie in een bepaald verband, meestal door andere gelijksoortige organisaties als „beste‟ erkent. Operationele test door potentiële en / of bestaande gebruikers / klanten op een externe locatie, die niet op enig andere manier betrokken zijn bij de ontwikkelaars, om uit te maken of een component al dan niet de gebruikers- / klantenbehoeften invult en of het past in het bedrijfsproces. Bètatest worden vaak gebruikt als een vorm van externe acceptatietesten voor standaard software om aldus terugkoppeling van de markt te krijgen Een vorm van integratietesten waarbij de software elementen, hardware elementen of beiden in één keer in een component of volledig systeem worden gecombineerd, in plaats van in stappen. [Naar IEEE 610]. Zie ook: integration testing – (integratietest) Zie: black-box design technique – (black-box testspecificatietechniek). Testen, zowel functioneel als niet-functioneel, zonder referentie naar de interne structuur van een component of systeem. Procedure om testgevallen af te leiden of te selecteren, gebaseerd op een analyse van de specificatie, functioneel dan wel niet-functioneel, van een component of systeem, zonder referentie naar zijn interne structuur. Een testgeval dat niet kan worden uitgevoerd, omdat niet aan de randvoorwaarden voor zijn uitvoering is voldaan. Een incrementele benadering van integratietesten waarbij de componenten op het laagste niveau eerst worden getest, en dan worden gebruikt om het testen van componenten op een hoger niveau mogelijk te maken. Dit proces wordt herhaald tot de component aan de top van de hiërarchie is getest. Zie ook: integration testing – (integratietest). Een invoerwaarde of uitvoerwaarde die op de grens ligt van een equivalentieklasse, of op de kleinste incrementele afstand aan beide zijden van een grenswaarde, b.v. de minimum of maximum waarde van een bereik. Een „black box‟ testspecificatietechniek waarbij testcases worden ontworpen gebaseerd op grenswaarden. Het percentage van grenswaarden dat is uitgevoerd door een testset.

Blocked test case:

Boundary value coverage: Boundary value testing: Branch: Branch condition: Branch condition combination coverage: Branch condition combination testing: Branch condition coverage: Branch coverage:

Programmapadconditie: Programmapad conditie-combinatiedekking: Programmapad conditie-combinatietest: Programmapad conditiedekking: Programmapaddekking:

Pagina 10 van 42

Zie: boundary value analysis – (grenswaarde analyse) Een basis blok dat geselecteerd kan worden voor uitvoering gebaseerd op een programmaconstructie waarin een van twee of meer alternatieve programmapaden beschikbaar zijn, b.v.: case, jump, go to, if-then-else. Zie: condition – (conditie) Zie: multiple condition coverage. – (meervoudige conditiedekking) Zie: multiple condition testing. – (meervoudige conditietest) Zie: condition coverage. – (conditiedekking) Het percentage programmapaden dat door een testset is uitgevoerd. 100% programmapaddekking impliceert zowel 100% beslissingsdekking als 100% programmaregeldekking.

Engelse term

Nederlandse term

Omschrijving

Branch testing:

Programmapadtest:

Buffer:

Buffer:

Buffer overflow:

Buffer overloop:

Bug: Bug: Bug taxonomy: Bug tracking tool: Business process-based testing:

Fout: Fout: Fouttaxonomie: Foutvolg-tool: Bedrijfsproces gebaseerde test:

Een „White-box‟ testtechniek waarin test cases ontworpen worden om programmapaden uit te voeren. Een apparaat of opslagmedium voor tijdelijke gegevensopslag, waar verschillen in snelheid van de gegevensstroom, tijd of gebeurtenissen optreden, of hoeveelheden gegevens die verwerkt kunnen worden door apparaten of processen betrokken bij de overdracht of het gebruik van de gegevens. [IEEE 610]. Een fout in de geheugentoegang toe te schrijven aan een poging van een proces om gegevens op te slaan groter dan de voorgeschreven bufferlengte resulterend in het overschrijven van aangrenzende geheugengebieden of het geven van een overflow melding. Zie ook: buffer – (buffer) Zie: defect – (fout). Zie: defect report – (foutrapport) Zie: defect taxonomy – (fouttaxonomie) Zie: defect management tool – (foutenbeheer-tool) Een benadering tot testen waarbij testgevallen worden ontworpen gebaseerd op beschrijvingen en / of kennis van bedrijfsprocessen.

C Capability Maturity Model (CMM):

Capability Maturity Model (CMM):

Capability Maturity Model Integration (CMMI):

Capability Maturity Model Integration (CMMI):

Capture / playback tool:

Opname- / afspeeltool:

CASE:

CASE:

CAST:

CAST:

Cause-effect graph:

Oorzaak-gevolg diagram:

Cause-effect graphing:

Oorzaak-gevolg diagrammen:

Cause-effect analysis:

Oorzaak-gevolg analyse: Beslissingstabel

Cause-effect decision table: Certification:

Certificering:

Changeability:

Veranderlijkheid:

Change control: Change control board:

Wijzigingsbeheer: Wijzigingsbeheercommissie: Inspecteur:

Checker:

Pagina 11 van 42

Een raamwerk dat is opgedeeld in 5 opeenvolgende niveaus die de sleutelelementen beschrijft van een effectief software proces. Het CMM omvat beste praktijkervaringen voor plannen, ontwerpen en het besturen van softwareontwikkeling en -onderhoud. Een raamwerk dat de sleutelelementen beschrijft van een effectief productontwikkelings en -onderhoudsproces. Het CMMI omvat beste praktijkervaringen voor plannen, uitvoeren en het besturen van productontwikkeling en -onderhoud. CMMI is de aangewezen opvolger van CMM. Een test-tool die invoer opneemt gedurende handmatige testen om testscripts te genereren die later automatisch kunnen worden uitgevoerd (dwz: afgespeeld). Deze tools worden vaak gebruikt om automatische regressietesten uit te kunnen voeren. Acroniem voor Computer Aided Software Engineering. Software engineering met behulp van een computer. Acroniem voor Computer Aided Software Testing. Testen met behulp van een computer. Zie ook: test automation – (testautomatisering) Een grafische representatie van invoer en / of stimuli (oorzaken) met de daarbijbehorende uitvoer (gevolgen), die gebruikt kan worden om testgevallen te ontwerpen. Een „black box‟ testontwerptechniek waarbij testgevallen worden ontworpen uitgaande van oorzaak-gevolg diagrammen [BS 7925/2]. Zie: cause-effect graphing – (oorzaak-gevolg diagrammen). Zie: decision table – (beslissingstabel). Het proces dat bevestigt dat een component, systeem of persoon voldoet aan de expliciete eisen, b.v. door te slagen voor een examen. De mate waarin een softwareproduct het toelaat om gespecificeerde aanpassingen door te voeren. [ISO 9126]. Zie ook: maintainability – (onderhoudbaarheid). Zie: configuration control – (configuratiebeheer). Zie: configuration control board – (configuratiebeheercommissie). Zie: reviewer – (reviewer).

Engelse term

Nederlandse term

Omschrijving

Chow's coverage metrics: Classification tree:

Chow’s dekkingsmetriek: Classificatieboom:

Classification tree method:

Classificatieboommethode:

Code:

Code:

Code analyzer: Code coverage:

Code analyse software: Codedekking:

[Chow]. Zie: N-switch coverage – (N-overgangendekking). Weergave van een hiërarchische ordening van equivalentiepartities die gebruikt wordt bij het ontwikkelen van testcases via de classificatieboommethode. Zie ook: classification tree method – (classificatieboommethode). Een „black box‟ testontwerptechniek waarin testgevallen ontworpen worden op basis van een classificatieboom om van waarden uit invoer- en / of uitvoerequivalentieklassen uit te voeren. [Grochtmann]. Computerinstructies en datadefinities uitgedrukt in een programmeertaal of in een assembleerprogramma, vertaler of ander vertaalprogramma [IEEE 610]. Zie: static code analyzer – (statische analyse software).

Code-based testing: Co-existence:

Programmatest: Coëxistentie:

Commercial off-the-shelf software: Comparator: Compatibility testing: Compiler:

Commerciële standaard software: Testvergelijkingsprogramma: Compatibiliteitstest: Compiler:

Complete testing: Completion criteria: Complexity:

Volledig testen: Stopcriteria: Complexiteit:

Compliance:

Volgzaamheid:

Compliance testing:

Volgzaamheidstest: (navolging) Component: Componentintegratietest: Componentspecificatie:

Component: Component integration testing: Component specification: Component testing:

Componenttest:

Compound condition:

Concurrency testing:

Samengestelde conditie: Welomschreven testgeval: Gelijktijdigheidstest:

Condition:

Conditie:

Concrete test case:

Pagina 12 van 42

Een analysemethode die vaststelt welke delen van de software uitgevoerd (of afgedekt) zijn door de testset en welke delen niet, b.v. dekkingsgraad voor programmaregels, beslissingen of condities. Zie: White-box testing – (‘White-box’ test) De mate waarin een softwareproduct naast andere onafhankelijke software in een gemeenschappelijke omgeving kan bestaan gebruikmakend van gemeenschappelijke bronnen. [ISO 9126]. Zie ook: portability – (portabiliteit). Zie: off-the-shelf software – (standaard software). Apparaat dat uitvoer van producten vergelijkt. Zie: test comparator – (testvergelijkingsprogramma). Zie: interoperability testing – (interoperabiliteitstest). Een software tool dat programma code in een hogere generatie taal omzet naar de overeenkomstige machinetaal. Zie: exhaustive testing – (volledig testen). Zie: exit criteria – (uitgangscriteria). De mate waarin het ontwerp en / of de interne structuur van een component of systeem moeilijk te begrijpen, onderhouden of verifiëren valt. Zie ook: cyclomatic complexity – (cyclomatische complexiteit). De mate waarin een softwareproduct voldoet aan standaarden, conventies, wettelijke regelgeving of waar het soortgelijke voorschriften volgt. [ISO 9126]. Het testproces om te bepalen of een component of systeem voldoet. Het kleinste deel van de software dat afzonderlijk getest kan worden. Testen om fouten in de interfaces en de communicatie tussen geintegreerde componenten aan het licht te brengen. Een beschrijving van de werking van een component in termen van de uitvoer voor bepaalde invoerwaarden onder bepaalde condities en over het gewenste niet-functionele gedrag (b.v. geheugengebruik). Het testen van afzonderlijke software componenten. [Naar IEEE 610]. twee of meer enkelvoudige condities, samengesteld door een logische operator (AND, OR, XOR), b.v. „A > B AND C > 1000‟. Zie: low level test case – (fysiek testgeval). Testen om te bepalen hoe een component omgaat met het uitvoeren van twee of meer activiteiten binnen een zelfde tijdsinterval, door deze activiteiten afwisselend of gelijktijdig uit te voeren. [Naar IEEE 610]. Een logische uitdrukking die bij evaluatie “Waar” of “Onwaar” oplevert, b.v. A > B. Zie ook: test condition – (testconditie).

Engelse term

Nederlandse term

Omschrijving

Condition combination coverage: Condition combination testing: Condition coverage:

Conditie combinatie dekking: Conditie combinatietest: Conditiedekking:

Zie: multiple condition coverage – (meervoudige conditie dekking).

Condition determination coverage:

Conditiebepalingsdekking:

Condition determination testing:

Conditiebepalingstest:

Condition testing:

Conditietest:

Condition outcome: Confidence test: Configuration:

Conditieresultaat: Betrouwbaarheidstest: Configuratie:

Configuration auditing:

Configuratiecontole:

Configuration control:

Configuratiebeheer:

Configuration control board (CCB):

Configuratiebeheer commissie (CBC):

Configuration identification:

Configuratieidentificatie:

Configuration item:

Configuratieonderdeel:

Configuration management:

Configuratiebeheer:

Configuration management tool:

Configuratiebeheer-tool:

Configuration testing: Confirmation testing: Conformance testing: Consistency:

Configuratietest: Bevestigingstest: Conformiteitstest: Consistentie:

Pagina 13 van 42

Zie:.multiple condition testing – (meervoudige conditietest). Het percentage van de conditieresultaten dat afgedekt wordt door een testset. Een conditiedekking van 100% vereist dat elke enkelvoudige beslissing in elke beslissingsregel getest wordt als „Waar‟ of „Onwaar‟. Het percentage van alle enkelvoudige conditieresultaten die, door het uitvoeren van een testset, elk afzonderlijk een beslissingsresultaat beïnvloedt. Conditiebepalingsdekking van 100% betekent een beslissingsconditiedekking van 100%. Een „White-box‟ testspecificatietechniek waarbij testgevallen gespecificeerd worden om enkelvoudige conditieresultaten die onafhankelijk van elkaar een beslissingsresultaat beïnvloeden te testen. Een „White-box‟ testspecificatietechniek waarbij testgevallen gespecificeerd worden om conditieresultaten te testen. Het resultaat van een conditie, zijnde “Waar” of “Onwaar”. Zie: smoke test – (proeftest). De opbouw van een component of systeem bepaald door aantal, aard en de onderlinge relaties van de samengestelde delen. De functie om de inhoud van de bibliotheken van configuratieonderdelen te verifiëren, b.v. voor het voldoen aan standaarden. Een onderdeel van configuratiebeheer, bestaand uit de evalueren, coördineren, het goed- of afkeuren en het doorvoeren van wijzigingen aan configuratieonderdelen na het formeel vaststellen van hun configuratieidentificatie. [IEEE 610]. Een groep van mensen die verantwoordelijk is voor het evalueren en vervolgens goed- of afkeuren van voorgestelde wijzigingen op configuratieonderdelen en toezien op het doorvoeren van de goedgekeurde wijzigingen. [IEEE 610]. Een onderdeel van configuratiebeheer bestaand uit het selecteren van configuratieonderdelen van een systeem en het vastleggen van hun functioneleen fysieke kenmerken in technische documentatie. [IEEE 610]. Een samenstelling van hardware en / of sofware welke vallen onder configuratiebeheer en wordt behandeld als een enkelvoudige eenheid in het configuratiebeheerproces. [IEEE 610]. Een discipline die technische- en administratieve sturing geeft aan en toezicht houdt op:  het vaststellen en documenteren van de functionele- en fysieke kenmerken van een configuratieonderdeel,  het beheer van wijzigingen van deze kenmerken,  het vastleggen van en rapporteren over het doorvoeren en invoeren van wijzigingen,  het controleren van het voldoen aan de gespecificeerde eisen. [IEEE 610]. Een tool dat ondersteuning biedt voor, het identificeren en beheren van configuratieonderdelen, de status van wijzigingen en versies en het vrijgeven van de basisversie met configuratieonderdelen. Zie: portability testing – (portabiliteitstest). Zie: re-testing – (hertest). Zie ook: compliance testing – (volgzaamheidstest). De mate waarin documenten, of delen van een component of systeem eenduidig, gestandaardiseerd en vrij van tegenstrijdigheden zijn. [IEEE 610].

Engelse term

Nederlandse term

Omschrijving

Continuous representation:

Continue weergave:

Control flow:

Programmastroom:

Control flow analysis:

Programmastroomanalyse:

Control flow graph:

Programmastroomdiagram:

Control flow path: Cost of quality:

Programmastroompad: Kwaliteitskosten:

Een 'capability maturity model' structuur waarbinnen de capaciteitsniveaus de aanbevolen volgorde beschrijven voor de uitvoering van procesverbetering binnen gespecificeerde procesgebieden. [CMMI]. Een opeenvolging van gebeurtenissen (programmapaden) tijdens uitvoering van een component of systeem. Een vorm van statische analyse gebaseerd op een weergave van de opeenvolging van gebeurtenissen (programmapaden) tijdens de uitvoering van een component of systeem. Een abstracte voorstelling van alle mogelijke opeenvolgingen van gebeurtenissen (programmapaden) tijdens de uitvoering binnen een component of systeem. Zie: path – (pad).

Conversion testing:

Conversietest:

COTS:

COTS:

Coverage:

Dekking:

Coverage analysis:

Dekkingsanalyse:

Coverage item:

Dekkingselement:

Coverage tool:

Dekkings-tool:

Coverage measurement tool: Custom software: Cyclomatic complexity:

Dekkingsmeet-tool:

Cyclomatic number:

Cyclomatische waarde:

Maatwerk software: Cyclomatische complexiteit:

De totale kosten als gevolg van activiteiten ten behoeve van kwaliteit en problemen, vaak opgesplits in preventiekosten, herstellingskosten, interne foutkosten en externe foutkosten. Het testen van software die de data van het bestaande systeem omzet voor gebruik in een vervangend systeem. Acroniem voor commerciële standaard software. Zie: off-the-shelf software – (standaard software). De mate waarin een bepaald dekkingsonderdeel geraakt wordt door een testset, uitgedrukt als percentage van het geheel. (Ook wel dekkingsgraad genoemd.) Het reviewen van de bereikte dekking van een dekkingselement tijdens testuitvoering aan vooropgestelde criteria om te bepalen of extra testen nodig zijn en zo ja, welke testgevallen daarvoor nodig zijn. Een eenheid of eigenschap die het uitgangspunt vormt voor het bepalen van de dekking, b.v. equivalentieklassen of programmacoderegels. Een tool dat objectieve meetgegevens verschaft over welke structurele elementen, zoals declaraties en programmapaden, geraakt zijn door een testset. Zie: coverage tool – (dekkings-tool). Zie: bespoke software – (maatwerk software). Het aantal onafhankelijke paden door een programma. De definitie van Cyclomatische complexiteit is: L – N + 2P, waarbij: L = aantal randen, verbindingen in een diagram N = aantal knooppunten in een diagram P = aantal ontkoppelde delen van het diagram (b.v. een aanroep naar een ander diagram, een deelprogramma) [Naar McCabe]. Zie: cyclomatic complexity – (cyclomatische complexiteit).

D Daily build:

Dagelijkse oplevering:

Data definition:

Datadeclaratie:

Data driven testing:

Datagerichte test:

Pagina 14 van 42

Een ontwikkelactiviteit waarbij een compleet systeem elke dag (meestal gedurende de nacht) gecompileerd en gelinkt wordt, om op elk moment een consistent systeem beschikbaar te hebben waarin alle laatste wijzigingen zijn opgenomen. Een uitvoerbare programmaregel waarbij een waarde wordt toegekend aan een variabele. Een scenariotechniek die zowel invoer als verwachte uitvoer in een tabel of rekenblad opslaat, zodat één enkel controlescenario alle testen in de tabel kan uitvoeren. Een datagerichte test wordt vaak toegepast tijdens de testuitvoering met behulp van geautomatiseerd test-tool zoals opname- / afspeel-tool. [Fewster and Graham]. Zie ook: keyword driven testing – (actiewoordtest).

Engelse term

Nederlandse term

Omschrijving

Data flow:

Gegevensstroom:

Data flow analysis:

Data flow testing:

Gegevensstroomanalyse: Gegevensstroomdekking: Gegevensstroomtest:

Een abstracte weergave van de volgorde van en mogelijke wijzigingen in de status van dataobjecten, waarbij een dataobject altijd één van de volgende statussen heeft: gecreëerd, gebruikt, geëlimineerd [Beizer]. Een vorm van statische analyse gebaseerd op definitie en gebruik van variabelen. Het percentage „definition-use pairs‟ dat geraakt wordt door een testset

Data integrity testing: Database integrity testing:

Dataintegriteitstest: Databaseintegriteitstest:

Dead code: Debugger: Debugging:

Dode code: Debugger: Debugging:

Debugging tool:

Foutoplossings-tool:

Decision:

Beslissing:

Decision condition coverage:

Beslissingsconditiedekking:

Decision condition testing:

Beslissingsconditietest:

Decision coverage:

Beslissingsdekking:

Decision table:

Beslissingstabel:

Decision table testing:

Beslissingstabeltest:

Decision testing:

Beslissingstest:

Decision outcome:

Beslissingsresultaat:

Defect:

Fout:

Defect based technique:

Testspecificatietechniek gebaseerd op foutcategorieën:

Data flow coverage:

Pagina 15 van 42

Een structurele („White-box‟) testspecificatietechniek, waarbij testgevallen worden ontworpen op basis van definitie en gebruik van variabelen binnen de code. Zie: database integrity testing – (database integriteitstest). Het testen van de procedures en processen die gebruikt worden voor toegang tot en beheer van de data(base), om te waarborgen dat toegangsprocedures, processen en regels functioneren zoals verwacht, en om er voor te zorgen dat gedurende de toegang tot de database, gegevens tijdens het databasegebruik niet corrupt raken of onbedoeld verwijderd, aangepast of aangemaakt worden. Zie: unreachable code – (onbereikbare code). Zie: debugging tool – (foutoplossings-tool). Het proces van het vinden, analyseren en verwijderen van de oorzaken van fouten (failures) in software. Een tool dat door programmeurs wordt gebruikt om operationele fouten (failures) te reproduceren, de status van een programma te onderzoeken en de bijbehorende programmafout (defect) te vinden. Een foutoplossings-tool maakt het voor programmeurs mogelijk om programma‟s stap voor stap uit te voeren, de programmauitvoering op elke programmaregel te stoppen en programmavariabelen te onderzoeken of een waarde toe te kennen. Een beslissingspunt in een programma waarbij het programmaverloop twee of meer alternatieve “paden” heeft. Een knooppunt met twee of meer verbindingen naar aparte programmapaden. Het percentage van alle conditieuitkomsten en beslissingsuitkomsten die zijn uitgevoerd door een testset. Een beslissingsconditiedekking van 100% impliceert zowel een conditiedekking van 100% als een beslissingsdekking van 100%. Een structurele („White-box‟) testspecificatietechniek waarmee testgevallen worden gespecificeerd om conditieuitkomsten en beslissingsuitkomsten uit te voeren. Het percentage van beslissingsuitkomsten die zijn uitgevoerd door een testset. Een beslissingsdekking van 100% impliceert zowel een programmapaddekking van 100% als een programmaregeldekking van 100%. Een tabel met combinaties van invoer en / of stimuli (oorzaken) en bijbehorende uitkomsten en / of acties (gevolgen), die gebruikt kan worden voor het specificeren van testgevallen. Een functionele („black box‟) testspecificatietechniek waarmee testgevallen worden ontworpen om de combinaties van invoer en / of stimuli (oorzaken), weergegeven in een tabel, uit te voeren. [Veenendaal]. Een structurele („White-box‟) testspecificatietechniek waarin testgevallen ontworpen worden om beslissingsuitkomsten uit te voeren. Het resultaat van een beslissing (waarmee dus wordt bepaald welk programmapad wordt genomen). Een fout in een component of systeem die er toe kan leiden dat de gewenste functie niet wordt uitgevoerd, b.v. een onjuiste programmaregel of datadefinitie. Wanneer een fout wordt geraakt bij de uitvoering van het programma, kan dit leiden tot een falen (failure) van het systeem of de component. Zie: defect based test technique – (testspecificatietechniek gebaseerd op foutcategorieën).

Engelse term

Nederlandse term

Omschrijving

Defect based test design technique:

Testspecificatietechniek gebaseerd op foutcategorieën:

Defect density:

Foutdichtheid:

Defect detection percentage (DDP): Defect management:

Fout detectiepercentage (FDP): Foutenbeheer:

Defect management tool:

Foutenbeheer-tool:

Defect masking:

Foutverhulling:

Defect report:

Foutrapport:

Defect taxonomy:

Fouttaxonomie:

Defect tracking tool:

Bevindingenbeheertool: Definitie-gebruik koppel:

Een procedure om test cases uit een of meerdere foutcategorieën af te leiden en/of te selecteren, waarbij de tests opgesteld worden met kennis van die specifieke foutcategorie. Zie ook: defect taxonomy – (fouttaxomonie). Het aantal fouten gevonden in een component of systeem, gedeeld door de omvang van die component of dat systeem (uitgedrukt in standaardmeeteenheden, zoals regels code, aantal klassen of functiepunten ….) Het aantal fouten gevonden in een testfase, gedeeld door het aantal gevonden fouten in die testfase plus de fouten die daarna, op welke manier dan ook, gevonden worden. Het proces van herkennen, onderzoeken, actie ondernemen en verwijderen van fouten. Hieronder valt het registereren en classificeren van fouten, en het identificeren van de mogelijke gevolgen van een fout. [Naar IEEE 1044]. Zie ook: problem management - (probleembeheer). Een tool dat het registreren en bijhouden van de status van fouten en wijzigingen faciliteert. Vaak ondersteunen deze tools workflow gerelateerde activiteiten, zoals het volgen en beheersen van het toewijzen, herstellen en hertesten van fouten, en bieden ze rapportagemogelijkheden. Zie ook: incident management tool – (bevindingenbeheer-tool). Een gebeurtenis waarbij een fout de detectie van een andere fout verhindert. [Naar IEEE 610]. Een rapportagedocument voor iedere fout in een component of systeem die er toe kan leiden dat een bepaalde uit te voeren functie van een component of systeem faalt. [Naar IEEE 829]. Een systeem van (hiërarchische) categorieën dat wordt ontworpen ter ondersteuning van de reproduceerbaarheid van geclassificeerde fouten. Zie: defect management tool – (bevindingenbeheer-tool).

Definition-use pair:

Deliverable: Design based testing:

Op te leveren product: Ontwerp gebaseerde test:

Desk checking:

Bureaucontrole:

Development testing:

Ontwikkeltest:

Deviation: Deviation report: Dirty testing: Documentation testing:

Afwijking: Afwijkingenrapport: Negatief testen: Documentatietest:

Domain:

Domein:

Driver:

Stuurprogramma:

Dynamic analysis:

Dynamische analyse:

Pagina 16 van 42

De relatie tussen definitie en gebruik van een variabele met het gebruik van dezelfde variabele. Het gebruik van variabelen omvat berekeningen (bv. vermenigvuldiging) of sturing van het uitvoeren van een programmapad (gebruik van predikaten). Elk (tussen)product dat opgeleverd moet worden aan iemand anders dan de auteur van het (werk)product. Een testaanpak waarbij testgevallen ontworpen worden op basis van architectuur- en/of detailontwerp van een component of systeem (b.v. het testen van interfaces tussen componenten of systemen) Het testen van software of specificaties door handmatige simulatie van de uitvoering. Zie ook: static analysis – (statische analyse). Formele- of informele test uitgevoerd tijdens het programmeren van een component of systeem, normaliter in de ontwikkelomgeving door ontwikkelaars. [Naar IEEE 610]. Zie: incident – (bevinding). Zie: incident report – (bevindingenrapport). Zie: negative testing – (negatief testen). Het testen van de kwaliteit van de documentatie. B.v. gebruikershandleiding of installatiehandleiding. De set waaruit geldige invoer- en / of uitvoerwaarden geselecteerd kunnen worden. Een softwarecomponent of test-tool ter vervanging van een component die andere componenten / systemen bestuurt en / of aanroept. [Naar TMap®]. Het proces van evaluatie van gedrag van een component of systeem tijdens de uitvoering van een programma. [Naar IEEE 610].

Engelse term

Nederlandse term

Omschrijving

Dynamic analysis tool:

Dynamische analyse-tool:

Dynamic comparison:

Dynamische vergelijking: Dynamisch testen:

Een tool dat informatie verstrekt over de status van de software tijdens uitvoering. Deze hulpmiddelen worden gewoonlijk gebruikt om niet toegewezen pointers (geheugenaanwijzers) te identificeren, om berekeningen met pointers te controleren, om de toewijzing, gebruik en vrijgave van geheugen te bewaken en om geheugenlekken aan te wijzen. Het vergelijken van feitelijke en verwachte resultaten tijdens het draaien van software, b.v. door een testuitvoerings-tool. Testen waarbij de software van een component of systeem wordt uitgevoerd.

Dynamic testing:

E Efficiency:

Efficiëntie:

Efficiency testing: Elementary comparison testing:

Efficiëntietest: Elementaire vergelijkingentest:

Emulator:

Emulator:

Entry criteria:

Ingangscriteria:

Entry point: Equivalence class: Equivalence partition:

Ingangspunt: Equivalentieklasse: Equivalentiepartitie:

Equivalence partition coverage: Equivalence partitioning:

Equivalentiepartitie dekking: Equivalentie partitioneren

Error:

(Menselijke) fout:

Error guessing:

Error guessing:

Error seeding: Error seeding tool: Error tolerance:

Foutzaaien: Foutzaai-tool: Fouttolerantie:

Evaluation: Exception handling:

Evaluatie Uitzonderingsafhandeling:

Executable statement:

Uitvoerbare programmaregel:

Pagina 17 van 42

Het vermogen van een softwareproduct om naar behoren te presteren bij een gegeven aantal systeembronnen en onder vastgestelde condities. [ISO 9126]. Het testproces om de efficiëntie van een softwareproduct vast te stellen. Een „black box‟ testspecificatietechniek waarmee testgevallen worden gespecificeerd om combinaties van invoerwaarden uit te voeren, gebruik makend van het principe van conditiebepalingsdekking. [TMap®]. Een apparaat, computerprogramma of systeem dat dezelfde invoer accepteert en uitvoer genereert als een gegeven systeem. [IEEE 610]. Zie ook: simulator - (simulator) Een set algemene en specifieke voorwaarden waaraan een proces moet voldoen om door te kunnen gaan naar een volgende activiteit, zoals b.v. een testfase. Doel van deze criteria is om te voorkomen dat men meer (extra) tijd moet steken in het uitvoeren van de taak zelf dan nodig zou zijn geweest om te voldoen aan de ingangscriteria. [Gilb en Graham]. De eerste uitvoerbare programmaregel in een component. Zie: equivalence partition – (equivalentiepartitie). Een gedeelte van een invoer- of uitvoerdomein waarvan op basis van de specificatie wordt aangenomen dat het gedrag van een component of systeem hetzelfde is. Het percentage van equivalentiepartities dat is uitgevoerd door een testset. Een „black box‟ testspecificatietechniek waarmee testgevallen worden ontworpen om representanten van elke equivalentiepartitie uit te voeren. In principe zijn de testgevallen ontworpen om elke partitie minstens één keer af te dekken. Een menselijke actie die tot een incorrect resultaat leidt. [Naar IEEE 610]. Een testspecificatietechniek waarbij de ervaring van de tester wordt gebruikt om te anticiperen op fouten die tengevolge van menselijke fouten (errors) mogelijk aanwezig zijn in de component of het systeem dat getest wordt en om de testen zodanig te ontwerpen dat deze fouten worden ontdekt. Zie: fault seeding – (foutzaaien), Zie: fault seeding tool – (foutzaai-tool). Het vermogen van een component of systeem om normaal te blijven werken bij (een door een gebruiker) fout ingevoerde gegevens. [Naar IEEE 610]. Zie: testing – (testen). Gedrag van een component of systeem ten gevolge van ongeldige invoer door een menselijke gebruiker, een andere component of systeem, of door een interne fout (failure) Een programmaregel, die bij compilatie wordt omgezet naar een uitvoerbaar programma, die wordt uitgevoerd als het programma draait en die ook een bewerking op data kan uitvoeren.

Engelse term

Nederlandse term

Omschrijving

Exercised:

Uitgevoerd:

Exhaustive testing:

Uitputtende test:

Exit criteria:

Uitgangscriteria:

Exit point: Expected outcome: Expected result:

Eindpunt: Verwachte uitkomst: Verwacht resultaat:

Experienced-based test design technique:

Op ervaringen gebaseerde testspecificatietechni ek: Onderzoekend testen:

Men zegt dat een programmaonderdeel door een testgeval is "uitgevoerd", wanneer de invoerwaarde van dat testgeval heeft geleid tot de uitvoering van het betreffende programmaonderdeel (een programmaregel, beslissing of ander structureel element). Een testaanpak waarbij een testset alle invoerwaardencombinaties en precondities bevat Een set algemene en specifieke voorwaarden die zijn goedgekeurd door de verschillende belanghebbenden, en waaraan voldaan moet zijn om een proces formeel te kunnen afronden. Het doel van uitgangscriteria is om te voorkomen dat een taak (activiteit) als volledig afgerond wordt gezien, terwijl er nog steeds taakonderdelen zijn die niet zijn afgerond. Uitgangscriteria worden gebruikt voor rapportages en om te bepalen wanneer met testen gestopt kan worden. [Naar Gilb en Graham]. De laatst uitvoerbare programmaregel in een component. Zie: expected result – (verwacht resultaat). Het gedrag van een component of systeem, onder specifieke condities voorspeld door een specificatie of andere bron. Procedure om testgevallen, gebaseerd op de ervaring van de tester, af te leiden en / of te selecteren.

Exploratory testing:

Een informele testspecificatietechniek waarbij de tester gericht het testontwerp evalueert tijdens de testuitvoering, en de aldus verzamelde informatie gebruikt om nieuwe en betere testen te ontwerpen [Naar Bach].

F Fail:

Gefaald:

Failure:

(Opgetreden) fout:

Failure mode:

Foutmodus:

Failure Mode and Effect Analysis (FMEA):

FoutModus en GevolgAnalyse (FMGA):

Failure Mode, Effect and Criticality Analysis (FMECA):

FoutModus, Gevolg en Kritische Analyse (FMGKA):

Failure rate:

Foutratio:

False-fail result:

Onjuist foutresultaat: Onjuist geslaagd resultaat:

False-pass result:

Pagina 18 van 42

Het resultaat van de test is "gefaald" als het feitelijke - en verwachte resultaat niet overeenkomen. Afwijking van een component of systeem van zijn verwachte oplevering, dienst of resultaat. [Naar Fenton]. De fysieke of functionele manifestatie van een fout (failure). B.v., een systeem in foutmodus kan gekarakteriseerd worden door een trage werking, incorrecte uitvoerwaarden of volledige beëindiging van de uitvoering. [IEEE 610]. Een systematische aanpak voor het vaststellen en analyseren van risico's, waarbij de mogelijke foutmodi en maatregelen om die te voorkomen worden vastgesteld. Zie ook: Failure Mode, Effect and Criticality Analysis – (FoutModus, Gevolg en Kritische Analyse (FMGKA)). Een uitbreiding op FMGA, als een toevoeging op FMGA, welke inclusief een kritische analyse is, welke wordt gebuikt om de verwachting van de foutmodi tegenover de ernst van de gevolgen in kaart te brengen. Het resultaat licht de foutmodi eruit met een relatief hoge kans en ernst van de gevolgen, gevolg is dat de oploskracht op die gebieden waar de grootse waarde kan worden gericht. Zie ook: Failure Mode and Effect Analysis – (FoutModus en GevolgAnalyse (FMGA)). De verhouding tussen het aantal opgetreden fouten van een bepaalde categorie en een bepaalde meeteenheid, b.v. fouten per tijdseenheid, fouten per aantal transacties, fouten per aantal runs. [IEEE 610]. Een testresultaat waarin een fout wordt gerapporteerd hoewel een dergelijke fout niet in het testobject voorkomt / bestaat. Een testresultaat welke niet een fout in het testobject heeft geidentificeerd, terwijl wel een fout aanwezig is.

Engelse term

Nederlandse term

Omschrijving

False-positive result:

Zie: false-fail result – (onjuist foutresultaat).

Fault: Fault attack: Fault density: Fault Detection Percentage (FDP): Fault masking: Fault seeding

Onjuist positief resultaat: Onjuist negatief resultaat: Fout: Foutaanval: Foutdichtheid: Foutdetectiepercentage (FDP) Foutverhulling: Foutzaaien

Fault seeding tool

Foutzaai-tool:

Fault tolerance:

Fouttolerantie:

Fault Tree Analysis (FTA):

FoutBoomAnalyse (FBA):

Feasible path:

Uitvoerbaar pad:

Feature:

Kenmerk:

Field testing: Finite state machine:

Formal review:

Veldtest: Beperktetoestandmachine: Beperktetoestandtest: Formele review:

Frozen test basis:

Bevroren testbasis:

Function Point Analysis (FPA):

Functie Punt Analyse (FPA)

Functional integration:

Functionele integratie:

Functional requirement:

Functionele eis:

Functional test design technique:

Functionele testspecificatietechniek:

Functional testing:

Functionele test:

False-negative result:

Finite state testing:

Pagina 19 van 42

Zie: false-pass result - (onjuist geslaagd resultaat). Zie: defect – (fout). Zie: attack – (aanval). Zie: defect density – (foutdichtheid). Zie: Defect Detection Percentage (DDP) – (Foutdetectiepercentage (FDP)) Zie: defect masking – (foutverhulling). Het proces van opzettelijk toevoegen van (bekende) fouten aan de reeds in component of systeem aanwezige fouten, met als doel de mate van detectie en herstel te volgen en het aantal resterende fouten in te schatten. [IEEE 610]. Een tool voor het zaaien (bewust inbrengen) van fouten in een component of systeem. Het vermogen van een softwareproduct om een bepaald prestatieniveau te handhaven in geval van softwarefouten (defecten) of van een schending van de gespecificeerde interface. [ISO 9126]. Zie ook: reliability – (betrouwbaarheid). Een techniek die gebruikt wordt om de oorzaak van fouten te analyseren. De techniek laat visueel zien hoe de logische relaties tussen fouten, menselijke fouten en externe oorzaken kunnen worden gecombineerd om te veroorzaken dat bepaalde fouten zich openbaren. Een pad waarvoor invoerwaarden en precondities bestaan die ervoor zorgen dat het wordt uitgevoerd Een attribuut van een component of systeem gespecificeerd of geïmpliceerd door eisendocumentatie (b.v. betrouwbaarheid, bruikbaarheid of ontwerprestrictie). [Naar IEEE 1008]. Zie: beta testing – (bètatest). Een rekenmodel dat bestaat uit een beperkte reeks toestanden en overgangen tussen toestanden, mogelijk met bijbehorende acties. [IEEE 610]. Zie: state transition testing – (toestandovergangtest). Een review die gekarakteriseerd wordt door gedocumenteerde procedures en eisen, b.v. inspectie. Een testbasis document dat alleen gewijzigd kan worden door een formeel wijzigingsproces. Zie ook: baseline – (uitgangspunt). Een methode die erop gericht is de omvang van de functionaliteit van een informatiesysteem te meten. De meting is onafhankelijk van de gebruikte technologie. Deze meting kan gebruikt worden als basis voor het meten van de productiviteit, het schatten van benodigde middelen en het beheersen van projecten. Een aanpak voor integratie waarbij componenten of systemen samengevoegd worden met als doel zo vroeg mogelijk de basisfunctionaliteit werkende te krijgen. Zie ook: integration testing – (integratietest). Een eis die specificeert welke functie een component of systeem moet bieden. [IEEE 610]. Procedure om testgevallen af te leiden of te selecteren, gebaseerd op een analyse van de functionele specificaties van een component of systeem zonder referentie naar de interne structuur. Zie ook: black box test design technique – (‘black box’ testspecificatietechniek). Testen gebaseerd op een analyse van de functionele specificaties van een component of systeem. Zie ook: black box testing – (‘black box’ test).

Engelse term

Nederlandse term

Omschrijving

Functionality:

Functionaliteit:

Functionality testing:

Functionaliteitstest:

Het vermogen van een softwareproduct om in functies te voorzien die voldoen aan gedefinieerde en geïmpliceerde behoeften als de software wordt gebruikt onder specifieke omstandigheden. [ISO 9126]. Het testproces om de functionaliteit van een softwareproduct vast te stellen.

Glass box test:

Zie: „White-box’ testing - (‘White-box’ test).

Hazard analysis:

Gevaaranalyse:

Heuristic evaluation:

Heuristische evaluatie: Logisch testgeval:

Een techniek die wordt gebruikt om risico-elementen te typeren. Het resultaat van een gevaaranalyse zal richtinggevend zijn voor de te gebruiken ontwikkelen testmethoden. Zie ook: Risk analysis – (Risicoanalyse). Een statische bruikbaarheidstesttechniek om de gebruikers-interface te reviewen aan bepaalde bruikbaarheidsprincipes (de zogenoemde „heuristics‟). Een testgeval zonder concrete (implementatieniveau) waarden voor invoergegevens en verwachte resultaten. Er wordt gebruik gemaakt van logische operatoren; concrete gevallen van daadwerkelijke waarden zijn nog niet gedefinieerd en / of beschikbaar. Zie ook: low level test case – (fysiek testgeval). De traceerbaarheid waarin de eisen per testsoort gekoppeld kunnen worden aan de testdocumentatie (b.v. testplan, specificatie van testontwerp, testgeval, testprocedure of testscript). Een koppeling binnen een webpagina die naar andere webpagina‟s leidt. Een tool die wordt gebruikt om te controleren dat er geen gebroken koppelingen bestaan op een webpagina.

G Glass box testing:

H

High level test case:

Horizontal traceability:

Horizontale traceerbaarheid:

Hyperlink Hyperlink tool

Koppeling: Koppings-tool:

I Impact analysis:

Impactanalyse:

Incident:

Bevinding:

Incident logging: Incident management:

Bevindingenregistratie: Bevindingenbeheer:

Incident management tool:

Bevindingenbeheertool:

Incident report:

Bevindingenrapport:

Incremental development model:

Incrementeel ontwikkelmodel:

Pagina 20 van 42

Het beoordelen welke aanpassingen nodig zijn in de systeemdocumentatie, testdocumentatie en componenten na een wijziging in de (systeem)eisen Elke gebeurtenis die onderzoek vereist. [Naar IEEE 1008]. Het vastleggen van de details van een bevinding, b.v. gedurende testuitvoering. Het proces van vaststellen, onderzoeken, oplossen en sluiten van bevindingen. Het proces omvat het registreren, classificeren en bepalen van de impact van bevindingen. [Naar IEEE 1044]. Een tool dat het vastleggen en het bijhouden van de status van bevindingen faciliteert. Vaak bieden deze tools ondersteuning bij het beheersen van activititeiten die samenhangen met de levenscyclus van een bevinding, zoals toewijzen, herstellen en hertesten. Veelal bieden de tools ook rapportagemogelijkheden. Zie ook: defect management tool – (foutenbeheer-tool). Een document dat rapporteert over elke gebeurtenis die onderzoek vereist, b.v. gedurende testuitvoering. [Naar IEEE 829]. Een ontwikkellevenscyclus waarbij een project wordt opgebroken in een serie incrementen, waarbij elk increment een deel van de in de projecteisen beschreven functionaliteit omvat. De (systeem)eisen worden geprioriteerd en in volgorde van belangrijkheid opgeleverd binnen het daarvoor geschikte increment. Bij sommige - maar niet alle - varianten van dit ontwikkelmodel wordt voor ieder increment een soort "mini V-model" doorlopen, met eigen ontwerp-, bouw- en testfasen.

Engelse term

Nederlandse term

Omschrijving

Incremental testing:

Incrementeel testen:

Independence of testing:

Testonafhankelijkheid:

Infeasible path:

Onmogelijk pad:

Informal review: Input:

Informele review: Invoer:

Input domain:

Invoerdomein:

Input value:

Invoerwaarde:

Inspection:

Inspectie:

Inspection leader: Inspector: Installability:

Inspectieleider: Inspecteur: Installeerbaarheid:

Installability testing:

Installeerbaarheidst est: Installatiehandleiding:

Testaanpak waarbij per keer één of meerdere componenten of systemen worden geïntegreerd en getest, totdat alle componenten of systemen zijn geïntegreerd en getest. Scheiding van verantwoordelijkheden. Dit komt de objectiviteit van het testen ten goede. [Naar DO-178b]. Een pad door de code, dat door geen enkele reeks van geldige invoerwaarden kan worden uitgevoerd. Een review die niet gebaseerd is op een formele (gedocumenteerde) procedure. Een (binnen of buiten een component opgeslagen) variabele die gelezen wordt door een component. De verzameling waaruit geldige invoerwaarden geselecteerd kunnen worden. Zie ook: domain – (domein). Een met een waarde ingevulde invoervariabele. Zie ook: input – (invoer). Een collegiale review waarbij documenten visueel onderzocht worden om fouten op te sporen, b.v. afwijkingen van ontwikkelstandaards en inconsistenties ten opzichte van gerelateerde documenten (op een hoger niveau). Het is de meest formele review-techniek en daarom altijd gebaseerd op een gedocumenteerde procedure. [Naar IEEE 610, IEEE 1028]. Zie ook: peer review – (collegiale review). Zie: moderator - (moderator). Zie: reviewer - (review-er). Het vermogen van een softwareproduct om geïnstalleerd te worden in een gespecificeerde omgeving. [ISO 9126]. Zie ook: portability – (portabiliteit). Het proces van het testen van de installeerbaarheid van een softwareproduct. Zie ook: portability testing – (portabiliteitstest). Op enig medium geleverde instructies, die de installateur door het installatieproces helpen. Denk hierbij aan een gebruikershandleiding, een stapvoor-stap procedure, een installatie wizard of een vergelijkbare procesomschrijving. Op enig medium geleverde software die de installateur door het installatieproces leidt. De software voert het installatieproces uit, geeft terugkoppeling over installatieresultaten en geeft keuzemogelijkheden aan. Het toevoegen van code aan een programma om informatie te verzamelen over het gedrag van het programma tijdens het uitvoeren, b.v. voor het meten van codedekking. Software tool om gereedschappen (soft- en / of hardware) te laten werken. Een specifiek soort proeftest om te beslissen of de component of het systeem voor meer gedetailleerde en (vervolg)testen klaar is. Een innametest wordt gewoonlijk uitgevoerd aan het begin van de fase testuitvoering. Zie ook: smoke test – (proeftest). Het proces om componenten of systemen te combineren in een groter geheel. Testen uitgevoerd om fouten in de interfaces en in de interactie tussen geïntegreerde componenten of systemen bloot te leggen. Zie: component-, system integration testing – (component-, systeemintegratietest).

Installation guide:

Installation wizard:

Installatie wizard:

Instrumentation:

Instrumentatie:

Instrumenter: Intake test:

Instrumentatie-tool: Innametest:

Integration: Integration testing:

Integratie: Integratietest:

Integration testing in the large: Integration testing in the small: Interface testing:

Integratietest (voor systemen): Integratietest (voor componenten): Interfacetest:

Pagina 21 van 42

Zie: system integration testing – (systeemintegratietest). Zie: component integration testing – (componentintegratietest). Een integratietesttype dat zich richt op de interfaces tussen componenten of systemen.

Engelse term

Nederlandse term

Omschrijving

Interoperability:

Interoperabiliteit:

Interoperability testing: Invalid testing:

Interoperabiliteitstest: Ongeldigheidstest:

Isolation testing:

Isolatietest:

Item transmittal report:

Onderdeeloverdrachtsrapport: Iteratief ontwikkelmodel:

Het vermogen van een softwareproduct om met één of meerdere gespecificeerde componenten of systemen in wisselwerking te treden. [Naar ISO 9126]. Zie ook: functionality – (functionaliteit). Het testproces om de interoperabiliteit van een softwareproduct te bepalen. Zie: functionality testing – (functionaliteitstest). Het testen met invoerwaarden die door de component of het systeem zouden moeten worden afgekeurd. Zie ook: error tolerance – (fouttolerantie). Het testen van individuele componenten in afzondering van de omliggende componenten, waarbij omliggende componenten zijn vervangen door stubs en drivers. Zie: release note – (opleveringsdocument).

Iterative development model:

Een ontwikkellevenscyclus waar een project meestal in een groot aantal iteraties is opgedeeld. Een iteratie is een volledige ontwikkellevenscyclus die in een (interne of externe) oplevering resulteert van een werkend product, als onderdeel van het definitieve te ontwikkelen product. Het product evolueert met iedere iteratie verder tot het uiteindelijke product.

K Key performance indicator: Keyword driven testing:

Hoofdperformanceindicator: Actiewoordtest:

Zie: performance indicator – (performance-indicator).

LCSAJ:

LCSAJ (Linear Code Sequence And Jump):

LCSAJ coverage:

LCSAJ-dekking:

LCSAJ testing:

LCSAJ-test:

Een „Linear Code Sequence And Jump‟ bestaat uit de volgende drie elementen:  startpunt van een reeks opeenvolgende uitvoerbare programmaregels,  eindpunt van de reeks opeenvolgende uitvoerbare programmaregels,  'doel'-regel waar de besturingsstroom verder gaat (na een zogenaamde 'jump'). Identificatie gebeurt door regelnummers toe te voegen in een uitdraai van de broncode. Het percentage LCSAJs van een component die door een testset zijn uitgevoerd. Een LCSAJ-dekking van 100% impliceert een beslissingsdekking van 100%. Een „white-box‟ testspecificatietechniek waarbij testgevallen gespecificeerd worden op basis van LCSAJ

Learnability:

Leerbaarheid:

Level test plan:

Detailtestplan:

Link testing: Load profile:

Verbindingstest: Belastbaarheidsprofiel:

Een scriptingtechniek die gegevensbestanden gebruikt die niet alleen testgegevens en verwachte resultaten bevatten, maar ook de actiewoorden die betrekking hebben op de te testen toepassing. Een controlescript roept speciale ondersteunende scripts aan, die de actiewoorden interpreteren voor de test. Zie: data driven testing – (datagerichte test).

L

Pagina 22 van 42

Het vermogen van een softwareproduct om de gebruiker de toepassing te laten leren. [ISO 9126]. Zie ook: usability – (bruikbaarheid). Een testplan dat zich gewoonlijk op één testsoort richt. Zie ook: test plan – (testplan). Zie: component integration testing – (componentintegratietest). Een specificatie van de belasting waar het te testen component of systeem in operationele staat mee te maken kan krijgen. Een belastbaarheidprofiel bestaat uit een beschrijving van een toegewezen aantal virtuele gebruikers die een gedefinieerd aantal transacties uitvoeren in een vastgestelde tijd volgens een vastgesteld model voor systeemgebruik. Zie: operational profile – (operationeel profiel)

Engelse term

Nederlandse term

Omschrijving

Load testing:

Belastbaarheidstest:

Logic-coverage testing:

Logica-dekkingstest:

Logic-driven testing: Logical test case: Low level test case:

Logicagerichte test: Logisch testgeval: Fysiek testgeval:

Een type performancetesten uitgevoerd om het gedrag te meten van een component of systeem bij toenemende belasting, door bijvoorbeeld toename van het aantal gelijktijdige gebruikers en / of aantallen transacties, om te bepalen welke belasting de component of het systeem nog aankan. Zie: performance testing – (performancetest), stress testing – (duurtest). [Myers]. Zie: „White-box’ testing – (‘White-box’ test). Zie: „White-box’ testing – (‘White-box’ test). Zie: high level test case – (logisch testgeval). Een testgeval met concrete (implementatieniveau) waarden voor invoergegevens en verwachte resultaten. De logische operatoren uit de logische testgevallen worden vervangen door daadwerkelijke waarden die overeenkomen met de doelen van de logische operatoren. Zie ook: high level test case – (logisch testgeval).

M Maintenance:

Onderhoud:

Maintenance testing:

Onderhoudstest:

Maintainability:

Onderhoudbaarheid:

Maintainability testing:

Onderhoudbaarheidstest: Management review:

Management review:

Master test plan:

Master testplan:

Maturity:

Volwassenheid:

Measure:

Meetwaarde:

Measurement:

Meting:

Measurement scale:

Meetschaal:

Pagina 23 van 42

Wijziging van een softwareproduct na levering om fouten te corrigeren, prestaties of andere eigenschappen te verbeteren, of het product aan te passen aan een gewijzigde omgeving. [IEEE 1219]. Het testen van de wijzigingen in een operationeel systeem of het effect van een veranderde omgeving op een operationeel systeem. Het gemak waarmee een softwareproduct kan worden gewijzigd om fouten te corrigeren, kan worden gewijzigd om aan nieuwe eisen te voldoen, kan worden gewijzigd om toekomstig onderhoud gemakkelijker te maken, of kan worden aangepast aan een veranderende omgeving. [ISO 9126]. Het testproces om de onderhoudbaarheid van een softwareproduct vast te stellen. Een systematische evaluatie door of namens het management uitgevoerd voor de aanschaf van software, het leverings-, ontwikkelings-, verwerkings-, of onderhoudsproces. Dit wordt gedaan om de voortgang te bewaken, de status van plannen en programma‟s te bepalen, eisen en hun systeemtoepassing te bevestigen, of de doeltreffendheid van de managementaanpak, m.b.t. de geschiktheid om het doel te bereiken, te evalueren. [Naar IEEE 610, IEEE 1028]. Een testplan dat betrekking heeft op meerdere testsoorten. Zie ook: test plan – (testplan). (1) Het vermogen van een organisatie om processen en werkmethoden effectief en efficiënt in te richten en uit te voeren Zie ook: capability maturity model, test maturity model – (vermogenvolwassenheidsmodel, testvolwassenheidsmodel). (2) Het vermogen van een softwareproduct om een falen als resultaat van fouten (defects) in de software te vermijden. [ISO 9126]. Zie ook: reliability – (betrouwbaarheid). Het getal of de categorie die op grond van een meting aan een attribuut bij een entiteit wordt toegewezen. [ISO 14598]. Het proces van het toekennen van een getal of categorie aan een entiteit om een attribuut bij deze entiteit te beschrijven. [ISO14598]. Een schaal die het type gegevensanalyse beperkt dat op die schaal kan worden uitgevoerd. [ISO 14598].

Engelse term

Nederlandse term

Omschrijving

Memory leak:

Geheugenlek:

Metric:

Metriek:

Migration testing: Milestone:

Migratietest: Mijlpaal:

Mistake: Modelling tool:

Vergissing: Modeleer-tool

Moderator:

Moderator:

Modified condition decision coverage: Modified condition decision testing:

Aangepaste conditie beslissingsdekking: Aangepaste conditie beslissingsdekkingstest: Aangepaste meervoudige conditiedekking: Aangepaste meervoudige conditietest: Module: Moduletest: Monitor:

Een fout in het ontwerp van de dynamische opslagallocatie van een programma, die tot gevolg heeft dat het geheugen na gebruik niet geschoond of vrijgegeven wordt. Uiteindelijk zal dit leiden tot een falen van het programma als gevolg van gebrek aan geheugenruimte. De meetschaal en de methode die voor een meting gebruikt worden. [ISO 14598]. Zie: conversion testing – (conversietest). Een moment binnen een project waarop (tussentijdse) producten en resultaten klaar moeten zijn Zie: error – (fout). Een tool dat het valideren van software- of systeemmodellen ondersteunt. [Graham]. Leider van en hoofdverantwoordelijke voor een inspectie of een ander reviewproces Zie: condition determination coverage – (conditie bepalingsdekking).

Modified multiple condition coverage: Modified multiple condition testing: Module: Module testing: Monitor:

Monitoring tool: Monkey testing: Multiple condition:

Monitor-tool:

Multiple condition coverage:

Meervoudige conditie: Meervoudige conditiedekking:

Multiple condition testing:

Meervoudige conditietest:

Mutation analysis:

Mutatieanalyse:

Mutation testing:

Mutatietest:

Zie: condition determination testing - (conditie bepalingstest). Zie: multiple condition coverage - (meervoudige conditiedekking). Zie: condition determination coverage testing -(meervoudige conditietest). Zie: component – (component). Zie: component testing – (componenttest). Een softwarehulpmiddel of hardware-apparaat dat meedraait met een te testen component of systeem en tegelijkertijd controleert, registreert en / of analyseert hoe het te testen component of systeem zich gedraagt. [Naar IEEE 610]. Zie: monitor – (monitor). Zie: compound condition – (samengestelde conditie). Het percentage mogelijke combinaties van enkelvoudige conditieresultaten, binnen één programmaregel, dat door een testset wordt uitgevoerd. Een meervoudige conditiedekking van 100% impliceert een conditie bepalingsdekking van 100%. Een „White-box‟ testspecificatietechniek waarmee testgevallen ontworpen worden om combinaties van enkelvoudige conditieresultaten (binnen één programmaregel) uit te voeren. Een methode om de diepgang van de testset te bepalen door te meten in welke mate verschillen tussen het programma en kleine variaties op dat programma (mutanten) geïdentificeerd kunnen worden met behulp van die testset. Zie: back-to-back testing – (back-to-backtest).

N N-switch coverage:

Novergangendekking:

N-switch testing:

N-overgangentest:

Pagina 24 van 42

Het percentage opeenvolgingen van N+1 overgangen dat door een testset wordt uitgevoerd. [Chow]. Een soort toestandsovergangtest waarbij testgevallen ontworpen worden om alle geldige opeenvolgingen van N+1 overgangen uit te voeren. [Chow]. Zie: state transition testing – (toestandsovergangtest).

Engelse term

Nederlandse term

Omschrijving

Negative testing:

Negatief testen:

Non-conformity:

Non-conformiteit:

Non-functional requirement:

Niet-functionele eis:

Non-functional testing:

Niet-functionele test:

Non-functional test design technique:

Niet-functionele testspecificatietechniek:

Testen om aan te tonen dat een component of systeem niet werkt. Het negatief testen heeft meer te maken met de houding van de testers dan met een specifieke testaanpak of met een testspecificatietechniek, b.v. testen met ongeldige invoerwaarden of uitzonderingen. [Naar Beizer]. Het niet voldoen aan een gespecificeerde eis. [ISO 9000]. Een eis die niet te maken heeft met functionaliteit, maar met kwaliteitsattributen zoals betrouwbaarheid, efficiëntie, bruikbaarheid, onderhoudbaarheid en overdraagbaarheid. Het testen van een component of systeem op niet functionele kwaliteitsattributen, zoals betrouwbaarheid, efficiëntie , bruikbaarheid, onderhoudbaarheid en overdraagbaarheid. Procedure om testgevallen af te leiden en / of te selecteren voor niet-functionele testen, gebaseerd op een analyse van de specificaties van een component of systeem zonder referentie naar de interne structuur. Zie ook: black box test design technique – (‘black box’ tesspecificatietechniek).

O Off-the-shelf software:

Standaard software

Operability:

Bedienbaarheid:

Operational acceptance testing:

Operationele acceptatietest:

Operational environment:

Operationele omgeving:

Operational profile:

Operationeel profiel:

Operational profile testing:

Operationele profieltest:

Operational testing:

Operationele test:

Oracle: Orthogonal array:

Vraagbaak: Orthogonale matrix:

Orthogonal array testing:

Orthogonale matrix test:

Outcome: Output:

Resultaat: Uitvoer:

Output domain:

Uitvoerdomein:

Pagina 25 van 42

Een softwareproduct dat is ontwikkeld voor de algemene markt, met andere woorden voor een groot aantal klanten, en dat aan veel klanten in uniforme vorm wordt geleverd. De mate waarin een softwareproduct een gebruiker in staat stelt het te bedienen en te beheersen. [ISO 9126]. Zie ook: usability – (bruikbaarheid). Operationele test in de acceptatietestfase, met name uitgevoerd in een gesimuleerde operationele omgeving door een exploitant en / of beheerder, waarbij de focus ligt op operationele aspecten zoals herstelbaarheid, middelengedrag, installeerbaarheid en technische naleving. Zie ook: operational testing – (operationele test). Hardware- en softwareproducten die geïnstalleerd zijn bij de gebruiker of klant waar te testen component of systeem worden gebruikt. De software kan bestaan uit besturingssystemen, database-managementsystemen en andere toepassingen. Representatie van een verschillende reeks taken uitgevoerd door een component of systeem, mogelijk gebaseerd op het gedrag van de gebruiker in interactie met het component of het systeem en de waarschijnlijkheid van optreden. Een taak is meer logisch dan fysiek en kan uitgevoerd worden over meerdere machines of in niet op elkaar aansluitende tijdsegmenten. Statistisch testen gebruik makend van een model voor systeemgebruik (met kortdurende taken) en hun mogelijkheid voor specifiek gebruik. [Musa]. Testen om een component of systeem in zijn operationele omgeving te evalueren. [IEEE 610]. Zie: test oracle – (testvraagbaak). Een 2-dimensionale matrix samengesteld met speciale wiskundige eigenschappen waarmee elke willekeurige keuze van twee kolommen uit de matrix de mogelijke paar-combinaties oplevert voor elke waarde uit de matrix. Een systematische manier om met behulp van orthogonale matrixen alle paarcombinaties van variabelen te testen. Het reduceert het aantal van alle combinaties van variabelen die als paren getest moeten worden aanzienlijk. Zie ook: pair testing – (paargewijs testen) Zie: result – (resultaat). Een (binnen of buiten een component opgeslagen) variabele die gevuld wordt door een component. De verzameling waaruit geldige uitvoerwaarden geselecteerd kunnen worden. Zie ook: domain – (domein).

Engelse term

Nederlandse term

Omschrijving

Output value:

Uitvoerwaarde:

Een met een waarde ingevulde uitvoervariabele. Zie ook: output – (uitvoer).

Pair programming:

Paargewijs programmeren:

Pair testing:

Paargewijs testen:

Pairwise testing:

Paargewijs testen:

Partition testing:

Partitietest:

Pass:

Geslaagd:

Pass / fail criteria

Geslaagd / gefaald criteria:

Path:

Pad:

Path coverage:

Paddekking:

Path sensitizing: Path testing:

Pad ontvankelijk maken: Padtest:

Peer review:

Collegiale review:

Performance:

Performance:

Performance indicator:

Performance indicator:

Performance profiling:

Performance profilering:

Performance testing:

Performancetest:

Performance testing tool:

Performance testtool:

Een softwareontwikkelaanpak waarbij regels code (voor product en / of test) worden geschreven door twee programmeurs die gezamenlijk aan één computer zitten. Dit betekent impliciet dat de code gelijktijdig gebouwd én gereviewd wordt. Twee personen (b.v. twee testers, ontwikkelaar / tester of gebruiker / tester) werken samen aan het opsporen van fouten. Meestal delen ze één computer die ze afwisselend bedienen terwijl ze testen. Een „black box‟ testspecificatietechniek waarbij testgevallen ontworpen worden om alle mogelijke afzonderlijke combinaties van elk paar input parameters uit te voeren. Zie ook: orthogonal array testing – (orthogonale matrix test). [Beizer]. Zie: equivalence partitioning – (equivalentie partitioneren). Een test wordt als geslaagd beschouwd als de feitelijke resultaten en de verwachte resultaten overeenkomen. Beslissingregels om te bepalen of een testonderdeel (functie) of test is geslaagd of niet. [IEEE 829]. Een reeks gebeurtenissen (b.v. uitvoerbare programmaregels) binnen een component of systeem, met een beginpunt en een eindpunt. Het percentage paden dat door een testset is uitgevoerd. Een paddekking van 100% impliceert een LCSAJ-dekking van 100%. Een verzameling invoerwaarden zo kiezen dat de uitvoering van een bepaald pad wordt afgedwongen. Een „White-box‟ testspecificatietechniek waarmee testgevallen worden ontworpen om programmapaden uit te voeren. Collegiaal reviewen van een softwaretussenproduct met het doel om fouten (defecten) en verbetermogelijkheden te vinden. Voorbeelden zijn inspectie, technische review- en het gestructureerd doorlopen. De mate waarin een component of systeem de toegewezen functie uitvoert binnen de aan verwerkingstijd en doorvoersnelheid gestelde grenzen. [Naar IEEE 610]. Zie ook: efficiency – (efficiëntie). Een metriek op hoger niveau voor het meten van effectiviteit en / of efficiëntie die gebruikt wordt om de voortgang van de softwareontwikkeling te sturen en controleren. [CCMi]. Definitie van gebruikersprofielen bij performance, belasting en/of duur testen. De profilering moet het verwachte of werkelijk gebruik weerspiegelen gebaseerd op een operationeel profiel van een component of een systeem en van daar uit de verwachte werkbelasting weergeven. Zie ook: load profile, operational profile – (belastingsprofiel, operationeel profiel) Het testproces om de performance van een softwareproduct te bepalen. Zie ook: efficiency testing – (efficiëntietest). Een hulpmiddel dat performancetesten ondersteunt en dat meestal twee belangrijke faciliteiten biedt: het genereren van belasting en het meten van de duur van een testtransactie. Bij het genereren van de belasting kunnen talloze gebruikers of hoge aantallen invoergegevens gesimuleerd worden. Tijdens de uitvoering worden de reactietijden van geselecteerde transacties gemeten en vastgelegd. De meeste performancetest-tools bieden rapportages op basis van een testlogboek, en grafieken waarin belasting en responstijd tegen elkaar zijn afgezet.

P

Pagina 26 van 42

Engelse term

Nederlandse term

Omschrijving

Phase test plan:

Fase testplan:

Pointer:

Pointer:

Portability:

Portabiliteit:

Portability testing:

Portabiliteitstest:

Post condition:

Postconditie:

Post-execution comparison Precondition:

Post-uitvoeringsvergelijking: Preconditie:

Predicted outcome: Pre-test: Priority:

Voorspeld resultaat: Pretest: Prioriteit:

Probe effect:

Onderzoekseffect:

Problem: Problem management: Problem report: Procedure testing:

Probleem: Probleembeheer: Probleemrapport: Proceduretest:

Process:

Proces:

Process cycle test:

Procescyclustest:

Process improvement:

Procesverbetering:

Production acceptance testing: Product risk:

Productieacceptatietest: Productrisico:

Een testplan dat zich specifiek richt op één testfase. Zie ook: test plan – (testplan). Een data item dat de locatie van een ander data item specificeert; bijvoorbeeld, een data item dat het adres aangeeft van het volgende medewerkersrecord dat verwerkt moet worden. [IEEE610]. Het gemak waarmee een softwareproduct van de ene hardware- of software omgeving naar de andere kan worden overgezet. [ISO 9126]. Het testproces om te bepalen hoe goed een softwareproduct overdraagbaar is naar een andere omgeving. Omgevings- en toestandscondities waaraan voldaan moet zijn na uitvoering van een test of testprocedure. Vergelijking van feitelijke en verwachte resultaten, nadat de uitvoering van de software gestopt is. Omgevings- en toestandscondities waaraan voldaan moet zijn voordat een component of systeem kan worden onderworpen aan een specifieke test of testprocedure. Zie: expected result – (verwacht resultaat). Zie: intake test – (innametest). De mate van (bedrijfs)belang die aan een onderdeel, b.v. een fout (defect), wordt toegekend. Het effect dat een meetinstrument zelf heeft op de metingen aan een component of systeem. Voorbeelden van dergelijke instrumenten zijn een performancetesttool en een monitor. Bijvoorbeeld door het gebruik van een performancetest-tool kan de performance van een component of systeem verminderen. Zie: defect – (fout). Zie: defect management – (bevindingenbeheer). Zie: defect report – (foutrapport). Een test met als doel om te garanderen dat een component of een systeem kan werken in combinatie met nieuwe of bestaande bedrijfs- of operationele procedures van gebruikers. Een verzameling van onderling gerelateerde activiteiten, die invoerwaarden in uitvoerwaarden omzet. [ISO 12207]. Een „black box‟ testspecificatietechniek waarmee testgevallen worden ontworpen om bedrijfsprocedures en processen uit te voeren. [TMap®]. Zie ook: procedure testing – (proceduretest). Een programma van activiteiten ontworpen om de prestaties en volwassenheid van het organisatieproces te verbeteren, inclusief de resultaten van het programma. [CMMI]. Zie: operational acceptance testing – (operationele acceptatietest).

Project:

Project:

Project risk:

Projectrisico:

Program instrumenter:

Programmainstrumentatie-tool: Programmatest: Project testplan:

Program testing: Project test plan:

Pagina 27 van 42

Een risico dat direct aan het te testen object is gerelateerd. Zie ook: risk – (risico). Een project is een unieke verzamelingen van gecoördineerde en gecontroleerde activiteiten, met een begin- en een einddatum om een doel te bereiken in overeenkomst met specifieke eisen, inclusief randvoorwaarden betreffende tijd, geld en middelen [ISO 9000]. Een risico gerelateerd aan het beheer en controle van een (test)project, b.v. gebrek aan personeel, strikte tijdslimieten, veranderende eisen, etc. Zie ook: risk – (risico). Zie: instrumenter – (instrumentatie-tool). Zie: component testing – (componenttest). Zie: master test plan – (master testplan).

Engelse term

Nederlandse term

Omschrijving

Pseudo-random:

Pseudo-random:

Een reeks die willekeurig lijkt te zijn maar die in feite wordt gegenereerd volgens een van tevoren bepaalde volgorde.

Qualification:

Kwalificatie

Quality:

Kwaliteit:

Quality assurance:

Kwaliteitsborging:

Quality attribute:

Kwaliteitsattribuut:

Quality characteristic: Quality management:

Kwaliteitskenmerk: Kwaliteitsbeheer:

Het proces om aan te tonen dat aan de gespecificeerde eisen wordt voldaan. [Noot] De term „gekwalificeerd‟ wordt gebruikt om de bijbehorende status aan te duiden. [ISO 9000]. De mate waarin een component, systeem of proces voldoet aan gespecificeerde eisen en / of gebruikers / klant behoeften en verwachtingen. [naar IEEE 610]. Onderdeel van het kwaliteitsbeheer, dat zich concentreert op het creëren van vertrouwen dat aan de kwaliteitseisen wordt voldaan. [ISO 9000]. Een eigenschap of attribuut die de kwaliteit van een onderdeel beinvloedt. [IEEE 610]. Zie: quality attribute – (kwaliteitsattribuut). Gecoördineerde activiteit die een organisatie richting geeft en controleert m.b.t. kwaliteit. Richting en controle m.b.t. kwaliteit leidt in het algemeen tot het instellen van kwaliteitsbeleid en kwaliteitsdoelen, kwaliteitsplanning, kwaliteitscontrole, kwaliteitsborging en kwaliteitsverbetering. [ISO 9000].

Q

R Random testing:

Toevalstest:

Recorder: Record / playback tool:

Notulist: Opname- / afspeeltool: Herstelbaarheid:

Recoverability:

Recoverability testing:

Herstelbaarheidstest:

Recovery testing: Regression testing:

Hersteltest: Regressietest:

Regulation testing: Release note:

Reglementtest: Opleveringsdocument:

Reliability:

Betrouwbaarheid:

Reliability growth model:

Betrouwbaarheidsgroeimodel:

Pagina 28 van 42

Een „black box‟ testspecificatietechniek waarbij testgevallen worden geselecteerd, mogelijkerwijs met behulp van een pseudo-toevalsgeneratie algoritme, om te voldoen aan een operationeel profiel. Deze techniek kan gebruikt worden voor het testen van niet-functionele kwaliteitsattributen, zoals betrouwbaarheid en performance. Zie: scribe – (notulist). Zie: capture / playback tool – (opname- / afspeel-tool). De mogelijkheid van een softwareproduct om in het geval van een opgetreden fout opnieuw een bepaald niveau van performance te halen en om de data te herstellen die mogelijk verloren is gegaan bij de fout. [ISO 9126]. Zie ook: reliability – (betrouwbaarheid). Het testproces om uit te maken hoe goed de herstelbaarheid van een softwareproduct is. Zie ook: reliability testing – (betrouwbaarheidstest). Zie: recoverability testing – (herstelbaarheidstest). Het testen van een eerder getest programma na een wijziging, om aan te tonen dat er geen fouten (defecten) zijn geintroduceerd of ontdekt in ongewijzigde gebieden van de software als gevolg van die wijzigingen. Het vindt plaats wanneer de software of de omgeving is gewijzigd. Zie: compliance testing – (volgzaamheidstest). Een document dat testeenheden, hun configuratie, huidige status en andere opleveringsdetails bevat. Dit wordt overhandigd door het ontwikkelteam aan het testteam en mogelijk andere betrokkenen bij aanvang van de testuitvoeringsfase. [Naar IEEE 829]. Het vermogen van een softwareproduct om zijn vereiste functies uit te voeren onder gestelde voorwaarden gedurende een bepaalde tijdspanne of gedurende een bepaald aantal bewerkingen. [ISO 9126]. Een model dat de betrouwbaarheidgroei aantoont over langere tijd, terwijl er continu een component of systeem getest wordt na het verwijderen van fouten die geleid hebben tot een betrouwbaarheidsfout.

Engelse term

Nederlandse term

Omschrijving

Reliability testing:

Het testproces om de betrouwbaarheid van een softwareproduct te bepalen.

Replaceability:

Betrouwbaarheidstest: Vervangbaarheid:

Requirement:

Eis:

Requirements based testing:

Op eisen gebaseerd testen:

Requirements management tool:

Eisenbeheer-tool:

Requirements phase:

Eisendefinitiefase:

Resource utilization:

Middelenbeslag:

Resource utilization testing:

Middelenbeslagtest:

Result:

Resultaat:

Resumption criteria:

Hervattingscriteria:

Re-testing:

Hertest:

Retrospective meeting:

Evaluatiebijeenkomst:

Review:

Review:

Reviewer:

Reviewer:

Review tool:

Review tool:

Pagina 29 van 42

Het vermogen van een softwareproduct om een ander softwareproduct met hetzelfde doel en in dezelfde omgeving te vervangen. [ISO 9126]. Zie ook: portability – (portabiliteit). Een voorwaarde of mogelijkheid van een gebruiker om een probleem op te lossen of een doel te bereiken waaraan een systeem of subsysteem moet voldoen, waarbij aan een contract, standaard, specificatie of een ander formeel opgelegd document wordt voldaan. [Naar IEEE 610]. Een testaanpak waarmee testgevallen ontworpen worden op basis van testdoelen en testcondities die afgeleid zijn van eisen. B.v. testen die specifieke functies uitvoeren of het onderzoeken van niet-fucntionele kwaliteitsattributen als betrouwbaarheid of bruikbaarheid. Een tool dat ondersteunt bij het vastleggen van kenmerken (belang, kennisverantwoordelijke) en aantekeningen van eisen en ondersteunt bij de traceerbaarheid van eisen op verschillende detailniveaus en ondersteunt bij het wijzigingsbeheer van eisen. Sommige van dergelijke gereeedschappen bieden ook functies voor statische analyse, zoals consistentiecontrole en controle op het overtreden van voorgedefinieerde regels betreffende eisen. De fase in de software levenscyclus waarin de eisen voor een softwareproduct worden gedefinieerd en vastgelegd. [IEEE 610]. Het vermogen van een softwareproduct om de juiste hoeveelheid en type van de hulpbronnen te gebruiken, b.v. de hoeveelheid te gebruiken primair- en secundair geheugen door het programma en de grootte van de benodigde tijdelijke- of overloopbestanden, wanneer de software zijn functies uitvoert onder bepaalde omstandigheden. [Naar ISO 9126]. Zie ook: efficiency – (efficiëntie). Het testproces om het gebruik van hulpbronnen van een softwareproduct vast te stellen. Zie ook: efficiency testing – (efficiëntietest). Het gevolg / uitkomst van het uitvoeren van een test. Dat houdt schermuitvoer, gegevenswijzigingen, rapporten en het verzonden communicatieboodschappen. Zie ook: actual result, expected result – (feitelijk resultaat, verwacht resultaat). De testactiviteiten die herhaald moeten worden als het testen wordt hervat na een onderbreking. [Naar IEEE 829]. Het uitvoeren van testgevallen die de laatste keer niet geslaagd waren om de juistheid van herstelacties te verifiëren. Een bijeenkomst aan het eind van het project, waarin de projectleden het project evalueren en de opgedane ervaringen kunnen toepassen binnen een volgend project. De evaluatie van een product of projectstatus om afwijkingen t.o.v. geplande resultaten of doelstellingen vast te stellen en verbeteringen voor te stellen. B.v. management review, informele review, technische review, inspectie en doorlopen. [Naar IEEE 1028]. De persoon betrokken bij een review, die afwijkingen identificeert en beschrijft die voorkomen in het product of het project dat gereviewed wordt. Reviewers kunnen gekozen worden om een verschillende invalshoeken en rollen in het review-proces te vervullen. Een tool dat het review-proces ondersteunt. Specifiek voorziet dit tool in functies om de review planning, opvolging en de communicatie te ondersteunen, om gezamenlijke reviews uit te voeren en bevat dit tool een opslagmogelijkheid om metrieken te verzamelen en daarover te rapporteren.

Engelse term

Nederlandse term

Omschrijving

Risk:

Risico:

Risk analysis:

Risicoanalyse:

Risk-based testing:

Risico gebaseerd testen:

Risk control:

Risicobeheersing:

Risk identification:

Risicobepaling:

Risk level:

Risiconiveau:

Risk management:

Risicomanagement:

Risk mitigation: Risk type:

Risicovermindering: Risicotype

Robustness:

Robuustheid:

Robustness testing: Root cause:

Robuustheidstest: Hoofdoorzaak:

Root cause analysis:

Hoofdoorzaakanalyse:

Een factor die kan uitmonden in toekomstige negatieve gevolgen; gewoonlijk uitgedrukt in effect en waarschijnlijkheid. Het proces om vastgestelde risico‟s te beoordelen om hun effect en waarschijnlijkheid van optreden in te schatten. Een testaanpak om het produktrisico te verminderen en stakeholders te informeren over de status, beginnend met de initiele fasen van het project. Het heeft betrekking op de identificatie van produktrisico‟s en het gebruik hiervan om het testproces te doorlopen. Het proces om risico‟s te verminderen of om risico‟s binnen bepaalde grenzen te houden. Binnen het proces vindt besluitvorming plaats en worden risicobeperkende maatregelen geïmplementeerd. Het proces om risico‟s vast te stellen, gebruik makend van technieken zoals brainstormen, checklists en fouthistorie. Het belang van een risico zoals het gedefinieerd is volgens de karakteristieken gevolg en kans. Het risiconiveau kan gebruikt worden om de testinspanning te bepalen. Een risiconiveau kan zowel kwalitatief (b.v. hoog, middel, laag) als kwantitatief worden uitgedrukt. Systematisch toepassen van procedures en ervaringen om risico's vast te stellen, analyseren, prioritiseren en beheersen. Zie: risk control – (risicobeheersing). Een specifieke risicocategorie gerelateerd aan een testtype die dat specifieke risico kan verminderen (controle). Bijvoorbeeld, het risico van misverstanden in de gebruikersinteractie kan verminderen door een bruikbaarheidstest. De mate waarin een component of systeem correct kan functioneren tijdens ongeldige invoer of onder belastende omgevingsfactoren. [IEEE 610]. Zie ook: fault tolerance – (fouttolerantie). Testen om de robuustheid van een systeem te bepalen. Een foutenbron die als deze is verwijderd, de verschijning van dit type fouten verminderd of verwijderd. [CMMi] Een analysetechniek met als doel om de hoofdoorzaak van fouten te identificeren. Door correctieve maatregelen op de hoofdoorzaak te nemen, wordt gehoopt dat de kans op het terugkomen van fouten geminimaliseerd wordt.

S Safety:

Veiligheid:

Safety critical system:

Veiligheidskritisch systeem

Safety testing: Sanity test: Scalability:

Veiligheidstest: Gezondheidstest: Schaalbaarheid:

Scalability testing: Scenario testing: Scribe:

Schaalbaarheidstest: Scenariotest: Notulist:

Scripted testing: Scripting language:

Scripttest: Scriptingtaal:

Pagina 30 van 42

Het vermogen van een softwareproduct om een acceptabel risiconiveau te bereiken, waarbij de schade aan mensen, bedrijf, software, eigendom of het milieu aanvaardbaar is binnen een bepaalde gebruikscontext. [ISO 9126]. Een systeem dat bij weigering of het verkeerd werken kan leiden tot de dood of zware verwondingen van mensen. Of leidt tot zware schade aan apparatuur of omgevingsschade. Testen om de veiligheid van een softwareproduct te bepalen. Zie: smoke test – (proeftest). De mogelijkheid van een softwareproduct om te worden opgeschaald om verhoogde werklast aan te kunnen. [Naar Gerrard]. Testen om de schaalbaarheid van een softwareproduct te bepalen. Zie: use case testing – (use case test). De persoon die iedere fout (defect) en elke verbetersuggestie tijdens een loggingbijeenkomst noteert op een aantekenformulier. De notulist moet erop toezien dat het formulier leesbaar en begrijpelijk is. Testuitvoering volgens een eerder gedocumenteerde reeks testen. Een programmeertaal waarin uitvoerbare testscripts worden geschreven die gebruikt worden door een testautomatiserings-tool (b.v. een opname- / afspeeltool).

Engelse term

Nederlandse term

Omschrijving

Security:

Beveiliging:

Security testing:

Beveiligingstest:

Security testing tool: Security tool: Serviceability testing: Severity:

Beveiligingstesttool: Beveiligings-tool: Duurzaamheidstest: Ernst:

Simulation:

Simulatie:

Simulator:

Simulator:

Site acceptance testing:

Locatie acceptatietest:

Smoke test

Proeftest:

Software:

Software:

Software attack: Software Failure Mode and Effect Analysis (SFMEA): Software Failure Mode Effect, and Criticality Analysis (SFMECA):

Software-aanval: Software FoutModus en GevolgAnalyse (SFMGA): Software FoutModus, Gevolg en KritischeAnalyse (SFMGKA) Software FoutenBoomAnalyse (SFBA): Softwarekenmerk: Softwarelevenscyclus:

Kenmerken van softwareproducten die betrekking hebben op het kunnen voorkomen van op toevallige of opzettelijke wijze verkregen ongeautoriseerde toegang tot programma‟s of gegevens. [ISO 9126]. Zie ook: functionality – (functionaliteit). Het testproces om de beveiliging van een softwareproduct te bepalen. Zie ook: functionality testing – (functionaliteitstest). Een tool dat ondersteuning biedt voor het testen van beveiligingsattributen en kwetsbaarheden. Een tool dat ondersteuning biedt voor operationele beveiliging. Zie: maintainability testing – (onderhoudbaarheidstest). De mate van effect die een fout (defect) heeft op de ontwikkeling of op het functioneren van een component of systeem. [Naar IEEE 610]. Het nabootsen van bepaalde gedragingen van een fysiek of abstract systeem door een ander systeem. [ISO 2382/1]. Een apparaat, computerprogramma of systeem dat tijdens het testen gebruikt wordt. Het gedraagt zich of werkt als een bepaald systeem wanneer het voorzien wordt van een bepaalde verzameling gegevens. [Naar IEEE 610, DO178b]. Zie ook: emulator – (emulator). Acceptatietest op de locatie van en door gebruikers / klanten om te bepalen of een component of systeem al dan niet voldoet aan de verwachtingen van die gebruiker / klant en om te bepalen of het aansluit bij de bedrijfsprocessen. Meestal betreft het zowel hard- als software. Een deel van alle beschreven / geplande testgevallen die de belangrijkste functionaliteiten van een component of systeem afdekken, om zeker te stellen dat de meest kritische functies van een programma werken, zonder verdere details in beschouwing te nemen. Een dagelijkse opleveringstest en een proeftest behoren tot de best practices uit de industrie. Zie ook: intake test – (innametest). Computerprogramma‟s, procedures en mogelijk bijhorende documentatie en gegevens die relevant zijn voor de uitvoering van een computersysteem. [IEEE 610]. Zie: attack – (aanval). Zie: Failure Mode and Effect Analysis (FMEA) – (FoutModus en GevolgAnalyse).

Software Fault Tree Analysis (SFTA): Software feature: Software life cycle:

Software quality:

Softwarekwaliteit:

Software quality characteristic:

Software kwaliteitskenmerk:

Pagina 31 van 42

Zie: Failure Mode and Effect, and Criticality Analysis (FMECA) – (FoutModus, Gevolg en Kritische Analyse (FMGKA)). Zie: Fault Tree Analysis (FTA) – (FoutenBoomAnalyse). Zie: feature – (kenmerk). Een tijdsperiode die begint wanneer een softwareproduct bedacht wordt en eindigt wanneer de software niet langer beschikbaar is voor gebruik. De softwarelevenscyclus bevat typisch een concept-, eisen-, ontwerp-, implementatie-, test-, installatie-, uitrol-, operationele- en beheerfase en soms een afbouwfase [Noot] Deze fases kunnen overlappen of iteratief worden uitgevoerd. Het geheel van functionaliteit en eigenschappen van een softwareproduct dat voldoet aan de expliciete of impliciete behoeften. [Naar ISO 9126]. Zie: quality attribute – (kwaliteitsattribuut).

Engelse term

Nederlandse term

Omschrijving

Software test incident:

Software testbevinding: Software testbevindingenrapport: Software Usability Measurement Inventory (SUMI): Bronregel: Specificatie:

Zie: incident – (bevinding).

Software test incident report: Software Usability Measurement Inventory (SUMI): Source statement: Specification:

Specification based testing: Specification-based technique:

Specified input: Stability:

Specificatie gebaseerde test: Specificatie gebaseerde techniek: Specificatie gebaseerde testspecificatietechniek: Beschreven invoer: Stabiliteit:

Staged representation:

Faserepresentatie:

Standard software: Standards testing: State diagram:

Standaard software: Testen van standaards: Toestandsdiagram:

State table:

Toestandstabel:

State transition: State transition testing:

Toestandsovergang: Toestandsovergangtest:

Statement:

Programmaregel:

Statement coverage:

Programmaregeldekking: Programmaregeltest: Statische analyse:

Specification based test design technique:

Statement testing: Static analysis: Static analysis tool: Static analyzer:

Statisch analysetool: Statisch analyse software:

Pagina 32 van 42

Zie: incident report – (bevindingenrapport). Een testtechniek gebaseerd op een vragenlijst die de bruikbaarheid, b.v. gebruikerstevredenheid, van een component of systeem beoordeelt. [Veenendaal]. Zie: statement – (programmaregel). Een document dat de eisen, het ontwerp, het gedrag en andere kenmerken van een component of systeem beschrijft, idealiter op een volledige, nauwkeurige en te controleren manier. Vaak worden de procedures om te bepalen of aan deze voorwaarden is voldaan ook beschreven. [Naar IEEE 610]. Zie: black box testing – (‘black box’ test). Zie: black box test design technique – (‘black box’ testspecificatietechniek) Zie: black box test design technique – (‘black box’ testspecificatietechniek)

Een invoerwaarde waarvoor de specificatie een resultaat voorspelt. Het vermogen van een softwareproduct om onverwachte effecten van wijzigingen in de software te vermijden. [ISO 9126]. Zie ook: maintainability – (onderhoudbaarheid). Een modelstructuur waarbinnen het doel is om een bepaald volwassenheidsniveau van procesgebieden te behalen: elk niveau geldt als basis voor het volgende niveau. [CMMi] Zie: off-the-shelf software – (standaard software). Zie: compliance testing – (volgzaamheidstest). Een diagram dat weergeeft welke toestanden een component of systeem kan aannemen en toont welke gebeurtenissen of omstandigheden kunnen leiden tot of resulteren in een toestandswijziging. [IEEE 610]. Een tabel die de resulterende toestandsovergangen toont voor alle toestanden gecombineerd met elke mogelijke gebeurtenis, zowel geldige als ongeldige overgangen. Een overgang tussen twee toestanden van een component of systeem. Een functionele („black box‟) test specificatie techniek waarmee de testgevallen ontworpen worden om de geldige en ongeldige toestandsovergangen uit te voeren. Zie ook: N-switch testing – (N-schakelingstest). Een entiteit in een programmeertaal, die bestaat uit de kleinst mogelijke ondeelbare eenheid van programmauitvoering. Het percentage van uitvoerbare programmaregels die zijn uitgevoerd door een testset. Een „white-box‟ testspecificatietechniek waarmee testgevallen ontworpen worden om programmaregels uit te voeren. Analyse van softwareproducten, bijv. eisen of code, gedaan zonder deze softwareproducten uit te voeren. Zie: static code analyzer – (statische analyse software). Een softwareproduct dat statische analyse uitvoert.

Engelse term

Nederlandse term

Omschrijving

Static code analysis :

Statische codeanalyse: Statisch codeanalyse software:

Analyse van broncode zonder dat de software wordt uitgevoerd.

Static code analyzer: Static testing:

Statisch testen:

Statistical testing:

Statistische test:

Status accounting:

Status bijhouden:

Storage: Storage testing: Stress testing:

Opslag: Opslagtest: Duurtest:

Stress testing tool: Structure based testing:

Duurtest-tool: Struktuurgebaseerde test: Structuur gebaseerde techniek: structurele dekking:

Structure-based technique: Structural coverage: Structural test design technique:

Stub:

Structurele testspecificatietechniek: Structureel testen: Gestructureerd doorlopen: Stub:

Sub path: Suitability:

Subpad: Toepasbaarheid:

Suspension criteria:

Opschortingscriteria:

Syntax testing:

Syntaxtest:

System:

Systeem:

System of systems:

Systeem van systemen:

Structural testing: Structured walkthrough:

Pagina 33 van 42

Een softwareproduct dat statische code-analyse uitvoert. Het softwareproduct controleert broncode op bepaalde eigenschappen zoals het volgen van codeerstandaarden, kwaliteitsmetrieken of afwijkingen in de gegevensstroom. Testen van een component of systeem op specificatie- of implementatieniveau, zonder die software uit te voeren, bijv. review of statische code analyse. Een testspecificatietechniek waarin een model van de statistische verdeling van de invoer gebruikt wordt om representatieve testgevallen te construeren. Zie ook: operational profile testing – (operationele profieltest). Een onderdeel van configuratiebeheer, dat bestaat uit het vastleggen en rapporteren van informatie die nodig is om een configuratie effectief te beheren. Deze informatie bevat onder meer de overeengekomen configuratie identificatie, de status van voorgestelde wijzigingen aan de configuratie en de (implementatie) status van overeengekomen veranderingen. [IEEE 610]. Zie: resource utilization – (middelengebruik). Zie: resource utilization testing – (middelengebruikstest). Performancetesttype die erop gericht is om een component of systeem te evalueren op of over de grenzen van de daarvoor verwachte of gespecificeerde werkbelasting, of met beperkte beschikbaarheid van middelen zoals geheugentoegang of servers. [IEEE 610]. Zie ook: performance testing – (performancetest) load testing – (belastbaarheidstest). Een tool dat duurtesten ondersteunt. Zie: White-box testing – (White-box test). Zie: White-box test design technique – (‘White-box’ test specificatietechniek). Metingen gebaseerd op de interne structuur van een component of systeem die de mate van dekking aangeven. Zie: White-box test design technique – (‘White-box’ testspecificatietechniek). Zie: White-box testing – (‘White-box’ test). Zie: walkthrough – (doorlopen). Een minimale of specifieke implementatie van een softwarecomponent, gebruikt om een component te ontwikkelen of te testen die de stub aanroept of er op een andere manier van afhankelijk is. Het vervangt een aan te roepen component. [Naar IEEE 610]. Een reeks van uitvoerbare programmaregels binnen een component. Het vermogen van een softwareproduct om in een geschikte verzameling van functies voor specifieke taken en gebruikersdoelen te voorzien. [ISO 9126]. Zie ook: functionality – (functionaliteit). De criteria die gebruikt worden om (tijdelijk) alle of een deel van de testactiviteiten op testonderdelen te stoppen. [Naar IEEE 829]. Een functionele („black box‟) testspecificatietechniek waarmee testgevallen ontworpen worden gebaseerd op de definitie van het invoerdomein en / of uitvoerdomein. Een groep componenten opgezet om een specifieke functie of groep van functies tot stand te brengen. Meerdere heterogene gedistribueerde systemen die in een netwerk hangen en op meerdere niveaus en domeinen verbonden zijn, zich richtend op grootschalige interdisciplinaire algemene problemen en doelen.

Engelse term

Nederlandse term

Omschrijving

System integration testing: System testing:

Systeemintegratietest: Systeemtest:

Testen van de integratie van systemen en onderdelen, testen van koppelingen naar externe organisaties (bijv. electronische data uitwisseling, Internet). Het proces van het testen van een geïntegreerd systeem om te verifiëren dat het aan de gespecificeerde eisen voldoet. [Hetzel].

Technical review:

Technische review:

Test: Test approach:

Test: Testaanpak:

Test automation:

Testautomatisering:

Een groepsdiscussie met collega's die gericht is op het bereiken van consensus over de te nemen inhoudelijke aanpak. [Gilb and Graham, IEEE 1028]. Zie ook: peer review – (collegiale review). Een verzameling van één of meer testgevallen. De implementatie van een teststrategie voor een specifiek project. Specifiek omvat het de genomen beslissingen die volgen op basis van het doel van het (test-)project en de uitgevoerde risicoanalyse, uitgangspunten van het testproces, de toe te passen testspecificatietechnieken, uitgangscriteria, en uit te voeren testtypen. Het gebruik van software om test activiteiten uit te voeren of te ondersteunen, bijv. testbeheer, testontwerp, testuitvoering en het controleren van de resultaten.

Test basis:

Testbasis:

Test bed: Test case:

Testbedding: Testgeval:

Test case design technique: Test case specification:

Testgeval specificatietechniek: Testgevalspecificatie:

Test case suite: Test charter:

Testgevallenreeks: Testhandvest:

Test closure:

Testafronding:

Test comparator:

Testvergelijkingspro gramma: Testvergelijking:

T

Test comparison:

Test completion criteria: Test condition:

Testvoltooingscriteria: Testconditie:

Pagina 34 van 42

Alle documenten waarvan de eisen voor een component of systeem kunnen worden afgeleid. Op deze documentatie zijn de testgevallen gebaseerd. Als een document alleen gewijzigd kan worden volgens een formele wijzigingsprocedure, dan wordt de test basis een „bevroren test basis‟ genoemd. [Naar TMap®]. Zie: test environment – (test omgeving). Een verzameling van invoerwaarden, voorwaarden voor uitvoering, verwachte resultaten en voorwaarden na uitvoering, ontwikkeld voor een bepaald doel of testconditie, zoals het uitvoeren van een bepaald programmapad of om te verifiëren of aan een specifieke eis is voldaan. [Naar IEEE 610]. Zie: test design technique – (test specificatie techniek). Een document dat een verzameling testgevallen (doelstelling, invoer, acties, verwachte resultaten, en voorwaarden voor uitvoer) specificeert voor een testonderdeel. [Naar IEEE 829]. Zie: test suite – (testset). Een vastlegging van testdoelstellingen en mogelijk ideeën over een testaanpak. Testhandvesten worden gebruikt bij onderzoekend testen. Zie ook: exploratory testing – (onderzoekend testen). Tijdens de afrondingsfase van een test proces worden gegevens verzameld van de voltooide activiteiten om ervaringen, testware, feiten en cijfers te consolideren. De testafrondingsfase bestaat uit het afronden en archiveren van de testware en uit het evalueren van het testproces, inclusief de voorbereiding van het testevaluatierapport. Zie ook: test process – (testproces). Een test-tool om een geautomatiseerde testvergelijking uit te voeren tussen de eigenlijke- en werkelijke resultaten. Het proces van identificeren van verschillen tussen de werkelijke resultaten geproduceerd door de geteste component of het systeem en de verwachte resultaten voor een test. Testvergelijking kan tijdens testuitvoering (dynamische vergelijking) of na testuitvoering gedaan worden. Zie: exit criteria – (uitgangscriteria). Een onderdeel of gebeurtenis van een component of systeem dat geverifieerd zou kunnen worden door één of meer testgevallen, bijv. een functie, transactie, eigenschap, kwaliteitsattribuut of structureel element.

Engelse term

Nederlandse term

Omschrijving

Test control:

Testbeheer:

Test coverage: Test cycle:

Testdekking: Testcyclus:

Test data:

Testgegevens:

Test data preparation tool:

Testgegevens voorbereidings-tool:

Test design:

Test ontwerp:

Test design specification:

Testontwerpspecific atie:

Test design technique:

Testspecificatietechniek: Testontwerp-tool:

Een testbeheerstaak die er voor zorgt dat een aantal maatregelen ontwikkeld en toegepast wordt om het testproject op koers te krijgen wanneer de projectbewaking een afwijking aantoont t.o.v. wat was gepland. Zie ook: test management – (test management). Zie: coverage – (dekking). Uitvoering van het testproces op een afzonderlijk te identificeren vrijgave van een testobject. Gegevens die beschikbaar zijn (b.v. in een database) voordat een test wordt uitgevoerd, en die de geteste component of het systeem beïnvloeden of er door beïnvloed worden. Een type test-tool dat het mogelijk maakt dat gegevens geselecteerd worden uit een bestaande database of gecreëerd, gegenereerd, gemanipuleerd of gewijzigd worden voor gebruik in testen. (1) Zie: Test design specification – ( testontwerpspecificatie). (2) Het proces om algemene testdoelen om te zetten naar concrete testcondities en testgevallen. Een document dat de testcondities (dekkingonderdelen) voor een testonderdeel en de gedetailleerde testaanpak specificeert en dat de gerelateerde logische testgevallen identificeert. [Naar IEEE 829]. Een procedure die gebruikt wordt om testgevallen af te leiden en / of te selecteren. Een tool dat ondersteuning biedt bij de testontwerpactiviteit door testinvoer te genereren op basis van een specificatie die mogelijk in een CASE-tool is opgeslagen, bijv. een eisenbeheer-tool, op basis van de gespecificeerde testcondities opgeslagen in het tool zelf, of van de code. Zie: driver – (stuurprogramma). Een manier om software te ontwikkelen waarbij de testgevallen worden ontwikkeld, en vaak geautomatiseerd, voordat de software is ontwikkeld om de testgevallen uit te voeren. Een omgeving die hardware, instrumentatie, simulatoren, softwareprogramma‟s en andere ondersteunende elementen bevat die nodig zijn om een test uit te voeren. [Naar IEEE 610]. De berekende benadering van een resultaat (bijvoorbeeld: gedane inspanning, afrondingsdatum, benodigde kosten, aantal testgevalen, etc.) welke bruikbaar is, zelfs als de invoergegevens onvolledig, onzeker of onzuiver zijn. Een document dat aan het eind van het testproces geproduceerd wordt en waarin alle testactiviteiten en -resultaten zijn samengevat. Het bevat ook een evaluatie van het testproces en de geleerde lessen. Het proces van het uitvoeren van een test op de geteste component of het systeem, waarbij werkelijke resultaten worden geproduceerd. Het gebruik van software, bijv. opname- / weergave-tools, om de uitvoering van testen, de vergelijking van de werkelijke uitkomsten met de verwachte resultaten, de opzet van precondities en voor andere testmanagement en rapportagefuncties te beheren. De periode binnen een softwareontwikkellevenscyclus waarin de componenten van een softwareproduct worden uitgevoerd en waarin een softwareproduct wordt geëvalueerd om vast te stellen of het voldoet aan de eisen. [IEEE 610]. Een draaiboek voor de uitvoering van testprocedures. De testprocedures worden opgenomen in het testdraaiboek in de context en volgorde waarin ze uitgevoerd moeten worden. De methode die gebruikt wordt om de test uit te voeren, handmatig of geautomatiseerd. Een test-tool dat gebruikt kan worden om andere software uit te voeren, gebruikmakend van een geautomatiseerd testscript, b.v. opname / weergave. [Fewster en Graham]. Zie: fail – (falen).

Test design tool:

Test driver: Test driven development:

Testdriver: Test gedreven ontwikkeling:

Test environment:

Testomgeving:

Test estimation:

Testschatting:

Test evaluation report:

Testevaluatierapport:

Test execution:

Testuitvoering:

Test execution automation:

Testuitvoering automatisering:

Test execution phase:

Testuitvoeringsfase:

Test execution schedule:

Testdraaiboek:

Test execution technique: Test execution tool:

Testuitvoeringstechniek: Testuitvoerings-tool:

Test fail:

Testfout:

Pagina 35 van 42

Engelse term

Nederlandse term

Omschrijving

Test generator: Test leader: Test harness:

Testgenerator: Testleider: Testraamwerk:

Test incident: Test incident report: Test implementation:

Testbevinding: Testbevindingenrapport: Testimplementatie:

Zie: test data preparation tool – (testgegevens voorbereidings-tool). Zie: test manager – (testmanager). Een testomgeving, bestaand uit stubs en drivers, die nodig is om een test uit te voeren. Zie: incident – (bevinding). Zie: incident report – (bevindingenrapport).

Test infrastructure:

Testinfrastructuur:

Test input:

Testinvoer:

Test item:

Testonderdeel:

Test item transmittal report: Test leader: Test level:

Testonderdeel overdrachtsrapportage: Testleider: Testsoort:

Test log:

Testlogboek:

Test logging:

Testvastlegging:

Test manager:

Testmanager:

Test management:

Testmanagement:

Test management tool:

Testmanagementtool:

Test Maturity Model (TMM):

Test Maturity Model (TMM):

Test Maturity Model Integrated (TMMi):

Test Maturity Model Integrated:

Test monitoring:

Testmonitoring:

Test object:

Testobject:

Test objective: Test oracle:

Testdoel: Testvraagbaak:

Test outcome: Test pass:

Testresultaat: Geslaagd:

Pagina 36 van 42

Het proces van ontwikkeling en prioritering van testprocedures, maken van testdata en optioneel de voorbereiding van een testraamwerk en het maken van geautomatiseerde testscripts. De organisatorische benodigdheden voor het uitvoeren van een test, bestaand uit testomgevingen, testtools, werkplekken en procedures. De gegevens die tijdens de testuitvoering door het testobject ontvangen worden van een externe bron. De externe bron kan hardware, software of een persoon zijn. Een individueel onderdeel dat getest moet worden. Normaal gesproken is er één testobject en zijn er meerdere testonderdelen. Zie ook: test object – (testobject). Zie: release note – (opleveringsdocument). Zie: test manager – (testmanager). Een groep testactiviteiten die gezamenlijk georganiseerd en beheerd worden. Een testsoort wordt gekoppeld aan de verantwoordelijkheden in een project. Voorbeelden van testsoorten zijn de componenttest, integratietest, systeemtest en acceptatietest. [Naar TMap®]. Een chronologische vastlegging van relevante details over de testuitvoering. [IEEE 829]. Het proces van het vastleggen van details over de testuitvoering in een testlogboek. De persoon die verantwoordelijk is voor het projectbeheer van testactiviteiten en hulpbronnen, en het evalueren van een testobject. De persoon die de evaluatie van een testobject stuurt, beheerst, plant en bijstelt. Het plannen, begroten, monitoren en beheersen van testactiviteiten; dit zijn typerende werkzaamheden van een testmanager. Een tool dat hulp biedt bij het testmanagement en beheersen van een testproces. Het heeft vaak meerdere mogelijkheden, denk aan testware beheer, het plannen van tests, het vastleggen van resultaten, voortgangsbeheer, bevindingenbeheer en testrapportage. Een model voor testprocesverbetering bestaand uit vijf getrapte niveaus, gerelateerd aan het Capability Maturity Model (CMM). Het model beschrijft de belangrijkste elementen van een effectief testproces. Een model voor testprocesverbetering bestaand uit vijf faseniveaus, gerelateerd aan het Capability Maturity Model Integrated (CMMi). Het model beschrijft de belangrijkste elementen van een effectief testproces. Een testmanagement taak die bestaat uit het periodiek bekijken van de status van een testproject. Rapporten worden samengesteld die bestaan uit het vergelijken van de werkelijke stand van zaken met de geplande. Zie ook: test management – (test management). Een component of systeem dat getest moet worden. Zie ook: test item – (testonderdeel). De reden of doel voor het ontwerpen en uitvoeren van een test. De bron om de te verwachten resultaten te bepalen waarmee de actuele testresultaten vergeleken kunnen worden. De vraagbaak kan een bestaand systeem zijn (voor een benchmark), een gebruikershandboek, of de gespecialiseerde kennis van iemand, maar in geen geval de code. [Naar Adrion]. Zie: result – (resultaat). Zie: pass – (geslaagd).

Engelse term

Nederlandse term

Omschrijving

Test performance indicator:

Test voortgangsindicatie:

Test phase:

Testfase:

Test plan:

Testplan:

Test planning: Test policy:

Testplanning: Testbeleid:

Test Point Analysis (TPA): Test procedure: Test procedure specification:

TestPunt Analyse (TPA): Testprocedure: Testprocedurespecificatie:

Test process:

Testproces:

Test Process Improvement (TPI):

TestProcesVerbeteri ng (TPI):

Test progress report:

Testvoortgangsrapportage:

Test record: Test recording: Test reproducibility:

Test result: Test schedule:

Testlogboek: Testverslaglegging: Testreproduceerbaarheid: Testrapport: Testeis: Testinstallatie: Testuitvoering: Testuitvoeringslogboek: Testresultaat: Testschema:

Een maat op een hoger niveau met betrekking tot de effectiviteit en / of efficiëntie die wordt gebruikt om de verdere testontwikkeling te sturen. B.v. Defect Detection Percentage (DDP). Een afgebakende verzameling van bij elkaar horende testactiviteiten samengevoegd tot een beheersbare fase in een project b.v. de uitvoering van activiteiten binnen een testsoort. [Naar Gerrard]. Een document dat de afbakening, de aanpak, de hulpmiddelen en de planning van de testactiviteiten beschrijft. Het beschrijft o.a. de testelementen, de te testen aspecten, de testtaken, wie welke taak uit zal voeren, niveau van onafhankelijkheid van de tester, de testomgeving, de testspecificatietechnieken en de ingangs- en uitgangscriteria en de beweegredenen voor die keuze, en de risico‟s die noodscenario‟s behoeven. Het is het eindresultaat van het testplanningproces. [Naar IEEE 829]. De activiteit waarin een testplan wordt opgesteld of bijgewerkt. Een hoog niveau document waarin is beschreven welke principes worden gehanteerd, voor welke aanpak is gekozen, en wat de belangrijkste doelstellingen zijn binnen de organisatie met betrekking tot het testen. Een op rekenkundige schattingsmethode gebaseerd op functiepuntanalyse. [TMap®]. Zie: test procedure specification – (testprocedurespecificatie). Een document waarin de volgorde waarin activiteiten van een test uitgevoerd dienen te worden is opgenomen. Ook bekend onder de naam testscript of handmatig testscript. [Naar IEEE829]. Het fundamentele testproces omvat alle activiteiten voor planning en beheer, testanalyse en specificatie, testimplementatie en -uitvoering, het evalueren van uitgangscriteria, voorgangscontrole en afronding. Een continu raamwerk voor het verbeteren van het testproces waarin de belangrijkste elementen van een effectief testproces worden beschreven speciaal toegespitst op systeem- en acceptatietesten. Een document dat testactiviteiten en –resultaten samenvat, gemaakt met regelmatige tussenpozen, dat rapporteert over de voortgang van testactiviteiten tov. een basis (zoals het orginele testplan) en dat gebruikt wordt als communicatie van risico‟s en alternatieven waarvoor een managementbeslissing vereist is. Zie: testlog – (testlogboek). Zie: test logging – (testvastlegging). Een eigenschap van een test die aangeeft of iedere keer dat de test wordt uitgevoerd hetzelfde resultaat wordt geproduceerd. Zie: test summary report – (rapport testsamenvatting). Zie: test condition – (tesconditie). Zie: test environment – (testomgeving). Uitvoering van een test op een specifieke versie van een testobject. Zie: test log – (testlogboek).

Test scenario: Test script:

Testscenario: Testscript:

Test session:

Testsessie:

Test report: Test requirement: Test rig: Test run: Test run log:

Pagina 37 van 42

Zie: result – (resultaat). Een serie activiteiten, taken of gebeurtenissen van het testproces die de gewenste start- en einddatum en / of –tijd en onderlinge afhankelijkheden identificeren. Zie: test procedure specification – (testprocedurespecificatie). Wordt gewoonlijk gebruikt om te refereren aan een testprocedure specificatie, meestal een geautomatiseerde testprocedure. Een ononderbroken tijdsperiode waarbinnen testen worden uitgevoerd. Tijdens onderzoekend testen is iedere testsessie gebaseerd op een charter, maar testers kunnen ook nieuwe mogelijkheden of bevindingen tijdens een sessie onderzoeken. De tester creëert en voert testgevallen gaandeweg uit en legt de voortgang vast. Zie: exploratory testing – (onderzoekend testen).

Engelse term

Nederlandse term

Omschrijving

Test set: Test situation: Test specification: Test specification technique: Test stage: Test strategy:

Testset: Testsituatie: Testspecificatie of testontwerp: Testspecificatie techniek: Testsoort: Teststrategie:

Zie: test suite – (testset). Zie: test condition – (testconditie) Een document waarin de testspecificaties, de testgevallen en / of de testprocedures beschreven worden. Zie: test design technique – (testspecificatietechniek).

Test suite:

Testset:

Test summary report:

Rapport testsamenvatting:

Test target: Test technique: Test tool:

Testdoelstelling: Testtechniek: Test-tool:

Test type:

Testtype:

Testability:

Testbaarheid:

Testability review:

Testbaarheidsreview:

Testable requirements:

Testbare eisen:

Tester:

Tester:

Testing:

Testen:

Testware:

Testware:

Thread testing:

Procestest:

Time behaviour:

Tijdgedrag:

Pagina 38 van 42

Zie: test level – (testsoort). Een beschrijving op metaniveau van de testsoorten die uitgevoerd moeten worden alsmede hoe de tests binnen de testsoort moeten worden uitgevoerd voor een organisatie of een programma (wanneer sprake is van één of meerdere projecten). Een verzameling testgevallen die op een component of te testen systeem worden losgelaten, waarbij de eindstatus van de ene test vaak gebruikt wordt als startconditie voor een volgende test. Een document waarin de testactiviteiten en testresultaten zijn samengevat. Het bevat ook de evaluatie van de testgevallen ten opzichte van de uitgangscriteria. [Naar IEEE 829]. Een set uitgangscriteria. Zie: test design technique – (testspecificatietechniek). Een computerprogramma dat één of meer testactiviteiten ondersteunt zoals planning en beheer, het specificeren, het opbouwen van initiële bestanden en gegevens, het uitvoeren van de test en testanalyse. [TMap®]. Zie ook: CAST – (CAST). Een verzameling testactiviteiten met als doelstelling het testen van een component of systeem op een of meer gerelateerde kwaliteitsattributen. Een testtype wordt meestal toegespitst op een specifiek testdoel zoals betrouwbaarheid, bruikbaarheid, regressie enz., en kan plaatshebben binnen meerdere testsoorten of testfasen. [Naar TMap®]. Het vermogen van een softwareproduct om gewijzigde delen te laten testen. [ISO9126]. Zie ook: maintainability – (onderhoudbaarheid). Een uitgebreide controle op de testbasis om te bepalen of de testbasis van een adequaat kwaliteitsniveau is om als een invoerdocument voor het testproces te dienen. [Naar TMap®]. De mate waarin een eis is opgesteld in termen die het mogelijk maken een testontwerp (en de daarop volgende testgevallen) op te stellen en tests uit te voeren, om vast te stellen dat inderdaad aan de eis is voldaan. [Naar IEEE610]. Een toegeruste professional die zich bezighoudt met het testen van een component of systeem. Het proces bestaande uit alle levenscyclusactiviteiten, zowel statisch als dynamisch, die te maken hebben met planning, voorbereiding en evaluatie van softwareproducten en aanverwante zaken om aan te tonen dat ze aan de gespecificeerde eisen voldoen, om aan te tonen dat wordt voldaan aan de doelstelling en om fouten op te sporen. Producten die gedurende het testen worden vervaardigd benodigd voor het plannen, ontwerpen, en het uitvoeren van tests zoals documentatie, scripts, invoer, verwachte resultaten, opzet en afbouw procedures, bestanden, databases, omgeving en extra software of hulpprogramma‟s gebruikt tijdens het testen. [Naar Fewster en Graham]. Een variant van een component integratie test waarbij de gestaag vorderende integratie van componenten volgt op de implementatie van onderdelen van de eisen in tegenstelling tot de integratie van componenten op hiërarchische basis. Zie: performance – (performance).

Engelse term

Nederlandse term

Omschrijving

Top-down testing:

Top-down test:

Traceability:

Traceerbaarheid:

Een incrementele benadering van de integratietest, waar de component aan de bovenkant van de componentenhiërarchie als eerste wordt getest, terwijl componenten op een lager niveau door een stub worden gesimuleerd. De geteste componenten worden dan gebruikt om componenten op een lager niveau te testen. Het proces wordt herhaald tot de componenten op het laagste niveau zijn getest. Zie ook: integration testing – (integratietest). Het vermogen om gerelateerde onderdelen in documentatie en software, zoals eisen met bijbehorende tests te kunnen identificeren. Zie ook: horizontal traceability, vertical traceability – (horizontale traceerbaarheid, verticale traceerbaarheid).

U Understandability:

Begrijpelijkheid:

Unit: Unit testing: Unit test framework:

Programma: Programmatest: Programmatestraam werk:

Unreachable code: Usability:

Onbereikbare code: Bruikbaarheid:

Usability testing:

Bruikbaarheidstest:

Use case:

Use case:

Use case testing:

Use case test:

User acceptance testing:

Gebruikersacceptatietest: Gebruikersscenariotest: Gebruikerstest:

User scenario testing: User test:

Het vermogen van een softwareproduct om de gebruiker in staat te stellen om te begrijpen of de software geschikt is, en hoe het gebruikt kan worden voor de uitvoering van specifieke taken en condities [ISO 9126]. Zie ook: usability – (bruikbaarheid). Zie: component – (component). Zie: component testing – (componenttest). Een tool dat in een omgeving voorziet voor programma- of componenttesten, waarbinnen een component geisoleerd getest kan worden of met stubs en drivers. Het voorziet in andere ondersteuning voor de ontwikkelaar, zoals debugmogelijkheden. [Graham]. Code die niet aangeroepen kan worden en dus ook niet kan worden uitgevoerd. Het vermogen van een softwareproduct om door de gebruiker begrepen, eenvoudig te leren, te gebruiken en aantrekkelijk te zijn binnen de gespecificeerde omstandigheden. [ISO 9126]. Het testproces om de mate te bepalen waarin de gebruikers een softwareproduct begrijpen, gemakkelijk leren, gemakkelijk mee te werken en aantrekkelijk vinden in de gespecificeerde omstandigheden. [Naar ISO 9126]. Een opeenvolging van transacties in een dialoog tussen een gebruiker en het systeem met een tastbaar resultaat. Een „black box‟ testspecificatietechniek waarin de testgevallen worden ontworpen om gebruikersscenario's uit te voeren. Zie: acceptance testing – (acceptatietest). Zie: use case testing – (use case test). Een test waarbij echte gebruikers betrokken zijn om de bruikbaarheid van een component of systeem te beoordelen.

V V-model:

V-model:

Validation:

Validatie:

Variable:

Variabele:

Pagina 39 van 42

Een kader om de activiteiten van de softwareontwikkellevenscyclus van specificatie van eisen tot en met onderhoud te beschrijven. Het V-Model illustreert hoe de testactiviteiten in elke fase van de softwareontwikkellevenscyclus kunnen worden geïntegreerd. Bewijs door onderzoek en door aanleveren van objectief bewijsmateriaal dat aan de eisen ten aanzien van een specifiek voorgenomen gebruik of van een toepassing is voldaan. [ISO 9000]. Een opgeslagen element in een computer dat door een softwareprogramma toegankelijk is door er met een naam naar te verwijzen.

Engelse term

Nederlandse term

Omschrijving

Verification:

Verificatie:

Vertical traceability:

Verticale traceerbaarheid: Versiebeheer: Volumetest:

Bewijs door onderzoek en door aanleveren van objectief bewijsmateriaal dat aan de gespecificeerde eisen is voldaan. [ISO 9000]. Het traceren van eisen door de niveaus van ontwikkelingsdocumentatie heen tot aan de componenten. Zie: configuration control – (configuratiebeheer). Testen waarbij het systeem met grote volumes gegevens wordt belast. Zie ook: resource utilization testing – (brongebruiktest).

Version control: Volume testing:

W Walkthrough:

Doorlopen:

White-box technique:

White-box testing:

‘White-box’ techniek: ‘White-box’ testspecificatietechniek: ‘White-box’ test:

Wide Band Delphi:

Wide Band Delphi:

Wild pointer:

Vrije pointer:

White-box test design technique:

Pagina 40 van 42

Een stapsgewijze presentatie van een document door de auteur om informatie te verzamelen en een gemeenschappelijk begrip over de inhoud van het document te krijgen. [Freedman en Weinberg, IEEE 1028 ]. Zie ook: peer review – (collegiale review). Zie: white-box test design technique – (‘White-box’ testspecificatie-techniek). Procedure om testgevallen af te leiden en / of te selecteren gebaseerd op een analyse van de interne structuur van een component of een systeem. Testen gebaseerd op de analyse van de interne structuur van een component of systeem. Een testbegrotingstechniek die tot doel heeft om met behulp van de collectieve ervaring van de teamleden een nauwkeurige begroting te maken. Een pointer die verwijst naar een locatie buiten het bereik van die pointer of die niet bestaat. Zie ook: pointer – (aanwijzer).

Bijlage A (Informatief) Index van bronnen; de volgende non-normatieve bronnen zijn gebruikt bij het samenstellen van deze verklarende woordenlijst: [Abbott]. J. Abbot (1986), Software Testing Techniques, NCC Publications. [Adrion]. W. Adrion, M. Branstad and J. Cherniabsky (1982), Validation, Verification and Testing of Computer Software, in: Computing Surveys, Vol. 14, No 2, June 1982. [Bach]. J. Bach (2004), Exploratory Testing, in: E. van Veenendaal, The Testing Practitioner – 2nd edition, UTN Publishing, ISBN 90-72194-65-9. [Beizer]. B. Beizer (1990), Software Testing Techniques, van Nostrand Reinhold, ISBN 0-442-20672-0. [Chow]. T. Chow (1978), Testing Software Design Modelled by Finite-State Machines, in: IEEE Transactions on Software Engineering, Vol. 4, No 3, May 1978. [CMM]. M. Paulk, C. Weber, B. Curtis and M.B. Chrissis (1995), The Capability Maturity Model, Guidelines for Improving the Software Process, Addison-Wesley, ISBN 0-201- 54664-7. [CMMI]. M.B. Chrissis, M. Konrad and S. Shrum (2004), CMMI, Guidelines for Process Integration and Product Improvement, Addison Wesley, ISBN 0-321-15496-7. [Fenton]. N. Fenton (1991), Software Metrics: a Rigorous Approach, Chapman & Hall, ISBN 0-53249-425-1. [Fewster and Graham]. M. Fewster and D. Graham (1999), Software Test Automation, Effective use of test execution tools, Addison-Wesley, ISBN 0-201-33140-3. [Freedman and Weinberg]. D. Freedman and G. Weinberg (1990), Walkthroughs, Inspections and Technical Reviews, Dorset House Publishing, ISBN 0-932633-19-6. [Gerrard]. P. Gerrard and N. Thompson (2002), Risk-Based E-Business Testing, Artech House Publishers, ISBN 1-58053-314-0. [Gilb and Graham]. T. Gilb and D. Graham (1993), Software Inspection, Addison-Wesley, ISBN 0-201-63181-4. [Grochtmann]. M. Grochtmann (1994), Test Case Design Using Classification Trees, in: Conference Proceedings STAR 1994. [Hetzel]. W. Hetzel (1988), The complete guide to software testing – 2nd edition, QED Information Sciences, ISBN 0-89435-242-3. [McCabe]. T. McCabe (1976), A complexity measure, in: IEEE Transactions on Software Engineering, Vol. 2, p. 308-320. [Musa]. J. Musa (1998), Software Reliability Engineering Testing, McGraw-Hill Education, ISBN 0-07913-271-5. [Myers]. G. Myers (1979), The Art of Software Testing, Wiley, ISBN 0-471-04328-1. [TMap®]. M. Pol, R. Teunissen, E. van Veenendaal (2002), Software Testing, A guide to the TMap Approach, Addison Wesley, ISBN 0-201-745712. [Veenendaal]. E. van Veenendaal (2004), The Testing Practitioner – 2nd edition, UTN Publishing, ISBN 90-72194-65-9.

Pagina 41 van 42

Bijlage B (Methode om commentaar op deze woordenlijst aan te leveren) Geef vooral commentaar op dit document, zodat deze woordenlijst verder verbeterd kan worden om te voldoen aan de testgemeenschap. Wanneer er commentaar wordt aangeleverd, zorg ervoor dat de volgende informatie aanwezig is:  Uw naam en contactgegevens;  Het versienummer van de woordenlijst (nu v2.0);  Exact gedeelte van de woordenlijst (paginanummer en desbetreffende woorden;  Ondersteunende informatie, zoals de reden waarom een wijziging gewenst is, of de referentie naar het gebruik van een definitie. U kunt commentaar op verschillende wijzen aanleveren, welke in gewenste volgorde zijn: 1. Email: [email protected]; 2. Post: Improve Quality Services BV, t.a.v. Mr. E. van Veenendaal, Waalreseweg 39, 5554 HA, Valkenswaard, Nederland; 3. FAX: +31 40 20 21450, t.a.v. Mr. E. van Veenendaal.

Pagina 42 van 42