Aangenaam kennis te maken: ISO29119

Auteur: Nathalie Rooseboom de Vries – van Delft ● funtestic.fanatic@gmail.com

9 Oktober was de thema-avond van de Werkgroep ISO29119, bedoeld om het geïnteresseerde Nederlandse testpubliek te informeren over de gelijknamige International Software Testing standaard ISO29119.  Met een opkomst van tussen de 60 à 70 testcollega’s was het een redelijk druk bezochte thema-avond, die was opgedeeld in een puur informatief deel en een discussiedeel. In dit artikel wordt met name het informatieve deel nogmaals belicht.
Werkgroep ISO29119 bij TestNet
Bij TestNet overigens heeft een aantal mensen het initiatief genomen om in de vorm van een werkgroep deel te nemen aan het ontwikkelen van deze standaard. Ik kwam zelf bij deze werkgroep in 2009 en in 2012 heb ik de trekkersrol overgenomen. Namens de werkgroep was aan mij de taak iets te gaan vertellen over de tot nog toe behaalde resultaten van de ISO29119 standaard.
Startpunt van de ISO29119 standaard
De aanzet voor het ontwikkelen van deze ISO standaard was EuroStar 2006. In 2007 startte de ‘werkgroep 26’ aan de ontwikkeling van de standaard, nadat zowel Stuart Reid (British Standards Institution=BSI) en Jim Moore (Institute of Electrical and Electronics Engineers=IEEE) een voorstel hiervoor hadden ingediend. De BSI en IEEE hebben aan de basis gestaan van de volgende standaarden, die het fundament vormen voor de ISO29119:

• IEEE 829 Test Documentation
• IEEE 1008 Unit Testing
• BS 7925-1 Vocabulary of Terms in Software Testing
• BS 7925-2 Software Component Testing Standard.

Bestanddelen ISO29119
De ISO29919 bestaat op dit moment uit de volgende delen:

1. ISO/IEC/IEEE 29119-1  Concepts & Definitions
2. ISO/IEC/IEEE 29119-2  TestProcesses
3. ISO/IEC/IEEE 29119-3  TestDocumentation
4. ISO/IEC/IEEE 29119-4  TestTechniques
5. ISO/IEC/IEEE 29119-5  Keyword Driven Testing
6. ISO/IEC/IEEE 33063 Process Assessment Model

De eerste drie delen zijn in september 2013 gepubliceerd (punt 1 t/m 3).  Het vierde deel (punt 4) is nagenoeg klaar, verwachting is eind 2014. Publicatie van deel 5 (punt 5) wordt verwacht in 2015. Daarnaast is er nog een standaard, genaamd ISO/IEC/IEEE 33063 Process Asessment Model (punt 6), die oorspronkelijk wel als onderdeel werd bedacht voor de ISO29119, maar uiteindelijk daarbuiten is geplaatst. Oplevering hiervan wordt eind 2014 verwacht.
ISO29119 versus eerdere standaarden
Zoals je eerder hebt kunnen lezen is de standaard onder andere de opvolger van meerdere andere standaarden. Dan rijst onherroepelijk de vraag wat de verschillen zijn. Eerlijkheidshalve moet ik zeggen dat er in de basis niet veel is veranderd ten aanzien van de eerder beschikbare standaarden. Het kan dan wel een nieuwe standaard genoemd worden, maar het is zeker geen vernieuwende standaard.  Dit wordt bevestigd door de quotes uit het eerste deel die ik in Nederlands heb vertaald.
‘Het doel van testen is om informatie te leveren over de kwaliteit van het te testen item en overblijvende risico’s in relatie tot hoeveel het item is getest; om defects te vinden in het testitem voor vrijgave voor gebruik en om de risico’s te verkleinen voor de stakeholders die ze lopen door slechte productkwaliteit.’  Verder stelt de standaard dat ‘de focus van softwaretesten op het leveren van informatie moet liggen over het softwareproduct en het vinden van zoveel mogelijk defects, het liefst zo vroeg mogelijk in het ontwikkelproces, binnen de gestelde grenzen van kosten en tijd.’
Wat wel een belangrijk verschil is, is dat de oude standaarden zich met name op het systeem, een component of een statisch ontwikkelmodel richten. Daar waar de eerdere standaarden afzonderlijke delen waren, is er nu meer één geheel gekomen. Daarnaast  heeft de nieuwe standaard  meer focus op borging in zowel het project als de organisatie.
Bij de eerdere standaarden was bijvoorbeeld de ‘policy’ een document, dat ergens wel beschreef dat er iets op hoog niveau beschreven moest worden over hoe testen uitgevoerd moest worden in de organisatie. Nu is het een beschrijving over hoe het proces daarvoor ingericht kán worden. Met name dit woord geeft ook een belangrijk verschil aan; in deze standaard is veel aandacht besteed aan ‘ moeten’ , ‘kunnen’ , ‘zouden’  et cetera.  De voorgaande standaarden zijn veel dwingender van aard, onder andere door het taalgebruik. Daarentegen is de ISO29119 standaard veel meer gericht om, zoals het in deel 1 van de standaard wordt genoemd: ‘het context managed proces’. Wat zoveel betekent als dat je alles wel kunt willen plannen, controleren en monitoren, maar je moet altijd de omstandigheden daarin meenemen. Dat betekent ook dat er meer aandacht is voor bijvoorbeeld Agile en evolutionaire werkwijzen, testen in verschillende ‘life cycle models’, en voor testen gedurende de onderhoudsfase.
De aanpakken van ISO29119
In de ISO29119 worden ook diverse aanpakken beschreven. De op risico gebaseerde aanpak lijkt een primaire rol te hebben behouden, maar daarnaast komen de volgende aanpakken ook aan bod:

• requirement gebaseerd;
• model gebaseerd;
• rekenkundige modellen gebaseerd;
• op ervaring gebaseerde aanpakken;
• scripted & unscripted testen.

In de standaard staat ook meer over de verschillende rollen beschreven, die in de eerdere standaarden onderbelicht waren. Er is verder ook informatie beschikbaar over automatisering en defect management, al beperkt zich dit tot ondersteuning van de tester bij het onderzoeken van de bug en het rapporteren hierover. De processen en de concepten zijn te vinden in andere standaarden, waaronder het reeds bekende IEEE1044 (taxonomie) of de wellicht minder bekende ISO/IEC 12207.
Statisch testen niet meegenomen in ISO29119
Het statisch testen is niet in deze standaard meegenomen.  Het is niet zo dat statisch testen als onbelangrijk wordt gezien, maar omdat statisch testen zijn eigen standaard(en) kent. Het  valt op in met name het tweede deel dat de processen sequentieel worden weergegeven, maar dat bij ieder proces nadrukkelijk staat dat activiteiten ook iteratief of wederkerend kunnen worden toegepast. Als laatste tipte ik aan dat bij de ontwikkeling van de standaard, extra aandacht is geschonken aan het maken van voorbeelden. Dat wordt dan met name in deel 2, 3 en 4 zichtbaar.
Eerste deel: Concepts & Definitions
Het eerste deel zijn de concepten en definities. Dit is een zogenoemd informatief deel, wat zoveel betekent als dat men hier niet aan hoeft te ‘voldoen’ als men de standaard wil gaan toepassen binnen een organisatie.  De basis hiervoor was de BS7925-1, die tevens de basis was voor de ISTQB glossary. Naast een lijst met termen en beschrijvingen van wat die betekenen, is in dit deel ook de uitleg van de concepten en practices te vinden. In het eerste deel wordt de kadering beschreven van de gehele standaard, alsmede de samenhang van de diverse onderdelen.  Het drielaagsmodel, dat een rode draad is in de standaard, wordt hier geïntroduceerd, bestaande uit een high-level organisatorisch niveau, een ‘middenlaag’  op project, testsoort of testtype niveau en een onderste laag waar de testuitvoering wordt neergezet.


Tweede deel: Test Processes
Deel 2 van de standaard beschrijft de testprocessen zoals deze in de afbeelding hierboven zijn te zien. Dit is ook het deel van de standaard waar je als organisatie aan bepaalde zaken moet voldoen om ‘compliant’  te zijn. Dit zijn in de standaard de zaken die aangeduid zijn met ‘shall’  (zullen). Overigens is er ook een aangepaste conformance mogelijk, maar dan moet (=shall) wel beschreven zijn waarop dit wordt gedaan.
Op het eerste niveau is het testproces op organisatieniveau beschreven. Het doel van dit proces is het ontwikkelen, controleren en bijwerken van de testspecificatie op organisatieniveau. Het organisatorisch testproces levert twee documenten op namelijk: een beleidsstuk (Test Policy) en een gedetailleerde strategie (Test Strategy). De documentatietermen zijn hier overigens gelijk aan de IEEE 829. Het proces stelt dat hier afspraken worden gemaakt die gelden  voor de hele organisatie, het is dus belangrijk hier afspraken te maken die ook kunnen gelden voor de hele organisatie:  ‘hoog over’ denken dus.  Als je stelt dat je als testende partij altijd een indicatie geeft van een tijdslijn, is dat meer flexibel dan dat je voorschrijft hoe je dat exact gaat doen. Deze documenten zijn in het proces bekend onder de gezamenlijke noemer ‘Organizational Test Specification’, oftewel testspecificaties voor het organisatorisch niveau. Om ze te kunnen ontwikkelen kan bijvoorbeeld de visie van stakeholders, maar ook reeds bestaande beleidsstukken dienen of juist ervaringen die men heeft in de organisatie. Het proces beschrijft dus niet waaraan de documenten moeten voldoen, dit staat immers in deel 3 van de standaard. Wel staan er taken beschreven die horen bij de stappen in het proces.

Op het tweede niveau, het testmanagementniveau, zijn drie processen van toepassing:

• het testplanningproces;
• het testmonitoring- en controlproces;
• het testcompletionproces.

Dit niveau kán zich op projectniveau, op testsoortniveau (functionele test, gebruikersacceptatietest, et cetera) of testtypeniveau (performance, usability) afspelen. Éénmaal toegepast, gelden ze voor de hele groep activiteiten die hieronder valt.  In de presentatie liet ik alleen de highlevel platen zien van de processen, maar in de standaard staan ook verdiepingen van de processen zoals het ‘testplanningproces’.

De derde laag bevat de processen, die met het testen zelf te maken hebben. Het bestaat uit vier processen. Ik wil nogmaals hierbij benadrukken dat de stappen dus niet sequentieel uitgevoerd hóéven te worden, ze mogen ook iteratief of herhaaldelijk worden ingericht.  Zo kan dus ook het design na of tijdens de executie plaatsvinden.


Derde deel: Test Documentation
Het derde deel van ISO29119 beschrijft de testdocumentatie, dat wil zeggen; waaraan moet deze documentatie voldoen als men volgens de standaard wil werken. Aanhangers van ‘Agile’ zullen, hoogstwaarschijnlijk, hun wenkbrauwen fronsen als ze deze standaard openslaan. Met zoveel documentatie lijkt het niet erg te passen in het Agile manifesto waar werkende software wordt gesteld boven uitgebreide documentatie.  Toch heeft men, met name in de bijlagen, wel degelijk nagedacht over de ‘standaard documentatie’  in ‘Agile’ en hiervan voorbeelden gegeven. Het is immers niet gesteld dat een document minimaal 80 pagina’s moet bevatten. De standaard stelt wel wat voor type informatie in een document hoort te staan, maar dat kan ook op 1 A4-tje.
Ik liet tijdens de presentatie een voorbeeld zien wat er zoal in een document zou moeten staan. Dit voorbeeld was een Testplan. Dat deed ik ook om een vergelijking te kunnen maken met in dit geval TMap®.

Wederom zien we hier niets vernieuwends, of naar mijn idee niets vreemds.  Wie de standaard goed doorbladert, zal ook over het algemeen tot een conclusie kunnen komen dat de werkwijze die men hanteert geen geweld aan hoeft te worden gedaan om toch ISO29119 compliant te kunnen zijn.
Vierde deel: Testtechnieken
Hoewel deel 1, 2 en 3 reeds afgerond en gepubliceerd zijn en ik die dus met zekerheid kon presenteren, heb ik toch ook deel 4 aangestipt.  Ik heb hierbij van één techniek het voorbeeld laten zien.  Deel 4 gaat namelijk over, je raadt het al: Testtechnieken.  Ook deel 4 kent ‘ conformance’, die wordt behaald door te voldoen aan de ‘shall’  statements van de gekozen technieken. Indien een organisatie er dus voor kiest om alleen te conformeren aan de standaard voor grenswaardeanalyse, dan is dat hetgeen waar volgens de requirements aan moet worden voldaan. Het is dus best mogelijk dat alle andere technieken nog worden toegepast, maar dat voor deze techniek gesteld is, dat het volgens de standaard gebeurt.
Van iedere techniek bestaat een generieke procesbeschrijving uit drie stappen. Iedere techniek is ook uitgewerkt in een bijlage met een voorbeeld.

Tot slot
In de presentatie sloot ik af met een veelgehoord misverstand. In tegenstelling tot wat hier en daar gedacht wordt, is de ISO 29119 niet ‘gemaakt’ in opdracht van een certificerende instantie of gefinancierd hierdoor. Op dit moment wordt er, voor zover bij mij bekend, ook niet gewerkt aan een syllabus, document of certificeringsschema bij bijvoorbeeld ISTQB.
Overigens, maar dat is mijn persoonlijke mening, lijkt het mij wel een logische stap dat de ISTQB op de langere termijn wel overstapt op de ISO29119 omdat de standaarden waar de certificeringsmaterialen nu op zijn gebaseerd, zoals aan het begin van dit artikel genoemd, uiteraard zijn opgevolgd door de ISO29919.
Vragenrondje
In de daaropvolgende vragenronde, die ook werd gebruikt om wat opmerkingen te poneren, werden een aantal scherpe kantjes uitgelicht.  Een drietal die ik hieruit heb gepakt:
Er werd gerefereerd aan deel 4 (technieken) en iemand stelde de vraag waar de basis van de beschreven technieken lag. Het antwoord hierop was: ‘de BS7925-2’. Vervolgens stelde hij de vraag ‘Waar staat domain testing?’ en op het antwoord dat dit niet beschreven staat in de standaard,  merkte hij op dat de standaard niets nieuws of nieuwe technieken bevatte. Dit heb ik bevestigd, ik stelde immers ook aan het begin van dit stuk al dat de standaard weliswaar nieuw is, maar niet vernieuwend.
Iemand anders vroeg waar testautomatisering en keyword driven testen werden geplaatst. Keyword driven testen is een apart deel van de standaard (deel 5). Automatiseren wordt niet uitgebreid beschreven in de standaard.  Deel 1 besteedt er een paragraaf aan, maar dat is het dan ook wel.  Hoewel er bij mij niets inhoudelijks bekend is over deel 5, verwacht ik dat hier meer over automatisering in staat, maar zeker weten doe ik dit in ieder geval niet.
Een derde aanwezige had een vraag over het statisch testen. Als dit immers geen onderdeel uitmaakt van deze standaard, waar wordt dit dan beschreven? Ik heb hierbij uitgelegd dat statisch testen een onderdeel uitmaakt van de uit te voeren testactiviteiten en dat deze, als ze al niet op organisatorisch niveau zijn vastgelegd in de ‘organisational test specification’, in ieder geval in het testplan moet terugkomen.
Stellingen
Na de koffiepauze was de vloer aan de deelnemers. Met een zestal stellingen (pro/anti-paren) werd men uitgenodigd om te discussiëren over de standaard.  Iedereen kon discussiëren met mensen waarmee hij (of zij) graag over een specifiek onderwerp wilde praten.
Met het neerzetten van de stelling wil ik dit artikel dan ook afsluiten:

• ‘ISO29119, daar gaat toch niemand naar vragen’ versus ‘Iedereen vraagt straks om ISO29119’.
• ‘Het is een voordeel om voor een organisatie is met ISO29119 te werken’ versus ‘Kennis van ISO29119 gevraagd: bij zo’n organisatie wil ik niet werken!’.
• ‘Wie de essentie van ISO29119 begrijpt,  zal daar veel baat bij hebben in een Agile project’ versus ‘Het snappen van de essentie van ISO29119 geeft geen voordelen in een Agile project’.
• ‘ISO29119 is prima toepasbaar in Agile projecten’ versus ‘ISO29119 staat haaks op de statements van het Agile Manifesto’.
• ‘De ISO 29119 bepaalt hoe ik mijn werk moet doen’ versus ‘De ISO 29119 laat me alle vrijheid om mijn werk zelf in te vullen’.
• ‘De ISO 29119 zegt helemaal niks over mijn vaardigheden of over beroepsethiek’ versus ‘Vanuit de ISO29119 is prima af te leiden wat mijn vaardigheden of beroepsethiek moeten zijn’.