A Fool with a Tool

Ons vakgebied Testen is volop in beweging, iets wat de meeste lezers van onze blogs ongetwijfeld zullen herkennen. De factoren die deze veranderingen teweeg brengen zijn heel verschillend. Er zijn bewegingen die vanuit de testgemeenschap zelf komen, maar bewegingen van buitenaf moeten ook zeker niet worden onderschat. Deze trends hebben nu eenmaal gevolgen voor de methodieken die we gebruiken, de testontwerpen die wij opstellen, de uitvoer van onze testgevallen en de uiteindelijke analyse. Kortom, gevolgen voor ons vak in de volste breedte. Een belangrijke oorzaak van deze veranderingen is de steeds groter wordende diversiteit aan testprojecten en systemen. Het resultaat daarvan is dat de markt steeds meer vraagt van ons aanpassingsvermogen en onze specialisatie binnen het testgebied.

Uiteraard is het als tester cq. vakidioot erg leuk om hier op in te spelen, maar er gaan ook behoorlijke uitdagingen schuil achter deze vraag. Het mooie daarin is, we staan gelukkig niet alleen. Om effectief te testen en om kritisch naar de kwaliteit van software en projecten te kijken, hebben we hulpmiddelen nodig. Tools, of beter gezegd gereedschappen in goed Nederlands, zijn net zo divers zijn als het brede scala aan systemen waarmee wij te maken hebben. Deze gereedschappen zijn op hun beurt ook volop in ontwikkeling, ze worden steeds flexibeler of juist héél specifiek toepasbaar. Als gevolg hierop stellen wij onszelf continu de vragen: Wat is het juiste gereedschap? En is het erg om hier afhankelijk van te zijn voor de uitvoering van ons vak?

Een goed voorbeeld van dit dilemma toont zich in de volgende fictieve situatie:

Een onbekende foutmelding treedt op vanuit een functie in een derde partij component. Het doel is om de oorzaak zo specifiek mogelijk te isoleren om deze vervolgens te noteren in een inzichtelijk technisch rapport. Dit denkbeeldige voorbeeld heeft de volgende opstelling:

  • Twee testers die elk afzonderlijk het probleem bestuderen.
  • Beide testers zitten in verschillende ruimtes zonder interactie met elkaar te kunnen hebben.
  • Na een flinke kop koffie te hebben gedronken starten beide testers met de opdracht (de koffie zal zelf geen rol spelen in dit voorbeeld, maar jullie mogen er vanuit gaan dat het een goede kop koffie was).

De eerste tester heeft beperkte technische kennis van het systeem en besluit de foutmelding op te zoeken met zijn beschikbare gereedschap (Google is zijn beste vriend). Wat blijkt.. de melding is te vinden op een forum van de leverancier en verwijst naar een instelling die aangepast kan worden. Bingo! Dit is waardevolle informatie voor het rapporteren van de bevindingen! De tweede tester heeft ook toegang tot het internet maar heeft slechte ervaringen met het doorzoeken van internetfora en besluit gesterkt door meer gerichte technische kennis een stuk gereedschap voor netwerkverkeer analyse te gebruiken om meldingen te traceren en te onderzoeken. De oorzaak is al snel te zien: een aanroep naar een niet-bestaand adres. Bull's eye ! Jammer van de cryptische foutmelding, maar dit kan mooi als commentaar meegenomen worden in de foutrapportage!

Is dit te simplistisch gedacht? Natuurlijk, onderzoek is in de dagelijkse werkelijkheid veel lastiger en maakt gebruik van meerdere gereedschappen met beperkingen en onvolkomenheden. Toch hebben beide werkwijzen in dit geval vlot een oplossing gegeven. Chapeau!

Wat zal er nu bij een opvolgende vergelijkbare foutmelding gaan gebeuren? De eerste tester zal na het eerder succesvolle resultaat weer op internet gaan zoeken naar een oplossing. De tweede tester zal opnieuw met veel plezier de netwerkcommunicatie inzichtelijk willen maken na het vorige succes.

Wat is het probleem in deze aanpak?

Beide testers zijn in hun aanpak noodzakelijk reactief en hebben niet geleerd van elkaar. Wat als bij een nieuwe situatie de oorzaak van de foutmelding alleen indirect te herleiden is vanuit het betreffende internetforum? In dit voorbeeld is er een cruciaal versieverschil tussen het aanroepende en het ontvangende component waarvan alleen de symptomen getraceerd kunnen worden met inhoudelijke kennis op netwerk (protocol) niveau. Voor de eerste tester zal de melding op internet veel te onduidelijk zijn (mocht de betreffende informatie überhaupt al gevonden kunnen worden). De tweede tester zal op het netwerkniveau een melding vinden die deze keer niet naar een configuratie-instelling van de applicatie verwijst, en blijven doorzoeken op het communicatie-aspect zonder tijdig de beslissing te nemen om verder te kijken en breder te onderzoeken (tunnel-visie).

Samengevat, als je alleen een hamer hebt lijkt elk probleem op een spijker.Ook hier is de strekking simpel maar duidelijk. Er is niet één stuk gereedschap dat volstaat voor een volwaardig testanalyse proces. Tot zover is dit vraagstuk niet uitsluitend specifiek bedoeld voor het testvak, maar juist binnen het testen zien we duidelijk de verschillende rollen en vaardigheden: wie is er meer of minder technisch, wie analytisch, of juist kritisch? De diversiteit aan personen in een proces is misschien wel de grootste verandering in ons vakgebied van de afgelopen jaren. Dit vraagt ook om ons aanpassingsvermogen in het gebruik en de keuze van de juiste gereedschappen voor testuitvoer, -automatisering en -analyse.

Maar wat is dan de rol van al die gereedschappen die we gebruiken om te kunnen anticiperen op de groeiende datavolumes binnen onze projecten?

Onze gereedschappen zijn extensies van onszelf, we kijken verder door gebruik van het internet, een wereldwijd verbonden netwerk. We kijken bijvoorbeeld ook dieper door het uitvoeren van netwerkanalyses. Nu beslaan het ‘verder kijken’ en het ‘verkennen’ een enkele dimensie, maar wat als we met onze gereedschappen meerdere niveaus zouden combineren, zoals handelen (categoriseren, clusteren) en voorspellen (predictive analysis)?

Op basis van verzamelde data geeft dit meer inzicht en kunnen we beter oordelen. Een hamer heeft een beperkt aantal functies, een computer ook. Maar een organisatie of netwerk heeft veel meer functies en oplossingen dan de afzonderlijke componenten. Een zelflerend netwerk met begrip van de context dat kan interacteren met de tester in begrijpelijke taal, zal één van de twee testers uit het voorbeeld overbodig maken. Maar wie dan? En in welke situatie? Misschien worden beide testers wel overbodig? De focus om scherp te stellen en resultaten te beoordelen vraagt om meer dan alleen technisch inzicht; het gaat hier vooral om de wil om samen te werken.

De testers in dit voorbeeld zullen maar beperkt met nieuwe uitdagingen om kunnen gaan vanwege de geschetste hypothetische proefopstelling. Gelukkig hebben we als testers in de praktijk wel veelvuldig onderling contact en leren we van elkaars werkwijze en gereedschappen, iets wat we vooral ook moeten blijven doen. Niet alleen binnen de testgemeenschap, maar ook daarbuiten.Als we van elkaar leren en elkaars gereedschappen gebruiken zal de som hiervan meer zijn dan de delen, daar ben ik van overtuigd!

Tot slot, in het geval dat ik een hamer nodig heb mag ik deze vast wel even van iemand lenen om ermee de spijker op z'n kop te slaan.. toch?

Au!

Een hamer blijft een hamer….

Albert-Jan van Blaaderen

Albert-Jan is in 2001 vanuit een systeembeheer achtergrond betrokken geraakt bij testprocessen en kwaliteitsbeheer. Hierna vanuit passie voor het tekstvak een jaar later gestart als professioneel tester. 

Hij heeft ervaring in test coördinatie binnen overheid en bedrijfsleven en hecht veel waarde aan een hoge kwaliteit bevindingenrapportage. Als test consultant is hij gedreven om vanuit een praktische aanpak problemen te isoleren en proactief te communiceren.

Volg hem op linkedIn