Welcome Back To Our Unit Trust Discussion!

OK! Over the last few weeks I outlined and fleshed out the basics of my Unit Trust system, a system that is intended to help visualise risk. Then last week we got just a little mathematical, nothing crazy but when considering all of the units and various factors, there was a large volume of this simple maths. This week, I’m going to explain how I tie it into Jira and have some scripts do the leg work!

The Trust Tracker

The more I work with Jira, the more I want to try to push it to do things other than tracking work. It’s got a lot of customisation options and an API so it can be a pretty powerful tool. I needed a way to store how often a Unit had been tested and I decided on using Jira and this gave birth to the Trust Tracker.

It’s kind of a “silent” project, working away in the background alongside other projects, tracking, storing and linking data. It has two Issue Types, the Epic and the Trust Tracker.

Now, I structure my Test Cases in a way similar to what I picked up during my years in Compliance, where the Test Suites are grouped into higher levels. My highest level Test Suites are Generic, Design, and Other and these become the Epics in a Trust Tracker project.

I’ve just realised I haven’t mentioned my Test Suite structure yet and so I’ll cover it at a later date, probably in a QA Intermidiate series but for now, the Generic Suite is a suite of Test Cases that can be applied to most games and are written in a very high-level manner to facilitate this. The Design Suite contains Test Cases specific to a singular project and the Other Suite contains more “throw-away” Test Cases e.g. Tests that fall in neither Generic or Design but need to be tracked for a short while.

Within those Epics are all of the Units we want to track in a given project, they have a workflow that has the statuses Untrusted, Credible, Reliable and Trusted (i.e. the UCRT Rank) and a couple of custom fields to allow them to store the UCRT Level as well as the associated Test Case.

It’s a simple custom Jira project but it does the job well!

Why Though?

Why a Jira project and not a spreadsheet for storing the data? Well! Jira just uses a database like a “spreadsheet” anyway but presents it in a more user firendly manner. A user friendly manner that most game devs will know their way around. It also has these bonuses:

🔹You can attach automation “buttons” to Jira issues.
🔹Each issue/Unit gets its own URL that you can link anywhere.
🔹That link, when used elsewhere in Confluence or Jira, will generate a widget that will show the Unit’s current status.
🔹You can see all the Units on a nice UCRT columned kanban board.
🔹All of our bugs are in Jira, meaning we only need one set of authorisation tokens in our scripts.

Don’t forget, our Trust Trackers are just for storing data, not for visualising it but even so, there’s benefits to storing this data in Jira and not just a database.

Maintaining The Trust Tracker

This is where we start getting a little nifty with some scripts! Right quick review, the Trust Tracker stores the UCRT Level and a project’s Jira stores all of the bugs.

Now we have the following stored in Jira:

• How often a unit has been tested?✅
• How often bugs are found in that unit?✅
• How severe are the bugs being found?✅
• How many bugs are still open in the unit?✅
• How quickly are bugs being fixed?✅
• How deep is the coverage of the unit?✅ (This is calculated based on the Test Suites, i.e. the Epic)
• How often is it not testable?✅

That leaves us with only “What stage of development is the unit at?”, which we will come back to at a later date, but for now we’re all set to automate!

I started off using Google Apps Script and I am now currently using node.js for automatically maintaining the Trust Trackers and I have it setup in a way that any tester can use the app to maintain the Trust Tracker. Here’s the process:

1. Tester completes their checklist.
2. Tester ensures all bugs are up to date from that round of testing.
3. Tester goes to a web app URL.
4. Tester enters the name of the project their working on.
5. Tester selects their checklist.
6. Web app creates a table of units in the checklist.
7. Tester confirms which units were tested.
8. Tester confirms which units had new bugs.
9. Tester clicks submit.

And that’s it! two drop downs and a few checkbox clicks. Then the script does all the hard work i.e.

• If a unit was not tested, nothing changes.
• If a unit was tested but no new bugs were found, UCRT level is reduced by one, existing bugs are re-assessed and the UCRT Rank may decrease/increase dependant on fixes or unaddressed issues.
• If a unit was tested and new bugs were found, UCRT level is increased by one, existing bugs are re-assessed and the UCRT Rank may decrease/increase dependant on fixes or unaddressed issues.

It does this by using Jira’s API to gather all of the information required, then performs that little bit of maths for each and every Unit which results in a score for each unit that it can convert to a rank and then finally, via the API again, update the status of each Unit tested in the Trust Tracker.

---

Almost THere!

Thanks for sticking around to read this series on my Unit Trust system. I think we’re one maybe two more posts away from completing the picture!

And hopefully, that picture is now starting to take shape in your minds. We’ve got all of our data organised and store in an accessibel format that is simple to maintain. Next up, we have to make it shareholder firendly!

Next week, the Dashboard!

Take it easy!

---

P.S. I said “maybe two more posts” because I get the feeling that this whole system may be difficult to visualise so I think that for the post after the next, we’ll wrap it all up with some beautifully artist flow charts!