How do you test like your users?

A discussion started today on about hiring and remote work and why some companies might not offer remote work. It then delved into “But how do you test like your users would?”

@thatdamnqa asked:

“In an office you (probably) have reliable and quick wifi. What happens if you’re on 3G? 4G? EDGE? Behind a paid wifi paywall? Going through a tunnel? Using crappy hotel wifi? Your data connection is being throttled?”

“How do you test having the sun shining on the screen?”

“How do you test how easy it is to use when you’re on a train with minimal elbow room and you’re being thrown around the carriage by the movement of the train?”

Another point raised was do you test on 2G? Or as @gemma.hill1987 mentioned “you’re also assuming you need the internet to test what you’re testing”

So, in your situation (which of course will vary company to company) what do you do while testing to test like how your users would interact with your application?


I hang on to an environment that has loads of other stuff installed on it, and just let it get old with our product automatically updating.

I do a lot with other software, hoping to never see ours.


For networking, browsers dev tools have network throttling, so you can simulate 3G, 2G or even Edge. If using a smartphone, you can use wifi and a proxy (Charles or mitm) on another computer on the same network and filter all requests and responses (man tc & man iptables should help on Linux but only for experts).
Or use simulators or emulators if you can.

Going through a tunnel is like being offline for a while, then you just need to be offline.
You can also go out of your office, go in a cellar, in the subway…etc

And for very uncomfortable situation, I guess it’s easy to find, go below your bed, in your bathtub, use sunglasses close to a powerful light source. Just use your imagination, this is part of the tester skills right? :slight_smile:


Totally agree about ramping up the imagination to test UI. I’ve done some truly odd ball things that sometimes the devs raised their eyebrow (like Spock) but the results speak for themselves when I identify XYZ doesn’t work as per the product statement/brochure. This is the fun part about testing :grinning:


Seems logical Captain

If you’re talking about mobile app, then all of those tests mentioned above would be good, different connections, switching from one type of connection to another, like going from a place with good wifi to somewhere with just a 3g connection.

You should also be throwing in tests like how the app handles being interrupted by phone calls/messages/notifications. How does the app respond to that.

Then there is stuff like backgrounding an app or switching between app, how does the app handle coming back to it.

And also battery consumption, does it handle any different in low power mode?


hahaha… that’s what I like a tester with a sense of humour

I test embedded software so for me it is easy.

I build the hardware that the software will run on and then having spoken to the customer about how they are going to use the system I write my tests to cover what they have explained as their usage.

No need to worry about 2G, 3G, 4G the internet or browsers.

Life does get a little more complicated when the system is half way round the world and has no internet connection and a problem though.


Where ever possible I go and talk to the users and try to gain an understanding of their needs. Hopefully creating useful customer journey’s which I can then vary wildly from. :slight_smile:


You should use combination.
Office guys do functional testing, they know requirements, know domain and work close with product management and development.
Crowdsourcing testers should test usability and other things like network problems, corner cases, etc.
By the way, office guys should have a tool to emulate packet loss or poor speed of the network, at least to reproduce bugs which crowdsourcers found.

As it happens I’ve recently posted a blog post about this!

A couple of examples of things I’ve done…

  • I was working remote, so I took the local tram to the city centre, doing some testing on the way. Popped into a coffee shop where I sat down with a coffee and opened tickets for the bugs I found
  • I had a contract for a social network, which was handy, as I spent some of my free time using my own product. I deliberately made sure to use the version in development, and use any new/modified features.