Het inschatten van een onbetrouwbare test
Hoe u een onbetrouwbare test kunt inschatten: waarom het om twee schattingen gaat, en niet om éé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.
De ene versie betreft een oplossing van slechts één regel: een aanname over de timing, een afhankelijkheid in de testvolgorde, een ontbrekend elementawait. 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, en dat is nu juist de onbekende factor.
Door vooraf in te schatten hoe groot iets is, in plaats van achteraf, komt dit verhaal in week één op 5 uit en in week drie op 13. De oplossing ligt niet in een preciezer getal, maar in een andere aanpak van het werk. Stel een tijdslimiet vast voor het onderzoek en maak vervolgens een inschatting van de daadwerkelijke oplossing zodra de aanpak duidelijk is.
Wat er in de kamer wordt gezegd
Ingenieur A: „Als het om de reden die ik vermoed onbetrouwbaar is, dan is dit een 2.”
Ingenieur B: “Als het om de reden die ik vermoed niet betrouwbaar is, 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 het waard zijn om te stellen voordat u gaat stemmen
- Treedt het probleem 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?
- Zijn er mensen die deze functie ondertussen uitschakelen, 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 vervolgens een volwaardig artikel over wat u ook maar ontdekt.
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 functieniveau. Bekijk de andere uitgewerkte schattingsvoorbeelden, of start een gratis planning poker-sessie zodra het onderzoek resultaat heeft opgeleverd.