One problem that plagues both developers and QA testers is how to communicate the steps necessary to reproduce bugs in an application or piece of software. There can be a lot of back and forth in order to figure out the exact circumstances to reproduce an issue, which slows down the process of finding a solution. Sometimes it’s not easy to remember exactly how you got the problem point from the QA testing perspective. A lot of factors can be forgotten when writing out the steps that are required for the devs to see the problem. The worst case is when there is an issue on production that no one caught. Even when using comprehensive analytics data to track the issue can be difficult to figure out. Thankfully there are tools that can assist with these issues, unfortunately they are not universal, but they are very helpful when they can be used.
A Great Way to Test Step Clarity
The first browser based tool is really helpful during the QA process. Smashtest is a Chrome extension that reduces the amount of work for the QA tester to write testing steps. It also helps the developer when they try to follow said steps. Once installed, it records the actions of a user into an easy to read list. Smashtest records everything action that happens in a tab, from things like changing pages to what’s typed into a text box.
Example 1: History Mode
After the steps are recorded is it not only easier for a developer to read through the steps and reproduce the issue, but they can also see the exact process for themselves. The extension has two modes: the first called history mode (which was described above), and the second is sandbox mode.
The sandbox mode allows you to take the instructions created in the history mode and walks through them in the browser so you can debug using the exact same actions. This can cut down on a lot of confusion between the different teams which, oftentimes will increase the time it takes to develop a fix for an issue.
Example 2: Sandbox Example
What if you Could Watch Over your Customer’s Shoulder?
Once the package has been installed and properly initialized in your project, the tool records the user’s actions within the session. It also has a very impressive dashboard that allows developers to see when errors occur and debug almost as if the issue happened in their own browser. This includes access to the dev tools (including the logs/network console) and a recording of the actions taken by the user. It’s almost as good as if you are standing behind the user and watching them interact with your site. The sessions can be sorted/filtered by a variety of criteria from locations details to a variety of different user details. This tool can not only improve the bug fix process but also be integrated into improving your live chat functionality since you can watch the user’s actions and not just rely on their descriptions.
Example 3: Log Rocket Amazingness
The root issue we are trying to solve with these tools is an issue with communication between developers and those who are running into issues with their web applications. The tools mentioned in this post are just a few of the ones available to developers, and we feel they can help solve some base issues with the process.
Do you have other debugging tools that are working for your team? Let us know!