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 worden een aantal fases achter elkaar doorlopen. Deze fasen worden afgesloten met een mijlpaalproduct. Bij de ontwikkeling van e-business applicaties wordt over het algemeen systeemontwikkelingsmethodes gebruikt die gebaseerd zijn op Rapid Application Development (RAD) of een daarvan afgeleide methodeIn dit artikel gaan de auteurs in op de fasering van het ontwikkelen en testen van een e-business applicatie conform RAD. Bij de ontwikkeling van een e-businessapplicatie wordt een aantal eisen gesteld aan het ontwikkel- en testproces. In de eerste plaats dient de applicatie aan een aantal belangrijke kwaliteitscriteria te voldoen, zoals juistheid, snelheid, beveiliging en gebruikersvriendelijkheid. Ook op het internet geldt: ‘There is never a second chance for a first impression’. Als de gebruiker niet tevreden is over de applicatie omdat deze niet werkt zoals de gebruiker verwacht – de applicatie is bijvoorbeeld niet gebruikersvriendelijk is of te langzaam – klaagt deze potentiële klant niet; hij zapt. De kwaliteit van de applicatie dient dus hoog te zijn omdat het afbreukrisico op internet bijzonder hoog is. In de tweede plaats is in de internetwereld de ‘time to market’ belangrijk. Als wel ruim de tijd wordt genomen om een applicatie te ontwikkelen, heeft de concurrentie eventueel haalbare voordelen ingevuld. Deze eisen aan het ontwikkelproces hebben tot gevolg dat er feitelijk veel behoefte is aan gestructureerd ontwikkelen en gestructureerd testen; maar daar is hier beperkt de tijd voor. Een dilemma waar met watervalmethoden zoals SDM en de huidige testmethoden niet uit te komen is. Rapid Application Development (RAD) heeft als voordeel dat in korte tijd een werkend systeem kan worden opgeleverd, dit voordeel mag niet teniet worden gedaan door een langdurig testtraject. Daarom dient het testen te worden afgestemd op RAD. In dit artikel wordt allereerst op de hoofdlijnen van systeemontwikkeling conform RADprincipes ingegaan. Daarna wordt er een alternatieve testaanpak gepresenteerd die de geschetste nadelen ondervangt. Ontwikkelen conform RAD. Het ontwikkelproces conform RAD-principes kenmerkt zich door: 1. hoge betrokkenheid van de opdrachtgever en gebruikers; 2. toepassing van time-box principes; 3. iteratief ontwikkelen. De hoge betrokkenheid van de opdrachtgever komt tot uitdrukking in de aanwezigheid en actieve participatie van de opdrachtgever in alle fases van systeemontwikkeling. Volgens RAD dienen de gebruikers betrokken te zijn. Bij e-business geldt het praktische probleem dat de gebruikers een grote, soms anonieme groep vormen. De opdrachtgever, of vertegenwoordigers van de opdrachtgever, vervullen dan deze rol en treden op alsof zij de gebruikers zijn. Als de toekomstige gebruiker wel bekend is kan hij benaderd worden en gevraagd worden deel te nemen in het project. Per zogenaamde timebox, een vaststaande hoeveelheid tijd die over het algemeen redelijk kort is, wordt getracht een afgebakende hoeveelheid functionaliteit te realiseren. De lengte van de timebox staat vast, als er tijdsdruk ontstaat wordt er minder ontwikkeld, de timebox wordt niet verlengd. Het iteratieve karakter van RAD komt tot uiting in de ontwerp- en ontwikkelfasen van de systeemontwikkeling. Het iteratieve karakter houdt het continue, achterelkaar herhalen van ontwerp en bouw in. Steeds wordt in een timebox een nieuw stukje functionaliteit gerealiseerd of de functionaliteit die in een eerdere timebox is gerealiseerd aangepast of uitgebreid. Door het werken in timeboxen en iteratief ontwikkelen ontstaan voordelen: het systeem wordt snel gerealiseerd, overengineering wordt voorkomen en er wordt veel
doelgerichter gewerkt. Om commerciële redenen kan eventueel gestart worden met een beperkte versie van het systeem. Het ontwikkelproces conform RAD bestaat uit de volgende fases: • joint requirements planning (JRP); • joint application design (JAD); • prototyping; • realisatie; • implementatie; • o verall planning en beheer.
JRP
JAD
Prototype
Realisatie
Implementatie
Overall Planning en Beheer Realisatieproces
Joint requirements planning (JRP) Doel van de JRP-fase is dat opdrachtgever en project overeenstemming bereiken over de te bouwen functionaliteit, kwaliteitseisen, het ontwikkelproces en de projectorganisatie. De JRP is het beste te vergelijken met de definitiestudie uit SDM. Tijdens de JRP worden één of meerdere workshops georganiseerd. Deelnemers zijn het management van de opdrachtgever,bij voorkeur vertegenwoordigers van de gebruikers en enkele leden van het realisatieteam. De workshop staat onder leiding van een onafhankelijke workshop leider, ook wel vaak facilitator genoemd. Tijdens de JRP wordt de rechtvaardiging dat het systeem gebouwd gaat worden en de requirements vastgesteld. Vervolgens worden de functies die het systeem uit gaat voeren vastgesteld. Over het algemeen levert de JRP de rechtvaardiging, requirements en de architectuur van het systeem op. Joint application design (JAD) Doelstelling van de JAD-fase is het gezamenlijk ontwerpen van verschillende functies van het systeem. JAD gebeurt eveneens in workshopsessies onder leiding van een facilitator. Deelnemers zijn in dit geval de ontwerpers/ontwikkelaars (bij RAD zijn deze functies soms gecombineerd), de opdrachtgever en mogelijk eindgebruikers en eventueel de architect. Tijdens de sessie worden de functies tot op detail ontworpen. Hierbij wordt zoveel mogelijk gebruik gemaakt van hulpmiddelen zoals brown paper of ontwerptools. Doel is dat de ontwerpers/ontwikkelaars een goed besef krijgen van wat de eisen en wensen van de opdrachtgever en de gebruikers zijn, en er een ontwerp gerealiseerd wordt dat aan deze eisen voldoet. Door de actieve manier van samenwerken wordt getracht de communicatiemuur te doorbreken. Bij e-businessapplicaties proberen de deelnemers dus gezamenlijk vanuit de uiteindelijke gebruiker de applicatie te bekijken. Prototyping Doel van de fase prototyping is het gezamenlijk ontwerpen van een prototype van het systeem. Prototyping is een technieken om snel een ruwe versie van het ontworpen systeem te bouwen. Prototyping is vooral geschikt voor het ontwerpen van de user interface. Op basis van het prototype kan de opdrachtgever en, indien aanwezig, de gebruiker het toekomstige systeem beoordelen en eventuele verbeteringen aanbrengen. Omdat het succes van ebusinessapplicaties in hoge mate afhankelijk is van de user interface, is het toepassen van
prototyping dus belangrijk. Bij RAD dienen de gebruikers het prototype te beoordelen. Bij ebusiness zijn de eindgebruiker niet altijd bekend, ze vormen zeker geen onderdeel van de organisatie van de opdrachtgever. Indien de toekomstige gebruikers uit een beperkte groep bekende personen of organisaties bestaan, kan de opdrachtgever proberen een vertegenwoordiging hiervan uit te nodigen om het prototype te beoordelen. Als vanzelfsprekend heeft dit ook commerciële voordelen. Als de groep toekomstige gebruikers niet bestaat uit een beperkte groep bekende personen of organisaties, kan getracht worden een representatieve afvaardiging van (potentiële) gebruikers het prototype te laten beoordelen. Realisatie Op basis van de requirements (JRP), het ontwerp (JAD) en het prototype wordt de ebusinessapplicatie ontwikkeld. Delen van het systeem kunnen beoordeeld worden door de opdrachtgever; dit kan ook geïntegreerd worden in het testproces. Implementatie De implementatie kan plaatsvinden als het hele systeem af is, het kan gefaseerd gebeuren. Als vanzelfsprekend dienen de afzonderlijke delen bruikbaar te zijn en meerwaarde te hebben voor de gebruiker. Het kan bij e-business zelfs voordelen hebben het systeem in delen beschikbaar te stellen. Iedere keer als er weer een deel is geïmplementeerd, zijn de gebruikers aangenaam verrast en kunnen zij meer. Voorwaarde is wel dat de eerste versie voldoende functionaliteit bevat zodat de gebruiker voldoende redenen heeft het systeem te gebruiken. Ook is het een eis dat nieuwe versies foutloos zijn. Eén slechter ervaring kan het verlies van gebruikers veroorzaken. Het testproces Het ontwikkelproces is bij e-business, zoals uit bovenstaande blijkt, een dynamisch, flexibel proces met hoge betrokkenheid van de opdrachtgever en mogelijke gebruikers. Dat geldt niet voor het klassieke testproces zoals we dat kennen. Bij het testproces zoals wij dat kennen is sprake van een aantal fases die elkaar opvolgen. Daarom dient het testproces aangepast te worden bij het toepassen van RAD of een daarvan afgeleide methode. Het testproces bestaat uit de volgende fases: • teststrategie • voorbereiding • specificatie • uitvoering • testafronding Inzet testtools
Test Strategie
Voorbereiding
Specificatie
Uitvoering
Test Afronding
Overall Planning en Beheer Testproces
Teststrategie Het testproces start met het opstellen van een teststrategie. In de teststrategie wordt gesteld wat het doel van de test is en wat op welke manier getest gaat worden. Als input hiervoor worden de rechtvaardiging en de requirements van het systeem genomen. Tijdens de test dient namelijk vastgesteld te worden of het uiteindelijke systeem tegemoet komt aan de rechtvaardiging en de requirements. Eén van de eindproducten van de teststrategie is een lijst eisen en acceptatiecriteria die alle stakeholders aan het systeem stellen (H.J.J.
Cannegieter, kwaliteitszorg in ICT-projecten, 2001). Tevens is in de teststrategie aangegeven op welke wijze wordt vastgesteld hoe aan de eisen en acceptatiecriteria is voldaan. Voorbereiding Nu bekend is wat getest moet worden, wordt het testproces verder ingericht. Zaken als organisatie, infrastructuur, mijlpalen en bijbehorende producten worden gedefinieerd. Bij voorkeur worden ook sjablonen en andere hulpmiddelen gemaakt om de testspecificatie en – uitvoering te ondersteunen. Een andere belangrijke activiteit is de beoordeling of testtools bij dit project meerwaarde hebben. De implementatie van testtools wordt dan tijdens deze fase voorbereid (Één, twee, drie, test, Computable 25 februari 2000). Specificatie Het hart van testen is en blijft het specificeren van testgevallen. In de klassieke testaanpak gebeurt dat nadat het ontwerp is gemaakt. Mede hierdoor kost het testtraject, mits het om een kwalitatief goed testtraject gaat, veel tijd, wat een negatief effect heeft op de doorlooptijd. Daarom dient er bij RAD in combinatie met e-business eerder gestart te worden met het specificeren van testgevallen. Het specificeren van testgevallen dient dus gelijk op te lopen met het ontwerp en de bouw. Dit pleit ervoor dat de tester ook aanwezig is bij de JADsessies. Op basis van de informatie uit de JAD-sessies kan de tester direct testgevallen maken. Door de testspecificaties naast de functionele specificaties te leggen kunnen lacunes en misinterpretaties in beide documenten gevonden worden. Als de testspecificaties toch gebaseerd worden op de functionele specificaties is er een kortere tijd voor de testvoorbereiding. Mogelijk is het natuurlijk wel, het specificeren van testgevallen is dan eenvoudiger. Het specificeren van testgevallen kan door (vertegenwoordigers van) gebruikers gebeuren. Het professioneel toepassen van testtechnieken blijft echter van groot belang. Het gebruik van testtechnieken bepaalt in hoge mate de professionaliteit van de test. Toekomstige gebruikers kunnen daarom opgeleidt worden tot tester. Gegeven het eerder genoemde afbreukrisico is het inzetten van professionele testers vaak te prefereren. Bij e-business kunnen testers zich over het algemeen makkelijk in de rol van gebruiker plaatsen. Uitvoering De uitvoering van testgevallen dient zo vroeg mogelijk plaats te vinden. Het beoordelen van de user interface is bij e-business al mogelijk als het prototype klaar is. De eerste versie van het systeem kan ook direct getest worden. Bevindingen worden dan direct meegenomen. Ook in de uitvoeringsfase heeft de inzet van professionele testers een kwaliteitsverhogend effect op het testproces. Bij nieuwe versies van het systeem wordt de uitgebreide of aangepaste software getest. Het is, zeker als het om een nieuwe implementatie bij e-business gaat, echter minstens zo belangrijk dat de onveranderde delen van het systeem ook onveranderd werken. Dit betekend dus regressietesten. Daarom is het conserveren van testscripts van groot belang. Als bij de regressietest blijkt dat delen van de testscripts niet worden bewaard, dan wel onduidelijk of onjuist zijn, kost dit direct meer tijd. Testafronding Een deel van de testafronding, het conserveren van testware, dient te gebeuren tijdens de specificatie en uitvoeringsfase. Bij het afsluiten van het traject dient het echter zodanig geconserveerd te worden dat ook andere partijen gebruik kunnen maken van de testware. Inzet testtools Door het grote aantal hertests bij RAD, en dus vaak bij e-business, is de inzet van testtools die de testuitvoering automatiseren mogelijk zeer voordelig. Het onderzoek of testtools ingezet dienen te worden gebeurt tijdens de voorbereiding. De inzet vindt plaats tijdens de specificatie en uitvoering. De voordelen worden vooral benut tijdens de uitvoering.
Overall planning en beheer Het gehele testproject dient optimaal afgestemd te worden op de overige projectactiviteiten. Bij e-business zijn de eisen aan snelheid en kwaliteit zodanig hoog dat goede afstemming en strakke organisatie onontbeerlijk zijn. Bovenstaande testfasering leidt tot een testtraject wat aan de ene kant aansluit op de flexibiliteit en dynamiek van een e-businessproject. Aan de andere kant biedt bovenstaande testfasering voldoende zekerheden dat aan de vaak hoge kwaliteitseisen van een ebusinessapplicatie wordt voldaan. Dit wordt bereikt door de testers vroeg te betrekken bij het ontwikkelproces en de specificatie en uitvoering mee te laten itereren met het ontwerp en ontwikkeling van de applicatie. Op deze manier draagt testen bij tot het succes van ebusiness in plaats van een remmende factor te zijn. Jan Gieles en Jan Jaap Cannegieter. Jan Gieles is directeur van SYSQA B.V. Jan Jaap Cannegieter is productmanager van SYSQA B.V.
