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

Made with Slides.com