Categorie: Testmanagement

Als je een gebruikersinterface wilt testen dan wil je zeker weten dat deze gebruikersinterface consistent en gebruikersvriendelijk is. Hieronder beschrijf ik enkele testgevallen die handig kunnen zijn in het testen van een gebruikersinterface.

Lettertypes; Op elke pagina moeten de lettertypes gelijk zijn. Verschillen, of het toepassen van te veel lettertypes kan klungelig overkomen voor de gebruiker.

Lettergroottes; De lettergroottes dienen op elke pagina gelijk te zijn voor gelijke onderdelen. Ook hier geldt weer dat het gebruik van te veel lettergroottes de leesbaarheid verlaagt. Een styleguide helpt in het handhaven van de lettergroottes en lettertypes voor titels, koppen, tekst, etc..

Kleurgebruik; Het kleurgebruik moet voor elke pagina gelijk zijn. Het veranderen van kleuren verwart de gebruiker. Daarnaast is een juist gebruik van kleuren noodzakelijk voor kleurenblinden. Wederom is een styleguide zeer welkom.

Consitentie dialoogschermen; Dialoogschermen moeten hetzelfde opgebouwd zijn. Denk bijvoorbeeld aan de knoppen. OK en Cancel moeten op een ander scherm niet plots Save en Cancel heten.

Iconen; Door de hele applicatie moeten dezelfde iconen of icoonsoorten gebruikt worden. Bijvoorbeeld een Save icoon moet altijd gelijk zijn op elke pagina.

Buttons; De buttons op de schermen moeten consistent geplaatst worden. Dus niet eerst OK en Cancel en daarna Cancel en OK. Verder moeten de buttons ook de juiste naam hebben voor een gesuggereerde actie in het dialoogscherm.

Helptekst locatie; Voor applicaties met een helpfunctie of een tipfunctie moet deze functie altijd op dezelfde plaats getoond worden.

Links; Als er links op schermen staan dienen deze links een correcte afstand van elkaar te hebben, gelijk uit te zien en in dezelfde volgorde te staan op elk scherm.

Snelkoppelingen of sneltoetsen; Als er sneltoetsen gebruikt kunnen worden zoals CTRL+P voor printen, dan dient deze sneltoets op elk scherm gelijk te zijn en ook op elk scherm te functioneren.

Menuitems; Menu items die niet gebruikt mogen worden moeten uitgegrijsd worden of zelfs niet getoond worden. Verder dient de volgorde van de menu items (maar ook in de menu’s zelf) voor elk scherm gelijk te zijn.

Verwijderbevestiging; Als je iets wilt verwijderen is het gebruikelijk een bevestiging te vragen. Nog mooier is het als deze bevestiging voor toekomstige verwijderingen uitgezet kan worden, maar desgewenst ook weer aan.

Opslagbevestiging; Als je iets wilt opslaan is het wel eens nodig een bevestiging te vragen. Vooral als oudere bestanden daardoor overschreven worden.

Boodschappen; Boodschappen moeten in duidelijke taal opgesteld worden, waardoor elke gebruiker weet wat er aan de hand is en wat er eventueel moet gebeuren. Ernstige fout: KB164x3 is niet duidelijk voor een gebruiker.

Spelling; Voer een spellingscontrole en grammaticale controle uit op de schermen. Vooral d en dt fouten zijn eenvoudige fouten die erg klungelig kunnen overkomen en soms de betekenis van een zin volkomen kunnen veranderen.

In deze samenvatting een beschrijving van aandachtspunten bij exploratory testen.
Exploratory testen wordt in de volgende figuur weergegeven als acties op een ‘doos’. Er is niet precies bekend hoe de doos werkt. Er zijn echter wel experts die weten hoe het moet werken.
Exploratory testen probeert o.a. de grenzen van de doos op te zoeken en deze te testen. Verder stelt exploratory testen continu de vraag of de functie zo wel bedoeld is. Bij enige twijfel wordt een SME ingeschakeld.
Er wordt globaal bijgehouden wat er getest is, van elke test. Dit om te voorkomen dat dingen dubbel uitgevoerd worden.
Worden er bevindingen gevonden dan worden deze stapsgewijs beschreven en voorzien van schermdumps en mogelijk logs, zodat ze te allen tijde gereproduceerd kunnen worden door eender wie.

Rubriekentest

• Aftasten van de grenzen van rubrieken.
• Invullen van bewust incorrecte gegevens. Bijvoorbeeld naam: 1234.
• Invullen van code. Bijvoorbeeld naam: 1234
• Vrije tekst invullen met zeer veel karakters.

Functietest

• Juistheid van de functie.
• Gewenstheid van de functie. Denk aan ‘features’.
• Consistente functieafhandeling. Bijvoorbeeld: altijd met toetsenbord invullen of juist altijd met muis.
• Juiste foutafhandeling.
• Workarounds. Deze mogen niet voorkomen. Risico is dat ze standaard werkwijze worden.

Schermtest

• Bruikbaarheid.
  • Schermindeling.
  • Dialoogstructuur.
• Layout.
  • Idiot proof toetsenbordgebruik.
  • Juist en consistent gebruik functietoetsen.
  • Scrollmogelijkheid.
  • Cursorbesturing intuitief en consistent.
  • Spelling.
  • Foutboodschappen en gedrag na fouten.
• Rubrieken.
  • Karakteristiek (numeriek, alfabetisch, alfanumeriek).
  • Codepatroon (Vier numeriek en twee alfabetisch igv postcode).
  • Controle op minimum- en maximumwaarden.
  • Decimalen.
  • Hoofdletters en kleine letters.
  • Controle van de waarden (vb negatieve waarden en dergelijke).
  • Controlecijfer (igv BSN/ sofinr).
  • Logische, consistente wijze van afsluiting van ene naar andere rubriek.
  • Consistente afhandeling: wijzigen, invoeren etc.
• Overzichten.
  • Juistheid sortering informatie.
  • Juiste plaats en waarde tussenresultaten.
  • Bladovergang.
  • Overflow (te veel info).
  • Selectiemechanisme.
• Menustructuren.
  • Tabvolgorde

Beveiliging

• Inloggen.
  • Incorrect inloggen en foutmeldingen. Deze moeten de correct info weergeven.
  • Meer keer inloggen.
• Systeem knijpen.
  • Harddisk.
  • Netwerk.
  • Geheugen.
• Disaster recovery.
  • Wegvallen netwerk.
  • Wegvallen applicatie.
  • Uitvallen pc.

Aanpak

• Elk scherm.
• Logische testgevallen, voor zover gemaakt..
• Checklist.
• ToBe proces doorlopen.
• Training manual doorlopen/gebruiken.
• Expert input bij elk onderdeel.

In deze samenvatting een beschrijving van aandachtspunten bij acceptatietesten.
Acceptatietesten wordt in de volgende figuur weergegeven als acties op een ‘doos’. Er zijn vier acties mogelijk: functietesten, schermtesten, gegevenstesten en procestesten. Deze vier worden hieronder in punten uiteen gezet.

Functietest

• Normaal gesproken als volgt:
  • Op basis van functionele specificaties bepalen van de condities en resultaten.
  • Met behulp van test technieken testsituaties bepalen.
  • De functies dienen te werken zoals gespecificeerd.
  • Met zo min mogelijk testgevallen zo veel mogelijk dekken.
• Zonder goede specificaties
  • Actief en intelligent op zoek naar fouten in de software.
  • Zoeken naar grenzen.
  • Zoeken naar blokkades.
  • Ongewone acties (zoals 2 keer inloggen, disconnecten netwerk etc.).

Schermtest

• Bruikbaarheid.
  • Schermindeling.
  • Dialoogstructuur.
• Layout.
  • Idiot proof toetsenbordgebruik.
  • Juist en consistent gebruik functietoetsen.
  • Scrollmogelijkheid.
  • Cursorbesturing intuitief en consistent.
  • Foutboodschappen en gedrag na fouten.
• Rubrieken.
  • Karakteristiek (numeriek, alfabetisch, alfanumeriek).
  • Codepatroon (Vier numeriek en twee alfabetisch igv postcode).
  • Controle op minimum- en maximumwaarden.
  • Decimalen.
  • Hoofdletters en kleine letters.
  • Controle van de waarden (vb negatieve waarden en dergelijke).
  • Controlecijfer (igv BSN/ sofinr).
  • Logische, consistente wijze van afsluiting van ene naar andere rubriek.
  • Consistente afhandeling: wijzigen, invoeren etc.
• Overzichten.
  • Juistheid sortering informatie.
  • Juiste plaats en waarde tussenresultaten.
  • Bladovergang.
  • Overflow (te veel info).
  • Selectiemechanisme.
• Menustructuren.

Gegevenstest

• Levenscyclus gegevens.
  • Gegevens invoeren, wel of niet mogelijk in de frontend. Wel of niet mogelijk in de backend.
  • Gegevens muteren, wel of niet aanbrengen van wijzigingen.
  • Gegevens verwijderen.
  • Raadplegen van gegevens in bijvoorbeeld overzichten. Gebruikersrechten kunnen een rol spelen.
• Benodigde gegevens aanwezig.
• Bij elkaar horende gegevens.
• Analyse van de gegevens. Zijn ze correct? Denk bijvoorbeeld aan berekeningen.
• Overeenkomst met organisatiebeleid.
• Juiste wijze van implementatie.

Procestest

• Praktijkomstandigheden, zoals bijvoorbeeld in ToBe beschreven.
  • Juist functioneren.
  • Juiste flow.
• Voorvallen.
  • Binnen of buiten het systeem optredende gebeurtenissen.
  • Tijd voor het invoeren van gegevens.
  • Achtereenvolgende voorvallen.
• Afbreektest.
  • Reeds aangevangen processen afbreken of onderbreken.
• Volledigheid van de functies.
• Consistentie van het systeem.
• Leerbaarheid van het systeem.

Het ISO 9126 Quality Model (ISO1991) is een instrument om de kwaliteit van de software te evalueren.

Op de eerste plaats worden de risico’s bepaald. Vervolgens worden op basis van de vastgestelde risico’s de kwaliteitsattributen bepaald die getest moeten worden in een test. Dit is de basis van de verdere test strategie. Na het vaststellen van de kwaliteitsattributen kan worden vastgesteld wat de testfasen zijn die uitgevoerd moeten worden en wat de specifieke focus is van de test fasen.

Als test professionals krijg ik heel wat teststrategie documenten te zien. In veel gevallen zijn het documenten van een veertig tot vijftig pagina’s. Documenten die vol staan met algemene teksten over testen zoals de status van bevindingen, het defect management proces, teksten over hoe een generieke test wordt aangepakt of zelfs stukken die direct uit de literatuur gekopieerd kunnen zijn. De kern van dit testplan wordt volkomen over het hoofd gezien, omdat het document als een verplicht nummer wordt afgehandeld. De organisatie moet een test plan hebben, dus de template wordt ingevuld. Wat dan vaak opvalt is dat de concrete inhoud omgekeerd evenredig is met de dikte van het testplan.

Het grote probleem met dergelijke testplannen is dat ze totaal geen waarde toevoegen en daarmee zonde zijn van het papier waarop ze zijn gedrukt. Wat de kern moet zijn van een test plan is de teststrategie. Het dient een document te zijn waar inspiratie uit gehaald wordt en wat als houvast kan worden gebruikt voor het opzetten van de testen. Het moet dus gewoon een plan zijn. Alle rest kan in principe weggelaten worden. Beetje gechargeerd, maar toch.

Wat is een teststrategie dan precies? 
Laten we eens een stapje terug doen. Wat is een strategie? De Vandale zegt: 1 wetenschap, kennis van het oorlogvoeren, 2 bekwaamheid om met behulp van de ter beschikking staande middelen een gesteld doel te bereiken, 3 plan van handelen. Het is dus een plan om een bepaald doel te bereiken. Kijken we dan naar een teststrategie, dan is dat een plan om een test uit te voeren om de kwaliteit van een testobject vast te stellen. Ik meld hier expliciet plan, omdat een plan een overkoepelend karakter heeft. Een plan beschrijft expliciet niet stap voor stap wat getest wordt en hoe een testobject getest wordt. Dat is namelijk het gevolg van de opstelling van een teststrategie. Een teststrategie is dus ook niet een document. De teststrategie staat misschien genoteerd in een document, maar daar blijft het dan ook bij.

Nog een belangrijk detail is dat een teststrategie altijd kan wijzigen na nieuwe inzichten. Kijk naar “de wetenschap van het oorlogsvoeren”. Als er nieuwe ontwikkelingen zijn en de vijand oprukt moeten er aanpassing gedaan worden om weer in het voordeel te komen. Pas aan het einde is bekend hoe het totale plan gelopen is en wat de volledige vorm van de teststrategie is.

Wat bepaalt een een teststrategie?
Aangezien een teststrategie een overkoepelend plan is kan het gevat worden in een paar pagina’s. Er gaat veel, of beter gezegd, terdege denkwerk aan vooraf. Het resultaat kan vaak in een diagram, een stroomschema of een tabel samengevat worden. Een goede teststrategie kan dus meestal op zo’n 2 pagina’s weergegeven worden. Het doel van de teststrategie is het afdekken van de risico’s die door de stakeholders als belangrijk worden gezien. Bij het bepalen daarvan helpt de test professional. Het achterhalen van de stakeholders en vervolgens het achterhalen van de risico’s kan een tijdrovende klus zijn, maar het is essentieel in het achterhalen van de risico’s.De risicoanalyse van een testobject bepaalt de teststrategie. Laat ik daarvoor een aantal voorbeelden aanhalen. Bij een ziekenhuisinformatiesysteem met de mogelijkheid medicijnen voor te schrijven is het essentieel dat het systeem de juiste waarden gebruikt. Tussen microgram en milligram ligt een verschil van duizend. Een fout daarin levert dode patiënten op. Kijken we naar de lancering van een website voor een nieuwe game-console 4 weken voor Kerstmis, dan is het essentieel dat de performance van de site optimaal is voor een piekbelasting aan bezoekers en voor mogelijk aankopen. Als die site onderuit gaat kost dat vele aankopen en natuurlijk de mogelijkheid van een negatieve uitlatingen in de media.

De voorbeelden tonen al aan dat geen enkel project hetzelfde zal zijn. Dus een teststrategie zal dus ook voor geen enkel project hetzelfde zijn.

Het denkproces
Nu hebben we bepaald wat een teststrategie daadwerkelijk is en weten we wat de basis van de teststrategie is. Met de gevonden risico’s, de kaders van het systeem en het uiteindelijke doel is het zaak de teststrategie te gaan bepalen. Denk aan de grenzen waarbinnen er gewerkt moet worden. Een belangrijk onderdeel is ook welke tools er gebruikt gaan worden of mogelijk voorgesteld moeten worden. Dit is het daadwerkelijke denkproces wat moet plaatsvinden. De beste manier om dit denkproces uit te voeren is ‘met de benen op tafel’. Neem het testteam mee voor een picknick in het park, of barricadeer een vergaderkamer, serveer koffie met wafels en strooi met geeltjes waarop ideeën worden geschreven. Zodra er breder (en vaak anders) gekeken wordt naar het bepalen van de teststrategie komen de beste ideeën naar voren.Zoals meteen te zien is zal elke strategie anders weergegeven worden, omdat het een ander denkproces is. De weergave kan daarmee ook anders zijn. Een vast stramien bevriest het denkproces. Denk eens aan een MoSCoW piramide, een stroomschema, een foto van een whiteboard of een tabel met essenties per fase.

Communiceren van de teststrategie
Jammer genoeg blijft het communiceren van de teststrategie vaak bij het zenden van het document als bijlage in een email, nadat de teststrategie al is uitgedacht. Het is verstandig daar een stap aan toe te voegen, namelijk het managen van de verwachting bij de stakeholders. Presenteer de teststrategie aan de stakeholders en beantwoord mogelijke vragen. Het kan zijn dat ze nieuwe inzichten hebben gekregen, waardoor een deel van de teststrategie anders vormgegeven moet worden. Het is de review waar we als test professionals net zo happig op zijn als het om specificaties aankomt.Nu is er aan de creatie van een uiteindelijk teststrategie een heel proces vooraf gegaan. Daarbij waren de stakeholders en de leden van het test team betrokken. Waarschijnlijk ook andere project teamleden. Dan is het toch meer dan een kroon op het werk om vol trots deze strategie even voor te stellen. Al is het in een meeting, wederom een korte geeltjes sessie om het creatieve proces uit te leggen of natuurlijk een korte presentatie. Het hoeft niet eens meer dan een kwartier te duren. Het gaat erom dat het voorstellen als gereedschap kan worden gebruikt om de volgende werkzaamheden uit te voeren.

Na een voorstelling van de teststrategie kan elk teamlid de stapsgewijze testen voorbereiden en uitvoeren.

Het uiteindelijke test plan
De kern van het test plan is de teststrategie. Die template van 50 pagina’s moet dus grondig onder handen genomen worden, waardoor de secundaire secties de waarde toevoegen die een volledig test plan nodig heeft. Denk bijvoorbeeld aan de vermelding van de omgeving, de kernpersonen, de vakantieplanningen en de randinfomatie die gebruikt is voor de vaststelling van de teststrategie. Laat standaardsecties weg, zoals bevindingenbeheer en dergelijke. Deze zijn al vaak in een eigen proces vastgelegd. Een verwijzing is meer dan genoeg.

In deze whitepaper behandel ik hoe snel een korte professionele test opgezet en uitgevoerd kan worden voor het testen van nieuwe software, aanpassingen op software, webapplicaties en websites. Vanaf nu noem ik al deze stukken software voor het gemak ‘applicaties’.

Testen is een echt vak. Een vak dat helaas nog te vaak als sluitstuk op de projectbegroting wordt gezien. Dat zou anders moeten en kunnen. Als testen vanaf het begin van een project wordt ingezet, dan kunnen fouten al bij de documentatiefase in het project opgelost worden. Dat betekent dus nog voordat één regel code is geschreven. Een niet gemaakte fout hoeft vanzelfsprekend ook niet hersteld te worden, wat de projecttijd verkort en daarmee de kosten verlaagt. Testen heeft hierbij een essentiële rol. Testen is namelijk niets anders dan het controleren van de kwaliteit. De kwaliteit moet vanaf het begin van het project gecontroleerd worden. Er zijn daarvoor een aantal eenvoudige maar slimme acties te bedenken.
Deze whitepaper beschrijft alleen het opzetten en uitvoeren van een standaard testtraject.

De basisvraag voor elk testtraject
Het testtraject begint met de basisvraag: Welke risico’s wil je dat een test afdekt? Is er namelijk geen risico, dan is er ook geen test nodig. De vragen die daarvoor beantwoord moeten worden zijn onder andere:
Wat is de impact als de applicatie incorrect werkt? Gaat er geld verloren, is het gewoon niet mooi, niet handig, of gebeuren er ernstigere dingen? Gaat de klant overwegen je concurrent te benaderen, wordt jouw applicatie onderwerp in het nieuws of in de sociale media? Of krijg je juridische problemen?
Denk goed over de impact van inferieure kwaliteit. Een goed testtraject kan namelijk een hoop ellende voorkomen.

Voorbereiding op het testproject
Het testtraject begint met gesprekken met verschillende personen binnen het project. Op de eerste plaats om een goed beeld te krijgen van de applicatie en het project, maar ook om alvast de structuur, de aanpak en de diepgang van de testen te bepalen.
Dat wat achterhaald moet worden is:

• De achtergrond van het project. Wat wordt gebouwd en welk doel wordt nagestreefd?
• Het doel van het testtraject. Moet er functioneel getest worden of is bijvoorbeeld een End to End test essentieel? Er zijn veel mogelijkheden. Dus het doel moet helder zijn.
• De scope van het testtraject. Vindt de test plaats op de applicatie of slechts op één specifiek onderdeel?
• De milestones en deadlines. Wanneer moet een en ander live, wanneer worden (deel)opleveringen verwacht, hoeveel tijd is voorzien voor het testtraject, hoeveel tijd is voorzien voor development?
• De acceptatiecriteria. Wanneer wordt een positief vrijgaveadvies te geven? Dat kan zijn als er geen hoge prioriteit fouten meer open staan. Ook kan het zijn dat een bepaalde module goed moet werken, ongeacht wat de kwaliteit van de rest van de applicatie is.
• De knelpunten. Elke discipline kan vanuit zijn vak aangeven wat de knelpunten in het project en in het product zullen zijn. Wat is de impact als deze knelpunten voorkomen? Wat is de verwachting dat deze voorkomen? De risicoanalyse is daarmee begonnen.
• De ontwikkelcapaciteit. Hoeveel ontwikkelaars werken aan het product en hoeveel uren worden er in totaal besteed? De ontwikkelcapaciteit geeft vaak al een goed inzicht in de benodigde testcapaciteit.
• De structuur van de applicatie. Hoe ziet de uiteindelijke applicatie er voor de gebruiker uit? En hoe is de applicatie technisch opgebouwd? Is het een landschap van connecties of is het een standalone applicatie? Dit heeft implicaties op de infrastructuur, de testdata en natuurlijk hoe de testgevallen opgezet moeten worden.

Het bepalen van de risico’s
Het doel van testen is het vaststellen van de kwaliteit van de applicatie. Hierbij wordt gericht op de risico’s voor het incorrect functioneren van het eindproduct. Hoge prioriteit risico’s moeten aan een diepere test onderworpen worden dan lage prioriteit risico’s. Om het inzicht in de risico’s duidelijk te maken wordt een risicomatrix opgesteld. Maar alvorens de matrix opgesteld wordt dienen de risico’s bekend te zijn.De risico’s zijn grotendeels bekend geworden door de gesprekken met de verschillende disciplines. Ook de stakeholders moeten ondervraagd worden op hun verwachtingen en de risico’s die zij voor het project en met name het product zien.

Risico’s hebben een bepaalde impact. Wat is de schade als het risico voorkomt? Vindt iemand het onprettig werken, of wordt er een factor 1000 meer aan medicijnen gegeven, waardoor iemand het niet meer na vertelt?
Daarnaast heeft een risico ook een kans om op te treden. Hoe groot is de kans dat er een factor 1000 meer medicijn gegeven wordt als de hoeveelheid paracetamol niet in gram maar in milligram in een pil zit. Een pil van een kilo komt bijvoorbeeld niet zo vaak voor.

Naast productrisico’s zoals een foute dosis medicijnen is het verstandig te denken aan risico’s binnen het project die impact op de kwaliteit kunnen hebben. Als bijvoorbeeld een junior ontwikkelaar de rekenmodule van een webwinkel schrijft is het verstandig extra aandacht te geven aan het testen van die rekenmodule.

De kans en impact van een risico krijgen ieder weging toegewezen. 1 als laagste, 5 als hoogste. Elk risico wordt vervolgens in een matrix geplaatst wat in kwadranten wordt verdeeld. Op de hoge prioriteit risico’s dient het testtraject zich te richten. In de figuur hiernaast is daarvan een voorstelling gegeven.

De test-infrastructuur
De applicatie kan alleen getest worden als deze is geïnstalleerd in een omgeving. Deze omgeving kan gezien worden als een standalone pc, maar ook als een (web)server die met de nodige andere (virtuele) systemen samenwerkt. Uiteraard kunnen ook de andere systemen gesimuleerd worden. Hoe dan ook, er is een infrastructuur nodig waarop getest kan worden die het liefst zo goed mogelijk overeenkomt met de uiteindelijke productie infrastructuur.De gemakkelijkste manier om te achterhalen hoe de infrastructuur eruit moet zien is door met development en de functionele analisten te praten. In het geval er geen functioneel beheer aanwezig is kan development een handje helpen met de opzet van de infrastructuur. Als er gesimuleerde systemen (mock-ups) nodig zijn, dan zal een developer deze eenvoudig kunnen maken.

De opstelling van een testplan
Het testplan is de leidraad van het testtraject. Het kan net zo goed ook de teststrategie heten. Een volledig testplan is in feite de paperclip die de teststrategie en de onderzochte en vastgestelde onderdelen van het testtraject bij elkaar houdt. Het bevat alle essentiële informatie die er voor de uitvoering van het testproject nodig is. Een optioneel deel in het testplan zijn de organisatorische zaken, zoals vakanties en contactgegevens.
Een volledig testplan is zeer welkom als het testwerk door meerdere mensen wordt opgepakt of als het testtraject later overgedragen moet worden.
Het testplan kan ook één A4 zijn als er alleen een korte strategie nodig is. Dat is een beetje afhankelijk van de diepgang en essentie van het testtraject.
Let wel op dat een testplan niet de testgevallen bevat. Dat is namelijk een veel gehoorde misvatting. De testgevallen zijn een apart onderdeel binnen het testtraject. De strategie om te komen tot de testcases hoort wel thuis in het testplan en is de kern van het testplan.De opstelling van de teststrategie valt uiteen in een aantal stappen:

• De verdeling van de applicatie in een aantal logische blokken. Een webwinkel is bijvoorbeeld onder te verdelen in een productenoverzicht met zoekfunctie, een betaalmodule met connecties en een suggestiemodule om extra aankopen te stimuleren.
• Het bepalen van de kwaliteitsattributen voor de logische blokken. Wat is belangrijk? De functionaliteit, gebruikersvriendelijkheid, correctheid, etc.?
• Het bepalen van het belang van de kwaliteitsattributen voor de logische blokken. Hoe belangrijk is de gebruikersvriendelijkheid ten opzichte van de functionaliteit en de correctheid?
• Het bepalen van de testfasen. Gebruikersvriendelijkheid kan bijvoorbeeld beter in een gebruikerstest onderzocht worden dan tijdens een systeemtest.
• Het bepalen van de testtechnieken voor het testen van de kwaliteitsattributen voor de logische blokken. Wordt er een eenvoudige dataflow techniek gebruikt of wordt er gebruik gemaakt van beslissingstabellen? Wordt een combinatie gebruikt van beslissingstabellen voor onderdelen en wordt de rest exploratory getest?
• Het bepalen van de fysieke aanpak voor het testtraject. Denk bijvoorbeeld aan het opknippen van de testen bij tijdsgebrek. De belangrijkste testen worden uitgevoerd binnen één uur. Komen daar fouten uit, dan wordt de module aan een grondige test onderworpen. Zijn er geen fouten, dan wordt er vanwege het tijdsgebrek verder getest aan ander modules.

De vervolgstap op het testplan is de opstelling van de testplanning. Hoeveel tijd is nodig om de verschillende onderdelen op te zetten en uit te voeren. Een vuistregel voor een gestructureerd testtraject is dat het testen 60% van de ontwikkel-tijd kost. Een andere vuistregel die gebruikt wordt is dat het testtraject twee zo lang duurt als de documentatiefase.

De testspecificatie, logische en fysieke testgevallen
De testspecificatie bevat drie activiteiten.
Op de eerste plaats worden de logische testgevallen geschreven. Dit wil niets anders zeggen dat de functionele specificaties op abstract niveau in testsituaties wordt beschreven, waarbij meteen de juiste grenzen voor de testen opgezocht worden.
Als voorbeeld: Iemand mag een autoverzekering afsluiten als hij/zij 18 jaar of ouder is. De logische testgevallen zijn dan: 18 jaar precies, 18 jaar en 1 dag, 17 jaar en 364 dagen, 0 geboortedag (optioneel vanwege nul deling).Op de tweede plaats wordt de benodigde testdata bepaald. Er moet minimaal een verzekering te kiezen zijn uit de database met als regel 18 jaar en ouder. Mogelijk dat er een bestaande klant van 17 jaar en 364 dagen in de database moet worden ingevoerd, als deze niet via de applicatie ingevoerd kan worden.

Op de derde plaats worden de fysieke testgevallen beschreven. Dit betekent eenvoudigweg dat de logische testgevallen fysiek uitvoerbaar beschreven worden. Iedereen moet deze kunnen uitvoeren, zonder dat de beschrijving een uitgebreid proza wordt. Als voorbeeld van een goede testbeschrijving:

• Test: foutsituatie 17jr 364d

• log in: Hans 1234

• Nieuwe verzekering: auto
• Vul in details (niet relevant)
• Leeftijd: 17 + 364d
• Valideer
• Resultaat: Foutmelding – de verzekeringsnemer is te jong.

De uitvoering van de testgevallen en bevindingen
Alle stappen hiervoor zijn gedaan om de testen uit te voeren. Tijdens de uitvoering wordt onderzocht wat de kwaliteit van de applicatie daadwerkelijk is.De testdata wordt ingeregeld en de fysieke testgevallen worden stap voor stap uitgevoerd. Alle vreemde of afwijkende situaties worden genoteerd. Al is het dat de kleur van het logo niet helemaal past in het geheel, het wordt genoteerd. Mogelijk dat dergelijke issues verworpen worden in een classificatiemeeting, maar dan zijn ze wel gezien en beoordeeld. Er is een verschil tussen issues/bevindingen en defects. Alles is een issue/bevinding. Issues worden pas bij de beoordeling als defect geclassificeerd. Het correct registreren van issues is daarom uitermate belangrijk.
Issues dienen zo geregistreerd te worden dat iedereen die de applicatie en de beschrijving van het issue krijgt, het resultaat perfect kan herhalen.
Als voorbeeld: Er wordt niet gemeld: “Ik kan niet opslaan in Word”. Maar er wordt wel gemeld: “Start-Programs-Office-Word-File-Save as-Melding dat de schijf vol is, programma sluit automatisch af”.

Zoals al te lezen is in het bovenstaande stuk dienen de issues beoordeeld te worden. Dit gebeurt in eerste instantie door de tester zelf. De ernst en de prioriteit wordt vastgesteld. Hoe ernstig is het als de fout voorkomt in productie? Hoe belangrijk is het dat de fout onmiddellijk opgelost wordt? Het kan zijn dat een fout niet ernstig is voor productie, maar wel het testen in ernstige mate stoort. Dan is de prioriteit hoog, terwijl de ernst laag is.

De volgende stap is de beoordeling van de issues door een klein projectteam. Is een issue een defect dan kan deze tijdens de beoordeling toegewezen worden aan de juiste persoon binnen het project.

Het spreekt voor zich dat opgeloste issues opnieuw getest moeten worden. Tevens dient er goed onderzocht te worden of er geen nieuwe zaken zijn geïntroduceerd door het oplossen van het issue.

De afronding, het resultaat van het testen gerapporteerd
Het resultaat van het testtraject is een rapport waarin de kwaliteit van de applicatie inzichtelijk wordt gemaakt.
De inhoud van een goed testrapport bevat minimaal de volgende onderdelen:

• Naam, applicatie, datum, versienummer, omgeving.
• Vrijgaveadvies. Het vrijgaveadvies op basis van de rest van het rapport.
• Testuitvoering. Welke testen zijn (op hoofdlijnen) uitgevoerd en hoe is dit gegaan?
• Tabel van de bevindingen. Totaal aantal bevindingen. Aantal openstaande bevindingen gesorteerd op Status en Ernst. Aantal gesloten bevindingen gesorteerd op ernst.
• Acceptatiecriteria. Wat is de afspraak om een positief vrijgaveadvies te geven?

Optioneel:

• Kwaliteitsverbetering. Wat moet gedaan worden om de kwaliteit te verhogen? Of is de kwaliteit afdoende?
• Lijst met openstaande issues.

Een extra stap is het schrijven van een decharge document. Hierin wordt ingegaan op het testtraject. Wat ging goed en wat kan beter. Waar zaten de knelpunten . Waar is alle documentatie te vinden en wat zijn de login gegevens etc. Dit is in feite het overdrachtsdocument voor een toekomstige testronde, waarbij alle geleerde lessen vermeld worden.

Samenvattend
Het voert te ver om in deze whitepaper in te gaan op de verschillende testtechnieken en hoe verder invulling te geven aan templates en dergelijke.
Hoewel een testraject zelf kan worden vormgegeven is het zo dat professionele testers veel zorgen uit handen kunnen nemen. Een professionele tester geeft een stuk nachtrust omdat deze:

• Het testtraject sneller uitvoert. Dat spaart geld, want tijd is geld.
• Weet hoe met de minst mogelijke inspanning de beste test uitgevoerd kan worden. Dat spaart geld, doordat het testtraject korter is en fouten eerder gevonden (en dus opgelost) worden.
• De valkuilen in een testtraject weet te onderscheiden. Dat verhoogt de kwaliteit en voorkomt dubbel werk.
• Onafhankelijk blijft, ondanks dat hij/zij is ingehuurd. De rol van de testprofessional is het objectief vaststellen van de kwaliteit van de applicatie, of deze kwaliteit nu goed of slecht is.

Praat eens met Testhuis over Snel testen. Snel testen is een ‘Testing as a Service’. Dit is een geheel nieuwe dienstverlening:

• Professionele testcapaciteit inhuren wanneer u het wil.
• Enkel investeren in de daadwerkelijk gewerkte tijd.
• Een inzet vanaf een halve dag.
• Geheel flexibel op te zeggen, zonder opzegtermijnen.
• Groen door het nieuwe werken.
• Risicomijdend en kosteneffectief.