When I first joined the team at GluFactory, one of the team’s largest pain points of the development team resided in the off-site QA team, which was located at Glu India in Hyderabad. But the Hyd team wasn’t incapable of their work or in diligent — far from it. What I quickly found, coming onto the team, was that there was a large disconnect between devs and QA testers 9.5 hours around the globe. Sometimes, testers would stumble upon features in the morning’s build that they had received no word prior about — and were not in yesterday’s build.

Features would enter the build and releases would be planned with little involvement of the off-site studio. Both teams were not working in synchronization, which hurt the quality of builds, bugs reported, and test plans on the off-site team.

With two teams thousands of miles away from each other working on the same project, the testers and the devs needed Alignment. Otherwise, one hand wouldn’t know what the other is working on.

The team was using Jira Cloud when I joined, but I noticed there was no implementation of Confluence. Almost all documentation was done via Google Drive, and despite some pushback — I made a case for a situation in which Drive and Confluence could coexist peacefully: Drive was for free-form documentation; things that were in-progress or viable to change. Confluence was for archival documentation, which could be accessed cross-team.

While there ended up being overlap between the two: one core component of Confluence ended up being vital in allowing the off-site teams to better understand the dev team’s schedule: Jira links and releases.

The teams both needed something brief and constantly-updating that each could refer to when asking the following questions:

What build is live currently?
What build is in development?
When will the build be code frozen? Submitted to Audit? Submitted for final audit? Released?
What are the bugs tagged for this release? What is blocking our launch?

Utilziing Confluence and its often-underlooked connection to Jira, I wanted something that all teams could take advantage of at-a-glance. A Cheat sheet to these questions.

What came about was the following, shown below (Portions are blurred out to respect NDA, but you can get an idea of the format and presentation)

A brief breakdown of the page’s sections:

Live Versions: It’s important that we keep track of which client versions of the game were currently live — especially as we would frequently have multiple versions running, as not all users would immediately update their app to the latest build

Currently in Development: This section answers the very basic questions all in one small table: What version is being made, when are our release plan dates, what the min spec is, etc. etc., so that we are communicating our release schedule across the entire team.

Release Tasks: This is where using Confluence becomes handy. Jira’s “releases” function is tucked away beneath a few menus, but using it efficiently allows for opportunities to easily align team members on what exactly was fixed in the upcoming build, ticket-by-ticket.

So, utilizing Confluence Cloud’s Jira connection component, I set up a table that would read all the issues off a JQL query which looks for issues in the corresponding FixVersion and bugs, automatically sorted by priority. This ended up being a great tool for QA, as they could review bugs from their end and quickly collate lists of issues that needed dev assistance in regressing — or easily link critical issues (Which were often times marked as “Launch Blockers”) to follow-up on and confirm fixes before ship.

Release Notes: This section is a bullet-pointed list of the high-level features that are going into the release, with hyperlinks to documentation.

While this section is super simple, having an easy list of what’s actually in the build and where to find any specs for it was critical for the QA team in developing their test plans.

Branch Link: When we enter bug hardening period, we always cut a release branch from our core development branch in GitHub, and begin working in there. This was a quick link to the Branch page on GitHub, which allowed an easy view of the commit history.

Having these pages proved useful; while we were asleep, the team of 4 QA testers, 4 engineers and a producer in Hyderabad could utilize this information to prioritize testing and any feature work delegated to them, so we would wake up in the morning with updates and possibly PRs or new issues in Jira.

2 Countries, 1 Team: Unifying a International Team Working in Parallel with "Release Cheat Sheets"