Wanneer gaan bij mij de alarmbellen af?

Ik zit nu al heel lang in het vak, ben bij veel bedrijven geweest en heb nog veel meer applicaties gezien. In de loop van de tijd heb ik een soort van tweede zintuig ontwikkeld, waardoor ik kan aanvoelen waar een mogelijk kwaliteitsrisico zit. Niet omdat ik helderziend ben, maar omdat ik dezelfde situaties steeds terugzie. En als ik ze zie, gaan mijn alarmbellen af.

Missende groep in testdekking

Als het om mijn alarmbellen gaat, gaat het niet om “missen de randgevallen”. Het gaat eerder om “is er met genoeg brillen naar gekeken”. Zo wil ik bij het testen graag de volgende groepen herkennen

Testerskennis

Dit zijn testcases die vaak verschillende situaties testen of juist de uitzonderingen. Denk hierbij aan de controle op verplichte gegevens, lijsten controleren met 0, 1 en meerdere waardes en randgevallen. De zaken waar een tester op getraind is

Organisatiespecifiek

Hierbij gaat het om testgevallen, waarbij groepen testen afgestemd zijn op de ervaring in het bedrijf. Dit kunnen testgevallen zijn, die gebaseerd zijn op productiefouten. Maar ook testgevallen, die gebaseerd zijn op kennis van vorige projecten. In tegenstelling tot de vorige groep, is deze lijst minder voorspelbaar

Organisatiebelang

Dit is de groep waarin het niet specifiek gaat om wat er eerder fout ging of wat er volgens de regels moet. Hier gaat het erom: “Wat is er van belang voor de organisatie”. Bijvoorbeeld speciale aandacht voor beveiliging of compliance. Of juist voor correctheid

Waar dit eigenlijk op neer komt, is of er geen kokervisie is ontstaan, doordat een te beperkte groep mensen naar de applicatie heeft gekeken. Dit kan nog wel eens voorkomen als bijvoorbeeld een helpdesk slecht contact heeft met development. Of men een compliance afdeling liever ontwijkt.

Aantal als-dan loops

De kwaliteit van je applicatie is nooit zo goed, dat er nooit mensen over klagen. Ik heb ervaren dat het aantal klachten of klagers niet zo’n goede indicatie is van de kwaliteit. Wanneer je een goede applicatie hebt, klaagt men eerder over details. Als je een slechte applicatie hebt, brengt men de details niet eens ter sprake. Daarom tel ik het aantal “Als-dan loops” in de gemiddelde problemen. Wanneer de klacht bijvoorbeeld is “Als ik Hongarije als land selecteer, dan kan ik niet verder”, is dit een teken van een slechtere kwaliteit. Maar bij “Wanneer ik Hongarije selecteer in stap 1 en daarna bijgebouw selecteer in stap 2 om vervolgens terug te gaan naar stap 1, zijn de gegevens in stap 1 niet meer correct”, ben je een flinke kwaliteitssprong verder

Inconsistentie

Als er inconsistentie is, kom je daar vaak pas in de loop van het project achter. Op je Confluence pagina staan 5 items, in je story 7. Of in de ene story wordt gesproken van een organisatie en in een andere story van bedrijf. Hoe vaker dit voorkomt, hoe groter de kans dat er onderdelen gemist zijn of anders gebouwd zijn dan gewenst.

(Bijna) alle communicatie in Jira (of soortgelijk tool)

Wat moet je nu bouwen

Deze informatie staat in de story en is vaak wel aanwezig

·       Wat moet de applicatie zijn of worden

Dit is de informatie die ervoor zorgt dat story's gezamenlijk leiden tot een correcte applicatie

In de praktijk wordt er op de tweede groep snel en veel bezuinigd. Ik kom ze tegen, de projecten waar het antwoord vaak is “Dat staat in het ticket”. Dat klinkt goed, het is vastgelegd, maar in de praktijk merk ik dat dit vaak problemen geeft.

Wanneer informatie alleen in tickets is vastgelegd, is er zowel een grotere kans op het missen van onderdelen als op het bouwen van onderdelen die niet op elkaar aansluiten. Dit komt, doordat hoe vaker informatie opgesplitst en herhaald wordt, hoe eerder fouten ontstaan. Een lijst van 12 wordt opgesplitst in 24 story’s, 2 per item op de lijst. Denk je er dan bij punt 13 aan om ook story variant 2 hiervoor aan te maken? En als je aanpassingen doet voor team 1, worden die dan ook gedaan voor team 2?

Als men de tweede groep documentatie als basis gebruikt, worden er veel minder snel onderdelen vergeten en sluit wat gebouwd wordt eerder op elkaar aan. Al is het alleen maar door ernaar te verwijzen.

Jouw alarmbellen

Misschien heb jij een eigen lijst, met andere punten of andere prioriteiten. Dat is ook precies de bedoeling. Een alarmbellensysteem werkt alleen als het op jouw ervaring is gebaseerd, niet op die van iemand anders.

Wat ik in de loop van de jaren heb geleerd: de alarmbellen gaan niet af omdat ik een checklist afloop. Ze gaan af omdat ik patronen herken. En die patronen herken ik alleen omdat ik ze eerder heb gezien. Dat kan zijn in een ander project, bij een ander bedrijf, in een andere applicatie. Elke keer dat er iets misging waar ik op had kunnen letten, is er een bel bijgekomen.

Dus als jij nog geen lijst hebt: begin er één. Niet als protocol, maar als geheugen.

Twee jubilea, één rode draad - Groeien en toch jezelf blijven

Twee jubilea deze maand. Twintig jaar geleden ben ik begonnen als tester. 12,5 jaar geleden ben ik begonnen met deze blog. Er is in die tijd veel veranderd. Zowel in het testvak, als voor mijzelf.

Ik ben teruggegaan naar mijn eerste blog. Het was grappig hier de volgende tekst tegen te komen:

Ik ben geen testcoördinator. Ik ben geen testconsultant. Ik heb nooit op conferenties gestaan. Ik heb geen officiële complete Agile of Scrum opleiding gehad. Ik heb weinig collega's gehad om kennis mee uit te wisselen. Wat ik vooral heb, is ervaring. Ervaring in verschillende bedrijven, waarbij ik met vallen en opstaan heb geleerd wat werkt en wat niet. En het geluk om af en toe personen tegen te komen waarmee ik mijn ervaringen kan uit te wisselen. Personen waarvan ik kan leren. Soms testers, soms testcoördinatoren, soms scrummasters, soms ontwikkelaars, soms andere mensen. Of dit genoeg is om een blog te schrijven over Agile testen, laat ik ter beoordeling aan de lezer over. Maar ik zou zeggen, geef het een kans. Niet gelezen, altijd gemist.

Mijn werksituatie is sinds die tijd wel veranderd: vaker grotere teams, meer richting consultant en zeker officiële opleidingen gevolgd. Het werk is steeds meer verschoven van handmatig testen naar testautomatisering. Maar tegelijkertijd hecht ik nog steeds de meeste waarde aan het feit dat ik in heel veel verschillende bedrijven heb gewerkt. En zijn mensen om mij heen nog steeds belangrijk, als het gaat om groeien en leren. Nog steeds vind ik vooral het vallen en opstaan tijdens mijn werk een belangrijk deel van mijn ervaring. En ondanks meer certificaten en ervaring is mijn insteek bij elke blog nu ook “Of mijn kennis voldoende is om een blog te schrijven, laat ik ter beoordeling aan de lezer over. Maar ik zou zeggen: geef het een kans. Niet gelezen, altijd gemist.”

Omdat AI voor mij een standaard is geworden, heb ik Claude maar eens even gevraagd om mijn ontwikkeling te omschrijven op basis van mijn blogs:
de rode draad — kwaliteit verdedigen, weerstand ombuigen, eigenstandig redeneren — is tien jaar lang onveranderd gebleven. Wat wél veranderd is, is de technologische context (Selenium → Playwright → AI), de professionele situatie (vaste baan → detachering) en de diepgang van de reflectie. De blogger is ouder en wijzer geworden, maar schrijft nog steeds over hetzelfde: hoe je als tester "Ja" zegt waar de organisatie "Nee" zegt.

Een mooie samenvatting, al zou ik het zelf anders verwoorden. Hoewel mijn werk en mijn werkomgeving zijn veranderd, heb ik in de kern nog steeds dezelfde overtuigingen: ga voor kwaliteit, volg niet blind de mening van iemand anders (ook niet de meerderheid) en probeer onder alle omstandigheden beter te bereiken. Ik hoop dat ik inderdaad wijzer ben geworden, maar zelf zou ik het bescheiden houden op: ik heb meer kennis en ervaring nu.

Ik heb de testwereld zien veranderen van waterval naar Agile en van volledig handmatig testen naar steeds meer testautomatisering. Maar door alle ontwikkelingen heen, ongeacht methode, tools en technieken zijn mijn testovertuigingen niet veel veranderd. Ik heb waardering gevoeld voor waar ik voor wil staan als tester, maar ook afkeuring. Zowel toen als nu. En ik heb van beiden geleerd.

Maar wat ik vooral voel als ik terugkijk is trots. Trots op wie ik ben geworden, trots op wat ik bereikt heb. Maar ook trots op wie ik ben gebleven. Ik weet dat mensen uit 2016 me in mijn werk niet meer terug zouden kennen. En ik weet dat mensen uit 2016 mijn woorden nog steeds wel zouden herkennen. Dat is een evenwicht waar ik ook voor de komende 20 jaar best voor wil tekenen. Groeien in mijn vak, maar blijven staan voor wat ik belangrijk vind.