Een onbetrouwbare test inschatten
Hoe u een onbetrouwbare test kunt inschatten: waarom er twee schattingen nodig zijn in plaats van één, en waarom een tijdslimiet de voorkeur verdient boven discussies over punten wanneer het antwoord afhangt van wat u aantreft.
Een onbetrouwbare test bestaat uit twee schattingen. U weet nog niet welke van de twee het is.
awaitDe ene versie betreft een oplossing van slechts één regel: een aanname over de timing, een afhankelijkheid van de testvolgorde, een ontbrekend element. De andere versie betreft een race condition in de productiecode waar de test toevallig op stuitte, na drie dagen onderzoek. Wanneer de kaarten worden uitgespreid van 2 tot 13, is het team het niet oneens over de omvang — men is het oneens over wat voor soort bug het is, wat de werkelijke onbekende factor is.
Door vooraf in te schatten hoe groot iets is, in plaats van achteraf, komt dit verhaal in week één op plaats 5 terecht en in week drie op plaats 13. De oplossing ligt niet in een nauwkeuriger cijfer, maar in een andere aanpak van het werk. Stel een tijdslimiet vast voor het onderzoek en maak vervolgens een schatting van de daadwerkelijke oplossing zodra de aanpak bekend is.
Wat er in de kamer wordt gezegd
Ingenieur A: „Als het om de reden die ik vermoed niet goed werkt, is dit een 2.”
Ingenieur B: „Als het om de reden die ik vermoed niet goed werkt, is het een 13.”
Inleiding: “Heeft iemand het daadwerkelijk lokaal uitgevoerd met de seed vastgezet?”
QA: „Het mislukt alleen in CI. Nooit op een ontwikkelingscomputer.”
Vragen die u zich het beste kunt stellen voordat u gaat stemmen
- Treedt dit lokaal op, of alleen in CI?
- Hoe vaak gaat het mis — 1 op de 50, 1 op de 5, om de andere keer?
- Wanneer zijn de problemen begonnen? Bij welke commit?
- Is de test onjuist, of brengt hij iets reëels aan het licht?
- Zet iemand het ondertussen uit, en tegen welke prijs?
Het verschil tussen ingenieur A en ingenieur B is geen meningsverschil over story-points dat door middel van een gemiddelde kan worden weggewerkt — het is een onbekende factor die moet worden onderzocht. Een korte, beperkte spike lost dit op; een heftige discussie doet dat niet.
Stem op een tijdsbestek, niet op een oplossing. Een halve dag om onderzoek te doen, en daarna een volwaardig artikel over wat u ook maar aantreft.
Zie het inschatten van een bug die niet kan worden gereproduceerd voor een vergelijkbare situatie, en veelvoorkomende fouten bij planning poker voor het inschatten van bugs op feature-niveau. Bekijk de andere praktijkvoorbeelden van inschattingen, of start een gratis planning poker-sessie zodra het onderzoek resultaat heeft opgeleverd.