Tag Testen
Een tip voor testers
Elke softwareontwikkelaar weet dat hij zijn werk goed moet testen. Waarom glippen de meest voor de hand liggende bugs er dan toch doorheen? Omdat testen bij testers is belegd. Dat klinkt voor programmeurs verleidelijk efficiënt: waarom tijd besteden aan het schrijven van tests als iemand het werk toch nog naloopt? Deze taakverdeling nodigt uit tot lagere codekwaliteit en legt de pijn daarvan bij testers.
Behoefte aan een testlane
Als we met z’n allen met één ding bezig zijn, dan is onmiddellijk, voor iedereen, zichtbaar wat er al getest is en wat niet. Een testlane is een lapmiddel voor het eigenlijke probleem: dat we onvoldoende samenwerken. Daardoor weten we niet wie wat al heeft gedaan. Dáárom heb je behoefte aan een middel om daar inzicht in te verkrijgen.
De vergeten tester
Testen is cruciaal voor softwarekwaliteit. En toch, toen ik de kans kreeg een nieuw agile softwareteam samen te stellen, “vergat” ik de tester. Hoe verklaren we deze paradox? Hoe kan een tester tegelijkertijd zó belangrijk en toch ongewenst zijn?
TDD en de testpiramide
Ik ruimde een boekenkast in op het werk, toen een collega me vroeg of ik wist hoe je een call naar een keyed service uit de IServiceProvider mockt. Nee, niet direct, zei ik. Maar waarom zou je dat überhaupt willen? Vanaf daar ontspon er een gesprek over Test-Driven Development, het ontwerp van code en de verschillende delen van de testpiramide.
Hoe testers kwaliteit kunnen ondermijnen
Een complex systeem is een systeem waarin het onmogelijk is om te voorspellen wat de relatie is tussen oorzaak en gevolg. Om die reden worden complexe systemen vaak gekenmerkt door tegenintuïtiviteit. Een ontwikkelteam kan worden gezien een complex systeem. Dus het verbeteren van een ontwikkelteam wordt gekenmerkt door tegenintuïtiviteit.
Gegenereerde tests
Als ik collega’s spreek over de voordelen van LLMs, dan is meestal één van de eerste toepassingen die ze voor zich zien: tests laten genereren door AI. Ik begrijp waar die behoefte vandaan komt. Want tests achteraf schrijven is een rotklusje. Achteraf denk je als ontwikkelaar namelijk al te weten dat je code doet wat ‘ie moet doen. Zulke tests fungeren als een soort administratie van de handmatige tests die je tot die conclusie leidden. En wie houdt er nu van zijn administratie bijwerken? – En toch geloof ik niet dat het een goed idee is om AI in te zetten om tests te genereren.
De vergeten tester
Twee dingen kunnen tegelijkertijd waar zijn. (1) Ik vind de tester de belangrijkste rol hebben in het team. (2) Ik wil geen tester in het team. – Ik wil haast zeggen: de rol van de tester is te belangrijk om bij een tester neer te leggen, maar die uitspraak is makkelijk te misinterpreteren en nodeloos provocerend. En toch…
(Hoe te) releasen als het spannend wordt?
De laatste PI-planning stond er een interessante sessie op de agenda: ‘Releasen als het spannend wordt’. De titel intrigeerde ons. Met de boekenclub lazen we op dat moment Continuous Deployment van Valentina Servile, dus de hele notie van een spannende release deed de wenkbrauwen fronsen. Waar kwam dit gevoel vandaan?
Testen: Een filosofisch retrospectief
Eerst programmeren de programmeurs, dan testen de testers: het komt niet vaak voor dat zo’n voor de hand liggend idee zoveel misvattingen herbergt. Welk aannames liggen ten grondslag aan dat idee? En wat gebeurt er wanneer we die aannames kritisch tegen het licht houden?
Geen requirements, geen tests?
Ontwikkelaars zeggen soms dingen als: “Ik heb geen tests geschreven want de requirements zijn nog onduidelijk.” Of: “Het heeft geen zin om tests te schrijven want de requirements veranderen toch nog.” Dit is, denk ik, een redenering die grenst aan de waanzin – met potentieel desastreuze gevolgen bovendien. Maar het loont zich om erover te filosoferen wat ontwikkelaars ertoe drijft dit soort uitspraken te doen.