I’ve been seeing a few posts recently emphasing it being a core testing ability to think and test like an end user, its got me thinking about the misunderstandings and negative aspects this message can convey.
Here are some of my own thoughts that I shared on one of those posts.
Testers should think like a professional tester and not an end user.
A professional tester will recognise the risks associated with end users, how they are all unique, how they may use the system differently, how they have different desired outcomes and what’s important to one may not be important to an other, that some may have accessibility needs, working in different countries with different languages, on different devices and operating systems.
So on an so on. You are not thinking like an end user but you are considering how they think.
Something like persona testing can give you more insight into users, imaging yourself in different users shoes may bring to light risks and ideas for the pro tester.
Organizing user groups to use and give feedback on your app is also very useful, particularly with a broad range of users or a focus group like accessibility. End user testing is valuable and adds testing value on top of what testers do but that’s not you.
You are not thinking like a user though, you are thinking like a professional tester.
I believe it contributes to the myth that any user can test and ends up diminishing the value of the pro tester, what’s your view? Are you testing like an end user?
I have to agree with you, to an extent. Unless we truly are testing products we also use in our personal lives, it’s very difficult to really act as an end user would. Maybe that’s an interesting distinction to: acting like a user, vs testing or thinking like a user.
We’re also cursed / blessed with knowledge that real users wouldn’t normally have, and that’s bound to bias us. I also think it’s a mistake to try to emulate only one user (type). There are so many use cases, goals, personas, etc. to consider. And that’s part of being a professional tester, right? Acknowledging that there’s not one single way to think, interact, etc., and using that information to inform our testing (decisions).
Furthermore, I think the approach of thinking / testing like a user kind of means that all the testing would be black-box, which isn’t always the right approach. I think the intention of messages you describe is good, but agree that it can be misleading.
I think I agree with you as well. I’ll think of users and whether they may or may not like something etc. I also try to actually just use what I’m testing without thinking about it. This often works better when using a feature under test as part of testing something else. Admittedly this isn’t always possible, depending on how your team works (in terms of how work is broken down and deployed)
It feels to me that ‘think like an end user’ may have started out like a snappy way to describe what you are saying: consider the ways different end users may use your product and how that might deviate from the ‘intended’ way of use. But over time, that meaning got muddled.
I’m reminded of the writer’s adage of ‘write what you know’. It’s not intended to mean that writers should only write about things they’ve personally experienced (Stephen King didn’t encounter any murderous clowns — I hope), but sometimes gets used as a shutdown anyway.
As a tester most of my time uses tools and performs actions that a user wouldn’t. I do however like having specific end user focused tests, like journeys.
I definitely don’t do most of my testing like an end user. They aren’t going to be checking logs, playing with chrome dev tools, going back & forth, using scripts and doing all the activities that a tester would do within a session.
That said, I always advocate for doing as much testing in an environment most similar to a user. This is what I know some people have meant when saying “as an end user”. End users probably don’t have visual studio installed and all the developer build dependencies installed.
I do also like having a mindset switch to “be a user” and do a task within what I think their day is like (i.e. using personas). This involves having a goal to achieve and when I’m performing the test I’m trying to think as that user & cutting down my tool usage as much as possible.
Sure, I’ll consider the end user in all my normal exploratory or verification testing but doing specific end user testing is a different testing exercise.
I really don’t think I’m testing like one would do if they were an end-user. I do test with an end-user in mind.
The difference is important to me. An end-user just wants something done, while the cases look at risks, edge cases, and “what ifs” that a real user probably would never spend any amount of time thinking about.
That said, I do try to put myself in their shoes where necessary using personas, accessibility, different devices, languages, or contexts of use. I’m not interested so much in mimicking their behavior but rather in predicting the ways diverse people might interact with the product.
So I would say I test like a professional tester who takes end-user considerations but does not pretend to be one. That’s our value addition.
100% agree. If we were testing like an end user, we wouldn’t take any responsibility for the quality of our product right?
I do think we need to be closer to our user needs and I think the failure there is that these relationships can be treated as transactional. i.e. you get the need from the customer, build the story, develop it, test it, release it. Agile or not the problem there is, was that really what the customer needed or what they needed at that moment?
There needs to be wider understanding of a customers business process and if we don’t know it, then a professional tester would question it to make sure not only they know, but everyone in the team knows so there can be no assumption. So professional testers are skilled at questioning if we’re building the right thing 1st, and that it works 2nd.
Agree with all said above and adding this :
In the sense that most of regression tests I wrote are assessing flows as they are lived by a user yes I test like a user. I don’t test “technically” like a developer, i.e. using API instead UI. This is explained by the background I have, coming from business.
So in regression I prefer to test if the user is able to execute regular operations, like searching for an article, adding to the cart, checkout, pay, receive a confirmation… if this fails, then there is a huge impact in the customer journey, on the revenue, and in this sense I feel I test like a user and not as a developer/technical - they are asking me to add very technical stuff in test, to support and give confidence to development. I like this too but it’s another purpose.
@andrewkelly2555 Definitely. I approach testing by thinking about how actual users would interact with the application. For the web application I worked on, I’d test the user portal like someone just trying to get their work done—filling out forms, checking reports, updating their info. For the admin side, I’d think like someone managing users and reviewing data.
But I also test things users might accidentally do—like clicking buttons too fast, going back when they shouldn’t, or entering weird data. Sometimes the biggest bugs are in places users don’t normally go, but when they accidentally end up there, things break.