VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER

Transcriptie

1 VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER Sander Hoogendoorn Versie april 2002

2 Documentbeheer Versie Datum Auteur Omschrijving April 2002 Sander Hoogendoorn april 2002 Sander Hoogendoorn Eerste opzet april 2002 Sander Hoogendoorn Tekst artikel bewerkt april 2002 Sander Hoogendoorn Versie april 2002 Pagina i

3 Inhoudsopgave Ordina SMART 3 4 Testscenario s en stappenplannen 5 Het identificeren van scenario s 6 Attributen en testgevallen 7 Integratie en applicatiearchitectuur 8 Van requirements naar testgevallen 9 Publicatie 10 Versie april 2002 Pagina ii

4 Ordina SMART Ordina SMART is een complete aanpak voor de snelle ontwikkeling van moderne applicaties. SMART stelt organisaties in staat projecten uit te voeren aan de hand van een pragmatisch en flexibel proces. Dit betekent dat SMART snel en gemakkelijk inzetbaar is en aansluit op de bestaande en toekomstige systeemontwikkelomgevingen. De uitvoering van dit proces wordt ondersteund door een breed scala van moderne technieken. Ordina SMART maakt gebruik van de modelleertechnieken van de Unified Modelling Language, de facto standaard voor het ontwerpen van applicaties. Bovendien zijn SMART applicaties gebaseerd op een schaalbare service georiënteerde architectuur. SMART voorziet binnen vier pijlers - proces, modellering, architectuur en tools -, een breed scala aan services op het gebied van projectmanagement, standaards en richtlijnen, trainingen en audits. Deze bijzondere bundeling van kennis en expertise maakt Ordina SMART een professioneel kader voor de ondersteuning en uitvoering van systeemontwikkeling. Versie april 2002 Pagina 3

5 Het goed beschrijven van testspecificaties is lastig. Enerzijds wordt dit veroorzaakt doordat de functionele specificaties gedurende systeemontwikkelprojecten voortdurend wijzigen, anderzijds doordat er geen standaard notatiewijze wordt gebruikt voor het vastleggen van deze functionele specificaties. Het gebruik van de modelleertaal UML als basis voor het beschrijven van testspecificaties kan echter uitkomst bieden. De modelleertaal Unified Modeling Language (UML) is de laatste jaren uitgegroeid tot de defactostandaard voor analyse en ontwerp van applicaties. De verschillende modelleertechnieken van UML kunnen echter ook gebruikt worden als uitgangspunt voor het testen van functionaliteit. Vanuit deze optiek is het use case diagram de belangrijkste modelleertechniek van UML. Hierin worden de requirements voor de applicatie vastgelegd. Een bedrijfsproces of het werkproces van de gebruiker ( actor in UML) is uitgangspunt voor de modellering. Use cases worden vaak opgesteld tijdens workshops waarin de vraag gesteld wordt wat de gebruiker gaat doen als hij zijn werk begint. Een use case diagram bevat derhalve deze actoren, gerepresenteerd als draadpoppetjes. Daarnaast kent het uiteraard use cases. Een use case wordt weergegeven als ovaaltje (zie afbeelding 1) en beschrijft een deel van de functionaliteit; uitgevoerd door de actor of aangeroepen door andere use cases. De relaties tussen actoren en use cases en tussen use cases onderling worden weergegeven als pijlen. afbeelding 1: use case diagram voor het doen van een overboeking Het use case diagram is een nuttige modelleertechniek. Het is door zijn eenvoud een uitstekend communicatiemiddel met gebruikers en de projectomgeving. Use-casediagrammen worden derhalve opgesteld tijdens workshops waarin gebruikers deelnemen. De use case fungeert ook als uitgangspunt voor het verdere ontwerp van de applicatie en blijkt een uitstekende eenheid voor het inrichten en plannen van de iteraties van projecten. Iedere iteratie implementeert een collectie use cases, gerelateerd aan een te bereiken projectdoelstelling. Use cases zijn bovendien een goede eenheid voor het schatten van de omvang en complexiteit van het project. Versie april 2002 Pagina 4

6 Ook de relatie met testen is gauw gelegd. Use cases gelden als uitgangspunt voor de beschrijving van testscenario s en testgevallen. Op deze wijze kan worden aangetoond dat er daadwerkelijk gebouwd is wat er gebouwd moest worden. Zo is de cirkel rond en bestaat er een directe relatie tussen dat wat ontworpen is, dat wat gebouwd is en dat wat getest wordt. Testscenario s en stappenplannen Functioneel testen geschiedt op basis van testscenario s. Testscenario s beschrijven de testacties (of handelingen) die worden uitgevoerd en de uitkomsten die deze testacties opleveren. Testscenario s maken zo de functionaliteit verifieerbaar. Een testactie bestaat meestal uit het invoeren van velden op een scherm of webpagina, of een klik op een link of knop. Voor ieder veld kunnen uiteraard verschillende waarden worden ingevuld. Bij ieder testscenario bestaan daarom verschillende testgevallen die weliswaar hetzelfde scenario doorlopen, maar waarbij de waarden van de ingevoerde velden verschillen. Hoe sluit het ontwikkelen van testscenario s en testgevallen aan op de use cases en waaraan moeten use cases voldoen om er testscenario s en testgevallen op te baseren? De systeemontwikkelmethode Ordina SMART geeft hierop een antwoord. Iedere use case wordt begeleidt door een stappenplan (zie afbeelding 2). Dit stappenplan beschrijft de opeenvolgende handelingen die door de actor of het systeem worden uitgevoerd. Het stappenplan vormt de basis voor verdere modellering in activiteitsdiagrammen, interactiediagrammen en klassediagrammen en beschrijft hoe de uitkomst wordt bereikt. Deze wordt beschreven in de postcondities van de use case. Het scenario waarmee het gewenste resultaat wordt bereikt wordt het gewenste scenario genoemd. Er zijn echter meer scenario s mogelijk. Use case Identificeren Klant 1. Toon pagina Identificeren Klant 2. Actor voert Autorisatie in (Klantnummer en PIN). 3. Actor bevestigt 4. Systeem verifieert Autorisatie Klant 4a. Als Autorisatie Klant niet is geverifieerd, stop dan 5. Haal Klant op 5a. Als Klant niet wordt gevonden, stop dan 6. Bewaar Klant in Sessie. afbeelding 2: stappenplan bij de use case Identificeren Klant Nagenoeg ieder stappenplan kent beslismomenten waarbij van het gewenste scenario wordt afgeweken. Nu wordt de beoogde uitkomst niet gerealiseerd. Dergelijke scenario s heten faalscenario s. Ook kan vaak vanuit een faalscenario via een omweg alsnog de beoogde uitkomst worden bereikt. Zo n scenario is een herstelscenario. Versie april 2002 Pagina 5

7 Het identificeren van scenario s Het testen van een use case begint derhalve met het identificeren van de verschillende scenario s. Immers, bij ieder scenario hoort een bijpassend testscenario. Een uitstekend hulpmiddel bij het identificeren van de scenario s is het activity diagram van UML. afbeelding 3: activity diagam bij de use case Identificeren Klant Het activity diagram bestaat uit activiteiten, weergegeven als afgeronde rechthoeken, beslismomenten, gerepresenteerd als diamanten, een startstaat (dichte bol) en mogelijk verschillende eindstaten (bol met cirkel), maar minimaal één (zie afbeelding 3). Het wordt opgesteld aan de hand van het stappenplan, waarbij de individuele stappen worden vertaald naar activiteiten en beslismomenten in het diagram. Met behulp van enkele eenvoudige technieken kunnen uit het activity diagram de diverse scenario s worden geïdentificeerd. Hierbij geldt dat iedere mogelijke manier van het doorlopen van het diagram van startstaat naar een van de eindstaten een scenario representeert. Een deelpad is een verzameling activiteiten die tussen twee beslismomenten plaatsvindt, ofwel tussen het startstaat en een beslismoment, ofwel tussen een beslismoment en een van de eindstaten. De deelpaden worden genummerd en voorzien van een korte omschrijving. In het voorbeeld in afbeelding 3 zijn er nu drie scenario s te onderkennen. Het faalscenario Geen autorisatie dat bestaat uit de deelpaden 1 en 2, een tweede faalscenario Klant niet gevonden met deelpaden 1, 3 en 4 en het gewenste scenario Klant geïdentificeerd met deelpaden 1,3 en 5. Versie april 2002 Pagina 6

8 Bij ieder van deze drie scenario s wordt een testscenario gedefinieerd. De relatie is één op één. De individuele handelingen die door de actor of het systeem worden uitgevoerd, en met de deelpaden zijn geassocieerd, worden vervolgens geïdentificeerd. Deze handelingen worden testacties genoemd en zijn bepalend voor het correct doorlopen van het scenario. Het gewenste scenario leidt tot het testscenario in afbeelding Toon pagain Identicieren Klant Klant voert Autorisatie in Klant bevestigt 2. Klant wordt opgehaald 3. Klant wordt opgeslagen in Sessie afbeelding 4: testscenario Attributen en testgevallen Als volgende stap worden attributen gedefinieerd bij iedere testactie. Deze attributen zijn invoer of zijn het resultaat van een testactie. Het invoeren van de autorisatie (zie afbeelding 4) bestaat uit het invoeren van een klantnummer en een pin. Ook het opslaan van de geautoriseerde klant bij de sessie kent attributen, zoals klantnummer, naam en woonplaats. In het eerste geval moeten de attributen worden ingevoerd tijdens de test; in het laatste geval wordt het behalen van de gewenste uitkomst geverifieerd aan de hand van de attributen. Met het testscenario wordt een van de postcondities van de use case waargemaakt, namelijk dat de klant is geïdentificeerd en opgeslagen in de sessie. Dit wordt overigens geverifieerd door de aanroepende use case Doen Overboeking (zie afbeelding 1). Ieder testscenario wordt nu uitgebreid met de benodigde attributen (zie afbeelding 5). 1. Toon pagina Identicieren Klant Klant voert Autorisatie in (klantnummer en PIN) Klant bevestigt 2. Klant wordt opgehaald 3. Klant wordt opgeslagen in Sessie (klantnummer, naam, woonplaats) afbeelding 5: testscenario met attributen Tenslotte wordt bij ieder testscenario één of meerdere testgevallen gespecificeerd. Een testgeval bestaat uit de opeenvolgende testacties in een testscenario waarbij waarden ingevuld worden voor de bijbehorende attributen. Ervaren testers herkennen al snel de belangrijke waarden voor een attribuut. Denk bijvoorbeeld aan standaard en minimum- en maximumwaarden. Belangrijk is om grenswaarden bij beslismomenten in de testgevallen mee te nemen. Uiteraard verschillen de gebruikte waarden voor attributen per testscenario. In het voorbeeld zal in het testscenario Klant geïdentificeerd een geldig klantnummer en PIN moeten worden ingevoerd. In het testscenario Geen autorisatie is het echter van belang een niet bestaande combinatie van klantnummer en PIN in te voeren. Ieder testgeval wordt uitgeschreven in een tabel, waarbij de testacties op de horizontale as en de attributen bij het testscenario op de verticale as staan (zie afbeelding 6). In de tabel worden de waarden voor de attributen ingevuld. Daarbij wordt opgenomen of het invoer- of Versie april 2002 Pagina 7

9 uitvoerattributen betreft. De ingevulde tabellen worden vervolgens gebruikt om de functionaliteit van de use case te testen. Use case Identificeren Klant Scenario Klant geïdentificeerd Klantnummer PIN Naam Woonplaats Toon pagina Identicieren Klant Klant voert Autorisatie in Klant bevestigt (I) (I) 1234 Klant wordt opgehaald Klant wordt opgeslagen (O) (O) Hoogendoorn (O) De Meern afbeelding 6: testgeval Integratie en applicatiearchitectuur Resteert nog het testen van de integratie van verschillende delen van de applicatie. Ook hiervoor bieden de use cases handvaten. De verschillende use cases maken gebruik van elkaar functionaliteit. De aanroep van een use case door een andere is beschreven in het stappenplan van de aanroepende use case (zie afbeelding 7). Na uitvoering van de functionaliteit van deze use case worden de postcondities van de aangeroepen use case geverifieerd. Deze verificatie maakt eveneens deel uit van het stappenplan. Zo maakt het testen van de postcondities van use case Identificeren Klant deel uit van het stappenplan van use case Doen Overboeking. Dit leidt weer tot een aantal testscenario s. In afbeelding 7 is er in het gewenste scenario een klant geselecteerd. In een van de faalscenario is in de aangeroepen use case geen klant geselecteerd. De verificatie van de postcondities is een beslismoment geworden. In de bijbehorende testscenario s wordt dus een testactie opgenomen die de postcondities verifieert. Use case Doen Overboeking 1. Voer uit Identificeren Klant 3. Als geen Klant is geïdentificeerd (niet in Sessie), stop dan 4. Haal Klant op uit Sessie 5. Toon Klant afbeelding 7: stappenplan van use case Doen Overboeking met aanroep van use case Identificeren Klant Zo wordt ook ieder use case diagram vertaald in testscenario s. De verificatie van de postcondities van een aangeroepen use case levert zo een beslismoment in het stappenplan van de aanroepenende use case. Versie april 2002 Pagina 8

10 Van requirements naar testgevallen Natuurlijk is gradatie aan te brengen in de diepgang van de tests. Afhankelijk van de beschikbare tijd, en vooral afhankelijk van het belang en de complexiteit van de functionaliteit, kan door het projectteam worden besloten om meer of minder gedetailleerd te testen. Dit kan resulteren in minder testgevallen, of in minder gedetailleerde testgevallen. Belangrijk hierbij is de inschatting van het risico dat wordt gelopen bij het onvoldoende testen van de functionaliteit. Een belangrijke constatering is dat het gebruik van UML een belangrijke stap voorwaarts is in de integratie van testen in moderne systeemontwikkelprojecten. De voordelen zijn legio. De hier beschreven werkwijze biedt een rechtstreekse vertaling van requirements naar testspecificaties. Daarnaast faciliteert UML ook hergebruik van ontwerp. Immers, de use case Identificeren Klant wordt vast vaker gebruikt in de applicatie. Nu worden ook de testscenario s van Identificeren Klant hergebruikt. Zo wordt voorkomen dat testscenario s en testgevallen dubbel worden gespecificeerd. Bij iedere use case hoort één unieke set testscenario s en testgevallen. Hiermee geldt de use case ook als een prettige eenheid voor het testen van functionaliteit. Versie april 2002 Pagina 9

11 Publicatie De tekst van dit artikel wordt gepubliceerd in het maanblad Informatie, mei Versie april 2002 Pagina 10