Why the old system isn’t good enough
Bug tracking has increasingly expanded into the domains of the entire product team, not just R&D and for good reason. As software becomes complicated, it becomes more difficult to manage issues in excel sheets or post-its.
Need Process + Tools
Having an expensive tool for tracking bugs will not solve the issues by itself. Investing in extensive solutions like JIRA or Redmine, that require a setup with databases and servers, does not not guarantee a sure shot solution.
How the organization and team approach the process has a direct influence on the effectiveness of the setup.
Bugs are a headache for everyone
The teams that develop software and build products today are not composed merely of developers and quality assurance testers. There are many different stakeholders such as designers, product managers etc. Feedback from the end user is also a valued source of input in uncovering issues and the minutest problems are often discovered by the most ardent user.
By putting the onus of finding issues on just the quality assurance team, not only is critical time lost in capturing and reporting the issue but also in getting it in front of the right person to get the problem resolved.
What the present system should do
In the agile approach that has been adopted by most teams today, deployment and releases occur in rapid succession. Testing and QA cannot be put off to the end of sprints. Not only do issues have to be resolved quicker, their detection needs to be optimized as well. Hence, teams need to have processes and tools in place that not only allow identification of bugs but also foster efficient communication and collaboration.
Recreating the bug
The single, most important concern with any issue or bug that is reported is reproducing it. The bug report should ideally state what the problem encountered was as compared to the right functionality, and provide sufficient context for the developer. Having witnessed a bug, the QA tester scrambles to record the exact steps that led to it. But this conventional approach has limitations.
Chief among these is the loss of productivity on the developer’s end. The developer loses time recreating the issue, when they would be more productive if they had a live example of the issue. With a screen capture or recording of the bug, developers would, then, have much more time to actually fix it rather than reproduce it. If there’s a bug that is hard to recreate then having a live example can be even more helpful.
Another area where the conventional approach comes up short is if the bug is user reported. Asking users to record the steps involved is just not practical. It is much more easier for the user to capture their screen, attach the image, and send it as feedback. But then you have a screenshot that has to be processed from the customer support team to the developers or designers, and it is just not efficient at scale. There are indeed many tools that provide the ability to annotate on issues and send them directly to developers.
Prioritization
Just like when prioritizing features during the development road map, issues and bugs have to be prioritized as well. When tracking bugs reported by users and your QA testers on a website or an application, the value of it has to be taken into account.
Co-founder of Trello and Fog Creek Software, Joel Spolsky, mentions in one of his articles that, “Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it. While he does list a disclaimer before people brand him as someone who does not care about fixing bugs, it is worth noting what is the value provided to the health of your system or the user’s experience when you tackle a bug.
Certain issues are critical to track for the health of the system. Irrespective of whether they translate into direct use for the user or not, these critical issues need to resolved. On the other side of the spectrum, certain issues while not as critical to the system are important on the user side and that necessitates dealing with them pronto.
Accessible to the entire team
The only surefire way to guarantee bug-free software is to prevent their creation in the first place. Preventing bugs starts with communication and collaboration between product management, design, development, and QA.
Given that different kinds of stakeholders work on a project, the tools and processes setup to counter them should be equally accessible. Wikis and issue tracking logs are still useful but they cannot work end to end on today’s projects, specially with web applications becoming more graphical than ever before. Couple this with the fact that teams are incredibly agile and you will see why only conventional issue trackers like JIRA or Redmine are not enough.
In the move fast-break fast approach, every stakeholder has a role to play in making sure that no issues plague the application. This is why having more accessible tools like zipBoard enable everyone to contribute without setting up a database or installing more software.
Organizing and filtering through the issues
With users and internal team members both chiming in to share feedback and report issues, managing the sheer volume of it can become a task in itself. Both with internal and external feedback, you need to first and foremost classify the feedback into issues or feature requests.
Help desk software, Groove’s team was facing similar issues and at one point were severely overwhelmed with the volume of things coming their way. Backlogs were piling up and teams were starting to get stretched beyond what they could manage. The were spending more time trying to get the workflow right, to manage the chaos, rather than actually working on the issue itself. Getting the workflow right is so so vital. If you don’t fix this in the beginning, it gets completely out of hand as the feedback starts to mount.
The solution that works for our team is having one central platform for organizing everything. Apart from prioritizing feedback, assigning issues to the right person, sorting them into the right category, capturing metadata etc. are important to manage the volume of issues and bugs. Tags are another useful way to sort and organize issues so that teams can quickly filter through them.
Usability
Every product and service today has an interface that is the primary source of interaction with the users. Users interact with products via a number of different devices. This means optimization for mobile, fitting screens to different resolutions and sizes, and making sure that your website or application works in a host of different environments.
To give some perspective on the kind of variety available when it comes to devices on which applications can run, there are 8,075 certified Android devices that the iA Writer for Android application supports. Android in itself comes in 14,290 types of phones and tablets. Imagine the number of screens you have to develop and design for, when you throw in iOS, different desktops, laptops etc.
Responsinator and Browsershots are some of the nifty tools that give you a quick glimpse of how your applications and websites look across the prominent screen sizes and browsers. Soap opera testing is one of the go to methods to uncover issues in responsive web development. Besides just the layout, elements that have to function uniformly across environments are colors, fonts, buttons, links etc.
The variety in access is not just in devices but in people too. Many applications need to be translated for different countries and demographics. Often changes in language are accompanied by changes in design and structure.
Information architecture, themes, audio, images, navigation — all these are elements that need to be reviewed in localization. One of the most common pitfalls that teams face is that the layout/UI is designed for English, and when the language is translated, phrases and text end up taking vastly different amounts of space than expected. This makes the design seem incoherent.
When text is placed directly in the code, it becomes a tedious task to change it in all the different language instances of a project. Instead, if separate resource files are used, then a singular instance of the code can be translated to different languages and the changes do not have to be recurring.
Conclusion
In large scale organizations, there’s an entire skeleton that supports development efforts so that issues do not go undetected, and yet they do sometimes. But smaller teams do not have the same kind of resources available, both in terms of technology and time. For such teams, having transparency in processes that makes things simple is the priority.
Teams that still use Excel sheets and post-it notes to track issues are not using the optimal approach. What they’re attempting to do is not only track issues but collaborate and communicate over changes. But doing so via an Excel sheet get extremely tedious. The sheer volume of data that has to be managed gets overwhelming and that decreases the pace with which teams can tackle bugs.
To have a lean setup, teams need tools that get the job done but do not increase overhead in doing so. This is why collaboration tools that provide context and make communication easier for everyone on the team are extremely useful.
You can find more such articles on the zipBoard blog.
Top comments (0)