ISTQB Foundation level. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V

ISTQB Foundation level Een introductie

Algemene informatie voor medewerkers van: SYSQA B.V.

Organisatie Titel Onderwerp

SYSQA B.V. ISTQB foundation Een introductie

Pagina Versie Datum

2 van 10 1.0 08-11-2006

Inhoudsopgave 1

INLEIDING............................................................................................................................... 3 1.1 1.2

2

ISTQB ONDERWERPEN ........................................................................................................ 4 2.1 2.2 2.3 2.4 2.5 2.6

3

ALGEMEEN........................................................................................................................ 3 VERSIEBEHEER ................................................................................................................. 3 DE FUNDAMENTEN VAN TESTEN .......................................................................................... 4 TESTEN TIJDENS HET SYSTEEMONTWIKKELINGSPROCES ...................................................... 5 STATISCHE TESTTECHNIEKEN............................................................................................. 7 TESTSPECIFICATIETECHNIEKEN .......................................................................................... 8 TESTMANAGEMENT............................................................................................................ 8 TESTTOOLS ...................................................................................................................... 8

LITERATUURVERWIJZINGEN ............................................................................................. 10

Almere © 2005

Quality Assurance in ICT



Pagina Versie Datum

3 van 10 1.0 08-11-2006

1 Inleiding 1.1

Algemeen

ISTQB, ook wel bekend als testen volgens ISEB, is niet ontwikkeld als een testmethodiek, maar als een verzameling definities en begrippen die van belang zijn bij het testproces. ISTQB staat voor International Software Testing Qualifications Board en is een groep testexperts die de syllabus hebben geschreven die de basis vormt voor het The Certified Tester Foundation Level in Software Testing, ook wel bekend als ISEB Foundation. De invloed van ISTQB en de bijbehorende certificering hebben het echter tot een dergelijk belangrijk begrip gemaakt dat het inmiddels niet raar is om te “testen volgens ISEB” Hiermee kan ISTQB worden gezien als testmethode. Deze introductie gaat in op ISTQB foundation niveau.

1.2 Versie 0.1

Versiebeheer Status Concept

Datum 11 augustus 2005

Almere © 2005

Auteur H.J.J. Cannegieter

Opmerkingen Eerste concept




Pagina Versie Datum

4 van 10 1.0 08-11-2006

2 ISTQB syllabus In de ISTQB-syllabus bestaat uit de volgende onderdelen: • De fundamenten van testen; • Testen tijdens het systeemontwikkelingsproces; • Statische testtechnieken; • Testontwerptechnieken; • Testmanagement; • Testtools.

2.1

De fundamenten van testen

In het Engels bestaan verschillende foutbegrippen (failure, fault en error) in het Nederlands hebben we het altijd over fouten. Er is een verschil tussen testen en debuggen. Testen heeft als doel fouten op systematische manier aan het licht te brengen, debuggen richt zich op het verwijderen van fouten. Het is onmogelijk, ondanks het testen, om foutloze applicaties te realiseren. Het testen dient tot verhoging van de software kwaliteit. Testen neemt een groot deel van de ontwikkelkosten in beslag. De testkosten moeten afhangen van de risico’s en de beoordeling van schade die verbonden is aan het optreden van mogelijke fouten. Het testproces bestaat uit vier fases: 1. Testplanning en beheersing; 2. Testanalyse en -ontwerp; 3. Testuitvoering; 4. Testafronding Voor een gestructureerd testproces is de testplanning van groot belang. Dit houdt de planning van resources in, maar ook het vaststellen van de teststrategie. Hieruit komen de te behalen dekkingsgraad, te gebruiken testtechnieken, de prioritering van testen en de inzet van testtools naar voren. Het vaststellen van een teststrategie wordt onderkend als één van de belangrijkste taken tijdens de testplanning. Omdat een volledige testonmogelijk is, moeten er eisen worden gesteld aan de hand van een risico inschatting. Risico’s worden onderverdeeld in productrisico’s en procesrisico’s. Afhankelijk van de kans op fouten en de mogelijke schade bij het optreden van een fout, moeten de testactiviteiten over de verschillende delen van het systeem worden verdeeld. Doel van de teststrategie is het verkrijgen van een optimale verdeling. Uit risicoanalyse en teststrategie wordt de te behalen dekkingsgraad per systeemdeel opgemaakt. Dit kan een van de acceptatiecriteria zijn, net als eisen van de klant. Bij de behandeling van de testsoorten wordt ook een aantal maal van teststrategie gesproken. Hiermee wordt echter de praktische aanpak van een bepaalde testsoort bedoeld, niet de complete teststrategie zoals wij die in het onderzoek voor ogen hebben. Testanalyse en -ontwerp gebeurt in twee fasen: opstellen van logische en van fysieke testgevallen. Naast testdata horen ook de randvoorwaarden voor uitvoering bij een testgeval. Om te beoordelen of een testgeval goed of fout is verlopen, moet er een resultaatvoorspelling worden opgesteld. Verwachte waarden zijn af te leiden uit de specificaties van het testobject en eventuele andere bronnen. Naast risico zijn er andere criteria voor prioritering van testgevallen, bijvoorbeeld door te kijken vanuit het gezichtspunt van de gebruiker of van de ontwikkelaar Na testanalyse en -ontwerp volgt de testuitvoering. Na het vinden en oplossen van een fout moet er een hertest plaatsvinden. Of er voldoende getest is, moet besloten worden aan de hand van de acceptatiecriteria die zijn opgenomen in het testscript. In de praktijk wordt echter vaak gestuurd op tijd en kosten. De testafronding omvat het conserveren van de testware en een evaluatie van het testproces.

Almere © 2005




Pagina Versie Datum

5 van 10 1.0 08-11-2006

In dit hoofdstuk worden algemene testprincipes behandeld, dit zijn: Principe 1. Testen toont de aanwezigheid van fouten aan. Door middel van testen kan aan worden getoond dat er fouten zijn, er kan met testen niet worden aangetoond dat er geen fouten zijn. Testen reduceert de waarschijnlijkheid dat er onontdekte fouten overblijven in de software maar, zelfs als er geen fouten meer gevonden worden is dit nog geen bewijs van de juistheid. Principe 2. Volledig testen is onmogelijk. Alles testen (alle combinaties van invoer en precondities) is niet uitvoerbaar (feasible) met uitzondering van triviale gevallen. In plaats van volledig testen wordt gebruik gemaakt van risico’s en prioriteiten om te bepalen waar de testinspanning op concentreert. Principe 3. Vroeg testen Testactiviteiten moeten zo vroeg mogelijk in de software- of systeemontwikkelcyslus testen en moet gericht zijn vastgestelde doelen. Principe 4. Foutclustering / foutgroepering / foutophoping Een klein aantal modules bevatten de meeste fouten die gevonden worden tijdens het testen voor vrijgave en bevatten de meeste operationele systeemfouten (failures). Principe 5. Pesticide paradox. Als dezelfde tests keer op keer herhaald worden, worden er uiteindelijk geen nieuwe bugs meer gevonden. Om tegemoet te komen aan de pesticide paradox moeten de testcases regelmatig gereviewd en vernieuwd worden en nieuwe en andere tests moeten opgesteld worden om verschillende delen van de software of systeem uit te voeren om zo mogelijk meer fouten te vinden. Principe 6. Testen is afhankelijk van de context. Testen wordt verschillend uitgevoerd in verschillende contexten. Bij voorbeeld, veiligheid-kritische systemen worden anders getest dan e-commerce sites. Principe 7. Afwezigheid-van-fouten bedrog Het vinden en herstellen van fouten helpt niet als het systeem dat gebouwd is onbruikbaar is of de behoeften en verwachtingen van de gebruikers niet vervult.

2.2

Testen tijdens het systeemontwikkelingsproces

Testen moet worden geïntegreerd in het ontwikkelingsproces. Het V-model toont hoe het testen wordt gecombineerd met ontwikkelen via de watervalmethode.

Almere © 2005




Pagina Versie Datum

Gebruikers eisen/wensen

6 van 10 1.0 08-11-2006

Acceptatietest

Systeem integratietest

Functioneel systeemontwerp

Systeemtest Technische systeemontwerp

Component integratietest

Componenten specificatie

Componenttest

Ontwikkeling

Verificatie beoordeelt de correctheid en volledigheid van een fase ten opzichte van de voorgaande fase. Dit zijn in de figuur de pijlen omhoog aan de linkerkant. Validatie beoordeelt of een deelproduct voor zijn oorspronkelijke doel bruikbaar en nuttig is. Dit zijn de pijlen middenin het figuur van de testsoorten naar de ontwikkelfases De testsoorten worden als volgt omschreven: Componententest Test voor het eerst systematisch de vervaardigde softwarecomponenten, onafhankelijk van elkaar. Er wordt getest op functionaliteit, robuustheid, efficiëntie, en onderhoudbaarheid. Er worden whitebox technieken toegepast. Componentintegratietest Is de tweede testsoort en test groepen van eerder geteste componenten die zijn geïntegreerd. Testdoel is het onthullen van fouten in de interfaces tussen componenten. Omdat niet alle componenten gelijktijdig gereed zijn, moet er een integratiestrategie worden bedacht. Systeemtest Test het volledig geïntegreerde systeem in een aparte testomgeving. Er wordt getest op basis van functionele eisen (gebruikerseisen) en niet-functionele eisen (load test, performance test, volume test, stress test, databeveiliging, stabiliteit, robuustheid, compatibiliteit, verschillende configuraties, bruikbaarheid en onderhoudbaarheid). Probleem bij de systeemtest is vaak de klanteneisen niet duidelijk zijn geformuleerd. Systeemintegratietest Omvat het testen van complete systemen in combinatie met externe systemen. Er wordt zoveel mogelijk gebruik gemaakt van een productielike acceptatietestomgeving. Ook hier worden weer fouten in interfaces ontdekt.

Almere © 2005




Pagina Versie Datum

7 van 10 1.0 08-11-2006

Acceptatietest Is een speciale soort systeemtest die test op contractuele acceptatie. Hij wordt uitgevoerd bij de klant. Regressietest. Na acceptatie van de eerste versie wordt in de loop der tijd vaak systeemonderhoud uitgevoerd en wordt het systeem verder ontwikkeld. Ook dan moet er getest worden. Naast het testen van gewijzigde systeemonderdelen, is een belangrijk middel hierbij de regressietest, waarbij onveranderde onderdelen worden getest. Naast de testsoorten worden de volgende testtypes onderkent: • Testen van functies (functioneel testen); • Testen van software product karakteristieken (niet-functioneel testen); • Testen van de software structuur / architectuur (structuur testen); • Testen met betrekking tot veranderingen (conformatie of regressietesten).

2.3

Statische testtechnieken

Bij statisch testen wordt de software zelf niet getest maar worden reviews of geautomatiseerde statische analyse uitgevoerd. Met behulp van reviews worden tussenproducten, inclusief code, getoetst zodat fouten in deze tussenproducten vroegtijdig worden gevonden. Dit kan ook geautomatiseerd met behulp van tools. De volgende fases worden onderkent bij een review: • Planning, het selecteren van reviewers, toewijzen van rollen, definiëren van entry en exit criteria en bepalen welk deel van het document beoordeeld wordt; • Kick off, het verspreiden van documenten, toelichten van de doelstellingen, het proces en de te reviewen documenten aan de deelnemers alsmede het checken of aan de entrycriteria is voldaan; • Individuele voorbereiding, het zoeken naar fouten door iedere reviewer; • Review meeting, discussie over en vastleggen van de bevindingen in een groepsmeeting; • Rework, het doorvoeren van verbeteringen in het gereviewde product op basis van de bevindingen; • Vervolg, vaststellen of de fouten goed zijn verwerkt, verzamelen van metrieken en vaststellen dat voldaan is aan de exitcriteria. De volgende rollen worden onderkent binnen het reviewproces: manager (beslissen dat een review plaats moet vinden, beschikbaarstellen tijd en vaststellen of de reviewdoelstellingen zijn gehaald), moderator (organiseert en leidt de review en zit de meeting voor), auteur (maker van het te reviewen product), reviewers (voeren de review daadwerkelijk uit door het vinden en bespreken van bevindingen) en de scribe (documenteert alle bevindingen tijdens de meeting). De volgende reviewvormen worden onderkent in volgorde van mate van formaliteit): • Informele review: review zonder formeel proces; • Walkthrough: informele review waarbij de auteur zijn document in de meeting aan de deskundigen presenteert; • Technische review: formele, gedocumenteerde review door deskundigen worden vooraf bij de moderator ingediend. • Inspectie: formele, gedocumenteerde review waarbij de voorbereiding gebeurt aan de hand van checklists. De meeting wordt door een moderator geleid en er worden metrics gegenereerd voor procesverbetering.

Almere © 2005



2.4


Pagina Versie Datum

8 van 10 1.0 08-11-2006

Testspecificatietechnieken

Testspecificatietechnieken worden gebruikt bij dynamisch testen. Meestal wordt onder testen verstaan: het uitvoeren van het testobject op een computer. Er is een aantal technieken dat voor het bepalen van testgevallen kunnen worden gebruikt. De testspecificatietechnieken kunnen in twee categorieën worden ingedeeld: black-box technieken, white-box technieken en op ervaring gebaseerde technieken. Black-box technieken beschouwen het testobject als een zwarte doos. Over de code en interne opbouw is geen informatie noodzakelijk. Het gedrag van het testobject wordt van buitenaf waargenomen. White-box technieken nemen ook inzicht in de code mee. Tijdens de uitvoer van de testgevallen wordt de interne uitvoer van het testobject geanalyseerd. De volgende black-box technieken worden onderkent: • Equivalentieklassen test • Grenswaarde analyse • Beslissingstabellen test • Status-transactietest • Use case test De volgende white-box technieken worden onderkent: • Statement testen en dekking; • Decision testen en dekking; • Condition testen en dekking; • Pad testen en dekking. De volgende op ervaring gebaseerde technieken worden onderkent: • Error guessing; • Exploratory testen

2.5

Testmanagement

Er zijn verschillende organisatievormen in het testen, uiteenlopend van uitsluitend testen door ontwikkelaars tot een aparte testorganisatie. De te kiezen organisatievorm hangt af van de testsoort die onderhanden is. De volgende rollen worden onderkend in een testteam: testmanager, testontwerper, testautomatiseringsdeskundige, testbeheerder, tester (testuitvoerder). Binnen elke testsoort speelt zich een testcyclus af, bestaande uit testplanning, testspecificatie, testuitvoering, testregistratie en controle voor afronding. De testmanager is verantwoordelijk voor de planning van een testcyclus. Punten die hierbij in beschouwing worden genomen: stand van de ontwikkeling, testresultaten uit voorgaande testsoorten, resources. Voortgangscontrole vindt plaats op basis van een aantal metrics: gebaseerd op fouten, gebaseerd op testgevallen en gebaseerd op het testobject. Afwijkingen tussen verwachte en werkelijke waarde in de testuitvoering worden eerst geanalyseerd. Als de fout niet te maken heeft met een foutieve testuitvoering, wordt een bevinding opgesteld. In een project is het van belang om een goede bevindingendatabase bij te houden, die tevens dient als communicatiemiddel tussen verschillende partijen. Bevindingen moeten op een uniforme manier worden, zodat ze kunnen worden opgenomen in statistieken. Omdat in het proces van softwareontwikkeling meerdere ontwikkelaars en testers parallel deelnemen, is een goed configuratiemanagement belangrijk. De volgende eisen moeten hierbij worden vervuld: versiebeheer, configuratiebeheer, statusbeheer van fouten en veranderingen, configuratie audits.

2.6

Testtools

Voor iedere fase in het testtraject zijn testtools beschikbaar om het testwerk kwalitatief te verbeteren of te automatiseren. Testtools bieden alleen voordelen als het testproces beheerst en Almere © 2005




Pagina Versie Datum

9 van 10 1.0 08-11-2006

gestructureerd verloopt. De implementatie van een testtool kan een hoge investering vergen, een keuze moet daarom zorgvuldig geschieden. Er bestaan nogal eens onrealistische verwachtingen over de inzet van testtools. De implementatie van een tool moet derhalve worden begeleid. De volgende testtools worden onderkent: • Tools ter ondersteuning van het testmanagement - Testmanagementtools; - Requirementsmanagementtools; - Incidentmanagementtools; - Configuratiemanagementtools; • Tools ter ondersteuning van statisch testen: - Reviewproces ondersteunende tools; - Statische analyse tools; - Modeleer tools • Tools ter ondersteuning van testspecificatie: - Testontwerp tools; - Testdata voorbereidingstools; • Tools ter ondersteuning van de testuitvoering en vastlegging: - Testraamwerk/unittest framework tools; - Test comparators; - Dekkingsgraad-meet tools; - Beveiligingstools; • Monitor- en performance tools: - Dynamische analyse tools; - Performance testtools ; - Loadtesttools; - Stresstesttools; - Monitor tools; • Tools voor het ondersteunen van een specifiek applicatie gebied; • Overige tools zoals SQL-tools of debuggers

Almere © 2005




Pagina Versie Datum

10 van 10 1.0 08-11-2006

3 Literatuurverwijzingen International Software Testing Qualifications Board: Certified tester Foundation Level Syllabus. Version 2005. A. Spillner, T. Linz en M. Pol: Testen volgens ISEB. 9072194691

Almere © 2005


ISTQB Foundation level. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V

Recommend Documents