3 Keys to Testing for Real User Conditions
3 Keys to Testing for Real User Conditions
Delivering an awesome UX and UI means testing, but real user condition testing. Here are three fundamentals of real user testing, like defining the right users, adding user conditions, and fixing issues with reporting findings.
Join the DZone community and get the full member experience.Join For Free
If your company is taking steps to be a more digitally engaged business, congratulations -- you're on the path to innovation and success. But when trying to deliver high-quality digital products across mobile, web (mobile web, responsive web, desktop web), and IoT (Internet of things) on a variety of operating systems and networks, remember to stay focused on the all-important user experience.
Everything is driven by a winning UX: Business goals, customer satisfaction, positive app store reviews, word-of-mouth uptick and, of course, revenue.
But in complex digital environments, testing just basic mobile app features under ideal conditions will fall short of delivering great UX.
For instance, to the left is a recent search for Starbucks stores in Miami using both web search and the Starbucks native mobile app (on the right). Clearly, the mobile app testing team did not test against real conditions in this case.
In today's world, it's essential to test for the real user conditions that your customers experience every day. Here are three key tips to keep in mind when making user conditions part of your testing.
Define the Right Users for Your ProductsStep one is to identify your target users (aka "personas"). While this sounds easy, accurate personas can only be created through market research and data analytics; defining personas relies on consistent communication between engineering and business teams.
The next step is integrating these users and their traits into the test lab. This is usually the toughest task for engineering teams because mimicking real environment conditions is hard and requires ongoing lab maintenance.
Some of the core requirements for sustaining a lab that tests for user conditions:
- Ability to insert into the lab various network conditions, apps running in the background, phone call interruptions, and more
- Support for different geographies to cover testing of relevant users in relevant countries
- Support for any device and any operating system to sustain lab coverage as market matures
Add User Conditions to Existing Functional TestsOnce the lab is ready, DevTesters can add the relevant user conditions to existing functional tests in various ways, including manual testing, data-driven testing or through automated test code. We believe the most efficient path is through automation.
Implement user condition testing on top of functional test automation code by adding test code lines that define the target. The test code will automatically inherit user traits such as their name, the platforms and devices they use, their background apps, their location, their network conditions, and more.
Integrating these user traits into an existing continuous integration (CI) workflow and running many scenarios simultaneously will pay off in shorter release cycles, increased test coverage and, ultimately, better UX.
Use Reports to Find and Fix IssuesNow that your team has defined the target personas and implemented the test code correctly, they'll now need a detailed and actionable rich media report (see below). This report should include network logs, device and app memory and battery consumption details, and timers showing how long it took certain actions to take place.
Such reports should include results for every test scenario and should allow teams to take action and fix the issues. It’s also worth noting that to consistently address bug fixes, the report should compare the specific user condition tests to a "happy path" to show the contrast between real world conditions and ideal conditions.
For more details on how to test for the real users, download our white paper 3 Keys for Mobile App Testing for Real User Conditions.
Published at DZone with permission of Eran Kinsbruner . See the original article here.
Opinions expressed by DZone contributors are their own.