DEEL II TESTEN IN ALLE STADIA VAN E-BUSINESS

Maat: px
Weergave met pagina beginnen:

Download "DEEL II TESTEN IN ALLE STADIA VAN E-BUSINESS"

Transcriptie

1

2 DEEL II TESTEN IN ALLE STADIA VAN E-BUSINESS

3 5 Testen in het Informatie-stadium 5.1 Inleiding Zoals wij in paragraaf 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 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) 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.

4 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.

5 Figuur 8: voorbeeld van een website in het Informatie-stadium 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.

6 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. Beïnvloedingsfactor Stadium Informatie Heeft impact op schakel Fasering Stakeholders X X Kwaliteitseisen Testorganisatie Infrastructuur Architectuur X X Technieken X Figuur 9: impact matrix voor het stadium Informatie Typerend voor ICT-projecten is dat zij een dynamisch karakter hebben. Bij e- businessprojecten 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 e- businesstoepassing en de testfasering.

7 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 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. De fasen die worden doorlopen zijn in figuur 10 grafisch weergegeven 1. 1 Bron: Pol, M, Teunissen, R en Veenendaal, E van, Testen volgens TMap, Tutein Nolthenius, ISBN

8 Belangrijk om te beseffen is dat deze fasen niet lineair worden doorlopen, maar dat er sprake is van een iteratief proces. PLAN- NING EN BE- HEER VOOR- BEREI -DING SPECIFICATIE UITVOERING AFRONDING 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).

9 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) 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 ).

10 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 Technieken De gebruikelijke testtechnieken zijn onverkort bruikbaar bij e- businesstoepassingen. 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 e- businesstoepassingen 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

11 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.

12 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

13 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 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, en gebruikers. De belasting wordt net zolang verhoogd totdat het breekpunt wordt bereikt. Dit is de belasting waarbij de website door de grote toeloop van

14 (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 : simulatie van een groot aantal gebruikers en transacties (2) Endurancetest : grote belasting gedurende een lange tijdsduur (3) Spiketest : simulatie van een plotselinge piekbelasting (4) Stresstest : 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 e- businesstoepassing 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.

15 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. Voorbeeld van basisscripts voor een online reisbureau 2 :? Bezoek homepage : 35%? Zoek bestemming : 32%? Toon overzicht bestemmingen : 16%? Voeg reis toe aan winkelwagen : 7,8%? Toon inhoud winkelwagen : 4% 2 De in dit voorbeeld gehanteerde percentages hebben betrekking op het aandeel van de genoemde basisscripts in het totaal aantal testgevallen.

16 ? Registreer voordeelkaart : 2%? Bestel reis : 3%? Geef status bestelling weer : 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.

17 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)

18 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.

19 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

20 herhaald uitvoeren van dezelfde testgevallen heet regressietesten en kan dus ook heel goed gebruikt worden voor monitoring 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.

Webtesten onder schaarste

Webtesten onder schaarste Testnet najaarsevenement 2005 B e y o n d t h e o r d i n a r y Webtesten onder schaarste Vincent Staal ORDINA NV Ringwade 1 Postbus 7101 3430 JC Nieuwegein Tel: 030 6637000 Fax: 030 6637099 www.ordina.nl

Nadere informatie

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V.

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V. Regressietesten De aanpak en aandachtspunten Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING...3 1.1 ALGEMEEN...3 1.2 VERSIEBEHEER...3

Nadere informatie

Ontwikkelen en testen van e-business: beheerste dynamiek

Ontwikkelen en testen van e-business: beheerste dynamiek Ontwikkelen en testen van e-business: beheerste dynamiek Het ontwikkelen en gestructureerd testen van administratieve systemen is gebaseerd het watervalprincipe. Bij het ontwikkelen volgens het watervalprincipe

Nadere informatie

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. RAD Rapid application development Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval.

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval. TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE Kwaliteit zonder gestructureerd testen is toeval Inhoudsopgave 1. Inleiding 2. De TMap methode 3. De fase Planning & Beheer 4. De fase testspecificatie 5. De

Nadere informatie

Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV

Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV Mislukken Slagen gegarandeerd 2 Mislukken Slagen gegarandeerd Management verwacht onmiddellijk R.O.I. Doel:

Nadere informatie

TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN

TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN Copyright Sogeti Nederland B.V. te Vianen Niets uit deze uitgave mag verveelvoudigd en/of openbaar worden gemaakt (voor willekeurig welke doeleinden)

Nadere informatie

Organisatie SYSQA B.V. Pagina 1 van 6 Titel Overzicht Versie 1.0 Onderwerp Overzicht blackbox testtechnieken Datum 15 februari 1996

Organisatie SYSQA B.V. Pagina 1 van 6 Titel Overzicht Versie 1.0 Onderwerp Overzicht blackbox testtechnieken Datum 15 februari 1996 Organisatie SYSQA B.V. Pagina 1 van 6 Black-Box Test Technieken Er zijn een aantal test specificatie technieken, verder testtechnieken genoemd, die bruikbaar zijn binnen het black-box acceptatietesten.

Nadere informatie

Woordenlijst bij TMap

Woordenlijst bij TMap Woordenlijst bij TMap Acceptatietest De door de toekomstige gebruiker(s) en beheerder(s) in een zoveel mogelijk als-ware-het-productie omgeving uitgevoerde test, die moet aantonen dat het ontwikkelde systeem

Nadere informatie

Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2

Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Testen Presentatie Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Algemeen Tegenwoordig behoeft het belang van testen nauwelijks nog te worden uitgelegd. Binnen organisaties speelt

Nadere informatie

Factsheet Penetratietest Infrastructuur

Factsheet Penetratietest Infrastructuur Factsheet Penetratietest Infrastructuur Since the proof of the pudding is in the eating DUIJNBORGH - FORTIVISION Stadionstraat 1a 4815NC Breda +31 (0) 88 16 1780 www.db-fortivision.nl info@db-fortivision.nl

Nadere informatie

Digikoppeling adapter

Digikoppeling adapter Digikoppeling adapter Versie 1.0 Datum 02/06/2014 Status Definitief Van toepassing op Digikoppeling versies: 1.0, 1.1, 2.0, 3.0 Colofon Logius Servicecentrum: Postbus 96810 2509 JE Den Haag t. 0900 555

Nadere informatie

ISACA round-table 7 december 2009 Rik Marselis

ISACA round-table 7 december 2009 Rik Marselis ISACA round-table 7 december 2009 Rik Marselis Senior Testconsultant bij Sogeti Penningmeester van BNTQB, de member board voor België en Nederland van de International Software Testing Qualifications Board

Nadere informatie

Examen TMPA Test Management Approach (TMap) Professional Advanced

Examen TMPA Test Management Approach (TMap) Professional Advanced Examen TMPA Test Management Approach (TMap) Professional Advanced Publicatiedatum Startdatum 6 juni 2003 1 mei 2003 Doelgroep De module is bestemd voor (beginnende) professionele testers met een ½ tot

Nadere informatie

Testen kost te veel tijd

Testen kost te veel tijd Testen kost te veel tijd De oplevering van een nieuwe ICT applicatie betekent in de praktijk voor de opdrachtgever nog geen reden voor een feest. Vaak blijkt het product in onvoldoende mate te voldoen

Nadere informatie

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Data Warehouse Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 DOEL VAN

Nadere informatie

Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo

Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo Henrik Rexed & Joerek van Gaalen Voorstellen Joerek van Gaalen Performancetest specialist sinds 2005 Sinds 2014 CTO Computest Voorstellen

Nadere informatie

Vrijgaveadvies. Project

Vrijgaveadvies. Project <naam project> Vrijgaveadvies Project SYSQA B.V. Almere Datum : 08-02-2013 Status : Versie : Opgesteld door : Organisatie Project Pagina 2 van 16 Inhoudsopgave 1 Management samenvatting...

Nadere informatie

Kwaliteitsbewaking en testen in ICT beheerorganisaties

Kwaliteitsbewaking en testen in ICT beheerorganisaties DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt

Nadere informatie

Factsheet Penetratietest Informatievoorziening

Factsheet Penetratietest Informatievoorziening Factsheet Penetratietest Informatievoorziening Since the proof of the pudding is in the eating DUIJNBORGH - FORTIVISION Stadionstraat 1a 4815NC Breda +31 (0) 88 16 1780 www.db-fortivision.nl info@db-fortivision.nl

Nadere informatie

Begrippenlijst Inzicht in de wereld van big data, marketing en analyse

Begrippenlijst Inzicht in de wereld van big data, marketing en analyse Begrippenlijst Inzicht in de wereld van big data, marketing en analyse 4orange, 13 oktober 2015 Hogehilweg 24 1101 CD Amsterdam Zuidoost www.4orange.nl 2 Inhoud Achtergrond & Aanleiding... 3 A... 3 B...

Nadere informatie

Testaanpak: leidraad voor het kiezen van een testtechniek

Testaanpak: leidraad voor het kiezen van een testtechniek Testaanpak: leidraad voor het kiezen van een testtechniek SYSQA B.V. Almere Datum : 18 november 2012 Status : Definitief Opgesteld door : Organisatie: SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 Inleiding...

Nadere informatie

kwaliteitsmeterplus 4

kwaliteitsmeterplus 4 kwaliteitsmeterplus 4 Testen voor de toekomst Eenvoudig en intuïtief Werkproces georiënteerd Scheiding bevindingen en issues Hertest methode Schermafdruk en -opnames SaaS Open platform kwaliteitsmeterplus

Nadere informatie

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Evo Evolutionary Project Management Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING... 3 2. EVO... 4 3. FASERING...

Nadere informatie

Introductie Performancetesten

Introductie Performancetesten Introductie Performancetesten SYSQA B.V. Almere Datum : 19-12-2014 Status : Definitief Organisatie: SYSQA B.V. Pagina 2 van 12 1 Inleiding SYSQA is een onafhankelijke organisatie, gespecialiseerd in het

Nadere informatie

Procesvisie op Maat. Op basis van het Master Test Plan wordt een gedetailleerd testplan voor elke fase opgesteld.

Procesvisie op Maat. Op basis van het Master Test Plan wordt een gedetailleerd testplan voor elke fase opgesteld. 1. 1.1. Inleiding Doel In de discipline vindt de validatie van datgene wat binnen het project is gerealiseerd plaats. Dit bestrijkt het gebied van unittest tot en met acceptatie door gebruikers en beheerorganisatie.

Nadere informatie

Three Ships CDS opschalingsdocument Overzicht server configuratie voor Three Ships CDS

Three Ships CDS opschalingsdocument Overzicht server configuratie voor Three Ships CDS CDS opschalingsdocument Overzicht server configuratie voor CDS 1. Algemeen Dit document geeft een overzicht van een aantal mogelijke hardware configuraties voor het inrichten van een serveromgeving voor

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Richtlijnen voor het ontwerpen een Intranetportal Door Bas Fockens

Richtlijnen voor het ontwerpen een Intranetportal Door Bas Fockens Richtlijnen voor het ontwerpen een Intranetportal Door Bas Fockens Copyright Datacon www.datacon.nl Wat is een intranetportal? Een intranet is een online gepersonaliseerde en geïntegreerde toegang tot

Nadere informatie

Grenzeloos vertrouwen in een tool!?

Grenzeloos vertrouwen in een tool!? Grenzeloos vertrouwen in een tool!? TestNet voorjaarsevenement Maandag 30 juni 2008 Rick de Jong Agenda Korte introductie Kritische kijk op het gebruik van tools Intake en selectie van tools Het omarmen

Nadere informatie

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Agile systeemontwikkeling Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Terminologie... 4 3. Uitgangspunten...

Nadere informatie

Sjabloon testplan o.b.v. situationeel testen. <>

Sjabloon testplan o.b.v. situationeel testen. <<Organisatie>> Sjabloon testplan o.b.v. situationeel testen SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 11 Over dit sjabloon Dit

Nadere informatie

Testomgevingen beheer

Testomgevingen beheer Testomgevingen beheer Testen brengt het verwachte resultaat en de huidige toestand bij elkaar. Het geeft aanknopingspunten om de planning te maken, het product te verbeteren en om zorgen bij belanghebbenden

Nadere informatie

DigiNotar certificaten

DigiNotar certificaten DigiNotar certificaten Onlangs is duidelijk geworden dat er digitaal is ingebroken bij het bedrijf Diginotar. Daarmee worden alle DigiNotar certificaten niet meer als veilig geaccepteerd. Certificaten

Nadere informatie

OpenText RightFax. Intuitive Business Intelligence. Whitepaper. BI/Dashboard oplossing voor OpenText RightFax

OpenText RightFax. Intuitive Business Intelligence. Whitepaper. BI/Dashboard oplossing voor OpenText RightFax OpenText RightFax Intuitive Business Intelligence Whitepaper BI/Dashboard oplossing voor OpenText RightFax Beschrijving van de oplossing, functionaliteit & implementatie Inhoud 1 Introductie 2 Kenmerken

Nadere informatie

End-to-End Testen Acceptatietesten

End-to-End Testen Acceptatietesten End-to-End Testen Acceptatietesten Gerard Numan Polteq Test Services BV Agenda Krachtenveld V-model Hoe 2 1 Krachtenveld Techniek drijft de wereld Techniek overschrijdt alle grenzen Continue en parallelle

Nadere informatie

Naar de cloud: drie praktische scenario s. Zet een applicatiegerichte cloudinfrastructuur op. whitepaper

Naar de cloud: drie praktische scenario s. Zet een applicatiegerichte cloudinfrastructuur op. whitepaper Naar de cloud: drie praktische scenario s Zet een applicatiegerichte cloudinfrastructuur op whitepaper Naar de cloud: drie praktische scenario s Veel bedrijven maken of overwegen een transitie naar de

Nadere informatie

Mastertestplan <> <>

Mastertestplan <<Naam project>> <<Organisatie>> Mastertestplan SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie Pagina 2 van 17 Inhoudsopgave 1 Management

Nadere informatie

Test Process Improvement Benchmark. SPIder Conferentie 23 september Wim van Uden

Test Process Improvement Benchmark. SPIder Conferentie 23 september Wim van Uden Test Process Improvement Benchmark SPIder Conferentie 23 september Wim van Uden Agenda Korte inleiding TPI -model TPI benchmark overall Vergelijking branches DO s& DON Ts Test Process Improvement Optimaliseren

Nadere informatie

Testgedreven ontwikkeling dat is pas veilig!

Testgedreven ontwikkeling dat is pas veilig! Testgedreven ontwikkeling dat is pas veilig! INTRODUCTIE ANKO TIJMAN 2 Software tester sinds 1997 (TMap, ISEB Practitioner) Eerste agile ervaring in 2001 Presentaties op (inter)nationale congressen Nov

Nadere informatie

Content Management Systeem Specifieke modules van het Steenstra CMS 2011

Content Management Systeem Specifieke modules van het Steenstra CMS 2011 Content Management Systeem Specifieke modules van het Steenstra CMS 2011 2. Overzicht en specificering van additionele modules Naast de basis implementatie is het Steenstra CMS systeem uit te breiden met

Nadere informatie

TMap NEXT Test Engineer

TMap NEXT Test Engineer Voorbeeldexamen TMap NEXT Test Engineer Editie juni 2013 Copyright 2013 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Nadere informatie

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken De business organisatie heeft altijd stijgende verwachtingen van uw IT organisatie. Meer dan ooit is het van

Nadere informatie

Factsheet Penetratietest Webapplicaties

Factsheet Penetratietest Webapplicaties Factsheet Penetratietest Webapplicaties Since the proof of the pudding is in the eating DUIJNBORGH - FORTIVISION Stadionstraat 1a 4815NC Breda +31 (0) 88 16 1780 www.db-fortivision.nl info@db-fortivision.nl

Nadere informatie

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Drechtsteden Technische Architectuur (DTA) ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Status : Definitief 1.0 Redactie : DTA Datum : 29-08-2007 1 Versiebeheer

Nadere informatie

Optimaliseer de performance van uw dienst

Optimaliseer de performance van uw dienst Whitepaper Optimaliseer de performance van uw dienst Succes van uw online applicatie hangt mede af van de performance. Wat kunt u doen om de beste performance te behalen? INHOUD» Offline sites versus trage

Nadere informatie

Checklist risicofactoren IT-projecten

Checklist risicofactoren IT-projecten Organisatie SYSQA B.V. Pagina 1 van 5 Checklist risicofactoren IT-projecten In onderstaande checklists zijn de factoren die het slagen van een project beïnvloeden opgenomen. Projectomvang Hoe groot is

Nadere informatie

TMap NEXT Test Engineer

TMap NEXT Test Engineer Voorbeeldexamen TMap NEXT Test Engineer Editie juli 2011 Copyright 2011 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Nadere informatie

Wijzigingen volledig onder controle en geborgd

Wijzigingen volledig onder controle en geborgd Installation Management Platform IMProve 2014 is het ultieme hulpmiddel om het beheer van uw (terminal) serverfarm continu, stap voor stap, op een hoger niveau te brengen. Gedocumenteerd, geborgd en reproduceerbaar

Nadere informatie

VOICE OF THE CUSTOMER

VOICE OF THE CUSTOMER 4/20/ E-BOOK VOICE OF THE CUSTOMER Gratis e-book leansixsigmatools.nl Introductie Bij Six Sigma staat het denken vanuit de behoeften van de klant centraal. Juist de vertaling van de stem(men) van de klant(en)

Nadere informatie

Plan van Aanpak beschikbaar stellen broncode Basisregistratie Personen (BRP)

Plan van Aanpak beschikbaar stellen broncode Basisregistratie Personen (BRP) Plan van Aanpak beschikbaar stellen broncode Basisregistratie Personen (BRP) Samenvatting De minister van Binnenlandse Zaken en Koninkrijksrelaties (BZK) heeft in de Tweede Kamer toegezegd de broncode

Nadere informatie

Data at your fingertips

Data at your fingertips Data at your fingertips 4orange, 2015 Hogehilweg 24 1101 CD Amsterdam Zuidoost www.4orange.nl 2 6 redenen waarom de marketeer zelf eigenaar moet zijn van de Marketing Software uitdaging! Bij beslissingen

Nadere informatie

Privacyverklaring ViopTo

Privacyverklaring ViopTo Privacyverklaring ViopTo Voor ons is een zorgvuldige omgang met persoonsgegevens van groot belang. Persoonlijke gegevens worden dan ook zorgvuldig verwerkt en beveiligd. Hierbij houden wij ons aan de eisen

Nadere informatie

Adding value to test tooling Hoe en waarom DevOps de wereld van performance testen verandert

Adding value to test tooling Hoe en waarom DevOps de wereld van performance testen verandert Hoe en waarom DevOps de wereld van performance testen verandert Najaarsevenement 14 oktober 2015 Inleiding Wie zijn we Marc Koper: Specialist in performancetesten / testautomatisering HenkJaap van den

Nadere informatie

TESTEN IN DE LOGISTIEKE E-COMMERCEKETEN

TESTEN IN DE LOGISTIEKE E-COMMERCEKETEN TESTEN IN DE LOGISTIEKE E-COMMERCEKETEN Productinformatie Testen in de logistieke e-commerceketen Inhoudsopgave 1 Waarom testen in de logistieke e-commerceketen?... 4 1.1 Verschillende klantperspectieven...

Nadere informatie

SYSTEEMEISEN VOOR FACET FEBR. 2013

SYSTEEMEISEN VOOR FACET FEBR. 2013 SYSTEEMEISEN VOOR FACET FEBR. 2013 Het nieuwe computerexamensysteem Facet kan zowel offline als online gebruikt worden. Bij een online-afname worden de opgaven rechtstreeks ingelezen via het internet van

Nadere informatie

Aandachtspunten inzet testtool. Een aanpak. Algemene informatie voor medewerkers van SYSQA B.V.

Aandachtspunten inzet testtool. Een aanpak. Algemene informatie voor medewerkers van SYSQA B.V. Aandachtspunten inzet testtool Een aanpak Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA BV Pagina 2 van 12 INHOUDSOPGAVE 1. INLEIDING...3 1.1 DOEL EN AFBAKENING...3 1.2 CAPTURE

Nadere informatie

Aspecten die van belang zijn bij het ontwikkelen van een Internetsite

Aspecten die van belang zijn bij het ontwikkelen van een Internetsite Aspecten die van belang zijn bij het ontwikkelen van een Internetsite 1. Informatie - Kloppen de teksten? - Zijn ze feitelijk juist en spreken ze elkaar niet tegen? - Is de informatie actueel en gesteld

Nadere informatie

Offshoring & Testing. Verander een uitdaging in een kans. Door Ernst Labruyère. re Consultant ps_testware. 20 september 2007

Offshoring & Testing. Verander een uitdaging in een kans. Door Ernst Labruyère. re Consultant ps_testware. 20 september 2007 Offshoring & Testing Verander een uitdaging in een kans Door Ernst Labruyère re Consultant ps_testware 20 september 2007 Ernst Labruyere- Offshoring en Testing: : Verander een uitdaging in een kans - 1

Nadere informatie

Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008

Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Titel, samenvatting en biografie Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Samenvatting: Eibert Dijkgraaf (testconsultant Test

Nadere informatie

Het BiSL-model. Een whitepaper van The Lifecycle Company

Het BiSL-model. Een whitepaper van The Lifecycle Company Het BiSL-model Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u een overzicht op hooflijnen van het BiSL-model. U vindt een overzicht van de processen en per proces een beknopte

Nadere informatie

Performance Testen bij Rabobank Nederland. TestNet Noord Testers bij de bank 21 februari 2012 Allan Beumer

Performance Testen bij Rabobank Nederland. TestNet Noord Testers bij de bank 21 februari 2012 Allan Beumer Performance Testen bij Rabobank Nederland TestNet Noord Testers bij de bank 21 februari 2012 Allan Beumer Agenda Performance Testen bij Rabobank Nederland 1 2 3 4 Introductie Performance Competence Center

Nadere informatie

Voorbeeldexamen. Testen Foundation. Editie maart 2012

Voorbeeldexamen. Testen Foundation. Editie maart 2012 Voorbeeldexamen Testen Foundation Editie maart 2012 Copyright 2012 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system or circulated

Nadere informatie

Frontend performance meting

Frontend performance meting Frontend performance meting als aanvulling op de traditionele manier van performancetesten René Meijboom rene@performancearchitecten.nl Introductie Uitdaging bij huidige klant Succesvolle performancetest

Nadere informatie

Testen = Monitoren. Hoe de werkzaamheden van de boodschapper van de koning gaan veranderen. Datum: 30 April 2015

Testen = Monitoren. Hoe de werkzaamheden van de boodschapper van de koning gaan veranderen. Datum: 30 April 2015 Testen = Monitoren Hoe de werkzaamheden van de boodschapper van de koning gaan veranderen. Spreker: Ide Koops Datum: 30 April 2015 1 2 Agenda Testrapportages in het verleden Impact nieuwe ontwikkelingen

Nadere informatie

Persoonlijke gegevens. Werkgevers / Projecten. Certificering. Werkervaring. E.H.B. (Ewout) Vocking

Persoonlijke gegevens. Werkgevers / Projecten. Certificering. Werkervaring. E.H.B. (Ewout) Vocking Persoonlijke gegevens Naam E.H.B. (Ewout) Vocking Bedrijfsnaam Vandaag IT Consultancy Adres Albert Cuypstraat 51 Woonplaats en Postcode 8021 DV, Zwolle K.v.K. nummer 53699394 Geboortedatum 8 juli 1982

Nadere informatie

privacy statement WerkvoorWerk.nl Privacy Statement aandachtig door te nemen. De schuin geschreven gebruiksvoorwaarden van WerkvoorWerk.nl.

privacy statement WerkvoorWerk.nl Privacy Statement aandachtig door te nemen. De schuin geschreven gebruiksvoorwaarden van WerkvoorWerk.nl. privacy statement WerkvoorWerk.nl WerkvoorWerk.nl neemt de privacy van haar gebruikers zeer serieus en zal informatie over u op een veilige manier verwerken en gebruiken. In dit document wordt het Privacy

Nadere informatie

Rapport over het werkprofiel van Software engineer (sr)

Rapport over het werkprofiel van Software engineer (sr) Rapport over het werkprofiel van Software engineer (sr) Identificatienummer: Publicatiedatum: 19 november 2015 Leeswijzer Dit rapport omschrijft het werkprofiel van 'Software engineer (sr)' zoals die door

Nadere informatie

Parasoft toepassingen

Parasoft toepassingen Testen op basis van OSB en Digikoppeling Voor de bestaande Overheid Service Bus en de nieuwe standaard Digikoppeling zijn verschillende test- omgevingen opgezet. Hiermee kan het asynchrone berichtenverkeer

Nadere informatie

Risk & Requirements Based Testing

Risk & Requirements Based Testing Risk & Requirements Based Testing Tycho Schmidt PreSales Consultant, HP 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Agenda Introductie

Nadere informatie

Kwaliteitskosten onderzoek. Aanpak. Algemene informatie voor medewerkers van: SYSQA B.V.

Kwaliteitskosten onderzoek. Aanpak. Algemene informatie voor medewerkers van: SYSQA B.V. Kwaliteitskosten onderzoek Aanpak Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 KWALITEITSKOSTEN...

Nadere informatie

Testen bij DWH-projecten

Testen bij DWH-projecten Testen bij DWH-projecten Snelheid, Kwaliteit, Flexibiliteit onder úw regie Armando Dörsek, Software Control 18-09-2007 Wat gaat u horen? Testen van DW/BI > Structureren & Plannen Project- en teamstructuur

Nadere informatie

Risk Based Testing. TestNet Voorjaarsbijeenkomst. Johan Vink. A reality check

Risk Based Testing. TestNet Voorjaarsbijeenkomst. Johan Vink. A reality check Risk Based Testing A reality check TestNet Voorjaarsbijeenkomst Johan Vink Even voorstellen - Johan Vink - 42 jaar testervaring - 15 jaar betaald - Test competence leader Risk Based Testing, a reality

Nadere informatie

DEALS VOOR JOU Privacybeleid

DEALS VOOR JOU Privacybeleid DEALS VOOR JOU Privacybeleid In dit privacybeleid wordt beschreven hoe wij omgaan met uw persoonsgegevens. Wij verzamelen, gebruiken en delen persoonsgegevens om de DEALS VOOR JOU Website te laten werken

Nadere informatie

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe SPIDER werkgroep Requirements Management Subwerkgroep Methoden Toelichting inhoud en voortgang tot nu toe donderdag 17 januari 2008 Frans van Veen Bert Dubbelman Robert van Lieshout Erwin Bolwidt Jan-Willem

Nadere informatie

De tester als bruggenbouwer

De tester als bruggenbouwer De tester als bruggenbouwer Tim Koomen Testnet voorjaarsevenement 9 juni 2004 Agenda Bruggen Enkele bruggen toegelicht De bruggenbouwer Trends Sogeti Nederland B.V. Pagina 1 Bruggen Systeem Beheer Stuur

Nadere informatie

Martin van Leeuwen Happy Testing

Martin van Leeuwen Happy Testing Titel, samenvatting en biografie Samenvatting: Deze presentatie beschrijft een aantal test maatregelen die in een RUP nieuwbouw project zijn genomen, om ervoor te zorgen dat het testen aan het eind van

Nadere informatie

Testrapport Kiezen op Afstand Inhoudelijke Stresstest

Testrapport Kiezen op Afstand Inhoudelijke Stresstest Testrapport Inhoudelijke Stresstest Dit document heeft 10 pagina 's Testrapport 1nhoudelijke Stresstest vo.21 Document historie Versie Datum Bijzonderheden Autorisatie 0.1 20-09-2006 Opzet 0.2 22-09-2006

Nadere informatie

SmartTestAssistant. Het slimme testhulpmiddel. door Frank Stolker

SmartTestAssistant. Het slimme testhulpmiddel. door Frank Stolker SmartTestAssistant Het slimme testhulpmiddel door Frank Stolker Inhoud Wat is SmartTestAssistant? Achtergrond Opzet Werking Schematisch overzicht Onderscheidend vermogen Status en vervolgstappen Wat is

Nadere informatie

Whitepaper implementatie workflow in een organisatie

Whitepaper implementatie workflow in een organisatie Whitepaper implementatie workflow in een organisatie Auteur: Remy Stibbe Website: http://www.stibbe.org Datum: 01 mei 2010 Versie: 1.0 Whitepaper implementatie workflow in een organisatie 1 Inhoudsopgave

Nadere informatie

Marc Koper/ Bas M. Dam A Tool with a Fool is only a tool Voorjaarsevent Testnet: 30 juni 2008

Marc Koper/ Bas M. Dam A Tool with a Fool is only a tool Voorjaarsevent Testnet: 30 juni 2008 Titel, samenvatting en biografie Samenvatting: Marc Koper/ Bas M. Dam A Tool with a Fool is only a tool Voorjaarsevent Testnet: 30 juni 2008 Voor het uitvoeren van testen zijn diverse uitstekende tools

Nadere informatie

Whitepaper. Exploratory Testing. Waarom doen we dat niet altijd? door Dennis Joele

Whitepaper. Exploratory Testing. Waarom doen we dat niet altijd? door Dennis Joele Whitepaper Exploratory Testing Waarom doen we dat niet altijd? door Dennis Joele Dennis Joele is werkzaam als test designer bij TriOpSys en heeft als zodanig voor de Dienst der Hydrografie van de Koninklijke

Nadere informatie

EISEN AAN TESTPLANNEN

EISEN AAN TESTPLANNEN EISEN AAN TESTPLANNEN Auteur : Datum : Versie :.. Status :.. Datum overdracht : Overgedragen aan : Inhoudsopgave 1 Inleiding...

Nadere informatie

TestNet voorjaarsevenement 2014 Managen van een KetenTest bij NS met hun TOPAAS toolsuite. Managen van een Ketentest bij NS met hun TOPAAS tool-suite

TestNet voorjaarsevenement 2014 Managen van een KetenTest bij NS met hun TOPAAS toolsuite. Managen van een Ketentest bij NS met hun TOPAAS tool-suite Managen van een Ketentest bij NS met hun TOPAAS tool-suite Bart Broekman mei 2014 Onderwerpen De (prachtige) TOPAAS tooling De (niet zo prachtige) project-situatie De (oh zo mooie) dingen die we ermee

Nadere informatie

Factsheet CLOUD DESIGN Managed Services

Factsheet CLOUD DESIGN Managed Services Factsheet CLOUD DESIGN Managed Services CLOUD DESIGN Managed Services We ontwerpen flexibele en kosteneffectieve cloud-architecturen als fundament voor uw digitale platform(en). De ontwikkelingen binnen

Nadere informatie

Beschrijving toolset Netwerk/Protocol/Applicatie test Datum 11 januari 2012 Auteur Louis de Wolff Versie 1.0

Beschrijving toolset Netwerk/Protocol/Applicatie test Datum 11 januari 2012 Auteur Louis de Wolff Versie 1.0 Beschrijving toolset Netwerk/Protocol/Applicatie test Datum 11 januari 2012 Auteur Louis de Wolff Versie 1.0 Netwerk evaluatie tools Inleiding In een pakket geschakelde netwerk gebeurt de communicatie

Nadere informatie

PRIVACY STATEMENT WHAPPBOOK

PRIVACY STATEMENT WHAPPBOOK PRIVACY STATEMENT WHAPPBOOK Whappbook neemt jouw privacy zeer serieus en zal informatie over jou op een veilige manier verwerken en gebruiken. Om jouw privacy te waarborgen, handelt Whappbook altijd in

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

Orbis Software. Portal4U. Whitepaper. Deze whitepaper geeft u meer informatie over ons standaardproduct Portal4U van Orbis Software Benelux BV.

Orbis Software. Portal4U. Whitepaper. Deze whitepaper geeft u meer informatie over ons standaardproduct Portal4U van Orbis Software Benelux BV. Orbis Software Whitepaper Deze whitepaper geeft u meer informatie over ons standaardproduct van Orbis Software Benelux BV Orbis Standaard Product Maak eenvoudig uw eigen Portals Met beschikt u over een

Nadere informatie

Software Test Document

Software Test Document Software Test Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie

Nadere informatie

Continuous testing in DevOps met Test Automation

Continuous testing in DevOps met Test Automation Continuous ing in met Continuous testing in met Marco Jansen van Doorn Tool Consultant 1 is a software development method that emphasizes communication, collaboration, integration, automation, and measurement

Nadere informatie

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid Releasebeleid Ondanks alle aan de samenstelling van de tekst bestede zorg, kan Newway Retail Solutions bv (Newway) géén enkele aansprakelijkheid aanvaarden voor eventuele directe en/of indirecte schade,

Nadere informatie

PRIVACY STATEMENT OUDERMATCH.NL

PRIVACY STATEMENT OUDERMATCH.NL PRIVACY STATEMENT OUDERMATCH.NL Oudermatch neemt uw privacy zeer serieus en zal informatie over u op een veilige manier verwerken en gebruiken. Om uw privacy te waarborgen, handelt Oudermatch altijd in

Nadere informatie

Selenium IDE Webdriver. Introductie

Selenium IDE Webdriver. Introductie Selenium IDE Webdriver Het Wielsem 10, 5231 BW s- Hertogenbosch, telefoon 073-6409311 e- mail info@testwork.nl internet http://www.testwork.nl 1 Inhoudsopgave 1 Inhoudsopgave... 2 2 Selenium IDE... 3 3

Nadere informatie

Website Performance Rapport 2013: E-COMMERCE

Website Performance Rapport 2013: E-COMMERCE Website Performance Rapport 2013: E-COMMERCE E-commerce sites behoren als categorie tot de sites met de slechtste performance, ondanks het feit dat beschikbaarheid en performance rechtstreeks impact hebben

Nadere informatie

Service Level Agreement (SLA)

Service Level Agreement (SLA) Service Level Agreement (SLA) Telefoon: 088 773 0 773 Email: Support@adoptiq.com Website: www.adoptiq.com Adres: Johan Huizingalaan 763a 1066 VH Amsterdam KvK nr: 61820725 BTW nr: NL.854503183.B01 IBAN

Nadere informatie

Agile Testen in de praktijk

Agile Testen in de praktijk 1 Agenda 2 Agile Testen in de praktijk Summerschool 13 Juli 2011 Introductie Agile de context van agile Testen2.0 de tester in een agile project Waarden en principes DoD, PRA en MTP Testen3.0 in een agile

Nadere informatie

Werken zonder zorgen met uw ICT bij u op locatie

Werken zonder zorgen met uw ICT bij u op locatie Werken zonder zorgen met uw ICT bij u op locatie Naast de mogelijkheden om uw programmatuur en gegevens bij Drie-O via Evy 2.0 in de cloud te hosten hebt u ook de mogelijkheid om uw ICT omgeving bij u

Nadere informatie

voorbeeldexamen TMap TMap NEXT Foundation editie juli 2009 inhoud 2 inleiding 3 voorbeeldexamen 15 antwoordindicatie 33 evaluatie TMPF_2.

voorbeeldexamen TMap TMap NEXT Foundation editie juli 2009 inhoud 2 inleiding 3 voorbeeldexamen 15 antwoordindicatie 33 evaluatie TMPF_2. voorbeeldexamen TMPF_2.0 TMap TMap NEXT Foundation editie juli 2009 inhoud 2 inleiding 3 voorbeeldexamen 15 antwoordindicatie 33 evaluatie EXIN Hét exameninstituut voor ICT ers Janssoenborch, Hoog Catharijne

Nadere informatie