Products are ever-changing. And if you're like us, that means constantly pushing out new features and improvements.

But with those updates and changes comes the inevitable risk of bugs. And the best way to find and fix those bugs are your internal reporters and developers: your copywriters on the lookout for wonky content, your QA testers that find a broken form, designers that spot a font size five times too big, or your customer support team that receives word of billing issue blocking customers from paying.

And of course the developers – the ones actually tasked with fixing the issues.

But getting the whole team to report bugs into GitLab can be hard.

Reporters take forever to send actionable feedback to developers, who in turn don't have the information they need to smash those bugs.

So what can you do to make sure everyone can contribute?

alt_text
Source

Speed up workflow for internal reporters

Ideally, your bug-reporting workflow is a well-oiled machine and everyone can quickly share their feedback directly into a specific GitLab project.

But, because reporters aren't always super tech-savvy, it can be tricky for them to share reports that are helpful for your developers. The process is long, complicated and tracking down the crucial technical information isn't always easy.

In most teams, reporting bugs into GitLab looks like this:

  1. Find the bug
  2. Open screenshot tool, capture bug
  3. Open software to annotate screenshot, add comments
  4. Open and log into GitLab
  5. Select the correct project
  6. Create new issue
  7. Document the bug (How do I do this!?)
  8. Add technical information (What is this even?)
  9. Attach visual screenshots
  10. And then finally: submit report

That's a whopping 10 steps to report even the smallest bugs.

And we didn't even mention the super-fun scavenger hunt reporters have to go on to identify all of the environmental data developers need to even start thinking about fixing the bugs.

Source

But don't worry, that's why we created Marker.io, to speed up and simplify your team bug reporting. Now 10 steps are only 3.

  1. Capture and annotate screenshot of bug
  2. Send bug reports straight to your GitLab project
  3. Keep hunting for more bugs!

One real-life example is an issue we ran into with our pricing page a while back. During our QA process, we noticed a weird bug: the price for our Team Plan was mysteriously missing. Instead of using the lengthy process mentioned earlier in this post, we used Marker.io to quickly send feedback to our dev team and get the bug fixed in no time.

This is what reporting the issue with Marker.io looked like:

alt_text

Now, not only is the process much faster, but the best part: you never had to leave your website, you've nothing to configure and all the technical data the developers need is automatically captured by Marker.io.

Actionable reports for your developers

Developers get feedback flying at them in all forms - emails, phone calls, sticky notes and screenshots.

They're ready to gouge their eyes out because they can't reproduce the reported bugs.

Because developers often face tight deadlines and in general don't have a lot of extra time, it's super important they don't have to spend unnecessary investigating the bug reports they receive.

The reason they end up doing this is because they're not receiving actionable feedback from the get-go. Whether that means that reports include too much irrelevant information or too little crucial information.

Once a visual feedback tool like Marker.io is introduced into the equation your developers can relax.

alt_text
Source

They can choose where they receive feedback, down to the specific bug-tracking GitLab project, and the important technical data they need is automatically included in every bug report.

That means environment data, including:

  • Source URL
  • Browser
  • Operating system (OS) and version
  • Screen size
  • Zoom level
  • Pixel ratio

Here's an example of what a Marker.io bug report looks like in GitLab:

alt_text

This GitLab issue has all the information needed for your developers to act on it:

  • The issue is in the correct project
  • Any pre-set epics, milestones or labels are included
  • The issue is assigned to a team member
  • The annotated screenshot is attached
  • The expected and actual results are well documented
  • The steps to reproduce are detailed
  • The technical environment information is all there
  • The issue has the URL where the screenshot was captured
  • The issue has a due date

No more wasted time following up with reporters to fill in the gaps. It's all there, organised straight into your chosen GitLab project - complete with everything vital to fix your bugs.

GitLab + Marker.io = the perfect bug reporting workflow

Collecting actionable feedback doesn't have to be a painful process for your reporters or developers. Bug reporting can be fast, easy - and comprehensive.

By using a visual feedback tool like Marker.io, all you've got to do is capture your bug and send it straight to your specific GitLab project. Your bug tracking workflow gets a major boost and better yet, everyone on your team can contribute.

Want to try for yourself? Marker.io comes with a free 15-day trial. Give it go --> Marker.io/gitlab