Nauw betrokken zijn rondom ontwikkelingen met testen en modellen is een leerzame en interessante ontdekkingsreis. Het testvak op diverse aspecten zien veranderen of doen laten veranderen is niet alleen fascinerend vanuit het vak gezien maar vooral vanuit de klant gezien.
De klaagzang over late betrokkenheid, hoge kosten, weinig inzicht in dekking en al helemaal niet kunnen voorspellen hoeveel bevindingen er nog uit productie komen wil ik hier niet aan gaan. Deze kennen we allemaal wel. Wat wel een interessante gedachte is het onafhankelijkheidsprincipe. Velen klagen onafhankelijk te moeten zijn. De vraag is, is dat wel zo, en zo ja tot in welke mate?
Veel van de testers die zich bezighouden met Model Based Testing zijn van mening dat er een apart afzonderlijk test model moet komen. Om onafhankelijk te blijven, de kwaliteit aan te tonen en fouten te vinden. Een nobele gedachte maar met desastreuze gevolgen: de test pilaar wordt nog dikker, fouten worden nog steeds laat gevonden, fouten door misinterpretatie van ontwerpen blijven bestaan of worden zelf geïntroduceerd door een extra laag aan modellen (documentatie), eigen modellen maken is een tijdrovende klus enzovoort enzovoort. Dit alles onder het mom onafhankelijk te zijn.
De tegenargumenten hoor ik al komen, ja maar gevolgd door gedachten en opmerkingen die we allemaal wel kennen. Laten we het eens omdraaien, kijken vanuit de business, onze doelen en het einddoel.
De business wil uiteindelijk goede applicaties, die er toe leiden dat er meer euro’s worden verdiend (winst lange termijn), de business heeft voor projecten een bepaalde zak geld beschikbaar en deze moet het liefst zo klein als mogelijk blijven (winst korte termijn). We hebben als testers geen afzonderlijke einddoelen maar staan ten dienste van het team, de opdrachtgever en eindklanten. Wij moeten er mede voor zorgen dat er kwalitatief goede applicaties in productie komen.
Is het dan nodig dat we aparte modellen maken om onafhankelijk te zijn? Of kunnen we gewoon de modellen gebruiken die er toch al zijn? Het argument ja maar dan testen we niets is niet waar. We kunnen een model immers ook toetsen, de business helpen modellen te lezen, te verstaan en deze aan te scherpen. Elke formele beschrijving die slechts voor één uitleg vatbaar is, is mogelijk te gebruiken om geautomatiseerd testgevallen af te leiden, uiteraard gevolgd door geautomatiseerde uitvoering.
Een onafhankelijk test model is daarmee een oude gedachte. Het doel is niet een separaat model te maken maar de uitgangsdocumentatie voor testen zo ver te verbeteren dat we geautomatiseerd testgevallen kunnen afleiden en uitvoeren. Het maken en onderhouden van het model is daarmee niet het issue, dit wordt immers een business asset. Het gaat er dan om dat de uitgangsdocumentatie geschikt is om snel de kwaliteit te verbeteren of aan te tonen.
Als ik het heb over oude gedachten is het niet heel handig de Boehm Curve aan te halen, dat doe ik dan ook maar niet. Waar ik wel toe oproep is eens anders naar je vak te kijken. Was is je doel? Waarvoor ben je bezig met testen of meer in het bijzonder Model Based Testing?
Onafhankelijk zijn is immers niet de uitdaging…!?
Hoi Andreas,
Ik denk dat het belangrijk is dat testers onafhankelijk zijn van gedachte. Testers kijken anders tegen de wereld aan dan ontwikkelaars of projectleiders. Dit maakt hen juist waardevol. Ze zijn skeptisch. Het zijn kritische denkers. Met deze skills bouwen ze aan hun eigen persoonlijke testmodel; een mentaal testmodel met als doel het leveren van kwaliteits gerelateerde informatie.
Andere vormen van onafhankelijkheid zoals locatie, team of andere soorten testmodellen zijn wat mij betreft afhankelijk van de context.
Om kwaliteits gerelateerde informatie te verzamelen kan het zijn dat een tester eigen testmodellen nodig heeft zoals testscripts of een model van het product maar het is niet per definitie zo.
- Ruud Cox
Andreas,
Ik denk dat drie vragen belangrijk zijn bij het beantwoorden van de vraag of testers een eigen model moeten maken:
1) Zijn de testers betrokken geweest bij het ontwikkelen van het gemeenschappelijke model?
2) Bevat het door het team gemaakte gemeenschappelijke model de informatie die nodig is voor het (model based) uitvoeren van testen?
3) Is het model door de alle betrokken partijen (business & en IT) adequaat gevalideerd?
Als bovenstaande vragen met “ja” beantwoord kunnen worden is het m.i. niet nodig en zelfs onwenselijk dat de testers een eigen model bouwen.
Het door team gemaakte gemeenschappelijke model heeft dan grote waarde. Namelijk het door alle betrokken partijnen gedeelde begrip van datgene dat ontwikkeld & getest moet worden.
@Ruud, dank voor je waardevolle aanvulling, wat je zegt in de eerste zin beschrijft denk ik een rake kern. Het gaat er om dat je onafhankelijk bent in je gedachten. Je kunt dan inderdaad per situatie bepalen wat je moet doen wat team, documentatie of modellen betreft.
Nog wel een vraag, je stelt: “Testers kijken anders tegen de wereld aan dan ontwikkelaars of projectleiders” is dat wel zo? Hoe is die kijk anders? kun je daar is handen en voeten aangeven? Misschien geeft dat namelijk wel een antwoord op onafhankelijk zijn ingedachten.
@Johan,
waardevolle vragen die we ons inderdaad moeten stellen. Sommigen zijn van mening dat om onafhankelijk te zijn je juist NIET mee gewerkt moet hebben aan het model (vraag 1)jij stelt dat het niet uitmaakt als je wel hebt meegewerkt. Kun je dat toelichten?
Vraag twee is inderdaad een goede, bevat het model voldoende informatie om een test script uit te genereren. Soms denk ik wel dat we te snel geneigd zijn om te zeggen dat we er niets mee kunnen omdat we ons laten leiden door een specifieke tool.
Vraag 3: agree, volgens mij moeten we niet aan de slag gaan met een model dat niet is goed gekeurd maar datzelfde geldt voor andere bron documenten net zo
Andreas,
Ik ben van mening dat testers als lid van ontwikkelteam mee moeten helpen een door alle betrokken gedragen model te maken. De tester kan daarbij helpen door vanuit zijn houding “schuldig totdat het tegendeel is bewezen” kritische vragen te stellen of bij andere betrokkenen kritische vragen te “triggeren”. Op die manier kan het model sterk verbeterd worden. Zo kan een tester actief en vanaf de start van het project bijdragen aan het maken van een goed model. Het is toch zonde van tijd & geld om te wachten tot de rest van het team het model klaar heeft voordat je als tester zijn bijdrage gaat leveren aan het succes van het project?
Daarnaast kan maar een klein gedeelte van de informatie die bij het maken van het model door de teamleden wordt uitgewisseld vastgelegd worden in het model. Als je als tester niet heb deelgenomen aan het proces van het maken van het model mis je een hele boel zinvolle informatie. Bijvoorbeeld de discusssie achter bepaalde design keuzes en de zaken waarover de de businessvertegenwoordigers zich zorgen maken. Allemaal informatie die je als tester in staat stelt effectiever en efficienter te testen. Deze informatie achterstand loop je nooit meer in als je niet vanaf de start betrokken bent!
Ik zie in de praktijk dat testers “onafhankelijkheid” vertalen met: niet betrokken tot dat de documentatie en software ter review of test wordt aangeboden. Je hebt dan m.i. de kans gemist om vanaf de start van het project het team te helpen om fouten te vinden of zelfs te voorkomen.
Daarnaast zie ik dat testers “onafhankelijkheid” invullen door vooral niet de samenwerking te zoeken met het ontwerp & ontwikkelteam. Zonde, want de verschillende disciplines zouden elkaar goed kunnen helpen en aanvullen. Bijvoorbeeld doordat testers de ontwikkelaars helpen een goede dekking met unit testen te bereiken. Of ontwikkelaars die testers helpen met automatiseren van test cases. Of testers die het ontwerp verduidelijken door deze op belangrijke punten concreet te maken met voorbeelden (=test cases).
Andreas,
Het valt nog niet mee om een antwoord te formuleren op je vraag maar ik doe mijn best.
De vraag die een goede tester moet beantwoorden is “Hebben we een probleem”? Om een goed antwoord op deze vraag te kunnen geven is het dus belangrijk dat een tester nadenkt over hoe fouten ontstaan maar ook hoe ze gedetecteerd kunnen worden. Dit in de meest breede zin van het woord. Daarmee bedoel ik /alle/ problemen die de waarde voor de klanten bedreigen.
Voorbeeld:
Een ontwikkelaar vertaalt een ontwerp in code.
- Een ontwerp is een model en is per definitie incompleet, ambigu, inconsistent etc ongeacht de moeite die we doen om het /perfect/ te krijgen.
- Code is taal en daarmee ook een model. De programeertaal C heeft als ik me goed herrinner zelfs meer dan 40 punten van ongedefinieerd gedrag in de C standaard staan. Een implementatie van de C standaard (een compiler) kan ook weer fouten bevatten.
Een tester neemt een model niet voor waar aan. Hij blijft skeptisch omdat hij weet dat het om modellen gaat. Een abstractie met genoemde tekortkomingen.
- Het denkprocess van de ontwikkelaar wordt vaak ongemerkt beinvloed door aannames, cognitieve biases, opgedane ervaring en kennis Een mix van al dit, aangevuld met emotie zorgt ervoor dat de ontwikkelaar voor een bepaalde constructie in de code kiest.
Een tester stelt vragen aan de ontwikkelaar waarom hij bepaalde keuzes maakt en probeert zodoende bijv aannames boven water te krijgen die geverifieed moeten worden. Aannames zijn een bron van fouten. Ook biases zijn een bron van fouten bijv selection, confirmation, matching bias. Op wikipedia worden deze biases uitgelegd en zal duidelijk worden tot wat voor een fouten ze kunnen leiden. Kritisch denken (denken over denken) helpt deze fouten boven water te krijgen.
Het denkprocess is niet typisch voor een ontwikkelaar. Het is menselijk om aannames te doen en biases te hebben. Ook is ieder mens uniek in zijn ervaring, kennis en emotie. Het geldt dus ook voor testers. Zij zullen er aan moeten werken (skills) om minder van deze menselijke eigenschappen last te hebben.
Een tester is erg bewust bezig met het zoeken naar problemen waar de klant last van kan hebben. Dit doet hij door het stellen van vragen. Soms zijn dat vragen over het specificatie of ontwerp. Soms zijn dat vragen aan het eindproduct (tests). Bewust bezig zijn met probleemzoeken gaat, zoals ik hierboven probeer aan te geven, veel verder dan een testtechniek uitwerken en de afgeleide testcases stap voor stap uitvoeren.
Kijken ontwikkelaars en projectleiders anders tegen de wereld aan dan testers? Wel als het om de denkwijze gaat.
@Ruud @John, dank voor jullie reacties. Zitten goede punten tussen, dank voor de aanvulling en het delen van jullie visie