Requirements en testen. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V

Requirements en testen Een introductie

Algemene informatie voor medewerkers van: SYSQA B.V.

Organisatie Titel Onderwerp

SYSQA B.V. Requirements en testen Een introductie

Pagina Versie Datum

2 van 10 1.1 16-03-2011

Inhoudsopgave 1

INLEIDING .................................................................................................................. 3 1.1 1.2

2

REQUIREMENTS EN TESTEN ................................................................................... 4 2.1 2.2 2.3 2.4 2.5 2.6

3

ALGEMEEN ................................................................................................................... 3 VERSIEBEHEER ............................................................................................................. 3 INLEIDING ..................................................................................................................... 4 EEN PRAKTIJKVOORBEELD .............................................................................................. 4 REQUIREMENTSPROCESSEN IN RELATIE TOT TESTEN ......................................................... 5 HET TESTPROCES .......................................................................................................... 5 DE RELATIE TUSSEN HET REQUIREMENTS- EN TESTPROCES IN HET SYSTEEMONTWIKKELTRAJECT......................................................................................... 7 TIPS VOOR GEBRUIK IN DE PRAKTIJK: HET BELANG VAN REQUIREMENTS VOOR HET TESTPROCES ................................................................................................................ 8 LITERATUUROPGAVEN .......................................................................................... 10

Almere © 2011

Proud of it


1 1.1


Pagina Versie Datum

3 van 10 1.1 16-03-2011

Inleiding Algemeen

In dit document is beschreven welke rol requirements en requirementsprocessen spelen in relatie tot testen. Tevens bevat dit document verwijzing naar hulpmiddelen en sjablonen en een verwijzing naar literatuur voor verdere verdieping in dit onderwerp. De informatie vanuit Requirements, een introductie, een ander document vanuit de kennisbank van SYSQA wordt als bekend verondersteld. Het document staat ter beschikking van elke Sysqa-professional die rechtstreeks met deze materie van doen krijgt, of zich hierin wil verdiepen. In het gehele document wordt de term requirements in plaats van eisen gebruikt, omdat:  voor „requirements engineering‟ als overkoepelende term geen Nederlands equivalent beschikbaar is (mocht een Nederlandse term nodig zijn, dan kan eisenbeheer & -ontwikkeling worden gebruikt);  veel bedrijven deze term hanteren;  het aantal hits op internet (alleen Nederlandse sites) overwegend het gebruik van de term „requirements‟ voor eisen in ICT-trajecten weergeeft

1.2

Versiebeheer

Versie 0.9

Status Concept

1.0 1.1

Definitief Definitief

Datum 06-08-2008

15-09-2008 16-03-2011

Almere © 2011

Auteur Sysqa

Sysqa Sysqa

Opmerkingen Op basis van requirementsdocument expertisegroep requirements, omgezet naar SYSQA-sjabloon en aanpassingen. Opmerkingen verwerkt, definitief gemaakt. Aanpassen opmaak.

van

de

tekstuele

Proud of it



Pagina Versie Datum

4 van 10 1.1 16-03-2011

2 Requirements en testen 2.1

Inleiding

Requirements en testen zijn onderwerpen die onlosmakelijk met elkaar verbonden zijn. In de praktijk komen vaak tijdens de testfase, of erger nog, in productie, bevindingen naar voren die voorkomen kunnen worden door een betere afstemming tussen de requirements-; ontwikkelen testprocessen. “Onderzoek toont aan dat van de oorspronkelijk gedefinieerde requirements slechts 42% tot 67% daadwerkelijk door het project wordt gerealiseerd (the Standish Group, 2003)” Uit: Tmap Next (6). De requirementsbaseline is de formele vastlegging van de overeengekomen klanteneisen voor het op te leveren informatiesysteem en de wijzigingsprocedure op de requirements. Deze formele vastlegging is de basis voor het verder analyseren, definiëren, ontwerpen, bouwen, testen, accepteren en beheren van het systeem. Dit stuk gaat in op de problematiek van de vele vertaalslagen die liggen tussen de klanteneisen en een resulterend informatiesysteem en hoe de testdiscipline hier op af te stemmen. Met testen wordt hier zowel de verificatie (is gebouwd conform specificaties) als de validatie (is gebouwd wat gevraagd is) bedoeld.

2.2

Een praktijkvoorbeeld

Het volgende voorbeeld illustreert het belang van het testproces in relatie tot requirements. Klanteneis: Het management van een huizensite besluit dat geregistreerde bezoekers voortaan via een speciale optie het interieur van aangeboden objecten virtueel kunnen bezoeken. Enkele hieruit voorkomende Requirements:  Business: geregistreerde bezoekers moeten via een speciale optie het interieur van aangeboden objecten virtueel kunnen bezoeken.  User: De per email aangeleverde virtuele films moeten met maximaal 3 handelingen aan een object kunnen worden gekoppeld.  Systeem: De maximale belasting is 100 gelijktijdige bezoekers, tot aan deze belasting moet een bezoeker met een 2 MB verbinding ongestoord rond kunnen surfen met maximale wachttijden van 5 seconden Bij het testen komen enkele belangrijke bevindingen naar voren:  Het user-requirement is niet haalbaar, er zijn 5 handelingen per object nodig.  Het systeem-requirement van 100 gelijktijdige bezoekers blijkt onverwacht ontzettend kostbaar te zijn, tot een belasting van 50 gelijktijdige bezoekers wordt voldaan aan de 5 seconden-eis maar daarboven neemt de wachttijd dramatisch toe. Na analyse: Het blijkt dat 5 handelingen geen enkel probleem is, 4 van de 5 zijn een simpele muisklik en in totaal duurt het koppelen van een object maximaal 3 minuten, ver onder de verwachting van 15 minuten per keer. De dramatische terugval is te wijten aan een instelling op de database-server van de provider. In productie: De eerste dagen loopt het systeem als voorheen, er komen complimenten binnen van potentiële kopers en al snel neemt het bezoek toe. Na 2 weken beginnen de problemen en na 3 weken is de site vrijwel dagelijks onbereikbaar.

Almere © 2011

Proud of it



Pagina Versie Datum

5 van 10 1.1 16-03-2011

Na analyse: Het blijkt dat het aantal geregistreerde bezoekers ver boven verwachting is. Dagelijks zijn gemiddeld ongeveer 5000 bezoeken aan virtuele interieurs met piekbelastingen van 500 gelijktijdige. Nader onderzoek wijst uit dat alle bezoekers geregistreerd worden (al dan niet na het invullen van persoonlijke gegevens), de oorspronkelijke bedoeling van het management was geautoriseerd. Vanwege de concurrentiegevoeligheid was over het aantal echte (geregistreerde in de taal van het realisatieteam) bezoekers geen informatie beschikbaar gesteld, in de veronderstelling dat bezoekers die gebruik wilden maken van de virtueel-optie zich zouden aanmelden en dat hierover dus een flinke controle was. Uit dit fictieve voorbeeld blijkt dat bij een relatief eenvoudige klanteneis flinke verstoringen van het bedrijfsproces kunnen veroorzaken als er fouten in de vertaalslagen worden gemaakt of requirements onvoldoende specifiek zijn. Het probleem in dit geval is dat het businessrequirement onvoldoende onderzocht en gevalideerd is.

2.3

Requirementsprocessen in relatie tot testen

De set requirements vastgelegd in de requirementsbaseline is idealiter juist en volledig opgesteld bij de start 1 van het project en de individuele requirements zijn hierbij SMART , geprioriteerd op basis van de risicoanalyse, testbaar, voorzien van toelichtingen en consistent met andere requirements. Middels requirements management worden wijzigingsvoorstellen gecontroleerd afgehandeld. In de praktijk zal men echter vaak een set requirements hanteren die op veel punten niet aan deze eisen voldoet. Een pragmatisch uitgangspunt bij de voorbereidingen voor het testproces is dan ook een zo vroeg mogelijke betrokkenheid bij de totstandkoming van (wijzigingen op) de requirements in de vorm van bijvoorbeeld reviews, validaties, use-case- en teststrategie-overleggen etc.

2.4

Het testproces

De rode draad door het testproces is de set overeengekomen requirements tussen opdrachtnemer en opdrachtgever op basis waarvan het informatiesysteem wordt gerealiseerd. De requirements worden in het ontwikkelproces uitgewerkt in ontwerp-, bouw-, gebruiks- en beheerdocumenten en vormen als geheel de testbasis. Het testproces is erop ingericht de bij de requirements behorende productrisico‟s af te dekken. Bij de ontwikkelen systeemtesten worden als basis voor het testen met name de technische en functionele ontwerpen gebruikt, welke zijn afgeleid uit de requirements. Hierbij ligt de nadruk op verificatie van het ontwikkelde systeem ten opzichte van de ontwerpspecificaties. Vervolgens worden bij de acceptatietesten de (dan actuele!) requirements als basis gebruikt. Hierbij ligt de nadruk op het valideren van het gebouwde systeem tegen de overeengekomen klanteneisen. Het eindproduct van het testproces is een advies dat aangeeft in hoeverre de geïdentificeerde risico‟s zijn afgedekt. De relatie naar requirements vanuit de risico-analyse en de ontwerpspecificaties moet zijn geborgd zodat inzichtelijk is in hoeverre de requirements zijn gerealiseerd. 5.4.1 Testbaarheid De formulering van de requirements dient zo te zijn dat onder gegeven omstandigheden (S van specifiek) een eenduidig, voorspelbaar en meetbaar (M) resultaat kan worden afgeleid. Het toevoegen van acceptatiecriteria, voorzien van meetvoorschriften, verhoogt de testbaarheid en versnelt het acceptatieproces door de gebruikers- en beheerorganisatie. Tijdens de voorbereiding en specificatie van de testen wordt getoetst of hieraan wordt voldaan. Vanuit de testdiscipline wordt hiervoor een formele intake op de requirements gedefinieerd. Hiermee wordt de testbaarheid beter geborgd.

1

Specifiek, Meetbaar, Acceptabel, Realistisch, Tijdgebonden

Almere © 2011

Proud of it



Pagina Versie Datum

6 van 10 1.1 16-03-2011

Een goede testbaarheid geeft ook veel meer inzicht in de benodigde testtijd. Zo kan in een vroegtijdig stadium een realistischer testplanning worden afgegeven. Door de definitie en uitwerking van testgevallen worden requirements inzichtelijker en wellicht geherformuleerd zodat ze beter aansluiten op de werkelijke klanteneisen. In de praktijk is het testproces vaak laat gepland zodat geen ruimte en budget meer is om de requirements aan te passen. Er kunnen overigens altijd requirements zijn die niet testbaar zijn, bijvoorbeeld omdat het een business requirement is gebaseerd op een marktonderzoek. Voor zover mogelijk worden met nadere detaillering en uitwerking wel testbare requirements geformuleerd. 5.4.2 Teststrategie De requirements spelen een belangrijke rol bij het bepalen van de overall teststrategie, vastgelegd in het mastertestplan. Hierin wordt bepaald welke testsoorten en testvormen worden onderkend en in welke volgorde deze worden uitgevoerd. Voor het vaststellen van de teststrategie is de productrisicoanalyse in combinatie met de requirements het uitgangspunt. Testen is het afdekken van de productrisico‟s. Deze risico‟s worden geanalyseerd op basis van de gestelde requirements en de gekozen oplossingsrichting. Veelal wordt de teststrategie gedurende de specificatiefase uitgevoerd. Het risico van het parallel uitvoeren van teststrategie en -specificatie is dat tijdens de teststrategie ontdekte fouten in de requirements niet worden meegenomen in de specificaties. Dit verhoogt de herstelkosten. De gekozen ontwikkelmethodiek is ook van groot belang bij het opstellen van de teststrategie. Bij een iteratief ontwikkelproces is een goede afstemming tussen ontwikkelen testteam nodig. Dit leidt tot betere keuzes over inhoud, volgorde van de diverse te ontwikkelen incrementen of onderdelen van het systeem. Ofwel welke requirements worden wanneer gerealiseerd. 5.4.3 Testdekking Voor de verschillende testen wordt vastgesteld welke requirements relevant zijn. Andersom wordt per requirement vastgesteld welke testen onderzoeken in hoeverre het informatiesysteem hieraan voldoet. De testdekking is de mate waarin het risico behorende bij bepaalde requirements wordt afgedekt. In een traceerbaarheidmatrix wordt hiervoor de relatie aangegeven tussen de requirements en de bijbehorende testen. Omdat dit een arbeidsintensief proces is het raadzaam hierbij een geautomatiseerd requirements/testtool in te zetten.

Almere © 2011

Proud of it


2.5


Pagina Versie Datum

7 van 10 1.1 16-03-2011

De relatie tussen het requirements- en testproces in het systeemontwikkeltraject

Als we de requirements- en testprocessen in de context van het ontwikkelproces bekijken dan kan de samenhang schematisch worden weergegeven:

Figuur 5.1: Requirements- en testproces in het systeemontwikkeltraject Let wel: er zijn verschillende manieren en modellen mogelijk waarin requirements- en testprocessen met elkaar in relatie worden gebracht. Bovenstaand is een mogelijke weergave afgebeeld en toegelicht. In de praktijk kan bij organisaties de rangschikking hiervan afwijken. Toelichting: 1. De oorsprong van de klanteneisen wordt gevormd door de voor het project relevante bedrijfsprocessen. Klanteneisen kunnen ook leiden tot veranderingen in de bedrijfsprocessen. Let op: het nieuwe systeem kan leiden tot nieuwe processen (bijvoorbeeld in geval van buitenaf opgelegde eisen als wetgeving). 2. Zodra de klanteneisen vorm gaan krijgen en besluitvorming plaatsvindt om een verandertraject in te gaan zal het requirements managementproces gestart worden. Vanuit RM wordt aandacht gegeven om de scope te bepalen. Later in het verandertraject zal deze relatie steeds formeler en strakker worden naarmate het project zijn opleverdatum nadert. De requirements- en testmanager zullen hierbij de projectmanager adviseren bij het stellen van prioriteiten. 3. Vanuit de klanteneisen wordt verder gefocust op het verzamelen, analyseren en ontwikkelen van de requirements. 4. Gedurende de requirements ontwikkeling zal het requirements management ook verder inhoud krijgen. Vanuit RM zal sturing aanwezig zijn om de scope (opnieuw) vast te stellen. 5. Requirements ontwikkeling leidt tot een vastgestelde versie van de requirementsbaseline, de basis voor verdere projectactiviteiten. 6. De requirementsbaseline is de brug tussen requirements ontwikkeling en requirements management. 7. De requirementsbaseline dient (o.a.) als basis voor ontwikkeling, met name het basisontwerp. 8. De requirementsbaseline dient (o.a.) als basis voor test, met name de teststrategie. 9. Gedurende ontwikkeling en test vindt voortdurende afstemming plaats in de vorm van toetsen, testen en overleggen (van verkennende gesprekken tot formele bevindingenoverleggen). 10. Het ontwikkelproces levert informatie aan requirements management in de vorm van wijzigingsvoorstellen door voortschrijdend inzicht, traceerbaarheidsgegevens en statusgegevens. Almere © 2011

Proud of it



Pagina Versie Datum

8 van 10 1.1 16-03-2011

11. Het testproces levert informatie aan requirements management in de vorm van bevindingen op de requirements, traceerbaarheidsgegevens en statusgegevens. 12. Het gerealiseerde en geteste informatiesysteem (software, hardware, data, procedures, documentatie, getraind personeel, etc.) wordt opgeleverd ter acceptatie. Bevindingen uit het acceptatieproces leiden eventueel tot extra ontwikkelinspanning zonder dat requirements management hier een rol in speelt – zie ook 15. 13. Het testadvies wordt opgeleverd ter ondersteuning van acceptatie. Bevindingen uit het acceptatieproces leiden eventueel tot extra testinspanning zonder dat requirements management hier een rol in speelt – zie ook 15. 14. De requirementsbaseline dient (o.a.) als referentiekader voor acceptatie, in de vorm van (voor zover mogelijk meetbare) acceptatiecriteria. 15. Het acceptatieproces leidt wellicht tot wijzigingsvoorstellen. Requirements management levert input en stuurt waar nodig het acceptatieproces. 16. Bij het acceptatieproces spelen de relevante bedrijfsprocessen een cruciale rol. Hier vindt de uiteindelijke validatie plaats in hoeverre het gerealiseerde informatiesysteem bij zal dragen aan de realisatie of verbetering van de bedrijfsprocessen. 17. Requirements management leidt tot terugkoppeling naar klanteneisen, requirements ontwikkeling (bij ingrijpende wijzigingen) en de requirementsbaseline (overzichtelijk, direct formeel vast te leggen wijzigingen). 18. Directe terugkoppeling uit requirements management op het ontwikkelproces zonder impact op de requirementsbaseline. 19. Directe terugkoppeling uit requirements management op het testproces zonder impact op de requirementsbaseline. 20. Het gerealiseerde informatiesysteem wordt na acceptatie in gebruik en beheer genomen. 21. Gebruik en beheer levert input aan requirements management bij incidenten en onderhoud. Directe terugkoppeling uit requirements management op het gebruik- en beheerproces zonder impact op de requirementsbaseline. 22. Gedurende de eerste fase van ingebruikname zal het gerealiseerde informatiesysteem steeds beter geïntegreerd raken in de relevante bedrijfsprocessen en op den duur zal deze lijn dan ook niet meer nodig zijn, het gerealiseerde systeem maakt dan deel uit van de relevante bedrijfsprocessen (stippellijn). 23. Bij de requirements ontwikkeling zullen de relevante bedrijfsprocessen altijd als belangrijk referentiekader dienen. 24. Bij het ontwikkelproces zullen de relevante bedrijfsprocessen altijd als belangrijk referentiekader dienen. 25. Bij het testproces zullen de relevante bedrijfsprocessen altijd als belangrijk referentiekader dienen.

2.6

Tips voor gebruik in de praktijk: het belang van requirements voor het testproces

Het testteam heeft direct belang bij een goede uitvoering van de requirementsprocessen. Blijf hierop (gedoseerd) hameren. Gebruik argumenten als testbaarheid, een beter beheersbaar acceptatieproces, minder misverstanden tussen de diverse disciplines, met name gebruikers, ontwikkelaars en testers, een duidelijker wijzigingsproces waar alle betrokkenen (uiteindelijk) profijt van hebben. De grootte en volwassenheid van de organisatie spelen een belangrijke rol: stel vanuit het testen zo goed mogelijk vast op welk niveau de requirementsprocessen worden uitgevoerd. Gebruik hierbij de beschikbare checklist „Requirements Engineering‟ vanuit de kennisbank. Houd interviews met belanghebbenden. Informeer bij collega‟s uit andere projecten. “Zachte” aspecten als politiek, verhoudingen tussen afdelingen of medewerkers spelen geregeld een grote rol. Gecombineerd met tijdsdruk, complexiteit, (onvoorziene) wijzigingen etc. kan de spanning en werkdruk aanzienlijk oplopen. Vaak wordt de “pijn” naar achteren in het traject geduwd met als resultaat een testtraject dat zwaar onder druk komt te staan. Heldere requirements, een goede risico- en impactanalyse, duidelijke wijzigingsvoorstellen e.d. zijn dan “een wapen” om het testtraject beter te beheersen. De essentie is dat uit het (eventueel geforceerd naar voren gehaalde) testadvies de risico‟s inzichtelijk worden gemaakt op basis van de testresultaten, de requirements, aanvullende acceptatiecriteria etc. Almere © 2011

Proud of it



Pagina Versie Datum

9 van 10 1.1 16-03-2011

Traceerbaarheid kan goed geregeld worden met tools. Bij traceerbaarheid gaat (zoals gewoonlijk) de kost voor de baat uit. Helaas zien veel partijen de baten van traceerbaarheid te laat in (op het moment van grote wijzigingen als impactanalyses nodig zijn). Het kan helpen als vanaf de aanvang van het testtraject inzichtelijk wordt gemaakt hoeveel tijdwinst geboekt kan worden als traceerbaarheidsgegevens beschikbaar zijn. Uiteraard verhogen de traceerbaarheidsgegevens ook het overzicht van en inzicht in de voortgang. Daar waar specifieke tools niet beschikbaar zijn: begin eenvoudig met word of excel (zie sjablonen). Alleen al met een excelsheet is inzichtelijk te maken dat er requirements zijn die niet beantwoord worden in concrete producten en andersom producten die geen relatie hebben met een (geprioriteerde en gevalideerde) eis. Daarnaast maken alle eerste inspanningen in Word of Excel duidelijk aantoonbaar dat het beheren van requirements zonder adequete tooling lastig en arbeidsintensief is. Daarmee wordt als het ware vanzelf een businesscase gegegeneerd voor aanschaf van tooling. De tool wordt dan ook ontvangen als hulpmiddel om een lastige klus te vergemakkelijken. Direct starten met een kostbaar en complex tool leidt daarentegen vaak tot de beleving dat het werk door het tool complexer wordt gemaakt; voordat het tool werd gehanteerd hoefde al die ingewikkelde rompslomp immers niet… Start vanuit het testproces „hoe dan ook‟ met reviews op requirements of andere goedgekeurde documenten die als requirement fungeren binnen het project. Daar waar testen pas later bij het project wordt betrokken is veelal de inhoud onvoldoende concreet om testen op te kunnen baseren. Bijkomend effect is dat uit de reviews blijkt dat de kwaliteit eigenlijk ook nog onvoldoende is om op te bouwen en veel ruimte geeft voor aannames. Tracht vanuit het reviewproces de bevindingen om te zetten als besparingen. Onderzoek toont aan dat ieder uur geïnvesteerd in reviewen gemiddeld vijf tot zeven uur minder herstelwerk oplevert. Met behulp van de wet van Boehm is binnen een specifiek project aantoonbaar te maken dat fouten vroegtijdig gevonden uiteindelijk de herstelkosten verlagen. Daarmee is zichtbaar dat reviewen het project geld én tijd oplevert in plaats van dat het tijd kost. Dit verhoogt de acceptatie van reviewen en verstevigt de positie, belang en besef van toegevoegde waarde van de testdiscipline binnen het project.

Almere © 2011

Proud of it


3


Pagina Versie Datum

10 van 10 1.1 16-03-2011

Literatuuropgaven 1. Wiegers Karl E., Software Requirements, Microsoft Press, 1999. 2. CMMI for Development CMMI-DEV, V1.2, Carnegie Mellon University, 2006 3. Barry W Boehm, Software Engineering Economics, Prentice-Hall, ISBN 0-13-822122-7, 1981 4. Cannegieter, Jan Jaap, Kwaliteitszorg in ICT projecten - de PROQA methode, Ten Hagen Stam, ISBN 90-440-0369-0, 2001 5. M. Arendsen, H.J.J. Cannegieter, A. Grund, P. Heck, S. de Klerk en J. Zandhuis, Succes met de requirements!, SDU, ISBN 9789012125987, 2008 6. Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon, Tmap Next, Tutein Nolthenius, ISBN 9789072194799, 2006 7. Requirements, een introductie, kennisbank SYSQA.

Almere © 2011

Proud of it

Requirements en testen. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V

Recommend Documents