TestFrame. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

Transcriptie

1 TestFrame Een introductie Algemene informatie voor medewerkers van: SYSQA B.V.

2 Organisatie SYSQA B.V. Pagina 2 van 13 Inhoudsopgave 1 INLEIDING ALGEMEEN TESTFRAME TESTFRAME ALS BASIS VOOR EEN GEDEGEN TESTTRAJECT DE TESTFRAME FASERING TESTVOORBEREIDING Testclusters Clusterkaart als start van het testtraject TESTANALYSE Testclusters per testsoort of testtype Testcondities Testgevallen Actiewoorden TESTUITVOERING TESTAUTOMATISERING OVERDRACHT EN BEHEER OTAP BEHEER VAN TESTDATA EN TESTWARE OVERDRACHT VERKLARENDE WOORDENLIJST LITERATUURVERWIJZINGEN... 13

3 Organisatie SYSQA B.V. Pagina 3 van 13 1 Inleiding 1.1 Algemeen Uitgebreid en handmatig testen, om te komen tot een hoge quality-to-market, is tijdrovend. Deze tijd is meestal niet aanwezig omdat de time-to-market steeds korter moet worden. In de praktijk blijkt bovendien dat de ontwikkeling van ICT-systemen vaak uitloopt, terwijl de opleverdatum steeds dichterbij komt. Met dit dilemma krijgen steeds meer organisaties te maken. TestFrame biedt een gestructureerde aanpak, waardoor organisaties snel én grondig kunnen testen. Deze introductie is bedoeld voor medewerkers van SysQa B.V. en enige voorkennis van TMAP NEXT is vereist. Versiebeheer Versie Status Datum Auteur Opmerkingen Concept 07 juni 2000 SYSQA Eerste concept 1.0 Definitief 1 september 2000 H.J.J. Cannegieter Correctie en definitief maken 1.1 Concept 26 januari 2009 SYSQA Concept n.a.v. Testframe Definitief 1 februari 2009 H.J.J. Cannegieter Correctie en definitief maken 2.01 Concept 8 februari 2010 SYSQA Aanpassen testcluster-gedeelte 2.1 Definitief 11 maart 2010 SYSQA NAV controle en opmerkingen productmanagement

4 Organisatie SYSQA B.V. Pagina 4 van 13 2 TestFrame Structuur aanbrengen in tests betekent binnen TestFrame dat uitgevoerde tests herbruikbaar zijn. Tevens kunnen hulpmiddelen zoals een risico-analyse, templates en hulpmiddelen om testresultaten te beoordelen op een juiste en correcte manier ingezet worden. De terminologie binnen TestFrame sluit naadloos aan op RRBT (Risk & Requirement Based Testen). 2.1 TestFrame als basis voor een gedegen testtraject Time-to-market Quality-to-market Flexibiliteit Structurering Hulpmiddelen Herbruikbare testproducten Figuur 1: Het TestFrame model. Het TestFrame model is weer te geven in de vorm van een tempel. Het dak symboliseert de bedrijfsdoelen: een hoge quality-to-market en een korte time-to-market. Het fundament van deze tempel is herbruikbaar en gemakkelijk te onderhouden testmateriaal, zodat aanpassingen aan het systeem snel en effectief getest kunnen worden. Indien al het testmateriaal op dezelfde gestructureerde wijze is samengesteld is het testmateriaal goed onderhoudbaar. De drie zuilen (en daarmee succesfactoren) die het dak van de tempel dragen zijn: Flexibiliteit, Structurering en Hulpmiddelen. Flexibiliteit: Opgestelde testgevallen kunnen flexibel hergebruikt worden; Structurering: Het systeem wordt opgedeeld in clusterkaarten en testclusters, vervolgens in testcondities en testgevallen. Prioritering vindt plaats door productrisico s te prioriteren; Hulpmiddelen: Naast bekende hulpmiddelen m.b.t. voortgang, testplanning en testanalyse wordt hiermee ook testautomatisering bedoeld. Testen zit op het kritieke pad van het project. Het is daarom van belang het uitvoeren van testen plaats te laten vinden op het kritieke pad. Dit betekent dat de testvoorbereiding, de testanalyse en de testautomatisering parallel aan het systeemontwikkel-traject plaatsvinden.

5 Organisatie SYSQA B.V. Pagina 5 van 13 3 De TestFrame fasering Testvoorbereiding Productrisico s Projectrisico s Geprioriteerde requirements Begroting Planning Testplan Teststrategie Testorganisatie Testanalyse Testclusters Testcondities Testgevallen Testprojectuitvoering Faserapportage Bevindingenrapportage Eindrapportage Evaluatie Overdracht Testvoorbereiding Testcontract Testuitvoering Testlog Testresultaten Testautomatisering Navigatiearchitectuur Navigatiestructuur Navigatiescripts Voortgangsmanagement Testmanagementdossier Voortgangsrapportage Testinfrastructuur De TestFrame methode bestaat uit 4 deelprocessen: Testvoorbereiding; Testanalyse; Testautomatisering; Testuitvoering. De producten die in het schema opgenomen zijn, zijn bedoeld voor de testmanager en testcoördinator en worden hier niet verder toegelicht. 3.1 Testvoorbereiding De testvoorbereiding heeft als doel een testcontract op te stellen tussen de testmanager en de testcoördinator. Dit wordt gedaan door allereerst testclusters op te stellen.

6 Organisatie SYSQA B.V. Pagina 6 van Testclusters Een testcluster is een logische verzameling van tests die betrekking hebben op een vastgesteld deel van een systeem, proces of aandachtsgebied en wordt opgesteld door de testmanager. Een testcluster wordt opgesteld op basis van een clustermatrix en dient als kapstok waaraan later testcondities en testgevallen kunnen worden opgehangen. Ieder cluster krijgt een Cluster-ID. Een clusterindeling kan gemaakt worden vanuit de testsoort, de logische delen van het fysieke systeem, de processen waar het systeem deel van uit maakt of de scope van de test. Ieder testcluster beschrijft welke delen van het systeem zullen worden afgedekt met de bijbehorende prioriteit die door de stakeholders aan dit systeemdeel gegeven is. Per testcluster bepaal je door wie, hoe en wanneer deze test wordt uitgevoerd. Omdat de activiteiten zo duidelijk zijn opgedeeld (Work Breakdown Structure, WBS), kan de testmanager of testcoördinator de voortgang per testcluster gemakkelijk bewaken en de testmanager kan de projectleider doeltreffend informeren Clusterkaart als start van het testtraject Uitgaande van de testmanagementmethode RRBT (Risk & Requirement Based Testing) zal de testmanager in zijn teststrategie de productrisico s identificeren en er een gewicht/prioriteit aan toekennen. Op basis hiervan stelt hij een clustermatrix op, waarin hij de indeling geeft van de te testen kwaliteitsattributen. In de regel wordt per kwaliteitsattribuut een clusterkaart gedefinieerd; in een enkel geval, wanneer de kwaliteitsattibuten goed verenigbaar zijn, zal de clusterkaart betrekking hebben op meerdere met elkaar verwante kwaliteitsattributen. De clusterkaart wordt toegewezen door de testmanager aan de testcoördinator, en dient als contract tussen de testmanager en de testcoördinator. De informatie op de clusterkaart wordt ingedeeld in de volgende (sub)categorieën en gezien als startpunt van de testanalyse: Sleutelinformatie; o Clusternaam; o Informatiesysteem; o Testsoort; o Testafdeling; o Stakeholder. Opdracht; o Productrisico( s) (faalkans maal impact);

7 Organisatie SYSQA B.V. Pagina 7 van 13 o Belang (MoSCoW principe: Must, Should, Could of Won t test); o Kwaliteitsattribuut; o Uitgangsmateriaal (testbasis). Uitvoering; o Testaanpak; o Testomgeving. Resultaat. o Acceptatiecriteria (Expliciet!). De TC verdeelt de clusterkaart vervolgens onder in één of meerdere testclusters, op basis van risicogebieden. De testclusters wijst hij vervolgens aan de testanalisten toe. Deze testclusters worden vervolgens wanneer de testanalist dat nodig acht (bijvoorbeeld om de omvang te beperken) onderverdeeld in subclusters. In dat geval spreken we van hoofdclusters, die het volledige risicogebied beslaan, en subclusters, die daarvan een onderverdeling zijn. Deze werkwijze heeft tevens voordelen als steeds een aantal dezelfde testregels moeten worden uitgevoerd, waarbij van testautomatisering gebruik wordt gemaakt. Hiermee kan de fase Voorbereiding worden afgesloten en gaan in de fase Testanalyse de testanalisten aan het werk om testcondities en testgevallen te beschrijven. Schematisch ziet bovenstaande werkwijze er als volgt uit:

8 Organisatie SYSQA B.V. Pagina 8 van Testanalyse Vanaf het moment dat alle clusters en hun eventuele onderverdeling bekend zijn, gaan de testanalisten aan het werk. Zij zetten testclusters (hoofd- en/of subclusters) om in testcondities en testgevallen. Het is belangrijk de testclusters zo in te delen dat deze zo veel mogelijk onafhankelijk van elkaar uit te voeren zijn. Door rekening te houden met de opleverdata en oplevervolgorde van deelsystemen, kan de tester de te testen onderdelen beter aan laten sluiten op het kritieke pad. Bij iteratief ontwikkelen worden compleet werkende systeemdelen opgeleverd die ook daadwerkelijk in productie kunnen worden genomen. De oplevering van deze systeemdelen zijn dan leidend voor de volgorde van de test Testclusters per testsoort of testtype De testmanager werkt de testsoort en testtypen uit in de teststrategie van de clustermatrix. Hij verdeelt een testcluster in de volgende testsoorten: Componenttest; Componentintegratietest; Systeemtest; Acceptatietest(s); Regressietests; Bij deze testsoorten kunnen één of meerdere van de volgende testtypen horen: Specifieke afdelingen of producten; Functies binnen het systeem; Entiteiten; Systeemintegratietest; Scenario s; Soapscenario s; Niet-functionele requirements Testcondities Een testconditie beschrijft welke tests uitgevoerd gaan worden. Testcondities mogen niet naar technische of functionele beschrijvingen verwijzen. Ook worden ze in het testclusterdocument vastgelegd en door stakeholders goedgekeurd. Eisen aan de formulering van testcondities zijn: Volwaardige bondige zinnen; Ondubbelzinnige, heldere omschrijvingen; Juiste detailniveau; Eerst algemene situatie, dan de bijzondere situatie Testgevallen Een testgeval beschrijft hoe de test daadwerkelijk uitgevoerd gaat worden. Een testgeval bestaat altijd uit een vast aantal onderdelen: De uitgangssituatie De uit te voeren acties De verwachte resultaten

9 Organisatie SYSQA B.V. Pagina 9 van 13 Om een testgeval op te stellen beschrijft TestFrame een stappenplan: 1. Bestuderen van specificaties en testcondities 2. Gebruiken van voorgeschreven testspecificatietechnieken 3. Definiëren van testgevallen 4. Uitwerken van testdata 5. Documenteren van testgevallen Houdt bij het opstellen van testgevallen rekening met data-afhankelijkheden zoals: volgorde- en referentieafhankelijkheden Actiewoorden TestFrame omschrijft een actiewoord als volgt: Het actiewoord is binnen Testframe een belangrijk middel om testgevallen vast te leggen die een werkwoord bevatten in de gebiedende wijs enkelvoud, is zelfverklarend, zonder informatie over de applicatie zelf noch over de manier waarop dit gebeuren moet (Voer klant in). Actiewoorden kunnen op twee niveaus voorkomen, functioneel en technisch. Door actiewoorden vooraf te koppelen aan testgevallen is het mogelijk om (delen van) testgevallen gemakkelijk te implementeren in een nieuw testgeval die hetzelfde actiewoord oplevert. 3.3 Testuitvoering Binnen de testuitvoering worden 7 stappen gedefinieerd: 1. Entrycriteria controleren (uitvoeren globale kwaliteitscheck); 2. Het testdraaiboek en de testomgeving klaarzetten (van invloed op geautomatiseerd, alsmede handmatig testen); 3. De test uitvoeren (uitvoeren testscripts, reviewen testresultaten); 4. Bevindingen analyseren en registreren (afwijkingen ten opzichte van verwachte resultaten opsporen); 5. Opgeloste bevindingen hertesten (regressietest); 6. Rapporteren (inzicht geven aan testcoördinator over testvoortgang); 7. Exitcriteria controleren (voldoet het systeem aan de acceptatiecriteria). 3.4 Testautomatisering Indien de testmanager tijdens het opstellen van de clusterkaart aangegeven heeft dat de test geautomatiseerd uitgevoerd kan worden, moeten de volgende aspecten in ogenschouw genomen worden: Hoeveel testruns worden verwacht; Hoe complex zijn de testgevallen en de testomgeving; Zijn de juiste hulpmiddelen aanwezig; Hoe stabiel is de te testen applicatie; Is de organisatie volwassen genoeg om geautomatiseerd te testen; Wat is de doorlooptijd van het testproject. Kortom: De investering in tijd en geld moet je terug kunnen verdienen. Geautomatiseerde testen kunnen opgesteld worden vanuit het actiewoord. Ieder actiewoord wordt omgezet in een uniek script, welke geplaatst kan worden in een testgeval. Doordat ieder actiewoord zijn eigen script krijgt, zijn actiescripts voor meerdere testgevallen inzetbaar. Je werkt dan bottom-up.

10 Organisatie SYSQA B.V. Pagina 10 van 13 4 Overdracht en beheer Tijdens het opzetten van het testproject maakt de testmanager al afspraken over het beheer van de testomgevingen. Zo kan het helpen de doorlooptijd te versnellen als er meer dan één testomgeving beschikbaar is. De ene groep testers hoeft dan niet te wachten totdat de andere groep testers klaar is. 4.1 OTAP Voor een informatiesysteem worden vier logische omgevingen ingericht: Ontwikkeling, Test, Acceptatie, Productie (OTAP). De OTAP-configuratie zorgt er voor dat de verschillende typen gebruikers (ontwikkelaars, testers, acceptanten en eindgebruikers) geen hinder van elkaar hebben. Door deze splitsing van omgevingen kan ook de verantwoordelijkheid voor deze omgevingen gesplitst worden. De verantwoordelijkheid voor de ontwikkel en de testomgeving ligt vaak bij ICT, terwijl de acceptatie en de productieomgeving onder de verantwoordelijkheid van de business vallen. Versiebeheer in de OTAP-configuratie is als volgt ingedeeld. Ontwikkeling (v 1.3) Test (v1.2) Acceptatie (v1.1) Productie (v 1.0) Om deze versionering kort toe te lichten het volgende: Zodra in Acceptatie v 1.1 goedgekeurd wordt, dan mag deze in productie genomen worden. Zodra in Test een vrijgave gegeven wordt voor v1.2 dan schuift deze door naar Acceptatie. Geven de ontwikkelaars hun v1.3 vrij voor Test, dan wordt de versie waarin de ontwikkelaars ontwikkelen automatisch opgehoogd. Door deze indeling kunnen de verschillende typen gebruikers ongehinderd verder gaan met hun werk en is voor iedereen duidelijk binnen welke versie er gewerkt wordt. 4.2 Beheer van testdata en testware Het beheren van testdata en testware kost tijd en geld. Toch wordt het beheer van testdata en testware binnen TestFrame gezien als het fundament van de TestFrame-methode. Het beheer levert het volgende op: De testers beschikken bij een hertest over dezelfde testdata en testware tijdens de hertest als bij de oorspronkelijke run. Bij een nieuwe release van een informatiesysteem kun je gebruikmaken van de testdata en testware van de vorige release. De testers kunnen zich hierdoor meer richten op de wijzigingen, waardoor de kwaliteit van de tests beter wordt. De testdata en testware behoren bij een bepaalde versie van het informatiesysteem dat aan klanten wordt uitgeleverd. Mochten er bij klanten problemen optreden met het informatiesysteem, dan moet je altijd kunnen aantonen dat de versie correct is opgeleverd. Beheer van testdata en testware is eveneens noodzakelijk om op een gestructureerde manier te bepalen wat de impact van wijzigingen in het informatiesysteem is op de testdata en testware. Als er een fout gemeld wordt in de productieversie van een informatiesysteem, kan de beheerafdeling de opgeslagen testdata en testware gebruiken als naslagwerk: welke testgevallen zijn uitgevoerd, welke keuzes zijn gemaakt bij het eventueel oplossen van de bevindingen en wat is de status van deze testgevallen Volgens de TestFrame-methodiek komt de volgende testware in aanmerking voor versie- en configuratiebeheer: Clusterkaarten;

11 Organisatie SYSQA B.V. Pagina 11 van 13 Testclusters (inclusief testcondities, testgevallen en actiewoorden); Actiewoorddocumentatie; Testdatabases; Testbestanden; Navigatiescripts; Testomgevingen. 4.3 Overdracht In de overdrachtsfase van een TestFrame-project levert de testmanager een eindrapportage op. Dit eindrapport fungeert als een dechargedocument en als verantwoording richting de opdrachtgever. Onderdeel van de overdracht zijn ook de resultaten van een evaluatie en het overdragen van alle testproducten aan de partij die dit beheer in portefeuille heeft. Deze drie onderdelen (eindrapportage, evaluatierapport en testproducten) vormen samen de overdrachtsset.

12 Organisatie SYSQA B.V. Pagina 12 van 13 5 Verklarende woordenlijst Actiewoord Het actiewoord geeft aan welke actie moet worden uitgevoerd en welke argumenten daarbij moeten worden gebruikt. Een actiewoord kan in verschillende testgevallen worden hergebruikt. Clusterkaart Clustermatrix Hoofdcluster Navigatiearchitectuur Kaart met daarop de essentiele informatie (bijvoorbeeld stakeholder, productrisico s en acceptatiecriteria) die nodig is voor het opstellen en uitvoeren van de tests behorende bij deze clusterkaart en de daarvan afgeleide testcluster(s). Samen met het maken van de clustermatrix vormt het opstellen van de clusterkaarten de laatste fase van het beschrijven van een teststrategie. Het is de basis vaoor de testanalyse. Eerste indeling van de te testen kwaliteitsattributen naar stakeholder en testsoort. Deze indeling geeft aan welke clusterkaarten gemaakt moeten worden. (Optioneel) Verzameling testclusters Hierarchische opbouw van de samenhang tussen de diverse bouwstenen voor de testautomatisering Navigatiescript Navigatiestructuur Navigatiescripts zijn automatiseringsscripts met behulp van record & playback-tools. Beschrijft de structuur van de navigatieomgeving. Waar staat de testomgeving, waar komen de navigatiescripts en hoe komt de navigatiearchitectuur hierin terug. OTAP Acroniem voor Ontwikkelomgeving, Testomgeving, Acceptatieomgeving en Productieomgeving. Hiermee wordt de basisstructuur voor testomgevingen aangeduid die wordt gebruikt om een aparte testomgeving voor elk van de doelgroepen te definieren. Testcluster Testconditie Testdatabase Testgeval Testmanagementdossier Testomgeving Logische verzameling van tests die betrekking hebben op een vastgesteld deel van een systeem, proces of aandachtsgebied. Beschrijving van de uit te voeren tests. Beschikbare testgegevens opgeslagen in een database. Een testgeval is een beschrijving van hoe de test daadwerkelijk uitgevoerd wordt. Alle documenten die van belang zijn voor het juist uitvoeren van de testmanager-taken. Zie OTAP

13 Organisatie SYSQA B.V. Pagina 13 van 13 6 Literatuurverwijzingen Testframe, een methode voor gestructureerd testen, Chris. C. Schotanus e.a. ISBN