Cayne's QA Blog

“Someday, someone may experience these bizarre events. Hopefully, they will find my notes useful.” – Harry Mason

Blog Roll | About | Table Of Contents

Submissions to Sprints – Pt. 2

The Open For Test (OFT) Trello board. The idea was to emulate a “submission” into certification, but instead of testing an entire game, we’d test individual features. Each feature had its own versions, its own bug reports, and by using a Trello board, I aimed to mimic the publisher’s perspective during a certification process.

The goal? To create a mini feature certification department, all in one. Or so I hoped…

Looking back now, I can at least say this—it looked cool! It was also quick to set up, kept things organised, and the fundamental ideas were there—but the all-important data was too difficult to analyse. No one is making quantifiable risk assessments with one of these! And since it’s a Trello board, it wasn’t going to align with a sprint in Jira.

So let’s dig in and review.

The setup

Firstly, I read through the Game Design Document (GDD) and made a Trello card for every feature.
Then to organise them I:

  1. Created lists for possible phases.
  2. Added colour-coded labels to signify feature status.
  3. Added checklists to track what had been tested.
  4. Linked Jira bugs via checklists for easy reference
  5. Logged GDD summaries in the descriptions.
  6. Logged tested builds in the descriptions.

The end result? Something like this:

How it worked

It was pretty simple, really. Everything started off in the “Design” phase. When a dev team member needed something tested, they dragged the card into the Open For Testing column, filled out a checklist, and gave me a nudge!

When I was ready, I moved it to In Test, went through the checklist, and logged any discussions with the dev in the comments for future reference. Bugs went into Jira, and I linked them back to the Trello card so the Checklist icon showed how many bugs were associated with the feature. I also applied a colour label to indicate the severity of the bugs.

The idea was that for example, at a glance, you could see:

  1. Level 2 is in the prototype phase.
  2. Three items have been checked.
  3. Three open non-MF bugs (orange label for severity).

Why It Didn’t Work?

I still like the simplicity, but risk assessment was basically guesswork—like:

“Ooooh, the UI looks a bit risky. It should be at Alpha, but it has eight open Showstopper bugs (purple label)… maybe the dev needs more support?”

That, and the fact that those checklists became HUGE, made me rethink things. It wasn’t scalable, and I needed a better way to analyse data. I also wanted to integrate testing more closely into the sprint process, making it a seamless part of the dev team’s workflow.

What’s Next?

While the Trello board was in use, I leveled up in Jira workflows and automation—and from that, the QA Jira was born.
That’s what we’ll look at next week!


Thanks for taking the time to read this! I’d love to hear your throughts on the Open For Test Trello board – don’t hold back, share the criticism!

One response to “Submissions to Sprints – Pt. 2”

  1. […] your mind back, (or if you were never there, go back (link)), to the Submissions to Sprint series where we discussed “Why It Didn’t Work” and […]

    Like

Leave a comment