OK, I get it. You have an excellent team of developers, designers and project managers. You develop a great piece of software for a client. And you test it. Of course.
That is one awesome application. But then, when the application reaches the client’s end, bugs are popping out everywhere. Boom.
Despite all your best efforts, bug reports are coming in. So what’s the issue here?
With all these emerging new devices – from mobile devices, to wearables, to VR, to smart devices – having a proper bug reporting workflow in place becomes quite a challenge.
Building web applications in particular might seem quite painful due to the different screen sizes of the used devices. It can even be worse than testing native apps for the Android ecosystem.
In this post, I’d like to show you different ways of setting up your bug reporting workflow. Including manual, automated and crowd-sourced workflows.
You’ve done everything right. You’ve instructed your testers and QA agents, you’ve set up an easy-to-use bug tracking tool and a testing suite for your project. And then it happens.
Bad bug reports happen to the best of us, and, unfortunately, they can happen often. So, we at Usersnap put our heads together to think of the most common bug reports and ways how to avoid these bad bug reports.
I recently talked with someone comparing bug tracking to solving criminal cases. And I think there’s a lot of truth in it. Like police inspectors, we as developers rely on evidences which we gather through asking the right questions. A well-executed bug reporting strategy will bring answer to these questions.
In this post I’m going to show you four essential questions I wish every bug report answers.