Quality assurance traditionally entailed only of teams evaluating the code and ensuring that nothing was breaking or performing abnormally. In these setups, there wasn’t time to worry about how end users would take it, it just mattered that the app would work. However, in today’s world of endless software, quality assurance must make the customer the priority driving their work. Thinking like the customer is going to be crucial for QA teams for a few important reasons:
Uncover gaps in understanding
Development and QA teams must work together to create the best solution for their users, but they can only operate on the information that they are given. Before a project begins, teams meet with stakeholders and the customer to discuss requirements and answer any initial questions. However, if the groups come out of this gathering without all of the data they need, that could lead to major issues in design and functionality.
TechBeacon contributor Joe Colantonio suggested using domain-specific language to communicate in the same terms as the user. This will help create a more meaningful conversation on both sides to identify ambiguities or misunderstandings before teams start working on the code. Changing areas of an app can be expensive, so it’s essential to have all of the specifics fleshed out before the real effort begins. Thinking like a customer in this way also enables QA to fully visualize what the user is looking for and what types of tests should be created to ensure that deliverables are thoroughly assessed.
Deliver true value
It’s a common issue that developers and testers do more work than they need to, or they complete items that may not add value to the project. These efforts take up additional resources that need to be used for essential efforts within software creation. However, it can be difficult for teams to know where to draw the line and when they have created enough tests for their set. StickyMinds contributor Paul Fratellone suggested reviewing the approach and risks with stakeholders to identify any excessive testing as well as the risk associated with the strategy. By understanding the greatest risks, the number of test cases and how long it will take to deliver quality to the user, organizations can assess their costs and make plans to work off these numbers. With this data, there should be no surprises when a tough decision appears, and teams can be prepared to quickly take action. This will help deliver true value to the customer and demonstrate QA’s viability.
“Reliability, usability, and accuracy will manifest in the number of test cases and techniques used to satisfy the level of quality that the end-user is expecting and on which the business owner must plan to spend,” Fratellone wrote. “Complete transparency enables the team to make sound business decisions and decide on appropriate levels of risk and tradeoffs when plans are not being met.”
Discover possible defects
Testers understand by now that not all defects can be found. However, teams should still use capable quality testing tools and processes to discover as many as they can. With automation and other setups, tests are only as smart as we program them to be, meaning that there could be gaps in coverage. Relying only on repetitive scripts would open a lot of risk to businesses and their development projects. Instead, QA should aim to use exploratory and manual testing methods to break the system the way a user would. Software Testing Help noted that QA must be aware of what happens on the customer end if they enter the wrong information. If the app responds in an unexpected way, it’s integral to get this fixed before it is delivered to the user.
In these situations, it’s critical for QA to drive the initiative and fully think as a customer would. Computers cannot think subjectively and might not see the same errors that a person might. This applies to things like the user interface, navigability and overall feel of the application. Test automation frameworks might clear the code, but there could be glaring issues with how the software looks or how one function flows to another. By thinking like a customer, QA can uncover these flaws and deliver true value, building better user relationships.
QA must try to break apps in the same way a user might.
