Aandachtspunten inzet testtool. Een aanpak. Algemene informatie voor medewerkers van SYSQA B.V

Aandachtspunten inzet testtool Een aanpak

Algemene informatie voor medewerkers van SYSQA B.V.

Organisatie Titel Onderwerp

SYSQA BV Aandachtspunten testtools Testtool

Pagina Versie Datum

2 van 12 1.0 27-04-2004

INHOUDSOPGAVE 1. 1.1 1.2 2. 2.1

INLEIDING .......................................................................................................................................3 DOEL EN AFBAKENING ....................................................................................................................3 CAPTURE EN PLAYBACK TOOLS .......................................................................................................4 VRAGENLIJST ................................................................................................................................5 INVALSHOEK VRAGENLIJST ..............................................................................................................5

3.

VRAGEN MET BETREKKING TOT HET ASPECT KOSTEN ........................................................6

4.

VRAGEN MET BETREKKING TOT HET ASPECT TIJD................................................................9

5.

VRAGEN MET BETREKKING TOT HET ASPECT KWALITEIT..................................................12

Almere © 2003

2 van 12

Quality Assurance in ICT



1.

Inleiding

1.1

Doel en afbakening

Pagina Versie Datum

3 van 12 1.0 27-04-2004

Geautomatiseerde systemen worden steeds complexer. Hierbij moeten we denken aan gecompliceerde GUI’s en gedistribueerde processen, die in een heterogene omgeving uitgevoerd moeten worden. Daarnaast staan ingrijpende aanpassingen op stapel; De EURO en het millennium probleem. Deze zaken hebben ook hun weerslag op het testtraject. Geautomatiseerd testen wordt hierdoor steeds meer wenselijk. Automatiseringsprojecten kennen drie belangrijke variabelen die sterk met elkaar samenhangen: • • •

Budget Tijd Kwaliteit

Een manier om invloed uit te oefenen op een of meer van deze variabelen is de inzet van een testtool. Ter beperking van de omvang van het uit te voeren onderzoek is in eerste instantie gekozen voor de groep van meest gebruikte en daarmee meest in de aandacht staande testtools, namelijk capture en playback tools (zie volgende paragraaf X voor een toelichting). Een projectmanager heeft een probleem ten aanzien van het budget, de tijd of de kwaliteit. Een andere mogelijkheid is dat de projectmanager een nieuw systeemontwikkelingstraject gaat starten en hij of zij wil aan een van deze drie of zelfs alledrie bijzondere aandacht schenken (bijvoorbeeld als gevolg van problemen in het verleden). Voordat de projectmanager de telefoon pakt en de inkoopafdeling verzoekt een testtool aan te schaffen zal hij/zij zich het een en ander af moeten vragen. Daarbij is het goed te beseffen dat er zeer veel factoren van invloed zijn op de overweging een tool te gaan gebruiken (het afwegingsproces). Wat hij/zij zich af zal moeten vragen is zeer complex; door de variabelen budget, tijd en kwaliteit als uitgangpunt te nemen is getracht enige structuur te brengen in dit afwegingsproces. Het doel van dit rapport is ondersteuning bieden aan SYSQA-medewerkers die een opdrachtgever bij moeten staan bij de keuze al dan niet gebruik te gaan maken van een testtool. De opzet is als volgt: Per variabele zijn een aantal vragen geformuleerd. Deze zijn steeds van een toelichting voorzien waarin duidelijk gemaakt wordt wat met de vraag beoogd wordt en welke invloed de beantwoording heeft op het afwegingsproces. Het is de bedoeling dat dit een dynamisch document wordt waar, naar gelang de ervaring toeneemt zullen de vragen vervolmaakt moeten worden

Almere © 2003

3 van 12



1.2


Pagina Versie Datum

4 van 12 1.0 27-04-2004

Capture en playback tools

Capture en playback tools zijn tools die als het ware de testinvoer opnemen, zodat deze invoer op een later tijdstip afgespeeld kan worden. Mogelijkheden van dit soort tools zijn bijvoorbeeld hulp bieden bij het opzetten van de test (testinvoer) en het kunnen muteren van de opgeslagen invoergegevens. In combinatie met comparators is het mogelijk de testresultaten te analyseren. Over het algemeen wordt het als een nadeel gezien dat dergelijke tools bepaalde eisen aan de stabiliteit van de testbasis stellen. Capture en playback tools kunnen bijvoorbeeld de volgende functionaliteiten omvatten (“Testen volgens T-map”, Pol, Teunissen, van Veenendaal, 1996): • autmatische creatie van testscripts en de mogelijkheid tot handmatig onderhoud van testscripts bij gewijzigde situaties; • logging van (een) specfieke terminal(s) ten behoeve van performance testen; • multipliceren van testscripts ten behoeve van volumetests; • selectieve uitsluiting van (gevoelige) applicaties van logging; • opslag, beheer, documentatie en benadering van meerdere versies van testgevallen; • on-line en batch beschikbaarstelling van testgevalllen; • mogelijkheid tot automatische en interactieve vergelijking van opgenomen en actuele invoer; • mogelijkheid tot toevoegen en verwijderen van schermen, waarbij de integriteit van de test tijdens het afspelen van de test gewaarborgd blijft; • mogelijkheid tot directe analyse van verschillen bij de constatering; • mogelijkheid tot registratie van een verklaring van een geconstateerd verschil; • mogelijkheid tot het afbreken van de test en het later weer opstarten op het punt van afbreken; • de aanwezigheid van een test-control-language waarmee bijvoorbeeld diverse testscripts kunnen worden samengevoegd tot een testdraaiboek. Capture en playback tools bestrijken zowel het gebied van de testontwikkeling als dat van de testuitvoering. Test ontwikkeling: Bij het ontwikkelen van tests moet gedacht worden aan het ontwikkelen van testscripts, test data en verwachte resultaten na het uitvoeren van een gespecificeerd testgeval. Als er problemen zijn binnen een project bij het ontwikkelen van één van deze deliverables, is het zeker aan te raden een test ontwikkel tool aan te schaffen. Een capture & playback tool heeft een deel van deze functionaliteit in zich d.m.v. het capture gedeelte. Veel capture en playback tools ondersteunen alle drie deze aspecten. Test uitvoering: Tijdens het uitvoeren van de test zullen de volgende acties ondersteund minimaal ondersteund moeten worden: uitvoering van een opgesteld testgeval, het vergelijken van verwachte resultaten met de geconstateerde resultaten, het opslaan van alle data die met deze testactiviteiten verband houden. Zodra er problemen zijn met één van deze activiteiten kan een test uitvoerings tool uitkomst bieden. Een capture & playback tool kan hierbij uitkomst bieden: het playback gedeelte van vrijwel alle C&P tools bieden ondersteuning op alle drie de activiteiten.

Almere © 2003

4 van 12




2.

Vragenlijst

2.1

Invalshoek vragenlijst

Pagina Versie Datum

5 van 12 1.0 27-04-2004

De werkgroep heeft de aanname gedaan dat de vragenlijst wordt ingevuld door de algemeen projectleider van een systeemontwikkelingsproject. De eerste, belangrijkste vraag die gesteld moet worden is de vraag wat de verwachtingen / problemen zijn t.a.v. tijd, geld en kwaliteit, dus met andere woorden de volgende vraag:

Wat is de reden dat u de inzet van een testtool binnen dit project overweegt? • • •

Is dit uit kostenoverwegingen? Heeft u problemen / verwachtingen t.a.v. de doorlooptijd van de tests? Heeft u problemen / verwachtingen t.a.v. de kwaliteit van de tests?

Afhankelijk van het antwoord op die vraag kunnen verdere detailvragen worden gesteld met betrekking tot dat aspect. Hierna volgt de concept vragenlijst, toegespitst op de drie aspecten: kosten, tijd en kwaliteit. De lijst is zeker nog niet volledig, maar moet worden gezien als een eerste concept waar nog van alles aan toegevoegd, gewijzigd kan worden. Opmerkingen / aanvullingen zijn dus welkom.

Almere © 2003

5 van 12



3.


Pagina Versie Datum

6 van 12 1.0 27-04-2004

Vragen met betrekking tot het aspect Kosten

Indien een projectmanager uit is op een behoorlijke kostenbesparing van de huidige test, is een capture & playback tool niet op voorhand de juiste oplossing. Het inzetten van een testtool is pas kostenbesparend als meerdere malen een hertest uitgevoerd wordt. Deze hertest mag dan niet veel afwijken van de oorspronkelijk opgezette test. Dit impliceert dat de functionaliteit van het te testen object weinig aan verandering onderhevig mag zijn. Verder dient duidelijk gemaakt te worden dat een testtool altijd hoge investeringskosten met zich mee brengt, zowel wat betreft de aanschaf van de tool, als door de opleiding van mensen die met het tool moeten omgaan. Naarmate het systeem van groter (strategisch dan wel ander) belang is voor de organisatie, zullen betrekkelijk hoge investeringen gemakkelijker gedaan worden. Bij grote automatiseringsprojecten hoort vaak een hoog budget. De kosten voor een testtool zijn dan relatief gezien ten opzichte van de totale kosten, vrij gering. Aangezien automatiseringsprojecten echter al zoveel geld kosten, is de extra investering voor een testtool niet altijd gewenst, zeker als deze hoog uitvalt. Dit kan veranderen als blijkt dat de tool ook voor het testen van andere systemen in de organisatie (nu of in de toekomst) ingezet kan worden. Indien reeds eerder testtools zijn aangeschaft door de organisatie, zullen deze eerder in aanmerking komen om wederom ingezet te worden dan nieuw aan te schaffen tools. De investeringskosten zullen dan natuurlijk lager uitvallen, aangezien de tools reeds gekocht zijn. Het opleiden van gebruikers is echter de grootste kostenpost. Zijn de gebruikers nog niet vertrouwd met de aanwezige tools, dan zal de aanschaf van nieuwe tools het totale testbudget niet erg beïnvloeden. Zijn de gebruikers vertrouwd met de aanwezige tools, dan zal de volgende stap zijn om te bepalen of deze tools geschikt zijn voor het automatisch testen van het nieuwe informatiesysteem. Er wordt een aantal aspecten onderkend die van invloed zijn op de vraag of een capture & playback tool tegemoet kan komen bij kostenbesparingen. Deze worden hieronder uitgewerkt. Kennis en ervaring t.a.v. testtools: Het kennis- en ervaringsniveau t.a.v. testtools binnen het project zijn bepalend voor tijdsduur en kosten van de implementatie van een capture & playback tool; bij een hoog kennisniveau zal de implementatie minder kosten. Ook de aanschafkosten kunnen gereduceerd worden door het gebruik van een tool dat al binnen de organisatie gebruikt wordt.

Almere © 2003

6 van 12




Pagina Versie Datum

7 van 12 1.0 27-04-2004

Het aantal gebruikers: Hoe meer mensen met een tool gaan testen hoe lager de relatieve kosten voor het gebruik van zo’n tool worden. De licentiekosten bijv. Nemen relatief bij een hoger aantal gebruikers. Wat niet vergeten moet worden is dat de absolute kosten altijd zullen toenemen wanneer er meer gebruikers zullen zijn. Het aantal geplande hertests: Als het aantal geplande hertests is vastgesteld kan een capture & playback tool hulp bieden bij het geautomatiseerd uitvoeren van deze hertests. Dit heeft tot gevolg dat er sneller gehertest kan worden of dat binnen dezelfde tijd er meer hertests uitgevoerd kunnen worden. Implementatie van een capture & playback tool: Als de implementatie van een testtool niet serieus genomen wordt, kan dat resulteren in het mislukken van het doel van het invoeren van een testtool: snel, gestructureerd en kostenbesparend testen. Denk bijvoorbeeld aan het configureren van een testtool, het inbedden van een testmethodiek in het tool, het verzorgen van het vereiste platform waarrop het testtool draait, het installeren en configureren van andere applicaties waar het tool noodzakelijkerwijs gebruik van maakt, idem voor databases, etc. Zodra hier niet goed over nagedacht is, zal de implementatie van een capture & playback tool tot vertraging en meerwerk dus tot hogere kosten kunnen leiden.. Hoeveelheid testwerk: Naarmate de hoeveelheid testwerk meer wordt neemt de kans op fouten bij het handmatig testen toe. De hoeveelheid kan zelfs zo groot worden dat het überhaupt onmogelijk is alle testgevallen uit te voeren. Een capture & playback tool kan uitkomst bieden door geautomatiseerd (dus bijv. ook ‘s nachts) tests uit te voeren. Herbruikbaarheid van het testtool: Initieel kost het implementeren van een testtool binnen een project enkel geld. Het zou prettig zijn als deze initiele kosten er later weer uitgehaald kunnen worden. Op vier manieren kan dat gerealiseerd worden: het project is erg groot en zal lang duren en meerdere releases opleveren; er gaan veel gebruikers met het testtool werken; het project zal ook nog een behoorlijke periode in onderhoud genomen worden; andere projecten in de organisatie zullen het testtool ook gaan gebruiken.

Almere © 2003

7 van 12




Pagina Versie Datum

8 van 12 1.0 27-04-2004

Hoge dekkingsgraad: Vooral bij embedded software kun je je voorstellen hoe belangrijk het goed functioneren van software kan zijn. Denk bijv. aan een vliegtuigcomputer, ziekenhuisapparatuur, liften, etc. Zulke systemen zullen een zeer hoge mate van dekking vragen. Handmatig is het (haast) niet te doen om een hoge dekking te halen. Geautomatiseerd kan dit wel: denk bijvoorbeeld aan testgeval generatoren. Ook capture & playback tools kunnen hierbij een rol spelen. Omdat de testuitvoering geautomatiseerd gaat kan er meer aandacht besteed worden aan het opstellen van testgevallen. Hierdoor kan een hogere dekkingsgraad behaald worden.

Almere © 2003

8 van 12



4.


Pagina Versie Datum

9 van 12 1.0 27-04-2004

Vragen met betrekking tot het aspect Tijd

Het eerste wat een opdrachtgever verwacht van de inzet van een testtool is meestal tijdwinst. Of tijdwinst behaald kan worden is een complexe vraag. Deze vraag vormt echter de kern van alle vraagstukken over testtools met betrekking tot het aspect tijd. Is tijdwinst mogelijk ? Verwacht de opdrachtgever meteen resultaat, dan kan hij/zij snel uit de droom geholpen worden. Tijdwinst is alleen mogelijk bij langere doorlooptijd en indien frequent hertesten uitgevoerd moeten worden. Indien zich acute tijdsproblemen voordoen, kan beter op de huidige wijze door worden getest, eventueel met meer mensen, dan dat op dit moment de aanschaf van een testtool wordt overwogen. In de praktijk is aangetoond dat het gebruik van een testtool in eerste instantie extra tijd kost. Zelfs de overweging om al dan niet een testtool aan te schaffen heeft zijn tijd nodig. Hoe lang duurt op dit moment de voorbereiding en specificatiefase? Bij de overweging dient meegenomen te worden hoelang het produceren van testware duurt op de huidige manier t.o.v. de benodigde tijd bij inzet van testtools. Tijdswinst in de uitvoeringsfase: Zal inzet van een testtool de benodigde tijd per testrun beinvloeden, zijn minder testruns nodig? Kun je in dezelfde tijd (eventueel zelfs met minder capaciteit) meer testruns uitvoeren? Tijdswinst in het beheer van testresultaten? Onder testresultaten verstaan we hier niet alleen de probleemrapporten maar ook de resultaten van de uitgevoerde scripts. Met name de tijdswinst t.o.v. de handmatige werkwijze is hier van belang. Dit aspect heeft niet alleen betrekking op de tijd, maar ook op de kwaliteit. Hier wordt echter alleen de tijdswinst geteld. Hoeveel testwerk wordt verwacht? Deze vraag kan beantwoord worden vanuit het project waarvoor de inzet van testtools overwogen wordt, maar ook voor toekomstige projecten. De hoeveelheid testwerk speelt een grote rol in de keuze van het wel of niet toepassen van een testtool. Voor een goed inzicht in deze kwestie zal een schatting gedaan moeten worden van zowel het huidige als het in de toekomst te verwachten testwerk. Indien de totale hoeveelheid testwerk beperkt is, zal de tijd die nodig is om het testtool te leren werken relatief groot zijn in vergelijking met de totale hoeveeltijd tijd die het testtraject in beslag neemt. Dat betekent dat bij een geringe hoeveelheid testwerk een tool relatief minder tijdwinst zal opleveren dan bij een grote hoeveelheid testwerk.

Aanwezige kennis en/of ervaring met testtools Indien de aanschaf van een (bepaalde) testtool overwogen wordt, verdient het aanbeveling om eerst eens een grondige blik op de organisatie te werpen. Onderzoek of er reeds tools aanwezig zijn en/of er mensen zijn met ervaring met bepaalde testtools. . Daarnaast moet rekening gehouden worden met een inleertijd (periode die nodig is om gebruikers snel en efficiënt met een tool te laten werken). Als de gehanteerde planning voor een project geen ruimte biedt voor een extra tijdsinvestering, kan dit opgelost worden door meer resources

Almere © 2003

9 van 12




Pagina Versie Datum

10 van 12 1.0 27-04-2004

(testers) in te zetten. De opleiding en inleerperiode van deze extra krachten legt echter ook weer beslag op tijd en geld.

Indien binnen de organisatie kennis en/of ervaring met testtools voorhanden is, zal de tijd die benodigd is om met deze tools te leren werken korter zijn, dan wanneer dit niet het geval is. Het oplossen van eventuele problemen met de tool kan dan ook soepeler verlopen, aangezien dit grotendeels intern kan gebeuren. De invloed van de looptijd van een project Indien de looptijd van een project binnen een organisatie kort is, heeft het normaliter weinig nut om over het gebruik van testtools na te denken. Het aantal hertesten dat plaats zal vinden zal dan namelijk vrij gering zijn. De volgende algemene regel geldt hier: hoe meer hertesten, des te eerder zal een testtool over het gehele traject tijdwinst opleveren. De looptijd van een project kan verder eveneens iets zeggen over het belang van het project voor de organisatie. Hoe langer de looptijd, hoe kritischer het project, des te belangrijker is het voor de organisatie. Beschrijving van het testproces Voordat een testtool gebruikt wordt, kan het soms noodzakelijk zijn dat het testproces beschreven is. Is dit het geval en is het testproces nog niet vastgelegd, dan dient dit alsnog te gebeuren. Met de nodige gevolgen voor de tijdsplanning. Het is hier niet mogelijk om te beschrijven in hoeverre en in welke vorm het testproces beschreven dient te zijn. Verschillende testtools stellen hieraan verschillende eisen. Heeft de opdrachtgever reeds een bepaald tool in gedachten, dan kan hij over de benodigde beschrijving navraag doen bij de producent/leverancier van de tool. Documentatie van het systeem Niet alleen het testproces dient beschreven te zijn, ook het testobject, het automatiseringssysteem, moet gedocumenteerd zijn. Ook toekomstige veranderingen in het systeem zullen gedocumenteerd moeten worden. Dit heeft directe invloed op de totale tijd die benodigd is voor het systeemontwikkelingstraject en voor het onderhoud/beheer van het systeem. Beschrijving van het werkproces Naast het testproces en het testobject dienen tenslotte ook de werkprocedures vastgelegd te zijn. Een goede beschrijving van het werkproces maakt dat het minder belangrijk is wie welke werkzaamheden uitvoert. Bij een slechte of geen beschrijving is (vrijwel) alles afhankelijk van de kennis en werkwijze van bepaalde personen. Het kan dan behoorlijk veel (discussie)tijd kosten om het werkproces in kaart te brengen. Andere factoren die van invloed zijn op het aspect tijd Bij andere factoren kan gedacht worden aan de complexiteit van de organisatie (ingebruikname van tool duurt langer dan verwacht door bijvoorbeeld investeringsaanvragen, budgetten, politiek) en hard-/software eisen die aan een tool gesteld worden. Overig Ook voor het plannen van het testtraject zijn tools beschikbaar. Het eventuele gebruik is onder andere afhankelijk van de looptijd van het project, de hoeveelheid testwerk et cetera

Almere © 2003

10 van 12




Pagina Versie Datum

11 van 12 1.0 27-04-2004

(zie boven). Meestal is de overweging om dergelijke tools aan te schaffen alleen interessant in het begin van het testtraject. Later in het traject is het nut van deze tools achterhaald.

Almere © 2003

11 van 12



5.


Pagina Versie Datum

12 van 12 1.0 27-04-2004

Vragen met betrekking tot het aspect Kwaliteit 1. Waar liggen de oorzaken van de “mindere” kwaliteit in het verleden?

Als de oorzaak niet bekend is moet de oorzaak eerst onderzocht worden. Misschien ligt de oorzaak niet binnen het bereik van een testtool. 2. Op welke onderdelen verwacht u, door het inschakelen van een testtool, het testtraject kwalitatief te verbeteren? Op zich geeft de inzet van een testtool bij een test niet de garantie dat daarmee de kwaliteit van de test zal verhogen. Het kan echter wel resulteren in een efficiënter testproces, waardoor er binnen een bepaalde periode meer getest kan worden. Er zijn diverse tools die de kwaliteit van het testproject kunnen verhogen. Hierbij kan gedacht worden aan tools die bijdragen aan het generen van testgevallen, tools die het (plannings)proces verbeteren, etc. 3. Kwaliteitsbeleid van de organisatie? Welk belang hecht de organisatie aan de kwaliteit; is men bezig met iso-normering, waarbinnen een testtool een rol kan spelen, etc.

4. Welke testtechnieken worden momenteel gebruikt? Dit geeft een indicatie van het belang dat aan kwaliteit wordt gehecht; welk belang hecht men aan een goed product.

5. Welk tool wordt er al gebruikt? Van dit tool zou bepaald kunnen worden welke bijdrage het aan het kwaliteitsstreven van de organisatie heeft geleverd; of welke bijdrage het niet heeft geleverd.

Is dit testproject op zich staand qua teststrategie, beschikbare uitgangsdocumentatie of zijn er binnen de organisatie vaker vergelijkbare projecten? Als het onderhavige project in veel opzichten uniek is, is een testtool dat juist voor dit project wordt aangekocht misschien niet goed toepasbaar binnen andere systeemontwikkelingsprojecten, hetgeen betekent dat de investering in dat testtool volledig ten laste van het project komt. Als er vaker vergelijkbare SO-projecten plaatsvinden (de organisatie heeft bewust gekozen voor een bepaalde wijze van systeemontwikkeling qua methode, documentatievorm, etc.), is de kans dat een testtool ook in andere projecten goed bruikbaar is groter en de investering in tijd en geld makkelijker te verantwoorden.

Almere © 2003

12 van 12


Aandachtspunten inzet testtool. Een aanpak. Algemene informatie voor medewerkers van SYSQA B.V

Recommend Documents