Whitepaper. Exploratory Testing. Waarom doen we dat niet altijd? door Dennis Joele

Transcriptie

1 Whitepaper Exploratory Testing Waarom doen we dat niet altijd? door Dennis Joele Dennis Joele is werkzaam als test designer bij TriOpSys en heeft als zodanig voor de Dienst der Hydrografie van de Koninklijke Marine verschillende testen opgezet en uitgevoerd, uitgaande van gestructureerd testen. In dit whitepaper beschrijft hij een praktijkgeval, waarbij gekozen is voor Exploratory Testing. Aangezien beide manieren binnen één project gebruikt zijn, is het mogelijk een vergelijking te maken. De uitkomsten van deze vergelijking leidde tot de vraag bij de klant: Waarom doen we dat niet altijd?" Ook deze vraag wordt beantwoord. Normaal gesproken zijn we gewend om gebruik te maken van gestructureerd testen. Er moet dan wel aan een aantal voorwaarden voldaan zijn. Een voldoende gedocumenteerde testbasis en voldoende voorbereidingstijd voor specificatie van de testen moeten beschikbaar zijn. In het geval dat één van deze ontbreekt, is er toch een testtechniek die uitkomst kan bieden. Deze staat bekend als Exploratory Testing.

2 De werking Volgens één van de grondleggers van de techniek, Cem Kaner, wordt Exploratory Testing gedefinieerd als: Elke vorm van testen waarbij de tester zijn testontwerp opstelt tijdens de testuitvoering, en de informatie die verkregen wordt tijdens het testen gebruikt wordt om nieuwe en betere testgevallen te ontwerpen. Dit houdt in dat een aantal stappen wordt uitgevoerd: een stuk van het systeem wordt verkend (exploreren), er wordt nagedacht over wat er getest kan worden (testontwerp) en de bedachte test wordt uitgevoerd (testuitvoering). Er zijn verschillende nadelen aan te wijzen: de herhaalbaarheid van de testen is lastig, de gekozen testtechnieken tijdens het testontwerp zijn niet zichtbaar, er is geen testdekking te garanderen en de richting van het testen is niet van tevoren bekend. Om deze nadelen weg te nemen heeft James Bach de techniek verrijkt met een aantal elementen, zodat session based Exploratory Testing ontstaat: een test charter, een session, notes en een debriefing. Test charter Een test charter beschrijft de uit te voeren taak en de doelen, zie hieronder: What (scope) What not (not within scope) Exploratory testing is simultaneous learning, test design, and test execution. James Bach Why (questions to be answered) How (brainstorm) Expected Problems Reference (diagrams/models) De test charter kan eventueel ook de te gebruiken testtechnieken en de te verwachten mate van testdekking bevatten. De test charter geeft globaal de randvoorwaarden van het testen aan. Session Een session vindt plaats in een bepaalde tijdspanne, bijvoorbeeld 2 uur waarin aan de hand van de van tevoren gedefinieerde test charter het systeem getest wordt. Zo n session wordt vaak in tweetallen uitgevoerd, bijvoorbeeld een tester en een domeindeskundige. De tester draagt er zorg voor dat (impliciet) testtechnieken gebruikt worden en de domeindeskundige vult de testgevallen aan vanuit zijn/haar systeem- en domeinkennis. Pagina 2 van 7

3 Notes en debriefing Om nu achteraf te kunnen reconstrueren hoe de session verlopen is, worden tijdens de sessie notes gemaakt. Deze bevatten zowel het testontwerp dat tijdens de test wordt gemaakt als de testresultaten. Bevindingen worden natuurlijk ook genoteerd. Dit verbetert de herhaalbaarheid van de testen. Na de sessie worden de notes en de bevindingen doorgenomen met de steller van de test charter. Dan wordt bepaald of de vragen uit de test charter beantwoord zijn. Wanneer toepassen Onder bepaalde omstandigheden is het mogelijk om Exploratory Testing in te zetten. Een aantal van deze omstandigheden wordt hieronder opgesomd. Er is niet voldoende gedocumenteerde testbasis beschikbaar Er is niet voldoende tijd beschikbaar om de testen te specificeren Een aanvulling op/diversificatie van formele testtechnieken is gewenst Er zijn testers met voldoende testkennis beschikbaar De techniek kan bijvoorbeeld ook worden gebruikt om snel uit te vinden hoe een bepaald systeem werkt, om snel een beeld te krijgen van de kwaliteit van een systeem of om een specifieke bevinding in meer detail te onderzoeken. Wanneer niet toepassen Het is niet zo dat als aan één van de bovenstaande omstandigheden voldaan is, Exploratory Testing direct toegepast kan worden. Er zijn uiteraard ook situaties te bedenken waarin deze techniek niet geschikt is, zoals: De opdrachtgever eist de aantoonbaarheid van uitgevoerde testen De techniek kan bijvoorbeeld ook gebruikt worden om snel uit te vinden hoe een bepaald systeem werkt, om snel een beeld te krijgen van de kwaliteit van een systeem of om een specifieke bevinding in meer detail te onderzoeken. Testen moeten herhaald kunnen worden door anderen of met een testtool Kritische functionaliteit die hoge schade zou kunnen veroorzaken bij niet functioneren Als testen uitgebreid gespecificeerd dienen te worden Bij testen waar directe feedback ontbreekt, zoals bij batch functionaliteit Pagina 3 van 7

4 Exploratory Testing bij de Dienst der Hydrografie Het project waarin Exploratory Testing is toegepast betreft de bouw van een nieuw civiel en militair productiesysteem voor het maken van papieren en elektronische zeekaarten. Het systeem bestaat uit verschillende componenten, die deels extern aangeschaft en deels intern ontwikkeld worden. Deze componenten worden geïntegreerd tot één geheel waarbij Workflow Management een overkoepelende laag vormt. Deze zorgt ervoor dat de uitvoering van de bedrijfsprocessen gestuurd wordt. Er zijn in totaal 5 bedrijfsprocessen die achtereenvolgens geautomatiseerd worden. Voor het eerste bedrijfsproces waren reeds gestructureerde testen uitgevoerd. Exploratory Testing is geïntroduceerd als aanvulling op/diversificatie van de gebruikte formele testtechniek, in dit geval Process Cycle Test. Deze testtechniek richt zich op het afdekken van variaties in het procesverloop. Variaties binnen processtappen worden niet afgedekt en met Exploratory Testing is dit wel mogelijk. Exploratory Testing kan alleen toegepast worden als er testers met voldoende testkennis beschikbaar zijn. Normaal gesproken zou dit voldoende zijn. Het hydrografisch vakgebied is echter zeer specialistisch en materiekennis bij de tester was beperkt aanwezig. Om dat te ondervangen is een eindgebruiker betrokken bij de testuitvoering. Deze twee omstandigheden waren de uitgangspunten om de techniek te gebruiken. Voor het eerste bedrijfsproces waren reeds gestructureerde testen uitgevoerd. Pagina 4 van 7

5 Resultaten In een tijdsbestek van 2 uur werden in totaal 11 bevindingen gedaan. Voor het betreffende deelsysteem zijn voorafgaand aan Exploratory Testing een totaal van 52 bevindingen gedaan. Deze bevindingen zijn naar boven gekomen tijdens een uitgevoerde Functional Acceptance Test (FAT) en User Acceptance Test (UAT). Beiden hebben ongeveer 2 dagen in beslag genomen, waarbij de FAT door één persoon uitgevoerd is en er bij de UAT nog eens drie eindgebruikers extra betrokken waren. Effectief leverde Exploratory Testing dus een Bevindingen Frequentie op van 11 bevindingen/4 manuur = 2.75 bevindingen/manuur. Deze berekening is accuraat omdat de gehele tijd effectief besteed is aan het testen zelf. Als ook de tijd voor het opstellen van de test charter wordt meegenomen, levert dit een Bevindingen Frequentie op van 11 bevindingen/4.5 manuur = 2.44 bevindingen/manuur. Voor de voorgaande periode, waarin structureel getest werd, is ook wel een berekening te maken, maar deze is minder accuraat. De Bevindingen Frequentie komt uit op 52 bevindingen/60 manuur = 0.87 bevindingen/manuur. Hierbij is een factor 0.75 gebruikt voor de effectief bestede tijd. In deze berekening is de benodigde tijd voor het opstellen van de Software Test Description (STD) en het reviewen ervan nog niet meegenomen. Als deze op 2 mandagen wordt gesteld, vermindert de Bevindingen Frequentie naar 0.68 bevindingen/manuur. Voor de voorgaande periode, waarin structureel getest werd, is ook wel een berekening te maken maar deze is minder accuraat. Pagina 5 van 7

6 Het delen van beide Bevindingen Frequenties levert een factor op van 2.75/0.87 = 3.16 (exclusief inspanning voor documentatie) en 2.44/0.68 = 3.59 (inclusief inspanning voor documentatie). Het lijkt erop dat Exploratory Testing effectiever is dan de eerder uitgevoerde testen. Dat kan wel gesteld worden omdat de afwijkingen in de beide berekeningen meer dan die factor zou moeten zijn en dat is niet zo waarschijnlijk. Aan de tweede berekening is ook duidelijk het effect te zien van de tijd die nodig is voor het opstellen van documentatie. Deze zorgt ervoor dat de effectieve Bevindingen Frequentie van gestructureerd testen sterker afneemt dan die van Exploratory Testing. In deze berekening is alleen nog maar gekeken naar het aantal gevonden bevindingen, maar nog niet naar de aard van de bevindingen. Van de bevindingen uit de FAT en UAT werden er 8 geclassificeerd als Blocking of Major tegen 3 in de Exploratory Testing session. Dat levert de volgende Bevindingen Frequenties op: 3 bevindingen/4.5 manuur = 0.67 bevindingen/ manuur en 8 bevindingen/76 manuur = 0.11 bevindingen/manuur. Hier moet wel bij gezegd worden dat 2 van de bevindingen door regressie veroorzaakt werden. Als deze buiten de berekening gelaten worden, is Exploratory Testing ook nog steeds tweemaal zo effectief. Hoe dan ook, om beide methoden even effectief te laten zijn moet het gestructureerd testen in dit specifieke geval ruim 16.8 maal zoveel bevindingen opleveren (76 besteed manuur tegen 4.5 besteed manuur). Er kan wel gesteld worden dat die situatie niet gaat voorkomen. Naast het aantal gevonden issues wordt ook gekeken naar de aard van de issues. Pagina 6 van 7

7 Conclusie Als de resultaten van Exploratory Testing en gestructureerd testen met elkaar vergeleken worden, is te zien dat bij Exploratory Testing het aantal bevindingen per besteed manuur ruim 3 keer hoger ligt. Deze observatie is gebaseerd op 76 bestede uren bij gestructureerd testen tegen 4.5 bestede uren bij Exploratory Testing. Het komt er op neer dat bij Exploratory Testing volstaan kan worden met 1/3 van het aantal bestede manuren om toch eenzelfde aantal bevindingen te doen. Er zijn wel meerdere sessions voor nodig. Hiermee is Exploratory Testing een stuk effectiever dan gestructureerd testen. Na het rapporteren van de resultaten van de gehouden session, kwam er een simpele maar doeltreffende vraag van de directe belanghebbende, het hoofd van de afdeling Technologie & Ontwikkeling. Leuke , waarom doen we dat Exploratory Testing niet altijd? Het is natuurlijk zo dat Exploratory Testing niet in alle situaties toegepast kan worden. Dit is bijvoorbeeld zo wanneer het gaat om het testen van risicovolle functionaliteit of als door standaarden de aantoonbaarheid van uitgevoerde testen wordt geëist. Als voldaan wordt aan de omstandigheden waaronder Exploratory Testing toegepast kan worden, kan dit echter een zeer effectieve manier van testen zijn. Over TriOpSys Het komt er op neer dat bij Exploratory Testing volstaan kan worden met 1/3 van het aantal bestede manuren. TriOpSys is gespecialiseerd in het ontwerpen, bouwen en beheren van mission critical IT-systemen, ofwel bedrijfskritische softwaresystemen die nooit uit mogen vallen. Voorbeelden zijn verkeer- en alarmcentrales (te land, ter zee en in de lucht), berichten- en commandocentrales en meldkamers. Onze diensten beslaan 3 expertises: IT Consultancy, Software Ontwikkeling en Mission Critical Services, binnen 3 domeinen: Verkeers-management, Defensie & Ruimtevaart en Openbare Orde & Veiligheid en Beveiliging. Heeft u vragen naar aanleiding van dit whitepaper? Of zoekt u advies? Neem dan contact op voor een vrijblijvende afspraak. info@triopsys.nl Pagina 7 van 7