• Organise
• Culture

Best practice in Issue Reporting

WCIDFY

Here at Brightec we schedule regular ‘What can I do for you?' days. Perhaps more commonly known as R&D (Research & Development) days. Read our article about why we changed the name and format of our R&D days.

One of the objectives for these WCIDFY days, is to tackle some of the bigger or trickier challenges that we face as a team and work together to research, plan and facilitate solutions.

Together, we list the current issues and challenges before us. We discuss the ideas raised and decide on a few that we all feel are the most pressing. In the same way that we plan Sprints, we agree on an achievable list of tasks that can be completed in the allotted time.

Issues with issues

During one of our recent WCIDFY days, one of the tasks we identified as ‘high priority’ was our issue raising process. We effectively raised an issue about our issues...

It is the nature of what we do, and is true for all development teams, that issues will be present in the build we send our clients. Not the final build of course but when the initial development phase is complete.

We are proud of our professional approach to raising and dealing with development issues but we felt it was time to improve this further.

The old issue reporting process

We had been using a Google form; asking our clients to answer questions, specially written to break down the core information we’d need to replicate the issue.

We’d then transfer this information into Jira tickets that our developers would work from. We follow the same process for user stories during the development phase.

The standard format is laid out below:

Summary - A title that was short but detailed enough to provide the essential issue information and where it appeared within the app

Priority - Blocker, Major, Minor or Trivial (Design inconsistency)

Environment - We need to know what make, model and operating system of the device the tester was using

Description - A brief outline of what happened and why it is an issue. We suggested screenshots but they couldn’t be attached so clients had to email these in separately (as you can imagine this could wind up in a horrible jigsaw of images which somehow had to be deciphered to match a report that had been submitted).

Steps to recreate - A clear list of actions that led up to the discovery of the issue to enable us to replicate the same issue

Expected behaviour - What was expected to happen. We need to know what the client expected to happen so that we could understand why it was an issue.

Issues with the issue process

Some clients completed the form half-heartedly, not realising the importance of providing all the information we’d asked of them.

We’d go back and forth, asking for the Issue to be resubmitted, hoping to eventually weedle all the information out of them.

Each delay in communication stunted progression on the issue as we waited for clarity or uncovered another missing piece of information.

Other clients side-stepped the form and submitted their own reporting format as pdfs or emails. This was great - we had all the information upfront, in a clear and concise manner with the appropriate images embedded. But, we had to get it into a format that our developers could work from, which took time.

Fine-tuning required

The process worked but it needed improvement, we were sure there was a more succinct way for all parties to communicate.

We were keen for the developer and the issue reporter to be able to discuss each issue ticket individually, in one place eg. on our JIRA board, but our clients weren’t able to access this.

Once the client had hit ‘submit’ on that Google form, they were dependent on communication from us, whether it be an indication we’d seen the Issues had been raised or an update on how the developer was getting on with fixing it. We wanted them to be involved at every step and know exactly what was going on.

In some cases, we created spreadsheets with excessive colour coding to communicate the status of each of the issues so the client could see which needed more feedback from them and which had been resolved.

Did no other app developer have this problem?!

We wrote up a list of essential features a new process must have (you might have noticed these emerged in my explanation of the system we had) and spent the afternoon searching the internet, convinced that other people must have had the same problem and someone, somewhere, must have created a system that we could use.

There are plenty - but none that fitted our requirements. We took it back to basics, could BaseCamp work?!

We started the second WCIDFY day feeling deflated.

Nothing existed that could help us streamline the issue reporting process. Our sub-team openly reported our frustration to the rest of Brightec in the coffee-fuelled stand-up that morning. We left that meeting with scribbled names of suggestions to investigate.

Issue with our issues resolved

We were aware of Trello but hadn't considered that it could be used as a tool for this job.

Upon further investigation, we realised it wasn’t a ready-made solution but we could use and adapt it to make it work.

By the end of that afternoon, we had created our brand new Issue reporting system.

The way forward

From now on, each of our clients will get an invite to their own private Trello board to accompany the test build of their app.

The board has 8 simple columns, each a different status for example: Raised, Reviewed, Awaiting Development.

There are a number of template cards ready for the client to edit, each section of the card is a prompt for the information we need.

Finally, the best thing is that clients can now add screenshots and videos to an issue. The card can be moved across the columns to which visually represent the progress of each issue. Both the client and the developer have equal access, meaning they can both add comments enabling easy conversation which is attached to the specific ticket.

In under 12 hours that we’d set aside, we've set up a clear process that will save us and our clients time & hassle.

What's next?

Of course, we're now in the early stages of putting our process into practice. We'll be keeping a close eye on it and refining it where necessary.