Ik test een issue op DEV

In sommige projecten sluit een merge een issue nog niet af: de merge deployt naar DEV, en een tester controleert daar eerst of alles werkt. Met de handoff-instelling blijft de issue na /spexso-finish open en wordt hij aan een tester toegewezen.

Aanzetten (per project)

Voeg in .spexso/config.json toe:

"handoff": {
  "testers": ["jdoe", "asmith"],
  "fallback": "random",
  "skipTypes": ["maintenance", "spike"],
  "labels": ["Ready for test"]
}

Sleutel	Betekenis
testers	GitLab-gebruikersnamen die mogen testen
fallback	"random" (willekeurig uit testers) of één vaste gebruikersnaam
labels	Eigen labels van het project die bij de overdracht op de issue komen, bv. Ready for test. Optioneel. stage::-labels worden genegeerd
unlabel	Labels die bij de overdracht verdwijnen, bv. implementation: ongoing — zo staat er nooit twee levenscyclus-labels tegelijk op een issue. Optioneel
on	"merge" (standaard): de tester krijgt de issue meteen na de merge. "deploy": pas als de code op DEV staat — zie hieronder
skipTypes	type::-waarden die geen test nodig hebben. Standaard ["maintenance", "spike"]. Geldig: feature, bug, enhancement, tech-debt, maintenance, spike

Een issue zonder type::-label wordt altijd getest. Zonder handoff-sleutel blijft alles zoals vroeger: de merge sluit de issue.

Pas overdragen als DEV gedeployed is

De merge is nog niet de deploy: een pipeline kan traag zijn of geannuleerd worden, en dan begint een tester aan iets dat nog niet op DEV staat. Met "on": "deploy" beslist /spexso-finish alleen nog, en draagt de CI-job handoff-dev (uit de Flexso CI-template) de issues over zodra deploy-dev geslaagd is: alle gemergde issues sinds de vorige geslaagde DEV-deploy — ook die van een tussendoor geannuleerde pipeline.

Eenmalig nodig: een projectvariabele SPEXSO_TOKEN (project access token, scope api) — zie CICD-SETUP.md. Mislukt de overdracht, dan wordt de job oranje; de deploy blijft groen.

Wie krijgt de test?

1. Staat de maker van de issue in testers? Dan krijgt die de test.
2. Anders de vaste fallback-gebruiker, of bij "random" iemand willekeurig uit testers.

Je kan dit vooraf nakijken met npx spexso handoff <id> --dry-run.

Stappen voor de tester

1. Je krijgt de issue toegewezen, met labels stage::ship + needs::manual-test (plus de eigen labels van het project), en een comment Manual Test Checklist waarin je vermeld bent.
2. Test op DEV volgens de checklist (en het demo-scenario als dat er is).
3. Alles werkt? Verwijder needs::manual-test en sluit de issue.
4. Iets faalt?
   • Schrijf in een comment wat er misloopt (stappen, verwacht vs. gezien, screenshot).
   • Wijs de issue terug toe aan de developer.
   • Zet hem op stage::build (fout in de code) of stage::spec (de spec klopte niet).

Draait er een testserver?

Met npx spexso factory start --milestone <naam> --test test een testserver elke issue met needs::manual-test eerst zelf in een headless browser. Je ziet dan al een label op de issue:

• auto-test-success: de checklist slaagde in de browser. Kijk vooral naar wat een browser niet kan beoordelen.
• auto-test-fail: er is al één bug-issue aangemaakt met alle nieuwe fouten van deze issue, een screenshot en een link naar deze issue. Was een fout al gemeld in een andere bug, dan is de issue aan die bug gelinkt en wordt ze opnieuw getest zodra die bug slaagt.
• auto-test-skipped: niets op de checklist kon in een browser getest worden.

Verwijder het auto-test-*-label om de testserver de issue opnieuw te laten testen.

Wat gebeurt er bij een teruggestuurde issue?

De developer start opnieuw met /spexso-start <id>. Spexso haalt needs::manual-test en de eigen hand-off-labels weg, maakt een verse branch aan en geeft je comments (alles na de laatste checklist) als rework-context mee aan de planner. Na /spexso-finish komt de issue opnieuw bij een tester terecht.

TIP

Schrijf je bevindingen in één comment, concreet en reproduceerbaar: dat is letterlijk wat de planner te lezen krijgt.