Testing tickets and housekeeping
Fran García-Linares & Isabel Racine
March 2020
Agenda (30min)
GOAL
Team alignment on processes.
If we all "talk" the same language we'll understand each other better and tickets will flow more efficiently.
1
2
3
4
The problem
The side effects
The solution
Q & A
The problem(s)
Reality check
- The number of projects has grown (+50 and more to come).
- The number of people has grown (+10 devs, +4 PMs).
- The number of tickets has grown.
The problem(s)
- Some tickets can't be tested on other environments different to prod.
- Smoke testing sometimes is not enough.
- Unneeded communication that adds additional time and effort.
- Tight budgets.
- Quality suffers.
The side effects
If testing is done poorly or omitting certain steps this creates:
- Longer ticket cycle time (although you might be doing ^^ for the opposite reason)
- Confusion
- Additional steps (unneeded communication)
- Follow up tickets
- Site being down
- Unhappy client
- Unhappy PM
- Unhappy developers
- Poor quality or quality control
The solution
#teamWork #processes
Testing tickets process is really important and paramount to ensure quality.
ESTIMATIONS (quality control starts here!)
Developer checklist:
- Do I know the project?
- Lagoon / legacy?
- D7 / D8?
- Features?
- Fudge factor?
- Do you understand what the problem is clearly?
- Do you know what needs to be done?
- Can you do an estimate? Best case vs worst case vs just-in-case
- Factor in time for testing, time for code review and time for feedback if expected
- Do you feel comfortable with your estimate?
- Can I bounce tickets back?
The solution
#teamWork #processes
Testing tickets process is really important and paramount to ensure quality.
IN PROGRESS
Developer checklist:
- Does the ticket read well and make sense to you?
- Does the estimate look ok to you? Any follow up questions?
- Strive for quality, not for estimate
- Check prod site for config changes
TESTING
Developer checklist:
- ACs marked as (i) ?
- FULL deployment instructions?
- Review code
- Check functionality and if ACs actually achieved (if not mark them back as (x) )
- Check other pages (smoke testing)
DEMO
Developer checklist:
- ACs marked as (/)?
- Read and address all comments from PM (and/or client)
- Keep deploying feedback changes to `dev`
DEPLOY/CA
Developer checklist:
- Before merging:
- Check config on prod
- Check prod branch and merge into yours if needed
- After merging:
- Manual steps
- Check config
- Click around the site
It is ok to bounce tickets back to people if something is missing. This is quicker than guessing...
The solution
#teamWork #processes
How should feedback be given in tickets? Thoughts on this...
- Normal comment when appropriate
- AC list style might be useful for specific actions
After each comment, it should be clear:
- Who is the comment addressed at (tip: use `@user`)
- What the actions should be from that person
This is key in our async set up, we shouldn't rely on people being online at the same time and this should be ok and not a blocker. #weWillScaleUp
Q & A