Als testers moeten we steeds vaker op basis van minder concrete input gaan testen. De klant neemt besluiten/risico's om zo snel mogelijk naar de markt te kunnen. Men weet vaak zelf ook niet concreet hoe een traject gaat lopen, men begint zonder exact duidelijk te hebben waar het zal eindigen. Laat staan dat de requirements duidelijk zijn. Het wordt dan incrementeel managen, stapje voor stapje. Van de leverancier verwacht men dan geen vragen over 100 procent volledige documentatie, etc., want die is er domweg niet. Men verwacht een partner die bereid is risico's te nemen en deze samen te managen. Zo slim mogelijk met de tijd om gaan. Als je dan naar testen gaat, wordt creativiteit steeds belangrijker. Hoe maak je een planning/kostenbegroting, een teststrategie of testcases als je bij wijze van spreken niet eens een FO hebt? Daar ligt een uitdaging!
Ook dit lijkt dan op wat je kunt noemen incrementeel testen: globaal beginnen en in de tijd fijnslijpen, stapje voor stapje duidelijkheid creëren. Niet tegen de stroom in roeien maar meeroeien en langzaam bijsturen. Laag voor laag de ui afpellen. Kort gezegd: de uitdaging zit in een klant die zo snel mogelijk naar de markt wil, daarom projecten start zonder exact helder te hebben hoe zaken zullen gaan en de testpartner vragen dit te bewaken, inzicht in kwaliteit te verschaffen en dit uiteraard tegen vooraf redelijk inzicht in kosten/tijdsbesteding. Uitgangspunt is dat het beschikbare materiaal wordt gebruikt, aangevuld met eventuele wetgeving, vereiste standaarden, etc.
Net als bij een ui zul je de vraag moeten afpellen in een aantal slagen waardoor de requirements duidelijk worden. Dan loop je gelijk tegen een van de bekende valkuilen aan, namelijk hoe vertellen we elkaar wat we nodig hebben? Het probleem nummer 1 in ict-land! De huidige technieken schieten daarbij tekort! Kijk maar naar de grote hoeveelheid applicaties die geleverd wordt welke niet voldoen aan de wensen/eisen van de gebruikers.
Dit probleem constateren is een, maar hoe los je het op? Uiteraard moeten technieken als reviews en inspecties toegepast worden, maar die zijn toepasbaar op datgene dat concreet aanwezig is. De hiervoor geschetste problematiek gaat verder. Hoe stel je vast wat er exact aan functionaliteit nodig is?
In mijn ogen zijn er nog geen concrete (bewezen) oplossingen die hieraan invulling geven. Om het probleem op te lossen zullen we mijn inziens, voor een deel, buiten de ict moeten kijken. Een deel van de oplossing ligt in de sociale wetenschappen, maar dan niet alleen de toepassing van interviewtechnieken. Dat is te voor de hand liggend. Die gebruiken we al en lossen het probleem niet 100 procent op. Nee, technieken die een andere manier van denken stimuleren. Denken vanuit het waarnemen, vanuit het bedenken, vanuit de beleving of bijvoorbeeld het willen. Gecombineerd met een aantal waarheidsperspectieven, zoals monadisme, idealisme, etc.
Door deze technieken te combineren met het multidisciplinaire karakter van Agile kan er een basis ontstaan van datgene wat gewenst is. Deze basis zal ook getoetst moeten worden. Dat kan op de traditionele wijze, maar ook hier denk ik een stap verder. De laatste jaren wordt 'model based testing' voor een breder publiek toegankelijk. De definitie volgens Wikipedia is 'Model based testing is software testing in which test cases are derived in whole or in part from a model that describes some aspects of the system under test'.
De definitie zegt het al. Requirements worden vertaald naar modellen. Door deze slag te maken komen onduidelijkheden, open einden, etc. boven tafel. Door model based testing te combineren met de eerste stap krijg je in een aantal iteraties de gewenste functionaliteit boven tafel. De output van de modellen vormt de input voor de volgende iteratie. Tijdens de testuitvoer kan gekozen worden voor handmatige uitvoering of geautomatiseerde testuitvoering.
Is dit idee fictie of werkelijkheid? Beide nog net niet! Momenteel wordt met verschillende partners een onderzoek gedefinieerd om stap voor stap te onderzoeken of het geschetste idee realistisch en haalbaar is. Het onderzoek moet antwoord geven op vragen als: is de geschetste oplossing realiseerbaar? Welke testskills zijn nodig binnen deze aanpak, op welke punten moet bijvoorbeeld Agile uitgebreid worden en welke bagage hebben de toekomstige testers nodig?
Wat betekent dit voor je testskills? Hoe ga je het aanpakken? Voor het testvak komt er een extra dimensie bij. Om met het nieuwe werken om te kunnen gaan zijn er nieuwe skills noodzakelijk. Exact welke is nog niet bekend. Dat is een van de resultaten uit het onderzoek. Als de fictie werkelijkheid wordt, krijgen we als testcommunity de ideale testbasis op een presenteerblaadje aangereikt!
Helder stuk. Ik denk zeker dat een MBT aanpak helpt om requirements helder(der) te krijgen, zeker bij complexere systemen.
Voor wat betreft de noodzakelijke skills voor de tester:
– in staat zijn om zowel vanuit bedrijfs- als vanuit technisch perspectief te kunnen denken en werken
– over de eigen discipline heen kunnen stijgen en aansluiting kunnen vinden bij of de klant of de hardcore ICT’ers
– ook in fatsoenlijke mate met hen mee kunnen praten
– risk based aanpak kunnen (en willen) herijken in het werk en maatregelen daarop nemen
– kunnen omgaan met zachte factoren
– als adviseur kunnen optreden
Overigens “de ideale testbasis” (laatste zin) klinkt weer als een fixatie en ik denk dat we nu net aan het leren zijn dat we dat los moeten laten.
Goed stuk, de belevingswereld van de tester is de afgelopen tien jaar toch al veranderd, waarbij het uitvoeren van risico analyses, begeleiden van gebruikers, het meedenken met de business kant een aantal voorbeelden zijn.
Maar ik begrijp niet helemaal de link naar model based testing in dit stuk. Als er geen ontwerpen zijn, of zeer beperkt beschreven ontwerpen, dan is het al moeilijk genoeg om testgevallen op te stellen zonder hulp van domein experts / orakels.
Hoe kan je dan verwachten dat model based testing hiermee wel gaat helpen, dan moet er al wel heel gedetailleerd een ontwerp (of model) zijn uitgewerkt. Dit zie ik echt niet gebeuren de komende tijd, of één van onze nieuwe skills moet het motiveren en begeleiden van ontwerpers en business analisten zijn om dit toch te gaan doen. Zijn we dan nog tester?
@Rob: waarom zou je geen tester meer zijn als je anderen helpt om hun werk beter te doen?
Ik zie het juist als een kritische succesfactor als we in staat zijn om bruggen te slaan tussen de verschillende disciplines. Als tester moet je meer gaan leren over domeinen of techniek en de ontwerpers, analisten en programmeurs zouden meer testbagage moeten hebben.
Anko,
Vraag aan een tester: Wat doe je in het dagelijks leven? “Ik ben software tester.” Ondertussen weten wel wat meer mensen dat dit betekent: “Ik vergelijk verwachte uitkomsten en gedragingen van ICT systemen met het daadwerkelijke gedrag van het systeem” (kwaliteit).
Daarvoor heb je randvoorwaarden, zoals bijvoorbeeld duidelijkheid omtrent wat de verwachtingen zijn. Dit kan door een goed geschreven ontwerp of interviews of een goed OO model, et cetera.
Omdat er niet aan deze randvoorwaarde wordt voldaan ga je zelf op onderzoek uit, vraagt. En je probeert bewustzijn te creëren over goede input voor test. Een deel van mijn tijd gaat daaraan op. Is de bewustzijn daar, kan je reviews gaan initiëren, analisten en programmeurs gaan helpen met hun testkennis te verhogen. Je kan meehelpen om de ontwikkelmethodiek in een organisatie te stroomlijnen, zodat je daar als test ook goed op aan kan sluiten.
Krijg je de kans om dit te doen en je wil daar ook iets mee doen als tester, prima! Zelf help ik graag met het verbeteren van de kwaliteit van SW, en zal daar altijd alles (binnen de gegeven opdracht en planning) aan doen om dat te kunnen verbeteren. Dus ik begrijp wel dat we hier een goede aanvullende rol hebben.
Het stuk van Jos, “monadisme, idealisme..” Moeten we zover gaan om ook nog filosofie te gaan studeren om zo goed mogelijk te kunnen testen? James Bach noemt zichzelf filosoof en wordt beschouwd als een testguru. Ik heb met een psycholoog samen gewerkt om usability testen uit te voeren en de resultaten te analyseren.
Maar met al deze aanvullingen op het de skills van een “tester”, ben je dan nog tester of zit je op het pad van kwaliteits adviseur, projectleider kwaliteit? Over filosofie verder; interessant genoeg, ik weet er(nog) veel te weinig van, moest het woord monadisme opzoeken. Maar ik ga in een take gesprek niet zeggen dat ik filosoof ben. Misschien komt dat nog…