DEEL II TESTEN IN ALLE STADIA VAN E-BUSINESS

DEEL II

TESTEN IN ALLE STADIA VAN E-BUSINESS

5

Testen in het Informatie-stadium

5.1 Inleiding Zoals wij in paragraaf 4.2.1 uiteen hebben gezet is er in het stadium Informatie sprake van statische informatieverschaffing via internettechnologie in één richting, namelijk van de informatieaanbieder naar de informatievrager. Typische voorbeelden van dergelijke websites treft u aan bij bedrijven die zichzelf en hun producten of diensten presenteren met aanvullende tekst, een routebeschrijving en bijvoorbeeld een prijslijst. Het internet wordt in dit geval gebruikt als een vervangend of aanvullend middel voor informatie in gedrukte vorm.

5.2 Beïnvloedingsfactoren 5.2.1

Stakeholders

De informatieve website is vaak een aanvullend of vervangend medium voor een bestaande brochure of prijslijst. Het is dan ook vaak een zaak van de afdeling marketing. Dit kan leiden tot de eis dat de lay-out van de website dient te voldoen aan de reeds in gebruik zijnde standaard. Afhankelijk van het type organisatie zal de doelstelling verschillen: aanwezig zijn op het internet is voor veel organisaties al een doel op zich, 24 uur per dag productinformatie beschikbaar stellen, laagdrempelige toegang bieden en afstanden overbruggen. De gebruikers zijn over het algemeen onbekend en zeer divers. Daarom zal de website algemeen bruikbaar moeten zijn. De gebruikers hebben geen sterke verbondenheid met de website. Het operationele beheer zal relatief weinig inhouden. Derhalve zullen de beheerders in het algemeen aan een dergelijke toepassing weinig eisen stellen. Periodiek zal er een update van de content (inhoud van de website) nodig zijn. Een andere taak is het monitoren van de bezoekersaantallen en het soort gebruik. Hier zijn overigens diverse hulpprogramma’s voor beschikbaar (zie ook bijlage F). 5.2.2

Kwaliteitseisen

De website dient overzichtelijk te zijn en de bezoeker moet eenvoudig en duidelijk kunnen navigeren. De informatie moet makkelijk toegankelijk zijn, omdat de binding van de gebruiker met de website slechts gering is.

Het verdient aanbeveling om de website op te bouwen volgens algemeen geldende standaarden. De website moet tevens de identiteit van de organisatie uitstralen en hierin consistent zijn. Belangrijk is dat de website op een groot deel van de gangbare (versies van) browsers correct functioneert. Ook het besturingssysteem (operating system) van de gebruiker kan van invloed zijn. Door de bezoekers van de website te monitoren is te achterhalen welke browsers zij gebruiken en met welke besturingssystemen de bezoekers werken. Op basis van een inschatting hiervan zullen de eisen op dit gebied moeten worden vastgesteld: welke browsers, versies van browsers en besturingssystemen moeten ondersteund worden? De inhoud van de website dient correct en actueel te zijn. De website zal goed vindbaar moeten zijn op het internet aangezien er over het algemeen geen groep vaste gebruikers is. Op het gebied van beveiliging is de voornaamste eis dat onbevoegden de gegevens op de website niet kunnen wijzigen. Daarnaast zal de server dusdanig robuust moeten zijn dat deze blijft functioneren bij ongewenst gebruik. Voor wat betreft de performance kan de eis worden gesteld dat de pagina’s een maximale laadtijd niet mogen overschrijden. Dit is afhankelijk van de grootte van de pagina’s, de gemiddelde verbindingssnelheid van de gebruikers en de infrastructuur. Een voorbeeld van een website in het Informatie-stadium is weergegeven in figuur 8.

Figuur 8: voorbeeld van een website in het Informatie-stadium

5.2.3

Architectuur

De koppeling van de organisatie met de front-office (website) beperkt zich tot het (batchgewijs) voorzien van de website van nieuwe inhoud. Over het algemeen zal de impact op de organisatie dan ook gering zijn. De website is eerder een product van de organisatie dan dat deze invloed heeft op de dagelijkse werkzaamheden. De informatie wordt ontsloten door de server batchgewijs te voorzien van een nieuwe set data. Dit kan ad-hoc gebeuren of onderdeel zijn van een regulier proces waarbij met vaste tussenpozen de inhoud (content) van de website wordt bijgewerkt. Middels de webserver wordt de website ontsloten. De server vormt dus als het ware de “poort” naar het internet. Op het internet is de informatie voor iedereen die over een browser beschikt benaderbaar. Deze browser kan geïnstalleerd zijn op een PC, een mobiele telefoon (gebruikmakend van het Wireless Application Protocol) of een ander apparaat. De client (browser) en de server communiceren via een netwerkverbinding op basis van het TCP/IP protocol (Transfer Control Protocol/Internet Protocol). Een firewall kan het interne netwerk en de data-opslag afschermen van de buitenwereld.

5.3 Impact op testen Nu in kaart is gebracht wat de typische kenmerken zijn van een toepassing in het stadium Informatie, kan worden nagegaan in welke opzichten dit het testen van de toepassing beïnvloedt. Voor elke beïnvloedingsfactor (stakeholders, kwaliteitseisen en architectuur) is bepaald of deze invloed uitoefent op een van de schakels van gestructureerd testen (fasering, testorganisatie, infrastructuur en technieken). De navolgende figuur (9) geeft grafisch weer welke verbanden daarbij zijn vastgesteld. Stadium Informatie

Heeft impact op schakel

Beïnvloedingsfactor

Fasering Stakeholders

Testorganisatie

X

Infrastructuur

X X

Kwaliteitseisen

Architectuur

Technieken

X

X

Figuur 9: impact matrix voor het stadium Informatie

Typerend voor ICT-projecten is dat zij een dynamisch karakter hebben. Bij ebusinessprojecten is dat zeer sterk het geval. De opdrachtgever zal gedurende het project mogelijk zijn doelen en eisen bijstellen en afhankelijk van de tussenproducten het project bijsturen. Het testteam zal moeten anticiperen op deze manier van werken. Dit zal invloed hebben op de fasering van het testproces. Ook de korte time-to-market beïnvloedt de testfasering. De opdrachtgever zal vaak behoefte hebben om ondersteund te worden in het hele proces. Het testteam kan hierin een belangrijke rol vervullen. Dit zal de rol en organisatie van het testteam beïnvloeden. De kwaliteitseisen op het gebied van met name gebruikersvriendelijkheid, performance, portabiliteit, beveiliging en continuïteit zijn hoog. Dit heeft tot gevolg dat het testen van de toepassing specifieke testtechnieken behoeft. De dynamiek in het ontwikkelproces zal speciale aandacht vragen voor het beheer van de testomgeving. Ook de behoefte om te kunnen testen op diverse platforms zal de gebruikte testomgeving mede bepalen. Het vroegtijdig organiseren van de inrichting van de testomgeving is een must. In dat opzicht valt er dus een link te leggen tussen de architectuur van een ebusinesstoepassing en de testfasering.

De hier geschetste gevolgen voor het testen zijn ook aan de orde in de volgende stadia van e-business. Per stadium komen daar vervolgens een aantal nieuwe aandachtspunten bij.

5.4 Testaanpak 5.4.1

Fasering

Bij ontwikkeltrajecten van e-businesstoepassingen wordt veelal zonder echte methodiek, zoals de System Development Methodology (SDM) of de Dynamic System Development Method (DSDM), gewerkt. Dit vanwege de korte time-tomarket. De specificaties van het te ontwikkelen systeem zijn dan ook vaak niet op het niveau dat idealiter voor het testen gewenst is. Ook organisatieafhankelijke normen en standaarden omtrent het functioneel ontwerp worden vaak niet opgevolgd. Hierdoor zijn de specificaties veelal impliciet omschreven in een algemeen plan van aanpak. Ook komt het voor dat de ideeën direct zijn verwerkt in technische documentatie of een prototype. Dit komt de juiste functionele en technische werking en de onderhoudbaarheid niet ten goede. In al deze situaties is het van groot belang om als testteam vroegtijdig betrokken te raken bij het project. Op deze manier kan de kennis worden verzameld die nodig is om een goed beeld te krijgen van de verwachtingen van de opdrachtgever en daar waar nodig kan reeds in een vroeg stadium worden aangeven waar de wensen en de realisatie eventueel uiteenlopen. Door het iteratieve karakter van veel ontwikkeltrajecten zullen de fasen voorbereiden, specificeren en uitvoeren niet strict opeenvolgend in de tijd kunnen worden uitgevoerd. Er zal een dynamisch proces ontstaan waarbij regelmatig dient te worden teruggegrepen naar werkzaamheden die eigenlijk al zijn uitgevoerd, maar die ten gevolge van voortschrijdend inzicht opnieuw moeten worden bekeken. Dit zal een grote mate van flexibiliteit vergen. Te meer daar in een doorsnee e-businessproject zo’n 30% tot 50% van de eisen wijzigt gedurende de systeemontwikkeling. De genoemde karakteristieken hebben veel weg van het testen in Rapid Application Development trajecten. Een kanttekening die daarbij kan worden gemaakt is dat binnen de IT-ontwikkeling op losse wijze met methoden en technieken wordt omgegaan, waardoor de kosten en doorlooptijd uit de hand lopen. De planningsactiviteiten zullen minder tijd vragen dan in reguliere trajecten omdat er minder in detail gepland kan worden. Het beheer (voortgangsbewaking en bijsturing) van het testproject zal echter meer tijd vergen vanwege de dynamiek van het proces. Er zullen bijvoorbeeld vaker aanpassingen in de doelstellingen, uitgangspunten en randvoorwaarden zijn. 1 De fasen die worden doorlopen zijn in figuur 10 grafisch weergegeven . 1

Bron: Pol, M, Teunissen, R en Veenendaal, E van, Testen volgens TMap®, Tutein Nolthenius, ISBN 90-72194-58-6

Belangrijk om te beseffen is dat deze fasen niet lineair worden doorlopen, maar dat er sprake is van een iteratief proces.

PLANNING EN BEHEER

VOORBEREI -DING

AFRONDING SPECIFICATIE

UITVOERING

Figuur 10: fasering van testprojecten

Gedurende de fase planning en beheer wordt het testplan opgesteld en wordt de voortgang van het testproject bewaakt. Deze fase loopt tot het eind van het project door. Tijdens de voorbereidingsfase vindt beoordeling van de kwaliteit van de systeemdocumentatie (testbasis) plaats. Daarbij wordt vastgesteld of de documentatie bruikbaar is als informatiebron ten behoeve van het opstellen van testgevallen. Tevens wordt de benodigde infrastructuur (waaronder een testomgeving) gespecificeerd tijdens deze fase. Vervolgens worden tijdens de specificatiefase de testgevallen opgesteld en de benodigde uitgangsbestanden gecreëerd. Het uitvoeren van de tests geschiedt tijdens de uitvoeringsfase. Deze is in figuur 12 naar voren gehaald omdat dit het meest zichtbare deel van het testproces is. Door niet-testers wordt dit soms als de eerste (en enige) fase beschouwd, maar een goede test vereist dat de fasen planning en beheer, voorbereiding en specificatie worden doorlopen. Dit leidt er uiteindelijk toe dat de test resulteert in een beter inzicht in de kwaliteit van het geteste systeem en dat duidelijkheid bestaat over wat er is getest en op welke wijze. Het testproces eindigt met de afrondingsfase. Tijdens deze fase wordt de documentatie omtrent het testproject (de testware) overgedragen aan de beheerorganisatie ten behoeve van toekomstig gebruik. Tot slot vindt een evaluatie plaats van het testobject (het geteste systeem), eventueel resulterend in een advies omtrent acceptatie. Ook het testproject zelf wordt geëvalueerd en er worden lessen getrokken voor de toekomst. Onderdeel van de afrondingsfase voor een e-businessproject kan zijn het inrichten van de monitoring van het systeem na de ingebruikname (zie paragraaf 5.4.4).

5.4.2

Testorganisatie

E-businesstoepassingen zijn relatief nieuw en veelal zal de organisatie nog niet veel van dergelijke ontwikkeltrajecten hebben meegemaakt. Het is daarom van belang de opdrachtgever goed te betrekken bij hetgeen ontwikkeld wordt. Het testteam kan hierin een belangrijke rol vervullen omdat het veelal de belangen van de opdrachtgever behartigt. De testcoördinator zal dan ook veelal de rol van intermediair op zich nemen. Zo zal het een uitdaging zijn om de afdeling marketing en de ontwikkelaars bij elkaar te brengen. De marketingafdeling, die vaak opdracht geeft tot de ontwikkeling van de toepassing, heeft in de regel weinig IT-kennis. Aan de andere kant beschikt de IT-afdeling, die de toepassing ontwikkelt, over het algemeen nauwelijks over kennis van de bedrijfsvoering. Door uitgebreid te communiceren met beide partijen kan het testteam helpen om bruggen te bouwen en om de verwachtingen over en weer helder te maken. Let wel: dit behoort gewoonlijk niet tot het formele takenpakket van het testteam, maar is een benadering om toegevoegde waarde te bieden. Het is in ieder geval zaak om de afdeling die opdracht geeft tot ontwikkeling van de toepassing te betrekken bij (de besluitvorming rond) het testproces. De testers zullen dus veel meer moeten meedenken en vragen stellen. Zij dienen derhalve een pro-actieve instelling te hebben. Ook zal er in de organisatorische sfeer meer werk zijn om bijvoorbeeld proefpanels samen te stellen en te begeleiden. Een e-businesstoepassing in het stadium Informatie is over het algemeen nog niet zo complex dat er (technisch) specialisten nodig zijn om de testers te ondersteunen. Een uitzondering op deze regel vormt het beheer van de testomgeving (zie paragraaf 5.4.3). 5.4.3

Infrastructuur

De testomgeving is bij internettoepassingen een verhaal apart. Het is van groot belang om te kunnen testen in een omgeving die is gescheiden van de ontwikkelomgeving. Dit teneinde te voorkomen dat de ontwikkel- en testwerkzaamheden elkaar verstoren. Daarnaast zal de diversiteit van de door de toekomstige gebruikers benutte configuraties het testen op verschillende platforms en met verschillende browsers nodig maken. Hiervoor dient de benodigde hard- en software beschikbaar te zijn. Te denken valt daarbij aan het beschikbaar hebben van de meest gangbare platforms en internetbrowsers. Dit zijn wat betreft de platforms Windows (95/98/2000/NT), UNIX en het Macintosh platform en wat betreft de internetbrowsers de Internet Explorer en de Netscape Navigator. Aangezien niet iedereen met de laatste versie van dit soort software werkt, is het ook van belang te testen op een aantal “oudere” versies indien die nog veel gebruikt worden. Een alternatief voor het testen op meerdere (versies van) browsers, is het testen met behulp van de Opera browser. Deze benadering wordt in de volgende paragraaf uiteengezet (onder “portabiliteitstest”).

Gezien het grote aantal componenten waaruit de testomgeving wordt opgebouwd is een zorgvuldig versiebeheer een must. Tevens dient ruim voor de testuitvoeringsfase aangetoond te zijn dat de testomgeving functioneert. Het vroegtijdig organiseren van de inrichting van de testomgeving is geen overbodige luxe. Het testen op het “open” internet is uit den boze, omdat dan ook derden geconfronteerd kunnen worden met verstoringen in software die nog niet is geaccepteerd. 5.4.4

Technieken

De gebruikelijke testtechnieken zijn onverkort bruikbaar bij ebusinesstoepassingen. De specifieke aspecten van het internet maken het echter noodzakelijk op een aantal gebieden wat dieper op de materie in te gaan. De kracht van de KWTS testaanpak zit onder meer in het toetsen aan de hand van vragen. Hiervoor worden hulpmiddelen gebruikt die aangeven waar zwakke plekken in de toepassing zitten. Dit boek bevat diverse checklists die hierbij behulpzaam zijn (zie de bijlagen H tot en met M). Het valt aan te raden om van start te gaan met het toetsen aan de hand van checklists, reeds voordat de toepassing zover ontwikkeld is dat dynamisch testen mogelijk is. Deze vorm van testen (statisch testen) kan parallel aan de overige testactiviteiten (beoordelen systeemdocumentatie, opstellen testgevallen, et cetera) plaatsvinden. Dit draagt bij aan het vroegtijdig ontdekken van potentiële fouten, waardoor maatregelen getroffen kunnen worden die erop gericht zijn te voorkomen dat problemen zich in latere fasen voor gaan doen. Wanneer de systeemdocumentatie tekortschiet, kan het noodzakelijk zijn om aanvullende informatie boven tafel te halen, voordat over wordt gegaan tot het opstellen van testgevallen. Dit kan onder andere door het houden van interviews en het opstellen van business cases. De detail intake van de testbasis (documenten die als input dienen ten behoeve van het testproces) verdient tevens veel aandacht om eventuele tekortkomingen in de testbasis aan het licht te brengen. In het vervolg van deze paragraaf worden de testtechnieken benoemd (en waar nodig beschreven) die kunnen worden gehanteerd bij het testen van ebusinesstoepassingen in het Informatie-stadium. Syntaxtest De HTML-code die wordt gebruikt, dient door de verschillende merken en versies browsers correct te worden geïnterpreteerd. De ene browser zal hier gemakkelijker mee omgaan dan de andere: Internet Explorer van Microsoft ziet bijvoorbeeld een groot aantal onvolkomenheden door de vingers en presenteert de pagina zoals bedoeld. Dezelfde pagina kan in een andere browser tot foutmeldingen leiden. Het is daarom zaak om de syntax van de HTML-code te

controleren. Hiervoor zijn diverse eenvoudig te bedienen tools beschikbaar, waarvan een overzicht is opgenomen in bijlage D. Syntactische test Indien er een ontwerp is voor de uiterlijke kenmerken van de website, kan de syntactische test worden uitgeschreven. Aandachtspunten zijn onder andere de consistentie van het ontwerp: wordt dezelfde stijl gehanteerd, wordt de indeling van de pagina’s consequent doorgevoerd, is het uiterlijk en de functionaliteit van de buttons consistent, is de vormgeving conform de huisstijl? De syntactische test richt zich dus op de grafische user interface (GUI). Dit in tegenstelling tot de syntax test aan de hand waarvan de structuur van de HTML-code wordt beoordeeld. Navigatietesten Het gebruik van technologische hoogstandjes voor navigatie kan een effect hebben dat tegenovergesteld is aan wat beoogd wordt, omdat de bezoeker er door gehinderd wordt of zelfs wordt weggejaagd. De gebruiker moet immers snel kunnen vinden wat hij zoekt. Bij ontoereikende navigatie bestaat de kans dat de gebruiker verdwaalt in een wirwar aan informatie. Dat dit ernstige consequenties kan hebben, wordt bevestigd door onderzoek van de Boston Consulting Group. Daaruit blijkt dat slechte navigeerbaarheid voor 45% van de internetgebruikers een reden is om een website te verlaten. Enkele vuistregels voor een goede navigeerbaarheid zijn dat er altijd een startpagina moet zijn die vanuit elke andere pagina bereikt kan worden en dat er in ieder geval een structuur moet worden gekozen voor het navigeren. Verder zal voor de gebruiker uit de context duidelijk moeten blijken waar een link hem heen leidt. Dit geldt zowel voor links naar andere websites, als navigatielinks naar pagina’s op dezelfde website. Ook moet de structuur altijd duidelijk zichtbaar blijven, evenals de gevolgde weg naar de actuele pagina. Van belang is verder dat de structuur een duidelijke relatie vertoont met de inhoud van de website. Zeer bruikbaar om structuur aan te brengen is een bepaalde mate van hiërarchische (verticale) navigatie. Hierbij kan de gebruiker steeds een detailniveau dieper kiezen en bepalen welke pagina’s hij wil raadplegen. De navigatie mag echter ook weer niet te sterk hiërarchisch gestructureerd zijn, omdat dit niet vlot in het gebruik is en de gebruiker kan afhaken. Flexibiliteit in navigatie zal geboden moeten worden door tevens horizontale navigatie mogelijk te maken. De hiërarchische structuur hoeft dan niet altijd te worden gevolgd, waardoor er ook buiten deze structuur om direct aanverwante pagina’s kunnen worden opgeroepen. Hiermee wordt flexibiliteit ingebouwd, waardoor de gebruiker zich niet in een keurslijf gedrukt voelt. Ook dient bijvoorbeeld het navigeren door middel van “Up”, “Down”, “Next” en “Previous” in principe vermeden te worden. De gebruiker is onbekend met de website en het is niet te verwachten dat de gebruiker voldoende overzicht heeft om in deze vorm te navigeren.

Veelal worden er vuistregels gebruikt bij het oordelen over de navigatie: het maximum aantal muiskliks waarbinnen elk onderdeel bereikbaar moet zijn (“drie-klikken”-regel) en het maximum aantal hiërarchische niveaus. Dit zijn regels die niet te strikt moeten worden toegepast bij het testen. Het zijn geen directe foutsituaties. Wel kan het constateren van een afwijking van deze regels aanleiding zijn om een kritische vraag daarover te stellen of om een bevinding te noteren. Navigatie is een aspect van het kwaliteitsattribuut bruikbaarheid. Voor dat kwaliteitsattribuut is een checklist opgesteld waarin de voornoemde aspecten zijn verwerkt (zie bijlage H). Ook andere items op het gebied van bruikbaarheid zijn hierin opgenomen. Linkcontrole Het niet functioneren van links zal bij de gebruiker snel de indruk wekken dat het een amateuristische website betreft. Aangezien de binding met de bezoeker meestal gering is, is het risico dat de bezoeker de website verlaat (en misschien nooit meer terugkomt) groot. Heel belangrijk is dus om te checken of alle links correct werken. Dit betreft dan zowel de links binnen de eigen website (navigatie) alsook de links naar andere websites, en zowel tekstlinks als buttons/images. Geautomatiseerde tools om links te testen zijn volop aanwezig (zie bijlage E). Zij kunnen het testen van links aanmerkelijk vereenvoudigen. Als het aantal links erg groot is, kan dit met name leiden tot tijdsbesparing. Een kanttekening is echter op zijn plaats. De tools die links controleren tonen enkel aan of een link al dan niet ergens naartoe leidt. Of de link naar de juiste locatie verwijst kunnen deze tools niet beoordelen. Portabiliteitstest Het is absoluut noodzakelijk om vast te stellen dat alle webpagina’s correct worden weergegeven op zowel de Internet Explorer als de Netscape Navigator, en dan in ieder geval op de huidige versie en de vorige twee versies. Al naar gelang de gewenste dekking, zullen wellicht nog uitgebreidere tests noodzakelijk zijn. Wel is het zaak om in de teststrategie een afweging te maken tussen het vereiste aantal combinaties van browsers, platforms en besturingssystemen waarop men wil testen en anderzijds de beheersbaarheid en betaalbaarheid van de testinfrastructuur. Een alternatieve benadering om de portabiliteit te testen zonder een groot aantal verschillende merken browsers (in uiteenlopende versies) aan te moeten schaffen is het gebruik van de Opera browser. Dit is een browser die HTMLcode zeer strikt interpreteert. Alleen standaard HTML wordt door Opera correct verwerkt. Andere browsers kunnen naast standaard HTML ook specifieke extensies op HTML interpreteren. Daarbij overlappen deze extensies elkaar ten dele, maar hebben browsers ook “eigen” extensies op HTML die door andere browsers niet geïnterpreteerd kunnen worden (figuur 11). Een en ander betekent dat indien een website in de Opera browser goed functioneert, hij zeer waarschijnlijk ook op alle versies van Internet Explorer en Netscape Navigator

juist wordt weergegeven. Dit is het gevolg van het feit dat deze browsers naast allerlei specifieke extensies op HTML in ieder geval het standaard HTML kunnen interpreteren.

Figuur 11: relatie HTML-standaard en commerciële browsers

Het testen van de portabiliteit met de Opera browser wordt met name aanbevolen als er onvoldoende tijd en middelen zijn om te testen met behulp van uiteenlopende (versies van) browsers. De leverancier van de Opera browser is vindbaar op www.operasoftware.com. Performancetest Aangezien er weinig binding is met de gebruikers, is de performance van groot belang. Vooral de grootte van de webpagina’s (in aantallen bytes) en de opbouw en het gebruik van grafische onderdelen zullen de performance beïnvloeden. Er zal een norm moeten worden gesteld voor wat betreft de tijd waarin de pagina geladen moet zijn. Dit in relatie tot de snelheid van de verbinding van de gebruiker en uitgaande van gelijktijdig gebruik van de website door meerdere gebruikers. Een performancetest met behulp van testtools kan (deels) uitsluitsel bieden. Een complicerende factor daarbij is dat de performance wordt beïnvloed door tal van zaken, zoals de snelheid van de webserver, de prestaties van de Internet Service Provider, de snelheid van de verbinding van de gebruiker en de PC die hij of zij gebruikt, et cetera. Een groot deel van deze factoren ligt buiten de invloedssfeer van de organisatie. Derhalve is het niet exact te voorspellen hoe de performance zal zijn in een specifieke situatie. Wel is het mogelijk om de performance van de eigen infrastructuur te beoordelen. Zodoende kunnen eventuele bottlenecks aan het licht worden gebracht. Bij het testen van de performance is het zaak om met een geringe belasting te beginnen en deze geleidelijk op te bouwen. Bijvoorbeeld door het achtereenvolgens simuleren van 10, 100, 500, 1.000, 5.000, 20.000 en 50.000 gebruikers. De belasting wordt net zolang verhoogd totdat het breekpunt wordt bereikt. Dit is de belasting waarbij de website door de grote toeloop van

(virtuele) bezoekers niet meer functioneert. Ook is het zinvol om bij te houden wat de verhouding is tussen het totale aantal pogingen om een verbinding tot stand te brengen en het aantal mislukte pogingen bij grote belastingen. Dit zegt iets over de bereikbaarheid. Er zijn diverse vormen van performancetesten. In totaal kunnen er vier vormen worden onderscheiden, namelijk: (1) Loadtest

:

(2) Endurancetest

:

(3) Spiketest (4) Stresstest

: :

simulatie van een groot aantal gebruikers en transacties grote belasting gedurende een lange tijdsduur simulatie van een plotselinge piekbelasting belasting op maximaal toegelaten waarden (breekpunt)

Aanbevolen wordt om al deze vier vormen van performancetesten uit te voeren in de aangegeven volgorde, daar zij ieder andere bottlenecks aan het licht kunnen brengen. Een en ander uiteraard onder voorbehoud van beschikbare tijd en overige resources voor het testen. Een loadtest wijst uit of het systeem in staat is om grote aantallen gebruikers en transacties te ondersteunen. Vervolgens kan een endurancetest aantonen of de prestaties ook op voldoende niveau blijven wanneer er gedurende langere tijd (enkele dagen) veel van het systeem vereist wordt. Met name problemen met geheugenlekkages en resource locking (het niet vrijgeven van systeemresources na afloop van een bepaalde gebeurtenis) komen zodoende naar de voorgrond. Als deze tests met succes zijn uitgevoerd (het systeem blijft naar wens presteren), dan kan een spiketest uitwijzen of de ebusinesstoepassing in staat is om plotselinge pieken in de belasting op te vangen. Dergelijke pieken kunnen zich in een “live” situatie voordoen ten gevolge van bijvoorbeeld een reclame-uiting op radio of TV of als de organisatie in een of andere vorm in het nieuws staat. Tot slot wijst een stresstest uit waar het breekpunt van de toepassing ligt. Deze informatie is bijzonder waardevol omdat aan de hand daarvan bepaald kan worden wanneer de capaciteit van de webserver vergroot moet worden. Die situatie doet zich met name voor als uit analyse van de bezoekersaantallen blijkt dat deze de maximale waarden (het breekpunt) benaderen, zoals bepaald tijdens de stresstest. Bij voorkeur worden performancetests verricht op een systeem dat al enige tijd in de testomgeving draait. Het voordeel daarvan is dat databases en buffers al gevuld zijn waardoor een realistischer resultaat wordt bereikt. Aangeraden wordt om zo’n vijf tot tien scenario’s te selecteren op basis waarvan de performancetest wordt ingericht. Door deze gevallen tal van keren te kopiëren en het aanbrengen van geringe variaties in de gebruikte data kunnen in spreadsheetprogramma’s vervolgens in relatief korte tijd de grote aantallen testgevallen worden gecreëerd die benodigd zijn.

Het gezichtspunt van de bezoeker van de website dient leidend te zijn bij het inrichten van een performancetest. Het gaat dus om het end-to-end testen van de performance. De kernvraag luidt: “hoe ervaart de bezoeker de performance bij uiteenlopende belastingen van de toepassing”. Belangrijk om te beseffen is dat performance zich niet lineair ontwikkelt. Toename van de belasting leidt tot een meer dan evenredige afname van de performance. Performancetests dienen zowel tijdens de systeemontwikkeling als na de ingebruikname verricht te worden. Het laatste is van belang omdat de performance door onvoorziene omstandigheden terug kan lopen in de “live” omgeving. Hoe vroeger er gestart wordt met het testen van de performance, hoe beter. Zo kan er al op de databaseserver worden getest, voordat de grafische user interface gereed is. Vroege detectie van knelpunten is gunstig, omdat de herstelkosten van fouten toenemen naarmate de fouten later worden ontdekt. Een performancetest verloopt volgens de volgende stappen: ? ? ? ? ?

identificeren van testscripts; genereren van virtuele gebruikers; creëren van een load scenario; uitvoeren van de test; analyseren van de resultaten.

Deze stappen worden hieronder kort toegelicht. Ten behoeve van de duidelijkheid wordt daarbij een voorbeeld van een toepassing in het stadium Transactie gebruikt. Bij het identificeren van testscripts gaat het erom te bepalen welke typische processen gebruikers doorlopen. Te denken valt aan zaken als het bezoeken van de homepage, het raadplegen van een online catalogus, het vullen van de virtuele winkelwagen, het bestellen van producten, het zoeken naar informatie, et cetera. Een beperkt aantal basisscripts is voldoende. Vervolgens worden de virtuele gebruikers gegenereerd. Middels variaties in gebruikte data en timing kunnen op basis van een kleine basisset grote aantallen gebruikers gegenereerd worden. Bij het creëren van een load scenario gaat het erom een zo realistisch mogelijk scenario op te stellen. Deze bestaat uit grote groepen gebruikers die diverse handelingen verrichten. 2

Voorbeeld van basisscripts voor een online reisbureau : ? ? ? ? ? 2

Bezoek homepage Zoek bestemming Toon overzicht bestemmingen Voeg reis toe aan winkelwagen Toon inhoud winkelwagen

: : : : :

35% 32% 16% 7,8% 4%

De in dit voorbeeld gehanteerde percentages hebben betrekking op het aandeel van de genoemde basisscripts in het totaal aantal testgevallen.

? ? ?

Registreer voordeelkaart Bestel reis Geef status bestelling weer

: : :

2% 3% 0,2%

Tijdens de testuitvoering vindt verzameling van data over de performance plaats. Deze data is benodigd om achteraf een analyse van eventuele bottlenecks te kunnen verrichten. In bijlage J zijn diverse vragen opgenomen aan de hand waarvan een eerste beoordeling van performance-aspecten kan plaatsvinden. Met behulp van deze vragen kunnen potentiële bottlenecks in kaart worden gebracht voordat er een performancetest wordt verricht. Error guessing en checklist beveiliging Het testen van de beveiliging is in feite het “testen van zaken die niet gespecificeerd zijn”. Beveiligingslekken doen zich voor wanneer specifieke risico’s over het hoofd worden gezien. Het testen van de beveiliging vereist dus dat de tester probeert te achterhalen waar de ontwerpers en ontwikkelaars niet aan hebben gedacht. Bruikbare instrumenten bij het beoordelen van de beveiliging zijn de checklist functionaliteit (zie bijlage K) en error guessing. Hoe eerder er wordt gestart met het testen van de beveiliging hoe beter. De eventueel benodigde aanpassingen om beveiligingslekken te dichten, kunnen veel tijd vergen. Als belangrijke beveiligingslekken pas in een laat stadium aan het licht worden gebracht, loopt men de kans dat herstel voor de geplande implementatiedatum niet haalbaar is. Aangezien de beveiliging deels kan worden beoordeeld met behulp van checklists, is het in het algemeen een haalbare kaart om vroeg te starten met het testen van de beveiliging. Eén van de grootste risico’s in dit stadium is dat van buitenaf de informatie op de webserver wordt aangepast door onbevoegden. De beveiliging met betrekking tot het kunnen wijzigen van de op de server aanwezige webpagina’s zal daarom robuust moeten zijn. Andere risico’s zijn denial of service en verspreiding van virussen. Denial of service is het overbelasten van een website waardoor de performance degradeert tot een niveau waarop het systeem feitelijk onbruikbaar is gemaakt. Dit is een van de meest voorkomende vormen van “cyberterreur”. De websites van diverse bekende organisaties zijn door dit soort aanvallen al één of meerdere malen platgelegd. Voorbeelden daarvan zijn onder andere CNN en Microsoft. In het geval dat de website bij een externe organisatie op de server staat zullen afspraken moeten bestaan over de gegarandeerde beveiliging. Deze afspraken zullen getoetst moeten worden op bruikbaarheid in geval van problemen.

Penetratietest en security audit Tijdens een penetratietest trachten professionele hackers zich toegang te verschaffen tot databases, netwerken, servers, en dergelijke. Een security audit is een audit die de beveiliging van de e-businesstoepassing toetst aan de hand van een referentiekader omtrent wat een goede beveiliging inhoudt. Voor deze vormen van beveiligingsbeoordeling werkt KZA samen met partners die zich gespecialiseerd hebben in beveiliging van informatiesystemen. Bruikbaarheidstest Met behulp van een bruikbaarheidstest kan worden achterhaald hoe leden van de doelgroep het gebruik van de website ervaren. Door het tijdig verrichten van zo’n test kan worden voorkomen dat men in productie gaat met een toepassing die niet wordt begrepen of niet als prettig wordt ervaren door de doelgroep. Een goede bruikbaarheidstest levert een schat aan informatie op, waarmee ervoor kan worden gezorgd dat de toepassing beter gaat aansluiten bij het referentiekader van de doelgroep. Met name voor e-businesstesten is deze techniek van belang, omdat de gebruikers hoge eisen stellen aan de bruikbaarheid. Bovendien is er geen mogelijkheid voor formele opleidingen, dus moet het gebruik van de website intuïtief zijn. Bruikbaarheid is derhalve een kritische succesfactor. De bruikbaarheidstest wordt uitgevoerd zodra het interactie-ontwerp gereed is. Ook als de toepassing zelf nog niet is gerealiseerd, dan nog kan er getest worden met behulp van prototypes en/of ontwerptekeningen. Het voordeel van deze werkwijze is dat er tijd resteert in het ontwikkeltraject om geconstateerde problemen te verhelpen. Een bruikbaarheidstest wordt verricht met leden van de doelgroep. In totaal nemen vier tot vijf toekomstige gebruikers deel aan de test. Dit is voldoende om een representatief beeld te krijgen van de beleving van de doelgroep. Er worden realistische scenario’s opgezet die door de gebruikers worden uitgevoerd met behulp van een prototype of interactieontwerpen van de applicatie. Een groep observatoren neemt waar wat er gebeurt, maar mag op geen enkele wijze invloed uitoefenen op de test. Het geniet derhalve de voorkeur dat de gebruikers (testers) de observatoren niet zien. In het observatieteam nemen bouwers, leden van de doelgroep en onafhankelijke derden (zoals professionele testers) plaats. Voorafgaand aan de test vindt er een briefing van de gebruikers plaats waarin het doel en de opzet van de test wordt uitgelegd. Deze briefing heeft een tweeledig doel. Enerzijds om de betrokkenen te informeren over het verloop van de test en anderzijds om hen op hun gemak te stellen. Dit is van belang om een zo natuurgetrouwe nabootsing van de werkelijkheid te kunnen bereiken tijdens de test. Na afloop van de test worden de gebruikers geïnterviewd. De test wordt stap voor stap doorgesproken en de interviewer (een lid van het observatieteam)

tracht zoveel mogelijk informatie te verkrijgen over de ervaringen van de tester. Vragen die tijdens het interview aan bod kunnen komen zijn onder andere: ? In hoeverre sloot de inhoud van de website aan bij de verwachtingen van de gebruiker? ? Hoe werd de navigatie ervaren? ? Hoe werd de vormgeving van de website ervaren? ? In hoeverre kon de gebruiker de door hem of haar gewenste informatie eenvoudig vinden? ? In welke mate sloot het taalgebruik op de website aan bij dat van de gebruiker? ? Hoe werden de grafische aspecten van de website ervaren? ? In welke mate gaf de website de gebruiker vertrouwen in de privacyaspecten? Dit is geen limitatieve opsomming. De lijst van onderwerpen die worden besproken kan desgewenst worden aangepast of uitgebreid. De laatste fase van de bruikbaarheidstest is een nabespreking door het observatieteam. Tijdens dit overleg wordt in kaart gebracht welke verbeteringen er wenselijk zijn om beter aan te sluiten bij de verwachtingen van de doelgroep. Het observatieteam discussieert over knelpunten en mogelijke oplossingsrichtingen en formuleert verbetervoorstellen. Het toepassen van deze testtechniek leidt er toe dat er minder aanpassingen nodig zijn na de implementatie en dat er door gebruikers minder beroep wordt gedaan op ondersteuning. Bovendien zal de doelgroep (indien de juiste acties zijn genomen naar aanleiding van de geconstateerde knelpunten) het gebruik van de website als prettiger ervaren. Dit komt de mate van gebruik ten goede. De checklist bruikbaarheid in bijlage H biedt een overzicht van een groot aantal controles ten aanzien van bruikbaarheidsaspecten. Met behulp van deze checklist kan een statische test van de bruikbaarheid worden verricht. Dit is een waardevolle aanvulling op de hiervoor beschreven techniek. Indien de tijd en/of middelen voor het verrichten van een bruikbaarheidstest ontbreken, dan is het toetsen van de website aan de hand van de checklist een alternatief. Error guessing (exploratory testing) Deze ongestructureerde vorm van testen kan ook bij het testen van websites worden toegepast. Het uitgangspunt is dat het natuurlijke gedrag van de bezoeker zoveel mogelijk wordt gesimuleerd. Testers gaan op de website op zoek naar informatie, op een wijze zoals een gewone gebruiker dat zou doen. Dit kan problemen aan het licht brengen die met meer gestructureerde technieken over het hoofd worden gezien. Belangrijk is om deze techniek als aanvulling op andere technieken te gebruiken. Als enige vorm van testen is zij ontoereikend, omdat veel soorten fouten hiermee niet ontdekt kunnen worden.

Checklist continuïteit Eén van de doelstellingen is vaak de website 7x24 uur online te hebben. In de checklist betrouwbaarheid in bijlage I worden een aantal relevante controles genoemd om de haalbaarheid daarvan te beoordelen. Checklist onderhoudbaarheid Bij het beoordelen van de onderhoudbaarheid van webtoepassingen kan gebruik worden gemaakt van de checklist die in bijlage L is opgenomen. Cookietesten Een cookie is een stukje informatie dat door een webserver naar een client wordt gestuurd om daar opgeslagen te worden. De inhoud van de cookie kan later door de webtoepassing uitgelezen worden. Dit is handig om de browser specifieke informatie te laten onthouden. Als er geen gebruik wordt gemaakt van cookies, dan beschouwt de server elke vraag om een webpagina als een onafhankelijke, nieuwe aanvraag. Met behulp van cookies kan een sessieidentificatie worden vastgesteld, die door de webserver aan de client wordt aangeboden. Bij elk volgend contact stuurt de client informatie uit de cookie naar de webserver. Zodoende kan een vorm van communicatie ontstaan, waarbij de toestand van de communicatie bekend blijft. Dit is voor e-commerce een vereiste. Cookies moeten getest worden omdat zij kunnen verlopen en omdat gebruikers ze uit kunnen schakelen. Zaken die men kan beoordelen zijn het gedrag van de browser: ? ? ? ?

na het verlopen van een cookie; indien de gebruiker de cookie heeft uitgeschakeld; indien de gebruiker de cookie heeft uitgeschakeld tijdens een sessie (bezoek aan de website); indien de gebruiker de cookie van zijn harde schijf verwijdert tijdens een sessie.

Smoke testing Eventueel kan men dagelijks de laatste versies van alle bestanden compileren en laden in de testomgeving, teneinde een aantal globale controles te verrichten. Dit voorkomt dat er onopgemerkt code wordt ontwikkeld die niet functioneert. Deze vorm van testen staat bekend als smoke testing. Regressietesten De beheerstaak is voornamelijk gericht op het monitoren van de website. Is de website online en werkt alles naar behoren? Hierbij kunnen record-andplayback tools heel handig zijn. Door een script te maken voor het testen van een aantal functionaliteiten, kan deze test met behulp van de tool regelmatig herhaald worden. Dit herhalen kan ingepland worden, zodat bijvoorbeeld meerdere malen per dag een automatische check wordt uitgevoerd. Dit

herhaald uitvoeren van dezelfde testgevallen heet regressietesten en kan dus ook heel goed gebruikt worden voor monitoring. 5.4.4

Monitoring

Naast de reguliere testsoorten zoals programma-, integratie-, systeem- en acceptatietest kan voor het testen van e-businesssystemen een nieuwe testsoort worden onderkend. Deze wordt door KZA aangeduid met de term monitoring (zie figuur 12).

Monitoring

Productie acceptatietest

Functionele acceptatietest

Systeemtest

Integratietest

Programmatest

Figuur 12: testsoorten bij het testen van e-business

Dit behelst het periodiek controleren van de correcte werking van de webtoepassing nadat deze in productie is genomen. Daarbij wordt met name gecontroleerd op continuïteit, performance en de correcte werking van links. Continuïteit om te bewaken dat de toepassing operationeel is en performance omdat deze achteruit kan gaan als gevolg van overbelasting van de toepassing of het onder de maat presteren van een provider. Links kunnen plotseling niet meer functioneren doordat websites worden verplaatst of opgeheven. Het is dus van belang regelmatig te checken of de websites waar links naar worden gelegd nog actief zijn en niet zijn verplaatst. Bij reguliere informatiesystemen is monitoring overbodig, daar verstoringen direct aan het licht komen. Immers, interne medewerkers van de organisatie werken dagelijks met het informatiesysteem en melden problemen bij functioneel beheerders. Voor een e-businesstoepassing ligt dat anders. Een website kan uren uit de lucht zijn zonder dat de organisatie dit in de gaten heeft.

Een andere factor die monitoring noodzakelijk maakt is het feit dat er diverse zaken zijn waarop de organisatie geen invloed kan uitoefenen. Zo kunnen de prestaties van de Internet Service Provider tekortschieten of externe links worden verbroken doordat websites zijn verplaatst. Een andere factor die testen tijdens de gehele levenscyclus van het systeem noodzakelijk maakt is het feit dat veel websites constant evolueren. Zowel de content, de structuur als de functionaliteiten wijzigen regelmatig. Naast het testen van de wijzigingen dient vastgesteld te worden dat de niet-gewijzigde onderdelen volgens verwachting blijven presteren. Geautomatiseerde regressie- en performancetesten zijn de instrumenten bij uitstek om de monitoring handen en voeten te geven. Dit vanwege het feit dat de tests vaak herhaald worden. Het valt aan te raden om tijdens het ontwikkelen testtraject deze regressie- en performancetesten op te zetten en te benutten. Doordat de testautomatisering vroeg in het project plaatsvindt, is er meer terugverdientijd. In bijlage F is een overzicht van tools opgenomen die speciaal zijn ontworpen voor het testen van webapplicaties. Een alternatief voor het aanschaffen van regressie- en performancetesttools is het abonneren op een online service die regelmatig de beschikbaarheid en performance van de website controleert. De rol die testtools spelen bij het testen van internettoepassingen wordt benadrukt in het onderstaande citaat. Deze is afkomstig van de algemeen directeur van een van de succesvolste toolleveranciers in de Verenigde Staten. Derhalve moet een en ander dat in het citaat wordt gezegd in dit licht worden beschouwd. Anderzijds is het citaat illustratief voor het feit dat bij het testen van toepassingen op het internet men niet om het gebruik van tools heen kan. “Internet success is intrinsically tied to WebSite Quality. Whether companies like to admit it or not, how their WebSite looks, feels, and behaves makes a major impact on customers. Assuring Quality of Experience is a part of the larger picture nowadays called Quality of Service. Quality of Service efforts aim at assuring timely delivery of pages, assurance that "deep transactions" are trouble-free, and making sure that actual user experiences are good and productive. Technical approaches to accomplish Quality of Service for WebSites include the conventional software engineering configuration management methods, routine testing for such common errors as broken links, and deeper analysis of end-to-end experiences. All of these focus, in one way or other, on the processes of testing of WebSites, that is, making experiments. Obviously, in a Web-time world and for practical reasons, manual testing and experimentation can't possible meet the requirement for assuring large, complex, and techically deep WebSites. Present-day automated support tools run the gamut from simple proxy-based analyzers, to powerful applications of client-server technology, to sophisticated test-enabled web browsers. If you're

responsible for WebSite Quality you owe it to yourself to come up to speed with the newest tools and techniques for assuring WebSite quality. In most cases, the work needed can only be done by using the correct combinations of state of the art tools. They'll save you work, enhance your analytic powers, and contribute quickly and inexpensively to realistic increases in your WebSite Quality of Service.” Edward Miller, Chairman, Software Research, Inc Monitoring van operationele webtoepassingen speelt in alle e-businessstadia een rol. Aangezien er voor de overige stadia geen specifieke toevoegingen zijn aan de hier gemaakte opmerkingen wordt dit fenomeen in de volgende hoofdstukken niet opnieuw behandeld.

6

Testen in het Interactie-stadium

6.1 Inleiding In het Interactie-stadium is communicatie (interactie) mogelijk. Er is een gegevensstroom naar de gebruiker toe, maar de gebruiker zendt ook gegevens terug. Deze interactie kan bijvoorbeeld leiden tot speciaal voor een gebruiker opgebouwde pagina’s, berichten van de gebruiker die voor anderen beschikbaar komen en het ophalen van accountgegevens uit de back-office van de organisatie. Typische voorbeelden van websites die tot dit stadium behoren zijn de aanbieders van financiële producten. Nadat de gebruiker een vragenformulier heeft ingevuld, wordt hem een offerte verstrekt. Ook kan worden gedacht aan zogenaamde forums waarop gebruikers onderling communiceren. Andere voorbeelden van websites met interactie zijn portals waarbij de pagina geheel volgens de wens van een specifieke gebruiker wordt samengesteld.

6.2 Beïnvloedingsfactoren 6.2.1

Stakeholders

Het is de bedoeling van de opdrachtgever om een relatie op te bouwen met de gebruiker van de website. Dit kan een kortstondige relatie zijn (alleen tijdens het bezoek) of een langdurige (herkenning bij een volgend bezoek). De gebruiker zal geprikkeld moeten worden om gegevens te verstrekken, maar hij zal daar ook iets voor terug willen zien. Deze verhouding dient in balans te zijn, anders zal de gebruiker niet geneigd zijn hier aan mee te werken. Het systeem zal dynamischer van opzet zijn dan een toepassing in het stadium Informatie. Zo zullen er gegevens worden opgeslagen. Ook kan er sprake zijn van een regelmatige update van informatie. Dit brengt met zich mee dat de beheerders van het systeem een aantal eisen op tafel zullen leggen. Een voorbeeld van een dergelijke eis is dat het eenvoudig moet zijn om de inhoud van de website aan te passen of uit te breiden. Om de continuïteit van de toepassing in de toekomst te kunnen garanderen, zullen de wensen uit deze hoek moeten worden meegenomen in het ontwerp. Een andere groep stakeholders wordt gevormd door degenen in de organisatie die moeten reageren op interacties van bezoekers. Hun manier van werken wordt beïnvloed door de toepassing, dus is het raadzaam om hen te betrekken bij het ontwerpen, ontwikkelen en testen van de toepassing.

6.2.2

Kwaliteitseisen

De meerwaarde van een systeem, in dit stadium wordt gevormd door het interactieve element van het systeem (de mogelijkheid tot communicatie). Deze interactiviteit zal dan ook naar behoren moeten functioneren. De gebruiker zal er intuïtief mee moeten kunnen werken. Omdat er meestal gegevens opgeslagen worden, is de beveiliging van het communicatieproces van belang. Met name waar het gaat om persoonlijke gegevens, zullen deze alleen op de daarvoor geëigende manier benaderd mogen worden. Toepassingen in dit stadium zullen over het algemeen slechts in beperkte mate leiden tot het genereren van extra inkomsten voor de organisatie. Het is dan ook de bedoeling dat de interactieve componenten relatief eenvoudig (tegen geringe kosten) beheerd kunnen worden. Dit geldt zowel voor het technische beheer als het beheer van de inhoud van de website. Zo zal bijvoorbeeld een forum op eenvoudige wijze geschoond moeten kunnen worden van verouderde discussies of ongewenste berichten. Ook moeten de verzamelde gegevens eenvoudig te gebruiken zijn. Hierbij kan worden gedacht aan het gebruik van (email) adressen voor een nieuwsbrief. Een typische toepassing in het stadium Interactie is het aanvragen en berekenen van offertes en het doen van bestellingen. De berekening van een offerte gebeurt online evenals het plaatsen van de gewenste order. Echter, de verwerking hiervan vindt geheel volgens de gebruikelijke wegen plaats. De internetapplicatie is dan één van de kanalen, naast de fax, telefoon en post, om dergelijke aanvragen binnen te krijgen. Aansluiting van het ebusinessinformatiesysteem op de organisatie is dan ook een must. Het kwaliteitsattribuut inpasbaarheid is daarbij van belang. De back-office moet in staat zijn om tijdig te reageren op verzoeken om informatie die online binnenkomen. Omdat vaak onbekend is hoeveel gebruik gaat worden gemaakt van de website is het goed om de schaalbaarheid in het oog te houden. De continuïteit van de informatievoorziening is vanaf dit stadium van nog groter belang, in verband met het interactieve element. De verwachting bij de regelmatige gebruiker is namelijk dat de service continu ter beschikking staat. Websites in het stadium Interactie zullen in het algemeen vaker worden gewijzigd dan websites in het stadium Informatie. De onderhoudbaarheid gaat derhalve een grotere rol spelen. In figuur 13 wordt een voorbeeld getoond van een website in het Interactiestadium.

Figuur 13: voorbeeld van een website in het Interactie-stadium

6.2.3

Architectuur

Een toepassing in het stadium Interactie stelt meer eisen aan de onderliggende infrastructuur, dan een toepassing in het stadium Informatie. Hoewel het dataverkeer voornamelijk éénrichtingsverkeer betreft van website naar het internet, kan er sprake zijn van updating van tabellen door de bezoeker van de website. Zoals reeds genoemd in paragraaf 4.2.2. zijn er wat betreft het stadium Interactie twee typen koppelingen met de back-office: 1. 2.

Er is een online koppeling met back-office-systemen; wijzigingen in de back-office zijn rechtstreeks zichtbaar op de website. Er is een batch koppeling met back-office-systemen; de database van waaruit de website wordt opgebouwd wordt op regelmatige tijden ververst.

Vanuit testoptiek wordt het interessant waar informatie wordt opgeslagen, zoals bijvoorbeeld het profiel van de bezoeker. Merk op dat bij type 1 er meestal een rechtstreekse koppeling met de back-office moet worden gerealiseerd en er sprake is van middleware. Deze middleware zorgt ervoor dat de front-office (de website) en de back-office efficiënt kunnen communiceren. De webserver is dan gekoppeld aan een applicatieserver waarop de back-office systemen draaien. Eventueel is er een databaseserver waarop de data wordt opgeslagen en

gemanipuleerd. Applicaties van type 2 zouden volledig op de webserver kunnen draaien. Overigens is het vanaf het Interactie-stadium waarschijnlijk dat de back-office systemen aangepast moeten worden om de front-end hier gebruik van te laten maken. Een typische toepassing in dit stadium is een website die wordt opgebouwd afhankelijk van het profiel van de gebruiker. Heeft de gebruiker in het verleden bepaalde interesses kenbaar gemaakt, dan wordt een pagina opgebouwd aan de hand van dit profiel. Een goed voorbeeld is een beleggingswebsite waar de gebruiker op kan geven in welke koersen hij geïnteresseerd is. Voortaan worden direct deze koersen getoond zonder dat de gebruiker één voor één de koersen hoeft op te zoeken. Webpagina’s worden in het Interactie-stadium in het algemeen dynamisch gegenereerd vanuit een database, in plaats van hardgecodeerd opgeslagen.

6.3 Impact op testen Stadium Interactie

Heeft impact op schakel

Beïnvloedingsfactor

Fasering Stakeholders

Testorganisatie

Infrastructuur

Technieken

X

Kwaliteitseisen

X

Architectuur

X

X

X

Figuur 14: impactmatrix voor het stadium Interactie (verbanden uit het voorgaande stadium zijn hier niet vermeld)

Naast de impact die de beïnvloedingsfactoren op het testen hebben, zoals vermeld bij het stadium Informatie, zijn er in het stadium Interactie een aantal kenmerkende zaken die invloed hebben op de vier schakels waar het gestructureerd testen op gebaseerd is. Betrokkenheid in een vroeg stadium is een must voor het testteam teneinde vanaf de start van het e-businessproject de wensen en eisen van de opdrachtgever goed in beeld te hebben. Om te kunnen meedenken met de opdrachtgever zullen er relatief veel testinspanningen vroeg in het ontwikkelproces moeten plaatsvinden. De koppeling van het “open” internet met de back-office van de organisatie heeft als gevolg dat er specialistische kennis omtrent onderwerpen zoals beveiliging voorhanden moet zijn binnen de testorganisatie om goed te kunnen

testen. Er zal bovendien gebruik moeten worden gemaakt van technieken die de gevolgen van deze koppelingen testen. Verder zullen er uitgekiende testomgevingen nodig zijn. Inrichting en beheer van de testomgeving wordt dus beïnvloed.

6.4 Testaanpak 6.4.1

Fasering

De opmerkingen voor het stadium Informatie gelden ook voor het stadium Interactie. Betrokkenheid in een vroeg stadium is een must. Om de wensen van de opdrachtgever op tafel te krijgen en te kunnen nagaan hoe deze uitgewerkt worden, is het vaak noodzakelijk initiatief te nemen om informatie te verkrijgen. Hierbij kan men op zoek gaan naar documentatie waarin vermeld staan: vormgevingseisen, inhoudelijke eisen (bijvoorbeeld de update-procedure), autorisatie, verantwoordelijkheden, bevoegdheden en beveiliging. De testactiviteiten dienen zo vroeg mogelijk van start te gaan. Het verrichten van statische tests parallel aan het opstellen van testgevallen voor dynamische tests is derhalve opportuun. 6.4.2

Testorganisatie

Door de interactieve aspecten neemt de complexiteit van de applicaties toe ten opzichte van het stadium Informatie. Dit kan er toe leiden dat het noodzakelijk wordt om specialistische ondersteuning op het gebied van de infrastructuur te betrekken. Met name voor het testen van performance en beveiliging kan dit nodig zijn. Een alternatief is om een testspecialist nauw te laten samenwerken met de ontwikkelaars. Het risico dat hiermee gepaard gaat, is dat de objectieve positie van het testteam in het gedrang zou kunnen komen. In figuur 15 is een voorbeeld gegeven van een mogelijke organisatiestructuur van een testproject. In dit voorbeeld is er een Problemmanager aangesteld die verantwoordelijk is voor het beheer van de testbevindingen en het bewaken van de voortgang van de afhandeling van deze bevindingen. De beheerder van de testomgeving richt de benodigde testinfrastructuur in en bewaakt de consistentie daarvan. De rol van Functionele ondersteuning wordt vervuld door procesdeskundigen. Zij brengen kennis in over het bedrijfsproces.

Projectleider

Testmanager

Functionele ondersteuning

Methodische ondersteuning

Problemmanager

Beheerder testomgeving

Testers

Beveiligingsspecialist

Figuur 15: voorbeeld van de structuur van een testorganisatie

Degene die de rol Methodische ondersteuning vervult, houdt zich bezig met het ontwikkelen van richtlijnen, templates en procedures voor het testteam en bewaakt het gebruik daarvan. Tevens kan de persoon in kwestie als coach van het testteam optreden. Het testteam bestaat in dit voorbeeld verder uit een aantal Testers en een specialist op het gebied van beveiliging. De hier beschreven organisatiestructuur dient als voorbeeld. In de praktijk zijn diverse alternatieve vormen denkbaar.

6.4.3

Infrastructuur

Daar waar de infrastructuur gebaseerd is op interactie met de back-office zal de testomgeving danig uitgebreid worden. Het is van belang hier voldoende ondersteuning voor te krijgen binnen de organisatie. Eventueel zal er expertise van buitenaf ingeschakeld moeten worden. Het beheer van de testomgeving vergt meer werk dan in het Informatie-stadium. 6.4.4

Technieken

Ten aanzien van de testtechnieken die reeds in het vorige hoofdstuk zijn beschreven wordt hier een aantal specifieke aandachtspunten voor het Interactie-stadium benoemd. Tevens worden een aantal nieuwe testtechnieken behandeld die in dit stadium een rol kunnen spelen. Voor specifieke handvatten wordt waar nodig verwezen naar de checklists in de bijlagen. Syntactische en semantische test Veel meer dan in het stadium Informatie zal er gewerkt worden met invulformulieren e.d. Deze dienen uitvoerig door middel van de syntactische en semantische testtechnieken onder de loep te worden genomen. Hiervoor is vereist dat de gewenste interactievorm duidelijk omschreven is. In principe kunnen deze interactieve elementen dan getest worden door de primaire invoercontroles na te lopen, alsmede de onderlinge relaties tussen de gegevens binnen de schermen en tussen de (invoer)gegevens en de reeds in de database aanwezige gegevens. Tevens behoeft het navigeren in de interactieve component (bijvoorbeeld een formulier) aandacht. Het eenvoudige gebruik van dit element is essentieel voor de kwaliteit van de applicatie, zoals de eindgebruiker die ervaart. Dataflowtest In het geval dat de interactie verder gaat dan de Internet Service Provider, zullen er koppelingen tussen de website en de informatiesystemen binnen de organisatie worden gelegd. Hier zal speciale aandacht moeten worden besteed aan de interfaces, zowel in technische zin als voor wat betreft het tijdsaspect dat hiermee verbonden is. De gegevens zullen volgens vastgestelde regels van de ene naar de andere component moeten gaan. De dataflowtest is een goede testtechniek om deze zaken te testen. Koppelbaarheidsstest Op het moment dat er voor de interactieve elementen zaken als applets en plug-ins (programma’s die ervoor zorgen dat een website extra functionaliteit biedt aan degenen die over het programma beschikken) worden gebruikt, dient er extra aandacht te zijn voor het testen daarvan. Interessante vragen in deze zijn:

? ? ? ?

in hoeverre is de website compatibel met eerdere versies van browsers; wat gebeurt er als een gebruiker bijvoorbeeld een vereiste plug-in niet tot zijn beschikking heeft; wat zijn de eisen die men stelt aan de dataverbinding en de PC-configuratie van de eindgebruiker; zijn deze eisen realistisch?

Het uitproberen van diverse configuraties (diverse versies van browsers, ontbreken van plug-ins) levert inzicht op in de gevolgen van het gebruik van applets en plug-ins. Performancetest Een verschil met een systeem in het stadium Informatie is dat het interactieve gebruik van het systeem zal leiden tot extra belasting van de server. Zeker zal onder de loep moeten worden genomen welke responstijd acceptabel is en wat de invloed is van bijvoorbeeld meerdere gelijktijdige gebruikers. Zie ook de checklist efficiëntie in bijlage J. Ook in dit stadium valt het gebruik van een performance testtool aan te raden. In bijlage F is een aantal bruikbare testtools vermeld. Error guessing/semantische test en checklist beveiliging Nu er gegevens over bezoekers opgeslagen gaan worden op de server van de Internet Service Provider of op de eigen systemen, wordt beveiliging een belangrijk aandachtspunt. De opgeslagen data zal afhankelijk van de privacygevoeligheid en de strategische waarde voor de organisatie in meerdere of mindere mate beschermd moeten zijn tegen invloeden van buitenaf. Allereerst kan de vraag worden gesteld of bij de gekozen oplossing voldoende rekening is gehouden met dergelijke aspecten: wordt bijvoorbeeld het volledige klantenbestand, inclusief de financiële gegevens, op de server van de Internet Service Provider opgeslagen? Als dit het geval is, dient vastgesteld te zijn dat deze de beveiliging van deze gegevens goed heeft geregeld. Indien er sprake is van echt cruciale gegevens die door de gebruiker worden verstuurd, dient te worden bekeken of veilige communicatieprotocollen zijn geïmplementeerd. De beveiliging wordt vaak getest met een vorm van error guessing. Het is daarbij van belang dat de tester deskundig genoeg is op het gebied van beveiliging. Daarnaast is het zaak om de ongestructureerdheid die deze testtechniek in zich heeft binnen de perken te houden. Om een kader te plaatsen zullen allereerst de te onderzoeken zwakke plekken van het systeem worden geïdentificeerd. Vervolgens wordt tijdens de testuitvoering gezocht naar gaten in de beveiliging. Achteraf worden de gehanteerde testgevallen gedocumenteerd, ten behoeve van de reproduceerbaarheid van de testresultaten.

De semantische testtechniek kan zijn waarde goed bewijzen bij het testen van de beveiliging op het gebied van autorisatie en identificatie. Ook bij het testen van online-formulieren op beveiligingsaspecten komt deze techniek van pas. Daarbij wordt onderzocht of het systeem een onjuiste invoer correct ondervangt. Eventueel kunnen beveiligingsdeskundigen of hackers worden ingeschakeld om de beveiliging te beoordelen en om pogingen te doen om deze te doorbreken. Bij het beoordelen van de beveiliging kan eveneens gebruik worden gemaakt van de checklist functionaliteit in bijlage K. Daar zijn diverse toetsvragen met betrekking tot beveiligingsaspecten in opgenomen. Voorbeeld: beveiliging interactie met patiënt Het navolgende betreft een fictief voorbeeld. Ziekenhuis “De Zorg” richt een website in waarop patiënten informatie kunnen raadplegen omtrent wachtlijsten, de datum en het tijdstip van hun volgende controlebezoek en overige persoonsgebonden informatie. Dit doen zij door het inbrengen van enkele persoonlijke gegevens en een wachtwoord, op basis waarvan hun identiteit wordt geverifieerd. Vervolgens kunnen zij een persoonsgebonden behandeldossier raadplegen Het waarborgen van de privacy van de patiënt wordt buitengewoon belangrijk geacht. Daartoe worden maatregelen getroffen om de identiteit van de bezoeker van de website vast te stellen, de authenticiteit van berichten te waarborgen (heeft de persoon werkelijk een bericht verzonden/informatie opgevraagd) en de integriteit van berichten te waarborgen (is het bericht niet gewijzigd). Alvorens de toepassing beschikbaar te stellen aan het publiek dient vastgesteld te worden dat de beveiliging adequaat werkt. De KWTS biedt daartoe de volgende mogelijkheden: ? ? ? ?

verrichten van een toetsing van de beveiliging aan de hand van checklisten; uitvoeren van een semantische test waarmee de identificatieprocedure wordt getest en de toereikendheid van de beveiliging van de user interface wordt vastgesteld; uitvoeren van een security audit door beveiligingsexperts; uitvoeren van een penetratietest aan de hand waarvan de totale beveiliging wordt getoetst (inclusief zaken als authenticiteit en integriteit van berichten, de mate waarin de toepassing bestand is tegen hackers e.d.).

Bruikbaarheidstest Bij interactieve elementen is het van belang dat het voor de gebruiker duidelijk is wat er met zijn gegevens gebeurt. Hij of zij wil daar ook garanties over. Allereerst moet de gebruiker daarom kunnen nagaan wat er gebeurt met de informatie. Dit kan bijvoorbeeld door:

? ? ?

een melding terug te geven als een ingevuld formulier is verwerkt; het direct tonen op een forum van het zojuist ingevoerde bericht; het bevestigen van een bestelling door middel van een e-mailbericht.

Het invoeren van gegevens moet gemakkelijk gaan. Zo zal de gebruiker in staat moeten worden gesteld om onjuiste invoer in een online-formulier te corrigeren. Het systeem dient aan te geven waar en wat er mis is gegaan, maar dient wel alle correcte gegevens intact te laten. Een aantal van de bovenstaande eisen zijn moeilijk in meetbare eenheden uit te drukken. Eén van de mogelijkheden om hier toch een goed oordeel over te geven is om een bruikbaarheidstest te verrichten (zie het voorgaande hoofdstuk). Procescyclustest De koppeling van de toepassing met de bestaande organisatie en met andere informatiesystemen komt in dit stadium om de hoek kijken. Zo zal duidelijk moeten zijn hoe de respons op acties van gebruikers dient te verlopen. Ook kan men, via e-mail of telefonisch, vragen verwachten over het gebruik van de website. Met behulp van de procescyclustest kan onderzocht worden of de inpasbaarheid van de toepassing in de bestaande organisatie adequaat is geregeld. Statistische gegevens/checklist betrouwbaarheid Het systeem zal een grote mate van betrouwbaarheid moeten hebben. De database kan belangrijke informatie bevatten die niet zomaar verloren mag gaan. Ook de foutbestendigheid van het geheel is belangrijk; er kan niet op worden vertrouwd dat internetgebruikers altijd juiste informatie verstrekken. Het starten van interacties met onzinnige data als invoer kan zelfs gebruikt worden om systemen te ondermijnen. In geval van storingen moet men kunnen terugvallen op back-up systemen. Er zal dus zowel een procedure aanwezig moeten zijn voor het maken van de back-up, als voor het terugzetten van de back-up. Al deze zaken dienen om een maximale continuïteit te waarborgen. Gebruik van checklists (zie bijlage I) en statistische gegevens over de Mean Time Between Failures (gemiddelde tijd tussen het optreden van storingen) komt van pas bij het beoordelen van de betrouwbaarheid. Checklist efficiëntie Het kan gebeuren dat de gegevens die worden opgeslagen de inhoud van de database steeds verder laten toenemen. De vraag kan worden gesteld hoe snel dit gaat, wat de grenzen zijn, wanneer deze bereikt worden en wat er vervolgens gebeurt. De checklist efficiëntie kan van pas komen bij het verrichten van een beoordeling (zie bijlage J).

Checklist onderhoudbaarheid Wijzigingen moeten relatief eenvoudig doorgevoerd kunnen worden. Om dit te beoordelen zijn diverse controles beschikbaar (zie de checklist onderhoudbaarheid in bijlage L).

7

Testen in het Transactie-stadium

7.1 Inleiding Bij organisaties met een website behorende tot het stadium Transactie wordt het volledige handelsproces ondersteund via het internet. Er kunnen handelstransacties plaatsvinden via de website. Typische voorbeelden zijn online boekwinkels en supermarkten waarbij goederen online worden besteld en afgerekend waarna ze worden geleverd. Ook online veilingen behoren tot dit stadium.

7.2 Beïnvloedingsfactoren 7.2.1

Stakeholders

Het gebruikersprofiel kan zeer divers zijn. Bij een online boekwinkel is de gebruiker de gemiddelde internetsurfer. De gebruikers van een real-time beleggingswebsite vormen een specifieke doelgroep. De vertegenwoordigers van een organisatie die het internet gebruikt om (afgeschermd met wachtwoorden) orders op te geven zijn een zeer selecte en bekende gebruikersgroep. Elke groep heeft zo zijn eigen wensen. In de stadia Informatie en Interactie was de impact van de ebusinesstoepassing op de organisatie nog relatief gering. De medewerkers hadden er in het algemeen slechts incidenteel mee te maken en bovendien liep de informatiestroom parallel met andere informatiestromen. Zo kwamen er informatieaanvragen binnen per e-mail, alsook per post en telefonisch. In het stadium Transactie daarentegen gaat de informatiestroom van de ebusinesstoepassing een leidende rol spelen in het primaire bedrijfsproces. Dit betekent dat de werkzaamheden van de medewerkers en de werking van het informatiesysteem goed op elkaar moeten aansluiten. De gehele organisatie krijgt te maken met de e-businesstoepassing en diverse afdelingen zullen derhalve een stem in het ontwerp- en ontwikkelproces willen hebben. 7.2.2

Kwaliteitseisen

De gebruikersvriendelijkheid en de uitstraling van de website zijn nog steeds zeer belangrijk en kunnen beslissende factoren zijn bij toepassingen die moeten concurreren met vergelijkbare toepassingen van andere organisaties. Daarnaast is het bij het doen van betalingen een absolute voorwaarde dat inzichtelijk is wat er precies gebeurt. Het te betalen bedrag en de opbouw daarvan zal helder moeten zijn, evenals de procedure waarlangs de betaling verloopt.

In het geval dat de toepassing een bekende groep gebruikers bedient is er een aantal voordelen te behalen boven de situatie van een website voor de grote massa. Men kan immers deze gebruikers vragen wat hun wensen zijn en het is mogelijk de gebruikers te instrueren middels een handleiding of cursus (aangezien de doelgroep bekend is). Een dergelijke situatie doet zich bijvoorbeeld voor bij een internettoepassing die wordt gemaakt voor de medewerkers van een bepaald bedrijf (intranet). De e-businesstoepassing ondersteunt in het stadium Transactie een primair bedrijfsproces. De slagvaardigheid van de organisatie wordt voor een groot deel afhankelijk van de prestaties van het systeem. Deze prestaties zullen in een sterk concurrerende (internet)markt continu op een hoog niveau moeten worden gehandhaafd. Dat vergt veel aanpassingen in de informatie op de website, maar wellicht ook in de structuur van de website (en de organisatie) om de benodigde flexibiliteit te kunnen waarborgen. Hier zit een groot verschil met reguliere systemen. Daar wordt in principe een starre oplossing gerealiseerd voor de middellange termijn, terwijl de internetapplicatie een structuur moet bieden waarin zelfs op kortere termijn relatief eenvoudig zaken moeten kunnen worden gewijzigd. Fulfillment (het daadwerkelijk tot een goed einde brengen van een transactie) is een randvoorwaarde voor succes. Des te opvallender is, dat uit onderzoek van Accenture (voorheen: Andersen Consulting) blijkt, dat ruim een kwart van de binnengekomen orders nooit wordt uitgevoerd. De fulfillment wordt gewaarborgd door een goede aansluiting tussen de website, de back-office-systemen en het bedrijfsproces. De kwaliteitseigenschappen koppelbaarheid (van applicaties) en inpasbaarheid (in de werkprocessen) spelen derhalve een centrale rol. In figuur 16 wordt een voorbeeld getoond van een website in het Transactiestadium.

Figuur 16: voorbeeld van een website in het Transactie-stadium

7.2.3

Architectuur

De architectuur van een toepassing in het stadium Transactie kenmerkt zich door de volledige integratie met de back-office. Verder is de interactie met derde partijen opvallend. Deze partijen verifiëren de identiteit van de gebruiker (authentificatie) en handelen (bijvoorbeeld) diens betaling af.

7.3 Impact op testen Stadium Transactie

Heeft impact op schakel

Beïnvloedingsfactor

Fasering Stakeholders

Kwaliteitseisen

Architectuur

Testorganisatie

Infrastructuur

Technieken

X X X

Figuur 17: impactmatrix voor het stadium Transactie (verbanden uit voorgaande stadia zijn hier niet vermeld).

De impact van de stakeholders op het testen is met name afhankelijk van de rol die het testteam dient te spelen in het project. Dit zal de planning en organisatie van het testtraject kunnen beïnvloeden. In de fasering en de testorganisatie dient rekening te worden gehouden met het feit dat overleg plaats zal vinden met een groot aantal partijen. Inpasbaarheid in de organisatie en het testen daarvan winnen aan belang, hetgeen impliceert dat in de testorganisatie deskundigen met betrekking tot het bedrijfsproces opgenomen dienen te worden. Door de mate van complexiteit, die onder andere het gevolg is van de koppelingen met derde partijen, zullen de eisen aan het inrichten van de tests toenemen. De inrichting van testomgevingen dient daarom de nodige aandacht te hebben.

7.4 Testaanpak 7.4.1

Fasering

Voor het stadium Transactie is de enige wezenlijke verschuiving dat er met een groter aantal partijen overleg wordt gevoerd. Hier dient in de testplanning rekening mee te worden gehouden. 7.4.2

Testorganisatie

Meer dan bij vorige stadia grijpt de e-businesstoepassing in op het primaire bedrijfsproces. De testorganisatie is over het algemeen niet verantwoordelijk voor deze problematiek, maar er zijn natuurlijk raakvlakken. Een pro-actieve houding van het testteam bij het bepalen van de mate van aansluiting tussen de

IT-oplossing en de organisatie is van belang. Verder is het belangrijk om niet te veel te focussen op de werking van technische componenten. De inpasbaarheid in de organisatie en afhankelijkheden tussen systemen en bedrijfsprocessen zullen getoetst moeten worden. Dit betekent voor het testteam dat er teamleden van diverse pluimage in moeten zitten (testers, gebruikers, procesdeskundigen). Met name het toevoegen van personen met kennis van het bedrijfsproces is dringend gewenst, aangezien de inbreng van hun kennis leidt tot betere tests van de inpasbaarheid van de toepassing in de organisatie en werkprocessen. De testmanager krijgt te maken met diverse partijen. Er zullen afspraken moeten worden gemaakt met externe partijen om testomgevingen op te bouwen en tests uit te voeren. Dit betekent dat de testcoördinator hiervoor voldoende tijd moet inplannen. 7.4.3

Infrastructuur

Vanwege de koppeling met derde partijen en het werken met meerdere componenten zal het inrichten van de testomgeving speciale aandacht vergen. Een doordacht plan voor het integraal testen van de verschillende onderdelen is noodzakelijk. De testomgeving omvat de front-end webtoepassing, middleware, back-officesystemen en koppelingen naar derde partijen. Het opzetten en beheren van een dergelijke complexe omgeving vereist een zorgvuldige planning, expertise ten aanzien van infrastructuur en capaciteit. Procedures voor versiebeheer zijn benodigd om te voorkomen dat onjuiste configuraties leiden tot onjuiste testresultaten. Verder is het aan te bevelen om de tests zo in te richten dat er regressietesten uitgevoerd kunnen worden. Dit is noodzakelijk, aangezien ebusinesstoepassingen in dit stadium frequent gewijzigd worden (zowel voor als na de inproductiename). Bij het inrichten van regressietesten kan gebruik worden gemaakt van testtools (zie de bijlagen E en F). 7.4.4

Technieken

Checklist beveiliging Het is van belang vertrouwelijke gegevens zo ver mogelijk van het publieke net te bewaren (dus niet op de webserver) en extra te beveiligen. Verder zullen de gegevens die door gebruikers verstuurd worden zeer zorgvuldig gecontroleerd moeten worden. Er mogen geen gegevens kunnen worden gegenereerd welke de back-office-systemen kunnen ondermijnen. De beveiliging van transacties zal deels worden geregeld door het toepassen van technische maatregelen, zoals het versleutelen van gegevens en het gebruik van veilige communicatieprotocollen (zoals Secure Socket Layer). Daarnaast wordt idealiter een dichtgetimmerde procedure bedacht om de

transactie via derde partijen te laten verlopen. Gecontroleerd moet worden of aan alle afspraken wordt voldaan, of alle standaarden goed worden geïmplementeerd en of de procedures inderdaad waterdicht zijn. De checklist functionaliteit in bijlage K is een behulpzaam instrument bij het beoordelen van de mate van beveiliging. Dataflowtest De integratie met de interne organisatie gaat nog verder dan in het stadium Interactie. De koppeling met back-office-systemen zoals systemen voor boekhouding, voorraadbeheer en logistiek zal dan ook nader onder de loep moeten worden genomen. Een testtechniek die hierbij kan worden toegepast is de dataflowtest. Nu er sprake is van online-handelstransacties is de compleetheid van de geleverde informatie vanwege juridische aspecten nog belangrijker dan in het Interactie-stadium. Verder is de compleetheid van transacties belangrijk. Een transactie moet volledig afgerond en bevestigd zijn, wil men zich op enige geldigheid kunnen beroepen. Regressietesten Bij een toepassing in het stadium Transactie valt te verwachten dat er veel wijzigingen zullen optreden ten gevolge van voortschrijdend inzicht en nieuwe technologische mogelijkheden. Veel organisaties willen daar direct op inspelen en zullen de toepassing wijzigen. Dit vereist goed opgezette testscripts. Immers, deze zullen vaak moeten worden aangepast en opnieuw worden uitgevoerd. Testtools kunnen daarbij zeer behulpzaam zijn. Wanneer de testscripts eenmaal in een testtool zijn ingevoerd, kan het script eenvoudig worden uitgevoerd. De voordelen dienen uiteraard wel op te wegen tegen de investering die moet worden gedaan in verband met de inrichting van de testtool. Of een investering in een testtool gerechtvaardigd is kan onder andere worden beoordeeld door enerzijds de kosten van de tool en de implementatie te berekenen en anderzijds de tijdsbesparingen die kunnen worden gerealiseerd bij gebruik van de tool te bepalen. Aan de hand van deze informatie kan worden vastgesteld of implementatie van een tool tot financiële voordelen leidt. Overigens kunnen ook niet-financiële overwegingen een rol spelen bij de keuze om een testtool in te zetten. Voorbeelden daarvan zijn dat bepaalde tests handmatig niet verricht kunnen worden en dat het gebruik van tools een bepaalde uniformiteit in de werkwijze afdwingt. Procescyclustest Het informatiesysteem zal een centrale plaats innemen in het bedrijfsproces. Daarom is het van belang om vast te stellen of de e-businesstoepassing adequaat aansluit bij de bedrijfsprocessen en de back-office-systemen. Een procescyclustest kan antwoord geven op de vraag of het e-businesssysteem inpasbaar is in zijn omgeving (aansluiting bij procedures/systemen).

Performancetest De schaalbaarheid van de e-businesstoepassing wordt nu nog belangrijker. Door marktwerking kan het aantal bezoekers op de website snel toenemen, hetgeen door het systeem moet kunnen worden opgevangen. Uitgebreide tests met wisselende belastingen zijn absoluut noodzakelijk. Zie ook hetgeen is beschreven ten aanzien van performancetesten in het Informatie-stadium. Een nieuw element is dat klanten hun “virtuele winkelwagen” kunnen verlaten zonder een transactie af te ronden. Voor de e-businesstoepassing is niet duidelijk dat de transactie is afgebroken, dus wordt de data over de klant en diens potentiële bestelling vastgehouden. Dit kan leiden tot resource locking, oftewel het bezet houden van capaciteit en/of geheugenruimte. Dit is een belangrijk aandachtspunt tijdens het opzetten van een performancetest. In de testscripts moet ervoor worden gezorgd dat een fors percentage van de virtuele klanten de transactie tussentijds afbreekt. Te denken valt daarbij aan een percentage tussen de 60% en 80%, hetgeen overeenkomt met gangbare uitvalpercentages bij online-winkels. Bruikbaarheidstest De beleving van de gebruikers is nog steeds het best te testen met een bruikbaarheidstest. Daarbij wordt met name aandacht besteed aan de gebruikersvriendelijkheid van de bestelprocedure en het gemak waarmee betalingen kunnen worden verricht. Checklist onderhoudbaarheid Belangrijke aspecten zijn de wijzigbaarheid van het systeem en een efficiënt beheer. Functionaliteiten die hiervoor gewenst zijn zullen in kaart moeten worden gebracht en worden getoetst. De onderhoudsprocedures mogen niet als ingewikkeld of omslachtig worden ervaren. Dit kan worden nagevraagd bij de beheerders. Verder is de checklist onderhoudbaarheid behulpzaam bij het testen van dit aspect (zie bijlage L). Voor een goede traceerbaarheid is de inrichting van tracking en tracing van groot belang. Het zal relatief eenvoudig moeten zijn om de herkomst en levensloop van elke transactie te achterhalen. In het geval van storingen kan zo worden achterhaald wat er precies gebeurd is.

8 Testen in het Integratie-stadium 8.1 Inleiding In dit stadium is de organisatie volledig afgestemd op het elektronisch zakendoen door de inzet van e-businesstechnologieën binnen de keten(s) waar de organisatie deel van uitmaakt. De internettechnologie kan behulpzaam zijn bij het koppelen van bedrijfsprocessen. Nieuwe producten en/of diensten kunnen ontstaan door samenwerking binnen de keten. Een website waarop gehandeld kan worden in effecten is een voorbeeld van een toepassing die tot het stadium Integratie kan worden gerekend. De broker (makelaar) brengt de binnenkomende elektronische orders rechtstreeks op de beurs en verwerkt de transacties vervolgens elektronisch. Deze processen vinden zonder menselijke tussenkomst plaats. De basis van systemen in dit stadium zijn die uit het stadium Transactie. De focus van de testaanpak ligt dan ook op de zaken aangaande de koppeling en samenwerking met andere organisaties en systemen.

8.2 Beïnvloedingsfactoren 8.2.1

Stakeholders

De organisaties in de waardeketen waarmee koppelingen worden gelegd komen op de lijst van stakeholders. Van de overeengekomen protocollen, procedures en overige afspraken kan niet makkelijk worden afgeweken omdat zij het uitgangspunt voor de samenwerking vormen. Er moet dus duidelijkheid bestaan over de afspraken en volgens welke standaarden er wordt gewerkt. In het geval dat het systeem bestemd is voor een specifieke/beperkte groep gebruikers (bijvoorbeeld de inkopers van technische producten) zullen de eisen specifieker zijn en bestaat veelal ook de mogelijkheid deze te inventariseren. Indien het verzamelen van eisen tot de mogelijkheden behoort heeft dit absolute prioriteit in een vroeg stadium van het project. 8.2.2

Kwaliteitseisen

Door de integratie is het mogelijk om op een hoog serviceniveau uit te komen. Het imago van de organisatie wordt hier echter wel aan gekoppeld. Het belang van het slagen van dergelijke trajecten is dan ook groot. Zowel financieel, als

ook met betrekking tot het verliezen van tijd (achterop raken), maar zeker ook in verband met de goede naam van de organisatie. Een belangrijke eis is dan ook een goede werking van de toepassing op het gebied van correctheid, actualiteit, gebruikersvriendelijkheid en betrouwbaarheid. Allemaal items die in de vorige stadia reeds aan bod zijn gekomen. Zij blijven onverminderd van toepassing. De focus voor het stadium Integratie ligt sterk op de koppeling met andere organisaties en informatiesystemen. De kwaliteitseigenschap koppelbaarheid staat dus centraal. In figuur 18 wordt een voorbeeld getoond van een website in het Integratiestadium.

Figuur 18: voorbeeld van een website in het Integratie-stadium

8.2.3

Architectuur

De wijziging ten opzichte van het stadium Transactie zit vooral in de informatiestromen die de logistieke en financiële processen van de organisatie koppelen aan andere organisaties.

8.3 Impact op testen Stadium Integratie

Heeft impact op schakel

Beïnvloedingsfactor

Fasering Stakeholders

X

Testorganisatie

Infrastructuur

X X

Kwaliteitseisen

Architectuur

Technieken

X

X

Figuur 19: impactmatrix voor het stadium Integratie (verbanden uit voorgaande stadia zijn hier niet vermeld).

Het belangrijkste aspect in dit stadium is het feit dat er voor het testen nauw moet worden samengewerkt met een aantal andere organisaties naast die van de opdrachtgever. In de testplanning wordt rekening gehouden met de noodzaak om alle koppelingen te testen. Voor de testorganisatie is het gevolg van de nieuwe stakeholders dat er weer een aantal overlegvormen bijkomt en dat er afspraken moeten worden gemaakt over de taakverdeling tussen teamleden afkomstig uit diverse organisaties. Aangezien koppelbaarheid een belangrijk thema is zal men bij de selectie van testtechnieken geschikte technieken voor deze kwaliteitseigenschap moeten meenemen. De testomgeving dient de systemen van diverse organisaties en koppelingen daartussen te omvatten. Op organisatorisch vlak leidt dit tot speciale aandacht voor het managen van alle testactiviteiten. Op technisch vlak heeft dit met name impact op de inrichting van de testinfrastructuur.

8.4 Testaanpak 8.4.1

Fasering

Het testen van specifieke zaken op het gebied van koppelingen met andere organisaties en systemen buiten de eigen organisatie is voor wat betreft de uitvoering vaak het sluitstuk van het hele testtraject. Dat is inherent aan de werking van het geheel. De voorbereiding en specificatie is echter een traject dat net zo goed als de overige testactiviteiten reeds vroeg in het project zal moeten worden opgezet. Met name de communicatie en afstemming over de werkwijze met derde partijen is een proces dat trager verloopt dan men meestal wenst. Het testen kan onder druk komen te staan door (bijvoorbeeld)

vastgestelde opleverdata. Het testen van de koppelingen zal daarom tijdig een eigen plaats in het testtraject moeten krijgen. 8.4.2

Testorganisatie

Het testen van de gehele keten kan pas worden uitgevoerd als de betreffende systemen per organisatie naar behoren werken. Er zullen afspraken moeten worden gemaakt over welke onderdelen er getest gaan worden en wat de verwachtingen van elkaars systemen zijn. Er zal ook een gezamenlijk (geïntegreerd) testscript moeten komen waarin staat aangegeven welke testgevallen door wie worden gestart en welke output er van welk systeem of organisatie wordt verwacht. Het testen in deze fase is vooral een kwestie van plannen, voorbereiden en communiceren met diverse partijen. De rol van testmanager is relatief zwaar, want hij of zij krijgt te maken met een groot aantal stakeholders die invloed willen uitoefenen op het testtraject. Het testteam zal in het algemeen samengesteld zijn uit een testmanager, testers, materiedeskundigen (kenners van het bedrijfsproces en de markt), iemand die de methodische ondersteuning verzorgt en een beheerder van de testomgeving. Vaak zullen leden van het testteam afkomstig zijn uit diverse organisaties, waardoor het maken van gedegen afspraken omtrent taken, bevoegdheden en verantwoordelijkheden nog meer van belang is dan in de voorgaande stadia. 8.4.3

Infrastructuur

Het testen van de koppelingen met derde partijen kan niet geheel in eigen beheer. Hiervoor moeten samenwerkingsverbanden worden aangegaan met alle betrokken partijen. Het realiseren van een representatieve testomgeving is in dit stadium veelal onhaalbaar vanwege het grote aantal betrokken systemen en koppelingen. Anderzijds is het gebruik van het (open) internet voor testdoeleinden iets wat speciale zorg vraagt. Van tevoren kan men zich afvragen wat de gevolgen zijn wanneer tests mislopen. Waar komen dan de gegevens terecht? Kunnen er ook andere (delen van) websites beïnvloed worden? Wat zijn de risico’s voor het eigen netwerk? De testomgeving zal omvangrijk en complex zijn. Immers, de back-officesystemen van meerdere organisaties zullen er bij betrokken zijn. Er zal dan ook veel aandacht aan het beheer van die omgeving moeten worden geschonken. In de regel is dit minimaal één fulltime functie.

8.4.4

Technieken

De opmerkingen die in de voorgaande hoofdstukken zijn gemaakt ten aanzien van het gebruik van testtechnieken blijven onverminderd van kracht. Specifieke aandacht is vereist voor het verrichten van een ketentest. Tijdens zo’n test worden processen vanaf het begin tot het einde gesimuleerd. De aansluiting tussen processen en de werking van de infrastructuur wordt daarbij gecontroleerd. Dit gebeurt over de grenzen van de organisatie heen. Met name de koppeling met de systemen van organisaties in de bedrijfsketen krijgt bijzondere aandacht. Ook situaties die afwijken van de normale gang van zaken kunnen worden getest. Bijvoorbeeld: hoe te herstellen als een systeem is uitgevallen? Indien getest wordt in een real-life omgeving kunnen fouten worden gevonden die in een laboratoriumomgeving vaak niet naar voren komen: bijvoorbeeld responstijden die onvoldoende zijn. Ook speciale omstandigheden kunnen worden getest. Voorbeelden daarvan zijn: wat gebeurt er bij piekbelasting en welke invloed hebben (back-up) batchprocessen op de online perfomance? Een algemene eis is dat de systemen functioneel reeds moeten voldoen, voordat op deze wijze wordt getest.

9 Stappen bij het gebruik van KWTS® 9.1 Inleiding Het gebruik van de KZA Web Testing Solution sluit nauw aan bij de algemeen geldende principes van gestructureerd testen. Dat wil zeggen dat ook bij het testen van e-businesstoepassingen de fasen planning & beheer, voorbereiding, specificatie, uitvoering en afronding worden doorlopen (eventueel parallel en/of iteratief). De vier schakels van gestructureerd testen, fasering, infrastructuur, organisatie en technieken, blijven eveneens overeind. Dit hoofdstuk legt de link tussen de vijf fasen van het testproces en de rol die de KZA Web Testing Solution binnen deze fasen speelt.

9.2 Link testfasering en KWTS Hieronder is per fase aangegeven op welke wijze de KZA Web Testing Solution benut kan worden. Planning & beheer 1. 2. 3.

4.

5.

Bepaal het van toepassing zijnde stadium van e-business aan de hand van de checklist in bijlage B. Lees in dit boek na wat voor dat stadium de voorgestelde wijze van testen is. Bepaal samen met de opdrachtgever de teststrategie (op de in hoofdstuk 10 beschreven wijze), waarbij rekening wordt gehouden met de zaken die in dit boek staan beschreven en de risico’s die worden gelopen. Stel een testplan op dat gebaseerd is op de teststrategie en waarin zoveel mogelijk rekening is gehouden met de zaken die in dit boek staan beschreven. In bijlage O wordt de aanbevolen structuur van een e-businesstestplan beschreven. Schaf eventueel te gebruiken tools aan en plan en bewaak de implementatie daarvan.

Voorbereiding 6.

7.

Gebruik de KWTS bij het formuleren van toetslijsten ten behoeve van de detail intake van de testbasis en voer deze detail intake vervolgens uit. Voer zoveel mogelijk statische tests (tests aan de hand van checklists) zo vroeg mogelijk in het traject uit.

8. 9.

Specificeer de benodigde testinfrastructuur. Neem daarbij de in dit boek genoemde aandachtspunten in acht. Richt de te gebruiken tools in, verzorg eventueel trainingen ten aanzien van het gebruik en regel het beheer van de tools.

Specificeren 10.

11. 12.

Gebruik de diverse checklists ten aanzien van kwaliteitseigenschappen (zie de bijlagen H tot en met M) als basis voor het op maat snijden van eigen checklists ten behoeve van statische tests. Stel testgevallen op aan de hand van de geselecteerde testtechnieken. Automatiseer de tests die daarvoor in aanmerking komen met behulp van de beschikbare tool(s).

Uitvoeren 13.

In deze fase zijn er geen specifieke aandachtspunten. In de teststrategie, het testplan en de testscripts is gedefinieerd hoe de uitvoeringsfase er uit ziet.

Afronding 14.

Geef ruime aandacht aan het borgen (verzamelen, bijwerken en overdragen aan beheer) van de regressietestset en het overdragen van eventueel gebruikte testtools (en kennis daarover) ten behoeve van regressietesten/monitoring.

10 Formuleren van een teststrategie 10.1

Inleiding

Een teststrategie is voor elk project uniek. Op basis van afwegingen omtrent risico’s, tijd, budget, know-how en dergelijken, vindt een afweging plaats omtrent de vraag wat testen wij, op welke wijze en met welke diepgang doen wij dat en met welke hulpmiddelen. De testmanager en de opdrachtgever werken samen om tot een teststrategie te komen. De testmanager begeleidt het proces en documenteert de teststrategie, de opdrachtgever heeft de uiteindelijke stem in het vaststellen van de strategie. Het testen van alle mogelijke variaties in een systeem is geen optie. Daarvoor is het aantal mogelijke combinaties van handelingen en omstandigheden simpelweg te groot. Binnen een eenvoudige grafische user interface met vijf schermen, waarbij elk scherm een menubalk bevat met tien opties en per optie tien submenu-opties, loopt het aantal mogelijke testgevallen reeds in de miljoenen. Het uitvoeren van al deze tests zou enkel mogelijk zijn indien men over onbeperkte tijd en middelen beschikt. In de praktijk is dit nimmer het geval. Derhalve moeten er keuzes worden gemaakt die erop zijn gericht om met een minimale inspanning een maximaal resultaat met het testen te behalen. Het formuleren van een doordachte teststrategie is hiervoor een absolute voorwaarde. Een dergelijke strategie moet ertoe leiden dat de meest ernstige fouten zo vroeg mogelijk ontdekt worden. Hoe eerder detectie van fouten plaatsvindt, des te lager zijn de herstelkosten. De navolgende grafiek illustreert dit op treffende wijze. 200 180 160 140 120 100 80 60 40 20 0

IA

FO

TO

REAL PT/IT

ST

AT

EXPL

Figuur 20: relatie tussen het moment waarop fouten worden ontdekt en de herstelkosten (Boehm)

Verklaring van de gehanteerde afkortingen IA FO TO REAL PT/IT ST AT EXPL

: : : : : : : :

informatie-analyse functioneel ontwerp technisch ontwerp realisatie programma-/integratietest systeemtest acceptatietest exploitatie

Bij het formuleren van een op maat gesneden teststrategie kan gebruik worden gemaakt van de adviezen die in dit boek zijn gegeven ten aanzien van de testaanpak voor de verschillende stadia van e-business.

10.2

Identificeren stadium van e-business en risico’s

Het formuleren van een teststrategie voor het testen van ebusinesstoepassingen start met het bepalen van het stadium waarin de toepassing zich bevindt. Vervolgens worden de risico’s die gelopen worden in kaart gebracht. Het verrichten van een productrisico-analyse kan daarbij behulpzaam zijn. De wijze waarop zo’n analyse wordt verricht staat in bijlage P beschreven. Risico’s doen zich met name voor bij kritische functionaliteiten systeemonderdelen die de grootste kans op verstoringen vertonen.

10.3

en

Bepalen kwaliteitseigenschappen en testtechnieken

Zodra helder is wat de risico’s zijn wordt per risico bepaald aan welk kwaliteitsattribuut (functionaliteit, performance, gebruikersvriendelijkheid, schaalbaarheid, et cetera) deze gekoppeld kan worden en wat het relatief belang van dat kwaliteitsattribuut is. Vervolgens stelt men voor elk kwaliteitsattribuut vast met behulp van welke testtechniek de kwaliteit onderzocht gaat worden. Grafisch ziet dit er als volgt uit. Risico

Kwaliteitsattribuut Relatief belang 3 = groot 2 = redelijk 1 = gering

Testtechniek

Teneinde het eenvoudiger te maken om voor specifieke kwaliteitseigenschappen geschikte testtechnieken te kiezen is in bijlage C een matrix opgenomen waarin ten aanzien van een groot aantal kwaliteitseigenschappen is aangegeven met behulp van welke technieken getest kan worden.

10.4

Verdeling testtechnieken over testeenheden

Nu de van belang zijnde kwaliteitseigenschappen zijn bepaald, wordt het te testen systeem onderverdeeld in testeenheden. Dit zijn logische groepen van functionaliteiten. Te denken valt bijvoorbeeld aan modules. Per testeenheid wordt bepaald welke kwaliteitseigenschappen van belang zijn. Testeenheden Testeenheid 1 Kwaliteitsattributen

Testeenheid 2

Testeenheid 3

Testeenheid 4

De bovenstaande matrix wordt als volgt gevuld. Langs de horizontale as worden de onderscheiden testeenheden benoemd en langs de verticale as de kwaliteitseigenschappen waarop getest gaat worden. Voor elke combinatie van een testeenheid en een kwaliteitsattribuut (cellen in de matrix) wordt bepaald of deze onderwerp van test is. Zo ja, dan worden in de matrix bij de betreffende combinatie de te hanteren testtechnieken ingevuld. Sommige testeenheden hebben een groter belang dan anderen. Het relatief belang per testeenheid wordt in de volgende tabel weergegeven. Testeenheid

TESTEENHEID 1 TESTEENHEID 2 TESTEENHEID 3 …. Totaal

Relatief Testtechniek 1 belang

Testtechniek 1

Testtechniek 3

100%

%

%

%

De voorgaande tabel geeft globaal weer hoe de testinspanning wordt verdeeld over de diverse testeenheden en de gekozen testtechnieken. Zij dient als richtlijn voor de testers bij het verdelen van hun tijd en als stuurmiddel voor de testmanager.

10.5

Dekkingsgraad

De volgende stap is het beschrijven van de gewenste mate van diepgang van de test. De gekozen dekkingsgraad is mede gebaseerd op de aanduiding van de kritische functionaliteiten en de risico’s die worden gelopen. Ook kostenoverwegingen en de beschikbare tijd voor het testen spelen een rol. Bepaald wordt welke delen van het systeem al dan niet worden getest. Voor de delen die wel getest gaan worden, wordt bepaald hoe diepgaand de test zal zijn. Bijvoorbeeld door aan te geven hoeveel procent van de functionaliteit wordt getest.

10.6

Stop- en hervattingscriteria

De opdrachtgever en de testmanager bepalen onder welke omstandigheden de testuitvoering tijdelijk of permanent gestaakt wordt. Tijdelijk staken doet zich bijvoorbeeld voor als het systeem veel instabiel gedrag vertoont of als er bevindingen worden gedaan die de testuitvoering blokkeren. Definitief staken van het testen is aan de orde als het systeem van voldoende kwaliteit is en het niet rendabel is om door te gaan met testen omdat er nog maar weinig bevindingen worden gedaan. Eventueel kan een grenswaarde worden benoemd, zoals een Mean Time Between Failures (gemiddelde tijd tussen storingen). Wanneer deze waarde wordt bereikt staakt men de testuitvoering. In de hervattingscriteria beschrijft men onder welke condities een tijdelijk gestaakte test weer wordt herstart.

10.7

Tools

Er wordt bepaald welke tools ingezet worden tijdens het testen. Per tool wordt beschreven welke rol het speelt in het testproces en globaal op welke wijze het gebruikt zal worden. Tevens bepaalt men met welke browsers, versies van browsers en platforms getest zal worden. Bepaald dient te worden of met diverse browsers getest wordt of dat een alternatieve benadering wordt gekozen zoals het beoordelen van de weergave van de website in de Opera browser.

10.8

Strategie ten aanzien van hertesten

Men beschrijft welke aanpak er wordt gevolgd ten aanzien van het hertesten van reeds uitgevoerde testscripts. De uitersten zijn het enkel hertesten van bevindingen versus het verrichten van een volledige regressietest. De keuze is

afhankelijk van factoren zoals beschikbare tijd en budget, de mate van risico, aard en omvang van eventuele wijzigingen in opeenvolgende releases, et cetera.