“Seeing around corners” — is this the real value of testing?

Discussions
,
1

Q: One of the core values of testing is the ability to “see around corners”, how do we make that more visible and valued and how do we get better at it?

I recently watched a short video by Jensen Huang (NVIDIA CEO) said about intelligence. Post by Alex Wisch with the video here: https://www.linkedin.com/posts/alexwisch_mindset-peakperformance

Quote:

Someone who sits at the intersection of being technically astute but human empathy and having the ability to infer the unspoken around the corners, the unknowns. People who are able to see around the corners are trully smart and their value is incredble to be able to pre empt problems before they show up just because you feel the vibe and the vibe comes from a combination of data analysis, first principle, life experience, wisdom, sensing others. That vibe is smart

His definition of “smart” was about people who sit at the intersection of:

  • technical understanding

  • human empathy

  • intuition and pattern recognition

  • the ability to infer the unspoken and anticipate problems before they surface

He described it as being able to “see around the corners” using a mix of data, first-principles thinking, experience, and sensing the system.

That immediately made me think of testing.

:magnifying_glass_tilted_left: What I’m looking to find out

I’ve always agreed that this is where a lot of the real value of testing lives:

  • sensing risk early

  • noticing weak signals in behaviour, UX, logs, or assumptions, gathering data

  • asking uncomfortable “what if?” questions

  • connecting dots across different customers - users, tech, and people

  • anticipating failure modes that haven’t happened yet

But it’s also:

  • hard to measure

  • hard to articulate

  • and often under-represented / under valued when we talk about “what testers do”

I’m sure many recognise this as a core testing skill. Something we should dig deeper into and use to sell our value and get better at. I feel this has always been where the value of testing / testers has been but people don’t always see it, probably because we don’t sell it well or show it well enough

I’d love to hear:

  • how you personally experience this in your testing work

  • whether you actively try to develop this skill

  • how (or if) you make it visible to teams and stakeholders

  • how you talk about this value without it sounding vague or hand-wavy

This isn’t about bashing development or automation at all, just to praise testers and testing.

AI is getting very good at:

  • execution

  • automation

  • pattern detection at scale

But this more human side — judgement under ambiguity, sensing risk, testing to gather information , reading systems etc is something testing uniquely contributes to.

As testers i feel:

  • we don’t sell it well enough

  • the companies, system doesn’t know how to recognise it

Would love to hear peoples perspectives around this, how do we better define and show the real value we bring? How do we help teams feel the risk earlier? What are people doing to show the value they bring?

2 Likes
2

That’s the age old question, isn’t it? Why do we need quality or better, people who feel responsible for quality? Today’s lean, dumb management tends to view quality as something that hinders early deployment, costs a lot and is in general the domain of the worrywarts.
To me, there is a big difference between someone who tests and a tester. It’s easy to have developers review in pairing. And it’s probably going to go easy, there will be very few bugs since both want this code to be ok. A tester’s mindset works differently - if there is a bug (there always is) we need to find it. Unfortunately this argument doesn’t sit well with the guys looking to save money. And so it’s usually less testers and less testing until something catastrophic happens (see Boeing).
The only way to avoid that is mentioning audits by governance or other audit boards that could prevent deployment but I’m aware that that’s rarely the case. So all what is left to us is having examples of dangerous bugs found by testers. Or even “better” users.

1 Like
3

This really resonated with me. I’ve always felt that “seeing around corners” is less a single skill and more a habit of how testers look at systems. It shows up in the questions we ask early, the things that make us pause, and the moments where something feels off even when the happy path looks fine. The problem is that those instincts usually live in conversations, gut checks, or quick notes, so they disappear unless a bug actually happens later.

One thing that helped me make this visible was reframing it from intuition to signal gathering. Instead of saying “this feels risky”, I try to say “here are three weak signals I’m seeing and what they could lead to”. That could be UX friction, unclear ownership, logs that are noisy, or assumptions that only hold for one user type. When you tie that to concrete questions or scenarios, stakeholders stop hearing hand waving and start hearing early risk detection.

I’ve also found it helps to capture this thinking somewhere lightweight. Not as formal test cases, but as risk notes, assumptions, and questions raised during testing. Tools like Tuskr have been useful for us in that sense, mainly because they let us record what we noticed and why we explored something, not just what we executed. Over time, that creates a paper trail that shows testers weren’t just clicking buttons, we were actively reading the system.

AI will keep getting better at execution and pattern detection, but judgment under ambiguity is still very human. The more we can translate that judgment into visible artifacts, shared language, and early conversations, the easier it is for teams to feel the risk sooner and understand the real value testing brings.

3 Likes
4

Hi @rforjoe

thank you for articulating this - I see similar patterns in our work - an in the systems we test :). It reminded me of this piece

I think, therefore I test: the importance of thinking for testers | Ministry of Testing?

One thing I miss there, though, is the an “outreach” mindset. The ability to see outside the daily grind of deliveries and bugs. But towards a more systemic view of the org. I wrote about that recently here

5

I like to call it an end to end user experience. I think it comes naturally to some people. And its not just software, even in everyday life when I use a service or buy a product, I notice all the little things that make up for an “experience”.

It really is the “experience” that counts. As mentioned by others here, the stakeholder decisions to be narrow viewed on this then hurts the innovation that may result.

2 Likes