We tend to judge software quality by whether an application works as the engineers and business managers intended...
it to. This approach cannot account, however, for the unforeseen changes users make to an app, the mobile device it runs on or hardware it works with. An app may be technically perfect, but developers typically struggle to predict how users will get stuck.
To better deduce how to improve software quality, expand the focus of testing from just technical requirements to the customer experience. Dissect customer complaints and seek to identify the root cause of a problem. Use this approach to create and even automate tests for prevalent problems.
It isn't easy. Users often don't know what caused their problem, so QA professionals need to figure out how to reverse-engineer a complaint to get to its cause. "Surprisingly, I haven't found others who do this," said Nilanjan Bhattacharya, DevOps delivery coordinator at Bulletproof Group, a cloud consultancy in Australia. Here's how to add reverse-engineering to your testing repertoire.
Identify customer frustration
Software testing is a guessing game, like Pictionary, where one player draws a picture to describe a card and others try to deduce what the card says. Like most games, you get better at testing the more you play.
Software testers can improve their reverse-engineering skills by analyzing the potential root causes of a wide range of customer complaints. You also, need to expand your definition of a defect to truly figure out how to improve software quality.
"If a customer experiences even a hint of discomfort or irritation when using the software, and I hadn't considered that possibility, that is a shortcoming or defect in my thinking," Bhattacharya said. Testers should spend time on customer support forums, analyze the types of complaints handled by support personnel and watch how live users get stuck as they navigate an application.
From those observations, create a list of the ways an application typically creates customer frustration. Modern applications frequently consist of a variety of hardware and software components, so work with others in development, UX and customer support to cultivate these reverse-engineering skills across your company. Try reverse-engineering the problems of a hypothetical app or business process, such as the examples below, before moving to the company's existing applications.
Practice on a simple app
Imagine an app that organizes photos, and a user is struggling to run it. The software testing team can identify the most important factors that feed into the user's experience, including how the app consumes photo data, how this access is authenticated and how the app informs the user that they are consuming data from a particular source, like Dropbox or Google Photos. Testers can use this information to design app performance tests to ultimately improve software quality.
Another user of this fictional application complains that they cannot find newly captured photos in the app. Testers now know to focus on how data gets into the system. Is the location of a new photo automatically managed by its associated metadata, such as date, time and the device it was captured on? Is this process prone to break down if the user adds photos through a scan rather than upload? Testers can inform the developers of these problems, and suggest improvements to the software, like a feature that would enable the user to add metadata through other means.
Testers should continue to explore how to improve software quality with this photo app. Maybe users encounter issues when they back up their photos or move them to a new phone. So, if customer support personnel has to coach users through the app directory that organizes photos, a tester should take note. Consider how photos can move without the users needing to understand how the files are organized in a directory structure. The answer could lie in a date range feature, or another solution.
Edge cases are still test cases
Don't discount the edge cases, such as when a meaningless message pops up due to corruption in the indexing database that organizes the files. The corruption could stem from a broken network connection, a problem with compression or someone removing a flash drive at the wrong time; imagine unlikely cases like these. People inexperienced in testing are often bashful about corrupting data, Bhattacharya said, and that hinders software quality. This step is a good time to recruit hardware experts, who might notice problems missed by software developers and testers.
Software users can be very non-technical, Bhattacharya pointed out. To get higher software quality, particularly a better customer experience, QA teams and developers should approach the technical details with a non-technical mindset at first. They might realize the problem isn't about data capture processes, for example, but simply about a better user interface to direct the customer to photo storage options.