Bug reporting is a skill that everyone in the software development team should have. It helps to build the application while making the process shorter, more efficient and cheaper as a result. Dedicated quality assurance (QA) team is a must but there are ways to teach developers and other specialists the art of bug reporting. How to make a good bug report?
While QA specialists are trained and look for bugs on purpose, everyone else can be treated, at least to a point, as a user. QA team is the best example of that because they just try to use the app. At the same time, they cherry-pick features and try to break them to see if anything stick and if there’s a problem. These two viewpoints – developer that know the app best and a QA member that works in a “detective mode” so to speak, complement each other immensely.
The key to successful application building lies in communication
Like everything in life, being able to send and receive messages is vital. Same goes for software development. Other members of the team should understand the problem and being able to mitigate if for the future. If the bug repost isn’t clear enough, the work is not done properly.
Clear messaging, as well as precision, is very important. Don’t be afraid of simplify things for others to understand. Nobody is writing a novel for the Booker Award. It’s the ability to understand the problem in a timely matter is what saves the day.
Being unclear in the bug ticket prolongs the day for everybody. At the end, it can even generate additional and high costs, due to failure to understand, replicate and fix the bug. Furthermore, the bug will probably remain unresolved.
When should you report a bug and what are the stakeholders?
Naturally, bugs can be found at any moment in the Software Development Life Cycle (SDLC). A QA Specialist or any other member of development team should report it immediately. Partially because it’s cheaper that way moving on (bugs won’t generate other problems and pile up), but mainly because it’s efficient. Project Managers (PMs) can estimate the resources needed to address the bug and allocate time and manpower.
There are few stakeholders to think about. Software developers being the most obvious one. As a group actor, they move with the flow. A particular bug fixing could be addressed to a specific member of the team. Alternatively, each developer can pick and choose the bug from the list.
QA members are also important. If something is reported once, there is little chance the report will be duplicated elsewhere, wasting team’s time. Awareness is also relevant. By reporting a bug, other QA Specialists will know about the issue and look for a similar problem or expand on the existing one, searching for additional problems generated by this bug.
Project Manager is vital for operations. If the bug is complex and demands allocating multiple developers, a PM is the right person for the job. He or she will assure proper steps and assign countermeasures to various developers.
The last important piece of the puzzle – client. The client is usually involved if the bug is found after the release and potentially prevents the app to receive updates or is major enough to cause trouble in the prolonged period of time. The client must be informed about the situation. He or she also needs to know the steps and timetable for fixing the issue.
The difference between a good and bad bug report
Finding and reporting a bug isn’t enough. To understand what’s going on, the developer reading a bug ticket needs to understand the bug and the context, as well as steps to replicate the issue. The final part of the equation is the ability to anticipate the result. In other words – what will happen if we can’t fix the bug.
That’s where “street lights” comes in. Red stop, yellow prepare, walk on green. If the matter is urgent and breaks the app, then the bug is critical. If it’s significant, then it should be marked as important. Minor bugs are last in the queue.
The well-composed bug ticket means that the problem can be addressed in the reasonable timeframe, saving time and money. It also builds a developer – QA relationship built on quality and trust, which is invaluable in software development process. A good ticket allows re-testing the bug and maintains realistic product deadlines.
Bake or break – the recipe for clear bug reporting
In reality, bug reporting is like following a recipe. There are few ingredients and you should follow it. If proportions are wrong or something is missing, the cake can’t be made.
Acknowledge that you have found the bug and assign the proper developer to fix it. Most quality tracking apps like JIRA will take care of this for you but assignment is important. If you know who was responsible for what, pick a developer. If not sure, let Project Manager handle the case.
Describe the problem thoroughly. Sometimes even the title fixes the bug; it’s that obvious. In most cases, the proper description sends developers on the right path. Be sure that the title is clear enough to know what’s the problem and description is top notch. Build a context for the bug (more on that in a moment).
Prepare a list of steps to reproduce the bug. The most critical step of all. Sometimes people are vague in this regard. Describe, step by step, what led to the bug occurrence. What user behavior did you display while using the app? What did you do or not do? Do not assume people know about the bug from talks in the kitchen over coffee. Describe the problem the best you can and don’t skip details.
App’s behavior after reproduction. Also, very important. Sometimes product behaves differently before and after repetition of the same procedure. Focus on the reproduction steps and figure out, to the best of your knowledge, what makes the app act differently. Describe how the system works and how it should work under normal circumstances.
Severity & priority. The bug can be critical, major, minor, or trivial. This dictates urgency and conduct. If there are many bugs in the backlog, a bug triage meeting should be held that includes the Product Owner or Project Manager to review the severity and priority that is assigned. Medical reference is pretty useful one – after all, we want to heal the app!
Environment & devices. On what device did you test? For how long? What software was installed? In what version? From your experience – did the setup could affect the bug occurrence or reproduction? What operating system was on at the time, in what version? All these information is critical for reproduction of the bug.
Version-related context. What version of the app itself, and surrounding ecosystem was installed during the testing procedure? What operating system? This helps developers track the bug down to the last released version of the code.
Summary
In theory, everyone knows what they are doing and supposed to do. In real-world scenario, bug reporting if often missing context or other vital information. At Code & Pepper we prioritize apps’ performance and security, UX/UI but don’t forget about overall quality.
No matter if you want to build FinTech product from scratch or hire software teams for augmentation purposes. We got you covered. Quality goes hand in hand with performance. We stand out by making it happen every single time.
