RAD en testen Een aanpak
Algemene informatie voor medewerkers van SYSQA B.V.
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
1 van 23 1.0 23-04-2003
Managementsamenvatting Rapid Application Development (RAD) is een systeem-ontwikkelingsmethode die gebaseerd is op hoge gebruikersinbreng en iteratief ontwikkelen. Er zijn inmiddels vele varianten op RAD. Enkele aspecten die, naast hoge gebruikersinbreng en iteratief ontwikkelen, regelmatig terugkomen bij RAD zijn het gebruik van krachtige ontwikkeltools, prototyping, kleine zelfstandige ontwikkelteams, timeboxen, belangrijkste onderdelen eerst, 80/20-regel, hergebruik/object-oriëntatie. RAD kent vijf fases: informatieanalyse, joint requirement planning (JRP), joint application design (JAD), bouwfase en invoering. De informatieplanning en JRP worden één keer uitgevoerd, JAD en bouwfase worden meerdere keren (iteraties of incrementen) uitgevoerd. De effecten van RAD op de fasering van het gestructureerd testen zijn groot. De activiteiten uit de planningsfase van het gestructureerd testen veranderden niet, inhoudelijk moet er met name rekening gehouden worden met de effecten van iteratief werken. De intake, voorbereiding en uitvoering van de systeem- en acceptatietest zullen mee itereren met de bouw. Na iedere iteratie worden de producten opgeleverd, er wordt een intake uitgevoerd, testgevallen worden gespecificeerd en de test wordt uitgevoerd. RAD biedt door de iteraties de mogelijkheid eerder te gaan testen, het is van groot belang dat deze mogelijkheden benut worden. Vaak is het moeilijk om gedurende een iteratie de testbasis compleet te krijgen, omdat de specificaties bij RAD meegroeien met het systeem. Daarom is het voor de test van belang de testbasis vroeg en compleet boven water te krijgen. Hiervoor kunnen bijvoorbeeld JAD-verslagen worden gebruikt.Daarnaast kan de gebruiker worden ingeschakeld om testgevallen te specificeren. Een derde mogelijkheid is dat de tester plaats neemt in het bouwteam. Uiteindelijk itereert de test met de bouw mee en hiermee itereert de teststrategie en testbegroting mee. Derhalve is het moeilijk bij RAD een begroting te maken van de benodigde testcapaciteit. Met betrekking tot de infrastructuur heeft RAD effecten op de procedures en het gebruik van testtools. Doordat er bij RAD veel opleveringen plaatsvinden is de beheersing hiervan van groot belang. Daarnaast moet er voldoende aandacht worden besteed aan versiebeheer. Door meerdere iteraties ontstaan er vaak meerdere versies van de programmatuur. Als gevolg van hergebruik van programmatuur en de iteraties worden bij RAD veel hertests uitgevoerd. Derhalve is het van groot belang de conservering van de testware goed te verzorgen. Daarnaast moet het testontwerp helder en toegankelijk zijn. Testtools kunnen een belangrijke bijdrage leveren aan het efficiënt uitvoeren van de regressietests. Het gebruik van deze tools kost echter bij de eerste test meer tijd en geld en de tester moet er goed mee kunnen werken. Een zorgvuldige afweging voor inzet van een testtool is dus van groot belang. Met betrekking tot de pijler organisatie zijn twee vragen van belang. De eerste is of de gebruikers testverantwoordelijkheid krijgen, en zo ja welke en hoe dit georganiseerd wordt. De tweede vraag is waar de tester gepositioneerd moet worden, in het bouwteam of in een apart testteam. Voor beide vragen moet een zorgvuldige afweging worden gemaakt. Er zijn geen aparte testtechnieken die gebruikt worden bij RAD. Alle technieken zijn toepasbaar. Bij RAD is het moeilijk de kwaliteitseisen en acceptatiecriteria gedetailleerd uitgewerkt te hebben als aangevangen wordt met JAD en de bouwfase. Globale kwaliteitseisen en acceptatiecriteria kunnen wel opgesteld worden op basis van de producten van de JRP, maar de gedetailleerde invulling hiervan moet gegeven worden door de gebruikers tijdens de iteraties. Iedere oplevering moet dus gepaard gaan met een set gedetailleerde kwaliteitseisen en acceptatiecriteria waarop de test gebaseerd kan worden. Het is aan de kwaliteitsmanager dit proces te begeleiden. RAD biedt de mogelijkheid de acceptatie te vervroegen. Op basis van de participatie van de gebruiker in de bouwteams (het systeem is gebouwd overeenkomstig de wens van de afnemer) en testen van de producten voortkomend uit de iteraties kunnen opgeleverde delen geaccepteerd worden. Er moet dan echter nog wel een integratietest over het totale systeem worden uitgevoerd. De voorgestelde aanpak heeft echter consequenties voor de ontwikkel- en testaanpak. In de JRP-fase moeten de verantwoordelijkheden, bevoegdheden en mandaatgrenzen van de verschillende partijen duidelijk aangegeven worden. Daarnaast moet er in het mastertestplan aandacht worden geschonken aan waar welke testsoorten belegd worden en hoe acceptatie plaatsvindt. Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
2 van 23 1.0 23-04-2003
Inhoudsopgave MANAGEMENTSAMENVATTING ......................................................................................................... 1 1.
INLEIDING.................................................................................................................................... 3 1.1
2.
INDELING .................................................................................................................................... 3 RAPID APPLICATION DEVELOPMENT..................................................................................... 4
2.1 2.2 2.3 2.4 2.5 3.
INLEIDING .................................................................................................................................... 4 DEFINITIE RAD........................................................................................................................ 4 DOELSTELLINGEN RAD............................................................................................................ 4 KENMERKENDE ASPECTEN VAN RAD ........................................................................................ 4 FASERING ............................................................................................................................... 5 POSITIONERING VAN DE TESTSOORTEN IN RAD................................................................. 7
3.1 3.2 3.3 3.4 4.
INLEIDING ................................................................................................................................ 7 PROGRAMMATEST.................................................................................................................... 7 SYSTEEMTEST ......................................................................................................................... 7 ACCEPTATIETEST ..................................................................................................................... 7 RAD EN GESTRUCTUREERD TESTEN..................................................................................... 8
4.1 INLEIDING ................................................................................................................................ 8 4.2 DE TESTFASERING ................................................................................................................... 8 4.3 INFRASTRUCTUUR .................................................................................................................... 9 4.4 ORGANISATIE ........................................................................................................................ 10 4.4.1 De gebruikers................................................................................................................... 10 4.4.2 Positionering tester .......................................................................................................... 10 4.5 TECHNIEKEN ............................................................................................................................. 12 4.5.1 Technieken gebruikt in de planningsfase ........................................................................ 12 4.5.2 Technieken gebruikt in de voorbereidingfase.................................................................. 12 4.5.3 Technieken gebruikt in de specificatiefase...................................................................... 12 4.5.4 Technieken gebruikt in de testuitvoeringsfase ................................................................ 12 4.5.5 Technieken gebruikt in de afrondingsfase....................................................................... 12 5.
ACCEPTATIE EN ACCEPTATIETEST ..................................................................................... 13 5.1 5.2 5.3 5.4 5.5
6.
INLEIDING .................................................................................................................................. 13 KWALITEITSEISEN EN ACCEPTATIECRITERIA................................................................................. 13 GEÏNTEGREERD ACCEPTATIETESTEN .......................................................................................... 13 MASTERTESTPLAN ..................................................................................................................... 14 TESTSTRATEGIE ........................................................................................................................ 15 VALKUILEN BIJ RAD EN TESTEN .......................................................................................... 16
6.1 INLEIDING .............................................................................................................................. 16 6.2 VALKUILEN ............................................................................................................................ 16 Risico.............................................................................................................................................. 20 Risico.............................................................................................................................................. 20 Risico.............................................................................................................................................. 21 Risico.............................................................................................................................................. 21 7. VERKLARENDE WOORDENLIJST. ................................................................................................ 22
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
1.
SYSQA RAD en testen
Pagina Versie Datum
3 van 23 1.0 23-04-2003
Inleiding
In dit stuk staan aandachtspunten ten aanzien van testen in projecten waar ontwikkeld wordt aan de hand van de systeemontwikkelmethode RAD.
1.1
Indeling
Voordat dieper ingegaan wordt op de effecten van RAD op gestructureerd testen, zal kort aangegeven worden wat er in dit rapport onder RAD wordt verstaan en wat enkele van de kenmerkende aspecten zijn die zoal worden aangetroffen bij RAD. Hier wordt hoofdstuk 2 aan besteed. In hoofdstuk 3 worden de verschillende testsoorten belicht. Vastgesteld wordt of RAD effecten heeft op deze testsoorten. De effecten zelf worden in de daaropvolgende hoofdstukken uitgewerkt. In hoofdstuk 4 worden de effecten van RAD op gestructureerd testen uitgewerkt. De focus van dit hoofdstuk is de systeemtest, hoewel grosso modo deze wijzigingen ook betrekking kunnen hebben op de acceptatietest als deze op conventionele wijze wordt uitgevoerd. De mogelijkheden van RAD om het acceptatieproces te vervroegen of geïntegreerd te laten verlopen met het bouwproces worden behandeld in hoofdstuk 5. In hoofdstuk 6 zal een aantal valkuilen dat bij RAD en testen is te onderkennen de revue passeren. In hoofdstuk 7 is een verklarende woordenlijst opgenomen.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
2.
Rapid Application Development
2.1
Inleiding
Pagina Versie Datum
4 van 23 1.0 23-04-2003
In dit hoofdstuk zal kort aandacht worden besteed aan wat Rapid Application Development (RAD) is. Allereerst wordt een bruikbare definitie van RAD opgesteld. Vervolgens wordt aandacht besteed aan de doelstellingen van RAD. Daarna passeren enkele kenmerkende aspecten van RAD de revue. Als laatste onderwerp wordt de fasering van RAD belicht.
2.2
Definitie RAD
Rapid application development (RAD) is een vrij jonge methode om informatiesystemen te ontwikkelen. De methode is nog in ontwikkeling, er bestaat derhalve nog geen éénduidige definitie van RAD. Daarnaast is er een aantal nieuwe methodes dat variant is van RAD, zoals Iteratief Application Development (IAD), Dynamic Software Development Methodology (DSDM). Daarnaast zijn er meerdere afgeleiden van RAD ontwikkeld door verschillende organisaties, zowel software bedrijven als andere organisaties. De expertisegroep heeft meerdere definities van RAD gevonden. Geen van deze levert echter voldoende praktische handvatten op om RAD te definiëren. In dit stuk zal RAD als volgt worden gedefinieerd: Rapid Application Development (RAD) is een systeem-ontwikkelingsmethode die gebaseerd is op hoge gebruikersinbreng en iteratief ontwikkelen.
2.3
Doelstellingen RAD
RAD is ontwikkeld om tegemoet te komen aan de nadelen van het watervalmodel en de voordelen van beproefde ontwikkelmethoden zoals SDM te benutten, zoals fasering, structuur, doelgerichtheid, begroting en planning. De fasering van het watervalmodel wordt als rigide ervaren. Daarnaast is de ontwikkeltijd lang, de kosten hoog en wordt vaak in onvoldoende mate tegemoet gekomen aan de wensen van de gebruiker. Derhalve valt de doelstelling van RAD uiteen in meerdere zaken: • hoge gebruikersparticipatie om te komen tot een systeem dat aansluit bij de wensen en eisen van de gebruiker; • lage kosten; • snelle ontwikkeling, korte tijdspanne tussen het opstarten van het project en de eerste concrete resultaten; • goede kwaliteit. Met goede kwaliteit wordt in dit kader bedoeld: het voldoen aan de gedefinieerde kwaliteitseisen.
2.4
Kenmerkende aspecten van RAD
Er is een aantal kenmerkende aspecten dat vaak bij RAD trajecten terugkomt. Het is dus niet zo dat al deze aspecten per se terug moeten komen. Vaak zijn RAD- of aanverwante trajecten een samenstel van deze aspecten. • Gebruik krachtige ontwikkeltools; Door het gebruik van krachtige ontwikkeltools kunnen snel (deel)applicaties ontwikkeld worden op een gecontroleerde wijze. Daarnaast is de kwaliteit van de programmatuur vaak beter en is de productiviteit hoger. • Iteratief ontwikkelen; In plaats van het hele systeem met al zijn gewenste functionaliteit te bouwen wordt eerst een beperkte versie gemaakt die op basis van de ervaringen ermee aangepast wordt. Dit proces wordt een aantal keer herhaald en op deze wijze evolueert het systeem naar zijn uiteindelijke vorm. Een variatie hierop is het incrementeel ontwikkelen; dit is het stapsgewijs uitbouwen tot een steeds grotere bruikbaarheid. De tussenproducten worden wel pilots genoemd. • Hoge gebruikersparticipatie; Tijdens alle fases zijn gebruikers intensief betrokken bij de ontwikkeling. In het begin vooral het management, later voornamelijk eindgebruikers van het systeem. Door middel van de gebruikersinbreng wordt getracht een systeem te maken wat beter aansluit op de eisen en wensen Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
•
•
•
•
•
•
SYSQA RAD en testen
Pagina Versie Datum
5 van 23 1.0 23-04-2003
van de gebruiker. Het mandaat van de geselecteerde gebruikers is van groot belang. Zij moeten en mogen beslissen namens de organisatie. Steun van de mandaatgever is eveneens van essentieel belang. Toepassing prototyping; Door middel van prototyping communiceert de ontwikkelaar met de gebruiker over het te bouwen systeem. Door middel van elkaar opvolgende prototypes wordt toegewerkt naar het uiteindelijke systeem. Kleine ontwikkelteams; De gebruikersorganisatie is vertegenwoordigd in deze teams. Indien er een systeem gebouwd moet worden dat te groot is om in één klein team ontwikkeld te worden, zijn er meerdere, parallel werkende teams. De teams worden wel aangeduid als SWAT-teams. Dit staat voor Skilled With Advanced Tools. Timebox; Dit is een van tevoren gedefinieerde periode waarin een bepaalde functionaliteit gebouwd wordt. Indien de functionaliteit niet gehaald wordt, wordt de einddatum niet verschoven. In plaats daarvan worden er minder functionaliteit gebouwd. Op deze wijze tracht men over-engineering te voorkomen en de druk op het project te houden. "Juicy bits first"; Het principe dat binnen een timebox eerst de belangrijkste onderdelen of functionaliteit worden gebouwd. Indien de opdracht voor de timebox niet gehaald wordt, vallen de minst belangrijke onderdelen vanzelf af. Herbruikbaarheid / object oriëntatie; Er moet naar gestreefd worden om kleine, herbruikbare eenheden software te bouwen. Dit verkort de ontwikkeling en verhoogt de kwaliteit, maar hierdoor kan er soms minder goed tegemoet worden gekomen aan de gebruikerswensen. 80/20. Deze werkwijze berust op de veronderstelling dat in 20% van de tijd 80% van de functionaliteit wordt ontwikkeld. Als men op 80% zit stopt men met ontwikkelen voor dat moment. De fine-tuning en completering volgt later, in een latere iteratie. Op deze manier beperkt met de doorlooptijd van iteraties, waardoor de snelheid erin blijft.
2.5
Fasering
Met het oog op de dynamiek van een RAD-traject liggen bepaalde accenten op het beheers- en managementproces. Bij een RAD traject zijn vijf fases te onderkennen. 1. Informatie-analyse fase; In deze fase vindt de informatie-analyse plaats. Deze geeft een beschrijving van de problemen, de oorzaken en mogelijke oplossingsalternatieven. Aan het eind van deze fase moet er een opdracht liggen een informatiesysteem te bouwen, compleet met probleemdefinitie, veranderingsanalyse, risicoanalyse en plan van aanpak. 2. Joint requirement planning (JRP); Tijdens de JRP wordt door de ontwikkelorganisatie en het management van de gebruikersorganisatie vastgesteld wat de doelstellingen, het werkterrein, de verantwoordelijkheden en bevoegdheden zijn. Daarnaast wordt in deze fase de architectuur uitgewerkt en vastgesteld. Ook wordt op hoofdlijnen aangegeven uit welke functionaliteit het te bouwen systeem moet bestaan en wat het belang is van de verschillende functies. De risico's en kritieke succesfactoren moeten in beeld worden gebracht en de kwaliteitsattributen worden vastgesteld. JRP gebeurt vaak door middel van een workshop. 3. Joint application design (JAD); Tijdens JAD-sessies ontwerpen de bouwers en de eindgebruikers samen het systeem. Tijdens de sessies wordt intensief gebruik gemaakt van prototyping. De gebruikerswensen worden vastgelegd en tijdens de sessie of tijdens een later sessie worden prototypes gemaakt. Op aangeven van de gebruiker worden de prototypes aangepast. Ook wordt een ontwerp van het gegevensmodel gemaakt.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
6 van 23 1.0 23-04-2003
4. Bouwfase; Tijdens de bouwfase wordt het tijdens de JAD-fase gedefinieerde product gebouwd. Hierbij komen enkele van de genoemde aspecten naar voren, zoals timeboxing, juicy bits first, evolutionair (of iteratief) ontwikkelen, 80/20 en (vooral) gebruik van tools. Het bouwen gebeurt in kleine (bouw-) teams waarin ook gebruikers vertegenwoordigd zijn. De gebruiker geeft zijn wensen aan (op gedetailleerder niveau dan tijdens de JAD-sessie), reviewt tussenproducten, werkt documentatie bij, et cetera. 5. Invoering. Aan het eind van de bouwfase (timebox) wordt het product opgeleverd en indien het aan de kwaliteitseisen voldoet kan het product ingevoerd worden. Opmerking: de JRP vindt éénmaal plaats. De JAD-fase en bouwfase kunnen meerdere malen plaatsvinden. Dan wordt per timebox begonnen met een JAD sessie, waarna men gaat bouwen. Dit proces herhaalt zich dan enkele malen (iteraties). Hieronder wordt het verschil tussen een waterval methode en RAD grafisch weergegeven. Fasering volgens System Development Methodology: IA
FO
TO
REAL
IMPL
EXPL
IA = informatieanalyse FO = functioneel ontwerp TO = technisch ontwerp REAL = realisatie (bouw) IMPL = implementatie EXPL = exploitatie Fasering volgens Rapid Application Development IA
JRP JAD
Bouw JAD
Bouw JAD
Bouw JAD
Bouw
Iedere JAD-bouw combinatie is één iteratie of increment. Iedere iteratie moet concrete softwareproducten opleveren. De positionering van de invoeringsfase hangt af van de variant van RAD die gekozen wordt.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
3.
Positionering van de testsoorten in RAD
3.1
Inleiding
Pagina Versie Datum
7 van 23 1.0 23-04-2003
Binnen het gestructureerd testen worden meerdere testsoorten onderkend. Een veelgehoorde indeling is de volgende: 1. Programmatest (of unittest, module test, bouwtest); 2. Systeemtest (of integratietest, functionele test); 3. Acceptatietest (of gebruikerstest). In dit hoofdstuk zal kort in worden gegaan op de effecten van RAD op de testsoorten. De uitwerking in detail volgt in de hoofdstukken 4 en 5.
3.2
Programmatest
Van oudsher wordt de verantwoordelijkheid voor de programmatest bij de bouwers gelegd. Bij RAD is dat niet anders. Nog steeds moeten de bouwers vaststellen dat het door hen gemaakte onderdeel werkt zoals beschreven. Er bestaat bij RAD wel, meer dan bij andere systeemontwikkelingsmethoden, het risico dat bouwers deze achterwege laten. Zij werken immers in een timebox en het streven is zo veel mogelijk functionaliteit te realiseren. Door minder te testen of te documenteren kunnen de bouwteams dan meer functionaliteit bouwen. Om dit te voorkomen zal hierop gestuurd moeten worden. Teamleiders zullen de verantwoordelijkheid moeten krijgen hierop toe te zien en als na oplevering blijkt dat geen adequate programmatest is gedaan zal het product terug moeten naar de bouwer die dan alsnog de programmatest uit moet voeren. Hierop kan ook geanticipeerd worden door van tevoren in voorlichtingsessies hier aandacht aan te besteden en het expliciet in te plannen en op te nemen als aparte post op tijdschrijf formulieren. Uitgangspunt moet zijn dat de bouw “testbare” producten oplevert.
3.3
Systeemtest
De systeemtest wordt uitgevoerd door de leverancier. Doel hiervan is vast te stellen of het totale systeem functioneert zoals beschreven staat in de specificaties. Bij een waterval-traject begint een testteam met de voorbereiding en het specificeren van testgevallen als de bouwers aan het bouwen zijn en worden deze testgevallen uitgevoerd zodra de bouwers klaar zijn. De systeemtest kan tijdens de bouw worden voorbereid. De testgevallen zijn gebaseerd op het functioneel ontwerp dat af is zodra de bouwers beginnen met bouwen. Bij RAD is er echter geen functioneel ontwerp beschikbaar zodra de bouwactiviteiten beginnen, er is slechts een globaal ontwerp. Daarnaast is er bij RAD geen sprake van één groot project, maar er is sprake van meerdere, snel op elkaar volgende ontwikkelcycli. De fasering en organisatie zoals we die kennen moet dus anders worden ingericht. Hierop wordt dieper ingegaan in hoofdstuk 4.
3.4
Acceptatietest
De acceptatietest is de verantwoordelijkheid van de opdrachtgever en richt zich erop een advies te geven over de kwaliteit van het systeem en inzicht te verschaffen over de risico´s van in productiename. RAD heeft een zeer dynamisch karakter. Hierdoor ontstaat regelmatig enige hectiek. Het moet echter wel een systeem opleveren dat het proces waarvoor het gemaakt is kan ondersteunen, zonder dat dit proces te zeer verstoord wordt. Om hier zekerheid over te verschaffen is het noodzakelijk een acceptatietest uit te voeren. RAD biedt echter mogelijkheden dit acceptatieproces te vervroegen en geïntegreerd met de bouw uit te voeren. In hoofdstuk 5 zal hierop in worden gegaan. Overigens is hoofdstuk 4 ook van toepassing op de acceptatietest.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
4.
RAD en gestructureerd testen
4.1
Inleiding
Pagina Versie Datum
8 van 23 1.0 23-04-2003
De definitie van gestructureerd testen is het proces van plannen, voorbereiden en meten dat tot doel heeft de kenmerken van een informatiesysteem vast te stellen en het verschil tussen actuele en vereiste status aan te tonen. Het gestructureerd testen is gebaseerd op vier pijlers: fasering van de testactiviteiten, technieken, infrastructuur & tools en organisatie & personeel. De theorie van het gestructureerd testen is uitgewerkt tegen de achtergrond van het watervalmodel. In dit hoofdstuk zullen de effecten van RAD op het gestructureerd testen worden uitgewerkt.
4.2
De testfasering
Het gestructureerd testen valt uiteen in een vijftal fases: 1. planning; 2. voorbereiding; 3. specificatie; 4. uitvoering; 5. afronding. Er wordt bij het gestructureerd testen vanuit gegaan dat als begonnen wordt met het testtraject, er een functioneel ontwerp ligt. Op basis hiervan kan een plan van aanpak, planning en een testbegroting worden gemaakt, de testtechnieken kunnen worden toegewezen en de testgevallen kunnen worden gespecificeerd. Op deze manier kunnen de testspecificaties gelijk oplopen met de bouw en wordt bereikt dat er een hoge dekkingsgraad wordt gehaald en het testen zo kort mogelijk op het kritieke pad zit. Voor wat betreft de fase planning zijn activiteiten hetzelfde als bij een watervaltraject. Inhoudelijk zijn de effecten wel groot. Zo zullen met name de iteratieve aspecten van RAD moeten worden verwerkt in het plan van aanpak. Hoewel er geen functioneel ontwerp ligt moeten de activiteiten uit de fase planning uitgevoerd kunnen worden op basis van het globaal ontwerp en de andere producten die uitvoer zijn van de joint requirement planning. De overige fases kunnen bij RAD niet op dezelfde wijze worden aangepakt als bij een watervaltraject. Bij aanvang van de overige fases is er namelijk geen functioneel ontwerp. Na de joint requirement planning ligt er een globaal ontwerp, maar meer is er vaak niet. Over het algemeen loopt het functioneel ontwerp mee met de bouwactiviteiten en kan dus niet of nauwelijks eerder worden opgeleverd dan de producten zelf. Hierdoor zou men pas kunnen beginnen met het specificeren van testgevallen als de bouwfase is afgerond. Dit staat echter haaks op één van de doelstellingen van RAD: het verkorten van de time to market. De winst die er is gehaald in de ontwerp- en bouwfase wordt dan weer teniet gedaan door het testen. Daarnaast zal de druk om zo kort mogelijk op het kritieke pad te zitten bij RAD mogelijk nog hoger zijn dan bij een watervalmethode. Doordat specificaties aan het eind van het (deel-)traject beschikbaar komen, vormt tijdsdruk het grote gevaar voor gestructureerd testen. Hierdoor ontstaat er een spanningsveld tussen zo snel mogelijk op willen leveren en kwaliteit. Bij RAD wordt de software echter wel eerder opgeleverd, waardoor eerder gestart kan worden met testen. Het probleem hierbij is dat de informatie op basis waarvan testgevallen gemaakt moeten worden laat beschikbaar komt. Er zijn meerdere mogelijkheden om dit probleem te lijf te gaan: 1. Haal zo vroeg mogelijk in het proces informatie uit het proces. Zo zou een tester bij de JADsessies aanwezig kunnen zijn als wel de JAD-verslagen kunnen gebruiken. Op basis van de opgedane kennis kan de tester dan (voorlopige) testgevallen maken die gecontroleerd en eventueel aangepast worden zodra de daadwerkelijke oplevering plaats vindt. 2. De gebruiker inschakelen bij het maken van de testgevallen. Gebruikers hebben vaak een goed beeld van wat getest moet worden. De tester kan hieruit testgevallen specificeren. Daarnaast hebben zij aangegeven hoe het onderdeel gebouwd moet worden, dus de functionele kennis is hier aanwezig. Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
9 van 23 1.0 23-04-2003
3. De tester kan in het bouwteam zitting nemen. Voordeel is dat de tester vroeg, snel, volledig en met weinig additionele inspanning van anderen geïnformeerd kan worden. Nadeel is dat de tester mogelijk zijn testgevallen gaat baseren op hetgeen hij gehoord heeft in plaats van wat er in de specificaties staat, waardoor de specificaties van onvoldoende kwaliteit zijn. Daarnaast komt de objectiviteit van de tester mogelijk in het gedrang. De tester kan een rol spelen in het reviewen van de aanpak van de programmatest. Er moet in ieder geval voor gezorgd worden dat zo vroeg mogelijk wordt begonnen de specificatie van testgevallen en het uitvoeren van de test. Zodra de eerste (voorlopige) producten klaar zijn moet de tester begonnen zijn met het specificeren van testgevallen. Hier moet niet mee gewacht worden tot het product uit geïtereerd is en zijn definitieve vorm heeft. Op basis van de pilots kunnen testontwerpen en testgevallen worden gemaakt die misschien aangepast moeten worden zodra het product zijn definitieve staat bereikt, maar over het algemeen kost dit aanpassen minder tijd dan het opzetten van geheel nieuwe tests. Zo wordt de tijd dat de specificatie en de uitvoering op het kritieke pad zit ook beperkt. Er wordt wel eens gezegd dat RAD een heleboel kleine watervalletjes achter elkaar zijn, waar het voordeel van is dat het water uiteindelijk ergens anders terecht zou kunnen komen dan bij één grote waterval. Het testen zal niet moeten wachten tot het water beneden is, maar bij RAD meteen na het eerste watervalletje moeten beginnen met haar activiteiten. Zo itereert de test vlak achter de bouw aan. Door het werken met iteraties beweegt het testontwerp en de testspecificaties zich naar hun definitieve vorm. In feite vinden de fases voorbereiding, specificeren en uitvoeren kort na elkaar plaats. Na iedere bouwiteratie zal in de voorbereidingsfase het product steeds opnieuw een intake moeten ondergaan. Bij de eerste oplevering zal een teststrategie moeten worden ontwikkeld en testtechnieken moeten worden toegekend en zal een testbegroting moeten worden gemaakt. Overigens kan een voorlopige begroting veel eerder gemaakt worden met behulp van een functiepuntanalyse en ervaringscijfers. Bij iedere volgende iteratie zal een intake plaats moeten vinden (is het product nog steeds van voldoende kwaliteit en wat zijn de wijzigingen) en zal beoordeeld moeten worden of de teststrategie, gekozen testtechnieken en testbegroting nog steeds de juiste zijn. Na de eerste intake zal begonnen kunnen worden met de specificatie. Deze verloopt hetzelfde als bij een watervalmethode. Na de iteraties zullen de testgevallen alleen moeten worden aangepast. Om hergebruik te bewerkstelligen zal de documentatie van de testgevallen van hoge kwaliteit moeten zijn. Anders kan na iedere oplevering opnieuw worden begonnen met de specificatie. Als laatste zullen de testgevallen uitgevoerd moeten worden, bij voorkeur automatisch (zie onderdeel tools). Ten behoeve van het hergebruik zal er continu geconserveerd moeten worden, maar het is verstandig regelmatig afrondingsfases in te lassen om de gemaakte keuzes te evalueren en de testgevallen goed te conserveren. Ten behoeve van het conserveren is het verstandig te werken met sjablonen of templates, om er voor te zorgen dat de testgevallen op éénduidige wijze worden vastgelegd en dat andere testers deze gevallen ook kunnen gebruiken/uitvoeren. Het testontwerp (logisch en fysiek) moet in een heldere structuur worden gegoten. Hieruit moet af te leiden zijn hoe uit de functionele documentatie het logische en fysieke ontwerp tot stand is gekomen, wat het testgeval doet en wat de outputvoorspelling is en dergelijke. Na afloop van het totale testtraject zal er, indien nodig, een uitgebreide afronding plaats moeten vinden, waarbij de documentatie van alle testgevallen op peil wordt gebracht.
4.3
Infrastructuur
Onder de infrastructuur wordt verstaan de testomgeving en de testtools.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
10 van 23 1.0 23-04-2003
De testomgeving bestaat uit de hard- en software, het netwerk, de testbestanden, de beheersprocedures en de kantoorinrichting. Het enige onderdeel waar RAD van invloed op is, zijn de beheersprocedures. Opleverprocedure Bij RAD vinden er veel opleveringen plaats omdat er iteratief ontwikkeld wordt. Hoe korter de iteraties des te meer opleveringen en des te meer risico dat dit proces ongecontroleerd plaats gaat vinden. Derhalve zal hier een goede procedure voor moeten worden gemaakt. In deze procedure zal minimaal moeten staan wie verantwoordelijk is voor het opleveren, wat er opgeleverd moet worden, hoe dit moet gebeuren en wat de kwaliteitseisen zijn. Versiebeheer Omdat er iteratief gewerkt wordt kan een nieuwe versie in de maak zijn, terwijl de vorige versie nog niet getest is. Het is daarom van groot belang het versiebeheer goed in te richten. Het moet duidelijk zijn waar welke versie is, welke versie opgeleverd en getest moet worden, in welke versie welke bevinding is gedaan, et cetera. Testtools CAST-tools (Computer Aided Software Testing tools) zijn hulpmiddelen voor het ondersteunen van het testmanagement, het analyseren van broncode, het geautomatiseerd vastleggen en uitvoeren van testscripts of het genereren van testdata. Door de vele iteraties bij RAD worden er veel regressietests uitgevoerd. Tools kunnen een waardevolle bijdrage leveren aan de effectiviteit en efficiëntie van het testproces. Bij iteratief ontwikkelen moet dezelfde functionaliteit meerdere malen getest worden. Met name bij het hertesten zijn testtools zeer krachtig en besparen ze veel tijd. Andere voordelen van geautomatiseerd testen zijn het ‘verplicht’ gestructureerd testen en vastleggen van test en resultaten, het eenvoudig verkrijgen van managementinformatie, de mogelijkheid om grote hoeveelheden tests uit te voeren en testdata te gebruiken, het ‘unattended’ uitvoeren van tests en het eenmalig vastleggen van standaardtests voor alle functionaliteit. Enkele negatieve punten bij het inzetten van CAST-tools zijn de hoge initiële kosten voor aanschaf en opleiding van testers (in verhouding tot de totale testkosten veelal toch zeer beperkt), de hoge investering in tijd voor het initieel aanmaken van de testscripts en het onderhouden van de scripts en testdata. Hierdoor zal de inzet van CAST-tools pas na drie tot vier keer hertesten, dus veelal pas in de beheersfase, rendement opleveren. Het gebruiken van CAST-tools kost nog steeds veel handwerk, is niet eenvoudig en vereist derhalve gespecialiseerde testers. Eindgebruikers zijn nauwelijks inzetbaar bij het gebruik van testtools.
4.4
Organisatie
Bij de inrichting van de testorganisatie worden meerdere partijen- en functionarissen onderkend; bouwers, testers, testmanagement, methodische ondersteuning en intermediair en technische ondersteuning. Bij RAD wordt hier nog één functionaris aan toegevoegd: de gebruiker. 4.4.1 De gebruikers Naast de rol van materiedeskundige kan de gebruiker bij RAD testverantwoordelijkheid krijgen. Het spreekt voor zich dat hij niet alle test verantwoordelijkheid kan krijgen, het is immers geen tester, maar het kan efficiënt zijn taken in het kader van user-interface tests bij hem neer te leggen. Bij RAD worden de schermen vaak met behulp van prototyping gebouwd met de gebruiker. De verschillende versies van de schermen (van initieel tot definitief) zal de gebruiker beoordelen. Hierbij staat voor hem voorop of het scherm functioneert zoals hij wil. Tegelijkertijd kan de gebruiker het scherm beoordelen op bijvoorbeeld organisatiebrede voorschriften en andere standaards. Als de gebruiker het scherm dan heeft goedgekeurd kunnen de testers er vanuit gaan dat het scherm voldoet aan de gestelde eisen. Hiermee wordt dubbel werk voorkomen. 4.4.2 Positionering tester Voor wat betreft de functionele test moet vantevoren gekozen worden of de tester in bouwteam plaats moet nemen of dat er gekozen moet worden voor een apart testteam. Beide opties hebben voordelen. De voordelen sluiten elkaar overigens niet uit.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
11 van 23 1.0 23-04-2003
Testers geïntegreerd met het bouwteam Voordelen: - korte communicatie-lijnen; - korte terugkoppeltijd van bevindingen na bouw omdat er direct na elke bouwfase (ook prototype) getest kan worden. - tester groeit mee met het iteratief ontwikkelen (elke wijziging is direct bekend waardoor er geen risico bestaat dat, door het iteratieve karakter van RAD trajecten, de programmatuur tijdens het testen al functioneel gewijzigd is voordat de testactiviteiten afgerond zijn en testsets en bevindingen hun waarde voor eventuele regressietests kunnen verliezen); - snel opbouwen van functionele kennis, door JAD-sessies; - bevindingen in een zeer vroeg stadium (al bij prototype); - snelle product review; - eerste oplevering sneller en kwalitatief beter (indien foutherstel heeft plaatsgevonden of met bug-list); - meeste tests vinden niet op het kritieke pad plaats; - bouwer en tester werken met hetzelfde tempo; Testers niet geïntegreerd met het bouwteam Voordelen: - geen directe wederzijdse beïnvloeding (bouwers bouwen en testers testen); - kleinere teams; - noodzaak van het opzetten van gedegen functionele beschrijvingen met alle functionele paden; - test op basis van specificaties gewaarborgd; - gedegen toetsing van de specificaties; - gestructureerd testen beter gewaarborgd; - conservering van bruikbare testware (t.b.v. regressie tests); - gedegen risicoanalyse mogelijk; - geen extra (technische) IT-kennis noodzakelijk; - functies en verantwoordelijkheden zijn duidelijk; - iedereen heeft zijn eigen technische bouw/test-omgeving; Er is een groot aantal factoren dat een rol speelt bij de vraag of de tester in het bouwteam plaats moet nemen. Enkele van deze factoren zijn: • Online versus batch programmatuur; Indien het een systeem betreft met veel online functies kunnen testers heel goed binnen het bouwteam worden geplaatst omdat de specificaties dan minder van belang zijn. Betreft het een systeem met veel batchtaken dan is het systeem over het algemeen veel ingewikkelder en is een gestructureerde test van veel groter belang. Een apart testteam ligt dan meer voor de hand. • Functioneel eenvoudig versus complex; Naar analogie van het vorige punt kunnen testers heel goed geïntegreerd worden in het bouwteam als het gaat om een functioneel eenvoudig programma. Gaat het om een complexer systeem dan is een apart testteam logischer. • Veel of weinig documentatie; Indien er weinig documentatie is dan heeft het voordelen de tester in het bouwteam te zetten, is er goede en uitgebreide documentatie dan kan hij buiten het bouwteam blijven. • Prototyping versus stabiel product; Wordt er veel aan prototyping gedaan dan kan een tester heel goed in het bouwteam zitten, is er sprake van een stabiel product dan gaat dat niet op. Met stabiel wordt in dit kader bedoeld een product dat weinig aan wijzigingen onderhavig is. • Programmatest versus systeemtest; Indien de tester in plaats van een bouwer een programmatest uit moet voeren zullen de voordelen van een tester in het bouwteam veel groter zijn dan wanneer de tester een systeemtest uit moet voeren. Ten behoeve van de afweging om de tester wel of niet in het bouwteam te plaatsen kan op basis van bovenstaande punten een beslissingsmatrix worden gemaakt. Voorafgaand aan de start van het project, of anders zo vroeg mogelijk, moet een bewuste keus worden gemaakt over de positionering van de tester. Omdat ieder project uniek is zal iedere keer opnieuw de afweging gemaakt moeten worden.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
4.5
SYSQA RAD en testen
Pagina Versie Datum
12 van 23 1.0 23-04-2003
Technieken
Iedere fase van het gestructureerd testen kent zijn eigen technieken. De invloed van RAD op deze technieken wordt hier besproken. 4.5.1 Technieken gebruikt in de planningsfase De technieken die in de planningsfase worden gebruikt zijn bepalen teststrategie en testbegroting. De technieken en het gebruik ervan wijzigen niet ten opzichte van een waterval traject. Hoewel er geen functioneel ontwerp is, moeten de voorliggende fases voldoende input leveren om deze fase uit te voeren. Als vanzelfsprekend moet er wel bij het plan van aanpak, de teststrategie en de testbegroting rekening worden gehouden met het feit dat met RAD ontwikkeld wordt. 4.5.2 Technieken gebruikt in de voorbereidingfase Door het iteratief ontwikkelen zullen veelvuldig producten worden opgeleverd en zullen producten ook meerdere keren worden opgeleverd. Derhalve zal intake van producten zeer vaak uitgevoerd worden. Het is daarom raadzaam goede checklists te maken en een procedure te ontwerpen hoe deze intake plaats moet vinden. De eerder genoemde overdrachtsprocedure hangt hier ook mee samen. 4.5.3 Technieken gebruikt in de specificatiefase Tijdens de specificatiefase worden met behulp van testtechnieken testgevallen gemaakt. In feite kan iedere iteratie worden beschouwd als een normaal testtraject, waarin een bouwtest, systeemtest en acceptatietest kan worden uitgevoerd. Dus kunnen alle gestructureerde testtechnieken worden toegepast. Er zijn geen RAD-specifieke testtechnieken. Projecten waarbij met RAD wordt ontwikkeld willen nog wel eens erg dynamisch verlopen. Er wordt op een snelle wijze, met korte communicatielijnen een pilot gebouwd en is die af dan wil men weer zo snel mogelijk verder. Het is zaak dat de testers zich niet hierin laten mee slepen. Daarom zal ervoor gewaakt moeten worden dat de technieken onverkort toe worden gepast, zodat er een kwalitatief goede test kan worden uitgevoerd. Indien blijkt dat er te weinig tijd is om een gefundeerd oordeel te kunnen kunnen vormen over de kwaliteit en risico moet dit worden gesignaleerd. Er kan dan een bewuste afweging worden gemaakt. 4.5.4 Technieken gebruikt in de testuitvoeringsfase De technieken die tijdens deze fase worden gebruikt zijn bij RAD niet anders. Belangrijker in deze fase is of er gebruik wordt gemaakt van testtools. De rapportage verandert overigens wel. Bij een project ontwikkeld met een watervalmethode zal van tevoren goed bekend zijn wat er nog op een testteam af komt. Bij RAD is dat anders, men weet wel wanneer er wordt opgeleverd (als gevolg van timeboxen), maar men weet niet exact wat er wordt opgeleverd. Er is wel vaak globaal bekend welke functionaliteit er in een timebox gebouwd moet worden. Op basis hiervan kan een globale testplanning gemaakt worden. Dit bemoeilijkt het plannen en rapporteren hierover. De enige vorm van (korte termijn) planning is dat de test achter de bouw aan komt. 4.5.5 Technieken gebruikt in de afrondingsfase Zoals gezegd moet evaluatie en conservering geïntegreerd in de iteraties plaatsvinden. Hiervoor moeten dus strakke procedures, sjablonen en dergelijke aanwezig zijn. In essentie veranderen de technieken (evaluatie en documentatie) niet, maar door de frequentie zal dit strakker gemanaged moeten worden. Zeker als de testers in de bouwteams zitten moet het documenteren / conserveren goed worden gemanaged. Iedere tester zal, in het kader van overdraagbaarheid, reproduceerbaarheid en traceerbaarheid, op identieke wijze zijn tests moeten documenteren. Hiertoe moet in een dergelijk geval een testcoördinator worden aangesteld. Deze kan er ook op toezien dat de verschillende testers hun taak naar behoren uitvoeren en geen ontwerp- / bouwactiviteiten op zich nemen. Hij moet de dynamiek van het testtraject beheersen, overzicht behouden in versies, foutmeldingen en resources. Hij is de linking pin naar de opdrachtgever en communiceert over het testtraject met de projectmanager.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
5.
Acceptatie en acceptatietest
5.1
Inleiding
Pagina Versie Datum
13 van 23 1.0 23-04-2003
Bij de traditionele ontwikkelscenario’s volgt de acceptatietest na de bouwfase en wordt getest op basis van van tevoren geformuleerde kwaliteitseisen en acceptatiecriteria. Voordeel hiervan is dat het totale systeem onderworpen wordt aan een acceptatietest. Nadeel is dat het de implementatie van het systeem uitsteld. Bij RAD is het nogal eens problematisch de kwaliteitseisen en acceptatiecriteria bij aanvang van de ontwikkeling concreet en helder boven tafel te hebben. Daarintegen biedt RAD de mogelijkheden om het acceptatieproces anders in te richten, te vervroegen. Op beide zaken wordt in dit hoofdstuk ingegaan.
5.2
Kwaliteitseisen en acceptatiecriteria
Als een systeem ontworpen wordt horen hierbij ook de kwaliteitseisen en acceptatiecriteria aangegeven te worden. De leverancier weet dan waar het systeem aan moet voldoen en alle testteams kunnen hun teststrategie hierop baseren. Bij aanvang van een RAD-traject is het globaal ontwerp bekend. Hieruit kunnen de globale kwaliteitseisen worden afgeleid. De specifieke invulling van de kwaliteitseisen en acceptatiecriteria is terug te vinden in het functioneel ontwerp. Dit is bij RAD niet beschikbaar als begonnen wordt het de JAD-sessies en bouwfase. Hiertegenover staat dat acceptatie gebaseerd moet zijn op een programma van eisen wat vooraf en concreet toetsbaar is vastgelegd. Acceptatie zal steeds op een bekende set van eisen – de door allen overeengekomen testbasis vormend – gegrondvest moeten worden. Er kan vaak al veel over acceptatiescriteria gezegd worden voordat het functioneel ontwerp er is. Zo kunnen er eisen zijn die gesteld worden door de beheers- of gebruikersorganisatie. Ook de architectuur of het kwaliteitssysteem kunnen de nodige zaken opleveren. Omdat de te bouwen functionaliteit nog niet voldoende concreet is vastgesteld is het vaak niet mogelijk een volledig en concreet pakket van eisen op tafel te leggen. Een mogelijke oplossing voor dit dilemma is het per onderdeel formuleren van kwaliteitseisen en acceptatiecriteria tijdens de JAD-sessies. Ieder detailontwerp moet dus vergezeld gaan van kwaliteitseisen en acceptatiecriteria. De gebruiker die bij de JAD-sessie input levert, moet deze eisen en criteria aangeven. Hij moet hier dan wel het mandaat voor hebben. Op deze wijze groeien de kwaliteitseisen en acceptatiecriteria per onderdeel uit tot de kwaliteitseisen en acceptatiecriteria van het totale systeem. Overigens moet dit proces goed begeleid worden, omdat de kans bestaat op te fragmentarische, los van elkaar staande kwaliteitseisen en acceptatiecriteria. Hier ligt een taak voor de kwaliteitsmanager. Deze moet erop toe zien dat er een samenhangende cluster van acceptatiecriteria en kwaliteitseisen ontstaat, die éénduidig gedefinieerd is. Zodra het totale systeem naar zijn uiteindelijk vorm toe evolueert moeten de kwaliteitseisen en acceptatiecriteria voor het totale systeem geformuleerd en door de opdrachtgever onderschreven worden. Op deze wijze groeien de kwaliteitseisen en acceptatiecriteria mee met het systeem en evolueren deze ook naar hun definitieve vorm. Risico hiervan is wel dat deze gaande het traject verandering ondergaan, waardoor een gekozen teststrategie aangepast moet worden. Consequentie is in het ergste geval dat de testspecificaties en scripts opnieuw gemaakt moeten worden of bijgesteld moeten worden. Deze gevaren moeten in dat geval boven tafel komen en als nadeel (kosten) worden aangemerkt bij het besluit de kwaliteitseisen en acceptatiecriteria te wijzigen. Indien dan de baten nog steeds opwegen tegen de kosten loont het om de kwaliteitseisen en acceptatiecriteria te wijzigen en een deel van het (test)werk opnieuw te doen.
5.3
Geïntegreerd acceptatietesten
Het is (theoretisch) mogelijk het acceptatietesten anders in te richten dan gebruikelijk. Gebruikelijk is in dit geval dat de planning, voorbereiding en specificatie plaats vindt op basis van tevoren Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
14 van 23 1.0 23-04-2003
gedefinieerde kwaliteitseisen en acceptatiecriteria. Het testen van het totale systeem vindt plaats na oplevering van de leverancier aan de opdrachtgever. Zoals we al hebben gezien kunnen, dan wel moeten, de kwaliteitseisen en acceptatiecriteria door de gebruiker worden bepaald tijdens het traject. De gebruiker kan dan ook, eventueel ondersteund door een tester, vaststellen of dat deel van het systeem voldoet aan de door hem gestelde eisen. Op basis hiervan vindt er gedurende het traject deel-acceptatie plaats van het systeem. Het totale systeem kan echter niet geaccepteerd worden op basis van deel-acceptaties. De werking van de delen zegt nog niets over de werking van het geheel. De werking van het geheel kan vastgesteld worden door een integratietest uit te voeren aan het eind van het traject. Dit kan door de leverancier en de opdrachtgever samen worden uitgevoerd en gestreefd kan worden naar het zo vroeg mogelijk uitvoeren van (delen van) de integratietest. Hiermee zou een uitgebreide acceptatietest aan het eind kunnen komen te vervallen. Bovenstaande werkwijze heeft zeker voordelen. Zo is het tijdrovende acceptatietesten overbodig, wat de time to market verkort, een doelstelling van RAD die in dit geval niet in de wielen wordt gereden door het testen. Daarnaast is de kwaliteitsborging goed verankerd in het project, doordat de gebruikers bij alle onderdelen kwaliteitseisen en acceptatiecriteria moeten formuleren en moeten testen. Daarnaast krijgen zowel de opdrachtgever als de leverancier vroegtijdig signalen als zaken niet goed lopen. Als het bijvoorbeeld blijkt dat het meer tijd kost een bepaald onderdeel van die kwaliteit te maken die gewenst is, blijkt dat al tijdens de bouwfase in plaats van tijdens de acceptatietest (de bouwer heeft immers kwaliteitseisen en acceptatiecriteria meegekregen bij zijn opdracht en er vindt al een stukje acceptatietest plaats tijdens het traject). Er kan dus vroeg worden bijgestuurd. Daarnaast worden de gebruikers zich bewuster van wat ze vragen. Als zij hoge kwaliteitseisen formuleren zullen ze zien dat er minder tijd is in de timebox om functionaliteit te bouwen of de gebruikersvriendelijkheid te verhogen. Er zal dus een trade-off ontstaan tussen te bouwen functionaliteit, tijd, geld en kwaliteit. De beslissingen hierover worden genomen op de plaats waar ze genomen moeten worden: bij de opdrachtgever. De geschetste werkwijze heeft echter ook een aantal nadelen c.q. risico´s. Voornaamste risico zit hem erin dat er geen volledige, productie-like acceptatietest wordt uitgevoerd. Bij een integratietest wordt vastgesteld of alle onderdelen van het systeem goed samenwerken, de test is er niet op gericht vast te stellen wat de kwaliteit is van de verschillende onderdelen en wat de risico´s zijn van in productiename. Daarnaast wordt een integratietest altijd in een bouwomgeving uitgevoerd en niet in een productie-omgeving. Natuurlijk kan ernaar gestreefd worden de integratietest zo uit te breiden dat (voor een deel) tegemoet kan worden gekomen aan de tekortkomingen. Ook bestaat het risico dat de bouwer de gebruiker “overruled” met kennis. In dat geval stelt de gebruiker niet onafhankelijk vast of het systeem(deel) voldoet aan de gestelde kwaliteitseisen en acceptatiecriteria maar laat de bouwer zien wat hij denkt dat het systeem(deel) moet doen. Als laatste wordt opgemerkt dat een testteam dat bij de leverancier zit een andere scoop heeft dan een acceptatietestteam dat bij de opdrachtgever zit. Een testteam bij de leverancier wil slechts vaststellen of voldaan is aan de opdracht, een testteam dat bij de opdrachtgever zit wil vaststellen of het systeem van voldoende niveau is om het werkproces er afhankelijk van te maken. Deze verschillende belangen kunnen tot problemen leiden. Indien het gaat om een bedrijfskritisch systeem kunnen deze risico´s zo groot worden dat het raadzaam blijft om een “conventionele” acceptatietest uit te voeren en de nadelen hiervan gewoon te accepteren. Het lijkt in ieder geval raadzaam om een productie-acceptatietest (schaduwdraaien, reallifetest) uit te voeren. Hierbij wordt er dan vanuit gegaan dat alle functionele paden door de leverancier, ondersteund door de gebruiker, zijn getest. De productie-acceptatietest toont dan aan dat het systeem in productie naar behoren werkt.
5.4
Mastertestplan
Meer nog dan bij waterval is het bij RAD belangrijk van tevoren goed na te denken over het testen en de acceptatie van het systeem. Vooraf moeten hierover keuzes worden gemaakt en vastgelegd. Verantwoordelijkheden, bevoegdheden en mandaatgrenzen zullen duidelijk en helder moeten zijn. Dit vormt een onderdeel van het kwaliteitssysteem. Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
15 van 23 1.0 23-04-2003
Ook zullen de verschillende testsoorten belegd moeten worden en aangegeven moeten worden wie op welke kwaliteitscriteria test. Er zal dus in een vroeg stadium een mastertestplan moeten worden geschreven, waarna de verschillende partijen hun proces conform dit plan in kunnen richten.
5.5
Teststrategie
In paragraaf 4.2 hebben we kunnen zien dat de kwaliteitseisen en acceptatiecriteria veelal niet bij aanvang beschikbaar zijn. Dit veroorzaakt een probleem bij het opstellen van de teststrategie. Deze moet namelijk gebaseerd zijn op de kwaliteitseisen en acceptatiecriteria. Daar de kwaliteitseisen en acceptatiecriteria lopende het traject opgesteld en concreet gemaakt worden, zal de teststrategie dus ook lopende het traject moeten groeien. Ook deze evolueert dus. Ergens moet er wel een moment worden gekozen dat de kwaliteitseisen en acceptatiecriteria vast staan. Hierop kan dan ook de definitieve teststrategie gebaseerd worden. Als vanzelfsprekend moet er een teststrategie ontworpen worden op basis van de aan het begin van het traject beschikbare informatie. Daarnaast zal de werkwijze van ieder testteam erop gericht moeten zijn te komen tot een teststrategie die ertoe leidt dat het systeem goed getest wordt. Er zullen dus continu prioriteiten moeten worden gesteld. Hierbij zullen de testers zich moeten richten op de sleutelelementen. Als er zaken weinig of geen aandacht krijgen moet dit in de lijn liggen van de accenten in de kwaliteitseisen en acceptatiecriteria. Ook zal dit helder gerapporteerd moeten worden aan de projectleider en de opdrachtgever. Aan deze partijen wordt de keuze gelaten waar het accent op moet liggen. Bij dit proces kunnen gebruikers een belangrijk rol spelen. Zij kunnen aangeven waar de test zich op moet richten en zij kunnen ook testspecificaties ter goedkeuring voorgelegd krijgen (ook dit is weer een keuze die bepaald moet worden in het mastertestplan). Overigens kunnen gebruikers zich richten op het testen van de user-interface en testers op complexe logica. Het testteam zal erop gefocust moeten zijn wat haar werkvoorraad is en of zij in staat is op tijd haar taak naar behoren te volbrengen. Indien het testteam aan ziet komen dat de taak niet volbracht zal worden moet dit gerapporteerd worden aan de projectleider en de opdrachtgever. Aan hen wordt dan de keuze gelaten de kwaliteitseisen te verlagen, het budget te verhogen, de te testen functionaliteit te verlagen of de einddatum te verschuiven. De planning en begroting blijft dan een hot item in een RADtraject.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
6.
Valkuilen bij RAD en testen
6.1
Inleiding
Pagina Versie Datum
16 van 23 1.0 23-04-2003
Er zijn meerdere valkuilen, of do’s en don’ts, te onderkennen bij RAD. Veel hiervan is in feite in de voorgaande hoofdstukken besproken, toch worden ze in dit hoofdstuk nog eens op een rijtje gezet. Ten behoeve van de toegankelijkheid is gekozen voor een vaste indeling per item: probleem, risico en oplossing.
6.2
Valkuilen
Probleem Er worden geen ontwikkeltools gebruikt. Risico Voor testen is het nadeel/risico hierbij beperkt. Het gebruik van conventionele programmeertechnieken is dat de voordelen van ontwikkeltools niet benut worden. Men moet hierbij denken aan snelheid en gestructureerdheid van het programmeer-proces. Nadeel voor het testen is dat er niet automatisch bepaalde documentatie wordt opgeleverd en dergelijke. Oplossing Probleem In het ontwikkelproces is geen tijd voor het toepassen van iteraties. Risico Één van de sterke kanten van RAD kan niet worden benut, het via meerdere iteraties toewerken naar de uiteindelijke vorm van de applicatie. Voor het testen brengt dit niet zoveel nadelen met zich mee, projectbreed moet men zich echter afvragen of op die manier het gewenste eindproduct kan ontstaan. Oplossing Probleem Het systeem wordt met onvoldoende documentatie opgeleverd. Risico 1. De tests kunnen niet worden gebaseerd op de specificaties, maar op de kennis van het tester. 2. Het systeem wordt niet geaccepteerd omdat het onvoldoende gedocumenteerd is (mits dit een acceptatiecriterium is). Oplossing 1. Risico’s en gevolgen duidelijk maken bij de projectleiding. 2. In procedures en standaards vast laten leggen dat het product bestaat uit programmatuur én documentatie. 3. Het product niet accepteren als de documentatie niet op peil is (kwaliteitscontrole voordat begonnen wordt met testspecificaties). 4. Documentatie-eisen stellen. Probleem Er is onvoldoende gebruikersparticipatie of er is een grote geografische afstand tussen gebruikers en bouw-organisatie. Risico Het systeem dat wordt gebouwd is (toch) niet datgene wat de gebruikersorganisatie wil. In het ergste geval wordt het systeem na bouw en test niet geaccepteerd. Daarnaast kan de gebruiker niet of moeilijker input leveren bij het testproces. Hierdoor kunnen de voordelen hiervan niet benut worden. Oplossing Het contact met de gebruikers intensiveren, afspraken maken over communicatie en tijden dat gebruikers geraadpleegd kunnen worden etc.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
17 van 23 1.0 23-04-2003
Probleem Gebruikers worden niet ingezet bij het testen. Risico De voordelen die gebruikersparticipatie bij het testen met zich mee kan brengen worden niet benut. De gebruiker heeft vaak een beter inzicht in gebruikersvriendelijkheid en dergelijke van het systeem. Oplossing Voorstellen de gebruikers actief te betrekken bij het testen en ze verantwoordelijkheid te geven bij het testen. Probleem Gebruikers hebben geen mandaat. Risico Het systeem wordt gebouwd en getest overeenkomstig de wensen van de aanwezige gebruikers, maar na oplevering blijkt dat het systeem toch anders had moeten worden gebouwd. Veel werk is datnvoor niets gedaan. Oplossing Dit risico speelt zich vooral af bij de opdrachtgever, deze zal met een systeem komen te zitten dat niet aan zijn wensen voldoet en hij draait op voor de kosten van herstel. Het kan raadzaam zijn de opdrachtgever hier op te wijzen. Een andere mogelijkheid is, als de opdrachtgever de gebruikers niet wil mandateren, om de gemaakte keuzes regelmatig terug te koppelen met een persoon die wel gemandateerd is, waardoor dan toch weer in een vroegtijdig stadium bijgestuurd kan worden. Probleem Er vind geen formele acceptatie van tussen- en eindproducten plaats. Risico Als het product gebouwd en getest is stelt de gebruiker dat het uiteindelijke product niet is wat hij wilde, waardoor het product niet geaccepteerd hoeft te worden door de opdrachtgever. Oplossing In de opleverprocedure formeel opnemen dat de gebruiker verklaard dat het product gebouwd is overeenkomstig zijn wensen en eisen. Er moet op worden toegezien dat dit ook gebeurd. Dit kan heel goed worden verwerkt in de intake die voor de test wordt uitgevoerd. Probleem Ontwikkelteams werken langs elkaar heen. Risico De verschillende pilots werken op zichzelf goed, geïntegreerd werkt het systeem niet voldoende. Oplossing Dit risico zo vroeg mogelijk signaleren bij het projectmanagement, aandacht aan dit probleem schenken in diverse rapportages. Probleem Bouwteams houden zich niet aan de timebox. Risico Er wordt teveel gebouwd in de timebox en de tijd om te testen wordt vaak korter (kreukelzone). Oplossing Probleem signaleren bij projectmanagement en voorleggen aan het projectmanagement wat niet of minder getest moet worden, dan wel dat de opleverdatum wordt verschoven. Probleem Bouwteams beginnen niet met belangrijkste onderdelen. Risico Aan het eind van de timebox komen de bouwteams in tijdsnood, waardoor de kwaliteit van product en documentatie in gevaar komt. Oplossing Bouwteams op wijzen, projectmanagement inlichten en vooral bij intake producten beoordelen op hun kwaliteit.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
18 van 23 1.0 23-04-2003
Probleem Bouwteams houden zich niet aan 80/20. Risico Er vindt nog steeds over-enginering plaats. Daarnaast kunnen de bouwteams (met betrekking tot andere onderdelen) in tijdsnood komen. Oplossing Signaleren richting bouwteams en projectmanagement, aandacht aan besteden in rapportages. Probleem Testen moet ook in een timebox plaatsvinden. Risico Indien de kwaliteit van de producten goed is en er zitten niet teveel fouten in, kan dit gedaan worden. Indien er echter veel fouten in een applicatie zitten kan het voorkomen dat de tester de timebox niet haalt en onvoldoende dekkingsgraad haalt zonder dat hij er wat aan kan doen. Er kan een onvoldoende oordeel worden gegeven over kwaliteit en risico’s van het onderdeel. Bedacht moet worden dat timeboxen ervan uit gaan dat niet de kwaliteit sluitpost is van de timebox, maar de functionaliteit. De tester heeft deze flexibiliteit niet, hij kan niet de functionaliteit als sluitpost gebruiken. In de praktijk kan hij slechts dekkingsgraad en mate van afronding van het testproces als sluitpost gebruiken. Oplossing Risico in beeld brengen, eisen stellen waaraan de test moet voldoen voordat de timebox afgesloten wordt en aan het eind van de timebox in beeld brengen wat niet of onvoldoende getest is. Probleem De gebruiker is van mening dat 80% van de functionaliteit onvoldoende is om het systeem acceptabel te maken. Risico De bouw stopt bij 80% en gaat de volgende iteratie in of pakt een ander onderdeel op. De gebruiker accepteert het onderdeel echter niet. Oplossing Allereerst moet de gebruiker bekend worden gemaakt met het 80/20 principe. Indien de gebruiker bij zijn standpunt blijft moet hij in beeld brengen wat nog aan het product aangevuld moet worden. Hier moet een kostenplaatje aan gehangen worden en indien de opdrachtgever dit wenst moet dit dan alsnog worden uitgevoerd. Overigens moet natuurlijk ook in beeld worden gebracht wat de effecten zullen zijn op de opleverdatum, kosten en dergelijke. Indien dit vaak voorkomt moet het 80/20 principe bij deze opdrachtgever heroverwogen worden. Probleem Er is geen globaal ontwerp van het systeem. Risico De basis om een bouw- en testtraject in te richten ontbreekt. Oplossing De fase informatieplanning en joint requirement planning moeten naar behoren zijn afgerond voor gestart kan worden met de bouwfase en de testfase. Probleem De bouwfase loopt tot de invoeringsfase. Risico Er is geen tijd voor een acceptatietest of een formele acceptatie. Er kan geen oordeel worden gevormd over de kwaliteit en risico’s van implementatie. Oplossing Risico in beeld brengen bij de opdrachtgever. Probleem De bouwers voeren geen (goede) bouwtest uit. Risico De systeemtest kost veel meer tijd, doordat de gebouwde producten van onvoldoende kwaliteit zijn. Oplossing Indien dit tijdens de intake al blijkt moeten de producten niet geaccepteerd worden door de testers. Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
19 van 23 1.0 23-04-2003
In de verschillende rapportages moet hier aandacht aan besteed worden en geprobeerd moet worden te komen tot afspraken wie wat test binnen het project. Eigenlijk moet het master-testplan hier uitsluitsel over geven. Probleem De testers hebben geen informatie op basis waarvan ze de test kunnen specificeren terwijl de het systeem gebouwd wordt. Risico De tests moeten gespecificeerd worden nadat de bouw klaar is, waardoor de doorlooptijd verlengd wordt. Oplossing 1. De tester krijgt de beschikking over JAD-verslagen. 2. De tester neemt zitting in het bouwteam. 3. De documentatie wordt eerst (in grote lijnen) uitgewerkt en overgedragen, dan wordt pas begonnen met bouwen. Probleem Er worden geen testtechnieken gebruikt Risico Tests worden niet op een gestructureerde wijze gespecificeerd, de kwaliteit van het testproces is niet gewaarborgd. Oplossing Toepassen testtechnieken. Met behulp van sjablonen en templates afdwingen dat testers technieken toepassen. Kwaliteitsmanagement met betrekking tot testen inrichten (opstellen standaards en normen). Probleem De testgevallen worden onvoldoende gedocumenteerd / geconserveerd. Risico 1. De test is moeilijk of niet reproduceerbaar en niet overdraagbaar. 2. Bij volgende releases moet het specificeren nogmaals worden gedaan. 3. Kennis gaat verloren. Oplossing 1. Risico’s en gevolgen duidelijk maken aan de projectleiding. 2. Capaciteit claimen om de tests te documenteren. 3. Trade-off test documenteren versus meer testen verhelderen. Probleem De testers zit in de bouwteams zonder een coördinerende functionaris erboven. Risico De testers werken allen op een andere manier, de tests worden onvoldoende gedocumenteerd, de testers houden zich bezig met andere dingen dan testen, de kwaliteit van het testen wordt niet bewaakt. Oplossing Het aanstellen van een testcoördinator en het opstellen van normen, standaards, sjablonen en templates, kortom, het inrichten van kwaliteitsborging met betrekking tot testen. Probleem Het product wijzigt als gevolg van iteraties vaak. Risico De gemaakte testscripts moeten aangepast worden of er moeten nieuwe testscripts worden gemaakt. Dit kost tijd en geld. Oplossing Wachten met het specificeren van tests tot het product (vrijwel) uit geïtereerd is. Nadeel hiervan is dat laat wordt begonnen met de specificatie. Alle opgebouwde kennis kan later, zij het vaak gedeeltelijk, worden gebruikt als de definitieve specificatie begint. (Bedenk hierbij dat kennis van het testobject ven essentieel belang is voor het specificeren van testgevallen, deze kennis wordt wel opgedaan als testgevallen worden gebaseerd op vroege iteraties.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
20 van 23 1.0 23-04-2003
Probleem Er is geen goede intake-checklist. Risico De intake is kwalitatief onvoldoende, waardoor het risico bestaat dat kwalitatief onvoldoende producten aan tests onderworpen worden. Oplossing Het opstellen van een goede intake-checklist en het inrichten van een goede intake-procedure. Probleem Er is geen goede opleverprocedure. Risico Het is niet goed duidelijk wat de tester moet testen, waar alle producten staat, welke versie hij moet testen en de testomgeving wordt niet goed beheerst. Oplossing Het opstellen van een opleverprocedure Probleem Er is geen versiebeheer ingericht. Risico Het is niet duidelijk in welke versie een probleem zich voordeed, herstelde problemen duiken later weer op, de tester weet niet welke versie hij test c.q. moet testen, men weet niet meer waar welk product uit bestaat. Oplossing Het inrichten van een goed versiebeheer. Probleem Er wordt geen testtool ingezet. Risico Bij veel iteraties blijft het testwerk handwerk, de (potentiële) tijdsbesparing wordt niet gerealiseerd. Daarnaast worden testgevallen bij toepassing van sommige testtools automatisch goed gedocumenteerd en bepaalde processen beter beheerst. Deze voordelen worden niet gerealiseerd. Oplossing Afweging van voor- en nadelen van de inzet van testtools maken en wellicht testtools inzetten. Probleem Er is geen bevindingenprocedure. Risico Er is onduidelijkheid wie wat moet doen als er bevindingen zijn. Taken, verantwoordelijkheden en bevoegdheden zijn niet vastgelegd. Oplossing Het inrichten van een bevindingenprocedure, wellicht in combinatie met de inzet van een testtool. Probleem De tester laat zich meeslepen in de hectiek van een RAD-traject Risico Deze hectiek kan goed zijn om de swing er aan de bouwkant in te houden, maar de test moet van een goede kwaliteit zijn en blijven. Het totale proces mag namelijk niet een systeem opleveren dat niet voldoet aan de gestelde kwaliteitseisen en acceptatiecriteria. Oplossing De testers uit deze hectiek halen, het kwaliteitsproces rond het testen goed inrichten en beheersen (opstellen normen, standaards, sjablonen en templetes, toezien op toepassing testtechnieken etc). Probleem Er zijn geen kwaliteitseisen en acceptatiecriteria opgesteld. Risico De tester weet niet hoe hij zijn test in moet richten, waar hij op moet testen. Formeel gezien moet de opdrachtgever het systeem altijd accepteren als hij geen acceptatiecriteria heeft opgesteld. Oplossing Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
21 van 23 1.0 23-04-2003
Risico’s in beeld brengen en er bij het projectmanagement en de opdrachtgever op aandringen dat deze worden opgesteld. In de verschillende rapportages aandacht aan besteden. Probleem Acceptatiecriteria en kwaliteitseisen wijzigen Risico Tests moeten opnieuw worden opgezet en uitgewerkt, de gekozen teststrategie moet worden gewijzigd. Oplossing Nadelen en kosten van de wijziging in beeld brengen. Wordt dan toch besloten de acceptatiecriteria en kwaliteitseisen te wijzigen dan moet in beeld worden gebracht welke werkzaamheden niet of later uitgevoerd zullen gaan worden. Probleem Er is geen mastertestplan geschreven Risico Er is geen goed afbakening van wie wat test, waar de verschillende partijen zich op richten en lacunes en doublures kunnen ontstaan. Oplossing Het schrijven van een master-testplan. Omdat het constateren dat dit moet gebeuren meestal niet tot gevolg heeft dat dit ook meteen gebeurd is het van belang de risico’s goed in beeld te brengen, evenals de voordelen van een master-testplan. Indien er dan nog niet wordt besloten tot het schrijven van een master-testplan moet in het plan van aanpak of een andere rapportage worden aangegeven waar de het betreffende testteam zich op richt. Probleem Er wordt gestart met testen voordat een plan van aanpak is geschreven. Risico Er is onduidelijkheid over wat getest wordt, waarmee getest wordt, waar de test zich op richt, wanneer verwacht wordt dat de test afgerond is, wat het effect van het testen op het totale traject is, wat de risico’s zijn, et cetera. Oplossing Het schrijven van een plan van aanpak. Probleem Er is geen teststrategie op basis waarvan de tests worden uitgevoerd. Risico Er is onduidelijk welke onderdelen met welke diepgang en welke technieken worden getest. Er is geen testbegroting. De individuele tester weet niet welke onderdelen hij met welke technieken en met welke diepgang hij moet testen. Het risico bestaat dat er te weinig wordt gedaan, waardoor het testproces niet op tijd kan worden afgerond. Oplossing Opstellen van een teststrategie.
Almere © 2003
Quality Assurance in ICT
Organisatie Titel Onderwerp
SYSQA RAD en testen
Pagina Versie Datum
22 van 23 1.0 23-04-2003
7. Verklarende woordenlijst.
Almere © 2003
Quality Assurance in ICT
