1. belang van testen illustreren [1]
2. benoemen van eenduidige requirements en acceptatiecriteria [1]
3. vertalen van requirements naar acceptatiecriteria [1]
4. uitleggen wat SMART requirements en acceptatiecriteria zijn [1]
5. datakwaliteit becommentariëren [1]
6. kwaliteitsaspecten van proces- en organisatiekwaliteit becommentariëren [1]
7. uiteenzetten waarom de bedrijfsdoelen centraal staan bij testactiviteiten [2]
8. belang aantonen van compliance van het te testen object [2]
9. de rol van de business case in een project uiteenzetten [2]
10. kenmerken van verschillende testaanpakken en testframeworks benoemen [2]
11. benoemen van testactiviteiten bij de verschillende fasen van systeemontwikkeling [2]
12. het SmarTEST procesmodel uiteenzetten [2]
13. benoemen van SmarTEST testactiviteiten, fasering en testproducten [2]
14. herkennen waar in ontwikkeling en beheer testen een rol speelt [2]
15. beschrijven van het testbegrotingsmodel [2]
16. verschillen tussen ontwikkeltesten, systeemtesten en acceptatietesten uiteenzetten [2]
17. inrichtingsvormen van testorganisaties in de lijn en bij projecten uiteenzetten [2]
18. uiteenzetten wat het belang van toetsen en statisch testen is [2]
19. de rol van stakeholders en acceptanten in een testtraject uiteenzetten [2]
20. Benoemen wat exploratief testen is [2]
21. relevante kwaliteitsaspecten toepassen vanuit het testbeleid [3]
22. de begrippen systeemkwaliteit, informatiekwaliteit en proceskwaliteit beschrijven [3]
23. het testbeleid analyseren [3]
24. analyseren van de teststrategie [3]
25. hoofdtestsoorten beschrijven [4]
26. beschrijven van de aanpak van ketentesten [4]
27. interpreteren van performance-, load- en stresstest resultaten [4]
28. verschil tussen product- en projectrisico’s uitleggen [5]
29. inspecties, reviews en walkthroughs toepassen in de praktijk [5]
30. de spelregels en stappen van de Fagan inspectie en de SmartReview uitleggen [5]
31. het belang van een risicoanalyse uitleggen [5]
32. een eendimensionale en/of tweedimensionale risicoanalyse toepassen [5]
33. Testspecificaties opstellen op verschillende detailniveaus [6]
34. Technieken hanteren voor het opstellen van testscenario's en testgevallen [6]
35. Logische en fysieke testgevallen opstellen [6]
36. Uitleggen uit welke producten testware bestaat [6]
37. interpreteren van testbevindingen [7]
38. De werking van het loketmodel en monitoringmodel uitleggen [7]
39. de vier pijlers van SMART-rapporteren uiteenzetten [7]
40. beschrijven van testresultaten in een testrapport [7]
41. verklaren van testresultaten via de vrijgavekaart [7]
42. testplan opstellen en in praktijk brengen [8]
43. Functies van bevindingenbeheertools onderzoeken [8]
44. vergelijken van testtools [8]
45. analyseren van functies van testtools [8]
,SmarTEST
Goed opdrachtgeversschap
Transparant zijn
Vastleggen, open zijn
Goede communicatie tussen projectleden en opdrachtgever
Governance (goed bestuur)
Transparantie
Ethisch component
IT governance, zelfde alleen voor IT kant
Testen is een strategisch instrument voor risicobeheersing
Testen geeft inzicht in kwaliteit en voortgang
Business Case = rechtvaardiging van het project
Requirement = functionaliteit (wat een bepaald product of dienst zou moeten doen) maar ook manier
waarop deze functionaliteit geboden wordt (snelheid, betrouwbaarheid, gebruikersvriendelijkheid.
In een requirement worden de benodigde attributen, capaciteiten, karakteristieken of kwaliteiten van
een systeem geïdentificeerd.
Functionele requirements beschrijven specifiek gedrag of functies, die het systeem dient te
vervullen. Bijvoorbeeld het opmaken van een tekst of het moduleren van een signaal. Deze worden
ook wel capaciteiten genoemd. Wat het moet doen
Niet-functionele requirements specificeren criteria om het functioneren van het systeem te
beoordelen, maar beschrijven niet het specifieke gedrag zelf.
Deze niet-functionele requirements kunnen verder onderverdeeld worden in requirements betreffende
performance, onderhoud, veiligheid, betrouwbaarheid, of menig ander aspect. Hoe het zich gedraagd
Testen in samenhang met andere disciplines
SmarTEST gaat uit van nauwe samenwerking tussen zeven disciplines:
1. Initiatie - Plan, doel, kaders
2. Definities - Requirements-definitie en business-architectuur
3. Ontwerp - IT-architectuur en high-level ontwerp
4. Realisatie - Bouw en programmering
5. Controle - Systeem- en acceptatietesten, audits, reviews
6. Exploitatie - Beheer en performance management
7. Coördinatie - Projectmanagement
Productrisico’s Risico’s verbonden aan het eindresultaat
Risicobeheersing door testen is gericht op het eindproduct: dat wat erstaat als het project er niet meer
is
,Projectrisico’s Risico’s verbonden aan planning, voortgang, budget, politiek, people issues
etc.
Risico’s verbonden aan de projectvoering aan de processen in het project
Doel van testen is de beoordeling van het eindproduct op kwaliteit en risico’s
Acceptatiecriteria zijn meetbaar geformuleerde criteria voor het eindproduct
Driedeling van het testen van het eindproduct:
1. Informatie, de informatie en de gegevens die door het informatiesysteem verwerkt gaan
worden, moeten juist, volledig, tijdig beschikbaar, actueel en relevant zijn
2. Processen en Organisatie, de werkwijzen en procedures dienen goed ingeregeld te zijn. En
de organisatie, inclusief bemensing, moet hierop berekend zijn
3. Systeem, het opgeleverde informatiesysteem moet voldoen aan requirements en specificaties
en goed samenwerken met aanpalende systemen
Bevriezen van requiremnets is een achterhoedegevecht. Het gaat erom dat je ze kunt beheren.
We hebben nodig:
Actief beheerde set actuele requirements, in de taal van de opdrachtgever en acceptant.
Een hieraan gekoppelde, en eveneens door de acceptanten gedragen, set acceptatiecriteria
Een test- en toestproces dat berekend is op het hanteren van deze set criteria, inclusief
veranderingen
Kwaliteit is het voldoen aan beoogde doelen en aan expliciete en impliciete verwachtingen van de
balanghebbenden
Succes = Kwaliteit x Acceptatie
Mensen bepalen de kwaliteit. Kwaliteit leveren is mensenwerk, kwaliteit beoordelen ook. De
wisselwerking tussen systeem-informatie-processen is pas optimaal als de één het goed inricht en de
ander het goed ervaart.
Kromme van Boehm hoe later fouten worden ontdekt, des te groter de kosten van herstel zullen zijn
Bij kwaliteitszorg nadruk op preventie
Bij testen ligt de nadruk op evaluatie en correctie van gemaakte fouten
Optimum in de verdeling van de twee kostencomponenten:
1. Test- en preventiekosten
2. Herstelkosten en (commerciële) schade
, Kwaliteitsmodellen worden gebruikt bij het definiëren van requirements en bij de (acceptatie)testen.
Analisten en ontwerpers gebruiken de modellen om tot volledige requirements en compleet ontwerp te
komen. Testers gebruiken de modellen voor risicoanalyses en om de opgeleverde (tussen)producten
te controleren.
IPSmodel (referentiemodel voor productkwaliteit)
360 gradenperspectief op alle mogelijke succesfactoren van de IV
Referentiekader voor specificatie en beoordeling van producteigenschappen
ISO 9126 systeemkwaliteit model bevat het WAT
Deelmodel brengt de software- en systeemkant van het product in beeld
Zes kwaliteitskenmerken:
- Betrouwbaarheid
- Efficiëntie
- Overzetbaarheid
- Functionaliteit
- Bruikbaarheid
- Onderhoudbaarheid
IDQ (information and data quality) informatiekwaliteit model bevat het WAT
Als gegevensverzamelingen een belangrijk projectresultaat zijn. Toepassing: datawarehouse, CRM,
MIS, ERP
Kwaliteit en bruikbaarheid van een gegevensverzameling worden bepaald door drie dingen:
1. Inherente kwaliteit, fundamentele eigenschappen van de gegevens zelf
2. Kwaliteit van de meta-informatie, informatie over de informatie
3. Systeemkwaliteit, de kwaliteit en functionaliteit van het informatiesysteem waarin de informatie
is opgeslagen of waarmee de informatie wordt benaderd
IDQ model betreft aspect 1 en 2 , oftewel de kwaliteit van de gegevensverzameling zelf, inclusief de
daarin beschikbare meta-informatie. Aspect 3 valt onder het ISO9126 model voor softwarekwaliteit.
Zes kwaliteitskenmerken:
- Juistheid
- Tijdigheid
- Doeltreffendheid
- Exclusiviteit
- Controleerbaarheid
- Onderhoudbaarheid
POQ (proces and organization quality) proceskwaliteit model bevat het WAT
Omvat alle kwaliteitsaspecten van geautomatiseerde en niet-geautomatiseerde processen in
organisaties. De toegevoegde waarde van dit model hangt af van de mate waarin ook een stuk
procesinrichting gedefinieerd of getoetst moet worden. Concrete beoordeling van de Operationele
processen
Zes kwaliteitsaspecten:
2. benoemen van eenduidige requirements en acceptatiecriteria [1]
3. vertalen van requirements naar acceptatiecriteria [1]
4. uitleggen wat SMART requirements en acceptatiecriteria zijn [1]
5. datakwaliteit becommentariëren [1]
6. kwaliteitsaspecten van proces- en organisatiekwaliteit becommentariëren [1]
7. uiteenzetten waarom de bedrijfsdoelen centraal staan bij testactiviteiten [2]
8. belang aantonen van compliance van het te testen object [2]
9. de rol van de business case in een project uiteenzetten [2]
10. kenmerken van verschillende testaanpakken en testframeworks benoemen [2]
11. benoemen van testactiviteiten bij de verschillende fasen van systeemontwikkeling [2]
12. het SmarTEST procesmodel uiteenzetten [2]
13. benoemen van SmarTEST testactiviteiten, fasering en testproducten [2]
14. herkennen waar in ontwikkeling en beheer testen een rol speelt [2]
15. beschrijven van het testbegrotingsmodel [2]
16. verschillen tussen ontwikkeltesten, systeemtesten en acceptatietesten uiteenzetten [2]
17. inrichtingsvormen van testorganisaties in de lijn en bij projecten uiteenzetten [2]
18. uiteenzetten wat het belang van toetsen en statisch testen is [2]
19. de rol van stakeholders en acceptanten in een testtraject uiteenzetten [2]
20. Benoemen wat exploratief testen is [2]
21. relevante kwaliteitsaspecten toepassen vanuit het testbeleid [3]
22. de begrippen systeemkwaliteit, informatiekwaliteit en proceskwaliteit beschrijven [3]
23. het testbeleid analyseren [3]
24. analyseren van de teststrategie [3]
25. hoofdtestsoorten beschrijven [4]
26. beschrijven van de aanpak van ketentesten [4]
27. interpreteren van performance-, load- en stresstest resultaten [4]
28. verschil tussen product- en projectrisico’s uitleggen [5]
29. inspecties, reviews en walkthroughs toepassen in de praktijk [5]
30. de spelregels en stappen van de Fagan inspectie en de SmartReview uitleggen [5]
31. het belang van een risicoanalyse uitleggen [5]
32. een eendimensionale en/of tweedimensionale risicoanalyse toepassen [5]
33. Testspecificaties opstellen op verschillende detailniveaus [6]
34. Technieken hanteren voor het opstellen van testscenario's en testgevallen [6]
35. Logische en fysieke testgevallen opstellen [6]
36. Uitleggen uit welke producten testware bestaat [6]
37. interpreteren van testbevindingen [7]
38. De werking van het loketmodel en monitoringmodel uitleggen [7]
39. de vier pijlers van SMART-rapporteren uiteenzetten [7]
40. beschrijven van testresultaten in een testrapport [7]
41. verklaren van testresultaten via de vrijgavekaart [7]
42. testplan opstellen en in praktijk brengen [8]
43. Functies van bevindingenbeheertools onderzoeken [8]
44. vergelijken van testtools [8]
45. analyseren van functies van testtools [8]
,SmarTEST
Goed opdrachtgeversschap
Transparant zijn
Vastleggen, open zijn
Goede communicatie tussen projectleden en opdrachtgever
Governance (goed bestuur)
Transparantie
Ethisch component
IT governance, zelfde alleen voor IT kant
Testen is een strategisch instrument voor risicobeheersing
Testen geeft inzicht in kwaliteit en voortgang
Business Case = rechtvaardiging van het project
Requirement = functionaliteit (wat een bepaald product of dienst zou moeten doen) maar ook manier
waarop deze functionaliteit geboden wordt (snelheid, betrouwbaarheid, gebruikersvriendelijkheid.
In een requirement worden de benodigde attributen, capaciteiten, karakteristieken of kwaliteiten van
een systeem geïdentificeerd.
Functionele requirements beschrijven specifiek gedrag of functies, die het systeem dient te
vervullen. Bijvoorbeeld het opmaken van een tekst of het moduleren van een signaal. Deze worden
ook wel capaciteiten genoemd. Wat het moet doen
Niet-functionele requirements specificeren criteria om het functioneren van het systeem te
beoordelen, maar beschrijven niet het specifieke gedrag zelf.
Deze niet-functionele requirements kunnen verder onderverdeeld worden in requirements betreffende
performance, onderhoud, veiligheid, betrouwbaarheid, of menig ander aspect. Hoe het zich gedraagd
Testen in samenhang met andere disciplines
SmarTEST gaat uit van nauwe samenwerking tussen zeven disciplines:
1. Initiatie - Plan, doel, kaders
2. Definities - Requirements-definitie en business-architectuur
3. Ontwerp - IT-architectuur en high-level ontwerp
4. Realisatie - Bouw en programmering
5. Controle - Systeem- en acceptatietesten, audits, reviews
6. Exploitatie - Beheer en performance management
7. Coördinatie - Projectmanagement
Productrisico’s Risico’s verbonden aan het eindresultaat
Risicobeheersing door testen is gericht op het eindproduct: dat wat erstaat als het project er niet meer
is
,Projectrisico’s Risico’s verbonden aan planning, voortgang, budget, politiek, people issues
etc.
Risico’s verbonden aan de projectvoering aan de processen in het project
Doel van testen is de beoordeling van het eindproduct op kwaliteit en risico’s
Acceptatiecriteria zijn meetbaar geformuleerde criteria voor het eindproduct
Driedeling van het testen van het eindproduct:
1. Informatie, de informatie en de gegevens die door het informatiesysteem verwerkt gaan
worden, moeten juist, volledig, tijdig beschikbaar, actueel en relevant zijn
2. Processen en Organisatie, de werkwijzen en procedures dienen goed ingeregeld te zijn. En
de organisatie, inclusief bemensing, moet hierop berekend zijn
3. Systeem, het opgeleverde informatiesysteem moet voldoen aan requirements en specificaties
en goed samenwerken met aanpalende systemen
Bevriezen van requiremnets is een achterhoedegevecht. Het gaat erom dat je ze kunt beheren.
We hebben nodig:
Actief beheerde set actuele requirements, in de taal van de opdrachtgever en acceptant.
Een hieraan gekoppelde, en eveneens door de acceptanten gedragen, set acceptatiecriteria
Een test- en toestproces dat berekend is op het hanteren van deze set criteria, inclusief
veranderingen
Kwaliteit is het voldoen aan beoogde doelen en aan expliciete en impliciete verwachtingen van de
balanghebbenden
Succes = Kwaliteit x Acceptatie
Mensen bepalen de kwaliteit. Kwaliteit leveren is mensenwerk, kwaliteit beoordelen ook. De
wisselwerking tussen systeem-informatie-processen is pas optimaal als de één het goed inricht en de
ander het goed ervaart.
Kromme van Boehm hoe later fouten worden ontdekt, des te groter de kosten van herstel zullen zijn
Bij kwaliteitszorg nadruk op preventie
Bij testen ligt de nadruk op evaluatie en correctie van gemaakte fouten
Optimum in de verdeling van de twee kostencomponenten:
1. Test- en preventiekosten
2. Herstelkosten en (commerciële) schade
, Kwaliteitsmodellen worden gebruikt bij het definiëren van requirements en bij de (acceptatie)testen.
Analisten en ontwerpers gebruiken de modellen om tot volledige requirements en compleet ontwerp te
komen. Testers gebruiken de modellen voor risicoanalyses en om de opgeleverde (tussen)producten
te controleren.
IPSmodel (referentiemodel voor productkwaliteit)
360 gradenperspectief op alle mogelijke succesfactoren van de IV
Referentiekader voor specificatie en beoordeling van producteigenschappen
ISO 9126 systeemkwaliteit model bevat het WAT
Deelmodel brengt de software- en systeemkant van het product in beeld
Zes kwaliteitskenmerken:
- Betrouwbaarheid
- Efficiëntie
- Overzetbaarheid
- Functionaliteit
- Bruikbaarheid
- Onderhoudbaarheid
IDQ (information and data quality) informatiekwaliteit model bevat het WAT
Als gegevensverzamelingen een belangrijk projectresultaat zijn. Toepassing: datawarehouse, CRM,
MIS, ERP
Kwaliteit en bruikbaarheid van een gegevensverzameling worden bepaald door drie dingen:
1. Inherente kwaliteit, fundamentele eigenschappen van de gegevens zelf
2. Kwaliteit van de meta-informatie, informatie over de informatie
3. Systeemkwaliteit, de kwaliteit en functionaliteit van het informatiesysteem waarin de informatie
is opgeslagen of waarmee de informatie wordt benaderd
IDQ model betreft aspect 1 en 2 , oftewel de kwaliteit van de gegevensverzameling zelf, inclusief de
daarin beschikbare meta-informatie. Aspect 3 valt onder het ISO9126 model voor softwarekwaliteit.
Zes kwaliteitskenmerken:
- Juistheid
- Tijdigheid
- Doeltreffendheid
- Exclusiviteit
- Controleerbaarheid
- Onderhoudbaarheid
POQ (proces and organization quality) proceskwaliteit model bevat het WAT
Omvat alle kwaliteitsaspecten van geautomatiseerde en niet-geautomatiseerde processen in
organisaties. De toegevoegde waarde van dit model hangt af van de mate waarin ook een stuk
procesinrichting gedefinieerd of getoetst moet worden. Concrete beoordeling van de Operationele
processen
Zes kwaliteitsaspecten:
