Fail more to learn faster

Context in software testing refers to the full set of conditions, people, tools, processes, and unknowns that shape what good testing looks like in a given situation. Because context is never static, “it depends” is not an evasion but the only honest answer. Testers who stay curious, ask why tools and processes exist, and treat change as opportunity rather than threat are best positioned to deliver real quality.

Key Takeaways

• “It depends” is the only honest answer in complex environments because context is never static and unknown factors emerge throughout the work.
• Decisive humility, knowing clearly what you do not know and where to go to find it out, is a more valuable tester trait than projecting false certainty.
• Asking why a tool, process, or decision exists is a core tester responsibility, not an overreach, because untested assumptions produce wrong solutions.
• Winners accumulate more failures than losers because acting into the unknown generates learning, while inaction leaves no foundation to build on.
• Testers who stay outside the AI narrative risk having their craft replaced by solutions built by people who do not understand software quality.

”It depends” is the only honest answer in complex work

The default answer to most testing questions is “it depends,” and that is not an evasion. It is the most accurate response available when the full picture isn’t yet visible.

The longer version is “it depends on the context.” A tester can offer an opinion drawn from history, experience, and reading. But until the context is understood, the real answer stays open.

Iterative work makes this sharper. Things emerge that nobody knows today. Context is never fixed, so the only sensible stance is to stay flexible, stay pragmatic, and be as informed as the work currently requires.

The hard part is saying “it depends” without sounding like you are dodging the job. Treating context as a genuine source of value, rather than an excuse, is a harder sell than simply doing the wrong thing quickly and confidently.

Decisive humility: be sure about what you don’t know

Decisive humility is the trait that matters most for testers facing constant change. It means being firm and clear about the large amount you do not know, while knowing exactly where to go to close those gaps.

Curiosity and critical thinking are the classic attributes. Decisive humility sits alongside them. You are decisive about the limits of your knowledge, and you know what to read, who to ask, and when to ask it.

This pairs with cautious optimism. Change in the industry usually triggers fear of the unknown, and some of that fear is fair. But the unknown also holds opportunity, and it is better to be at the front of a shift than to wait and treat it as a threat.

Comfort in the unknown runs against the traditional mindset, which prizes a well-mapped path and a known destination. Becoming a master of the unknown is something testers now have to learn deliberately.

Testers are trained to catastrophize, and that has a cost

Many testers were drawn to the role because they are good at spotting risks and problems. That same instinct can work against them.

A tester seen only as the source of catastrophe becomes “the no person,” the negative, the cost, the one nobody wants in the room. That reputation undermines collaboration with cross-functional teams.

Shifting from a failure framing to a success framing is neither easy nor instinctive. It is, though, how a team wins together instead of pulling in opposite directions.

How do you change a mindset without telling people to change it?

You cannot walk up to people and order them to adopt a new mindset. The route runs through understanding the individual humans you work with first.

Go back to context. Learn what makes a colleague tick, what they care about, what they avoid, where the daily pressure points sit in their work. That understanding lets you name a problem and then present it as an opportunity rather than an accusation.

Doing this alone is rarely smart. A sanity check with a trusted colleague before an important conversation helps you test your reading of a situation, even when you have to abstract away some of the detail.

Saying a plan out loud is often more useful than letting it spin around in your head. Add the decisive humility line: “I don’t know everything here, but I’ve spotted a margin for improvement, and I think there’s something we can do together.” That framing invites people in.

Software is built through people, not around them

You cannot succeed as an island. Careers may feel like your own story, but you are not the protagonist in anyone else’s, and growth comes through working with others.

The idea that software testing is a social activity holds even as AI spreads through the work. Social interaction stays at the core of what makes success possible.

This is why the perspective shift matters: approaching a colleague by asking what they value and need, then building a stronger relationship, before raising the thing you want to clarify.

Soft skills are harder to learn than hard skills

Soft skills resist learning because they force self-reflection and the breaking-down of how you actually behave. They cannot be acquired the way a tool or a technique can.

Chris Armstrong points to The Five Love Languages by Gary Chapman as a starting point he adapted for engineering teams, shifting the frame from love to appreciation. Engineers, customer service people, and technical writers are all wired differently and motivated differently.

Software testing is a social activity. We still have social interaction at the core of what we need to be able to succeed. — Chris Armstrong

People differ in how they focus. Some work in big-picture mode, others in micro detail. Some get irritated when pulled out of deep focus and struggle to get back in. Without grasping those differences, you cannot work well with people, and remote work strips away many of the social cues that used to help.

Influence does not require seniority. A tester in a team who advocates for quality and brings new ideas already holds a position of influence. Using it well means giving quieter colleagues time and space, and treating people with respect rather than pointing a finger and declaring the plan.

Why “question asker” is a fair reading of QA

If you never question why something exists, you risk using the wrong technology without ever knowing it. Questioning the purpose and the story behind a tool, a process, or a decision is the work.

Useful questions cut across the whole stack. Why did we choose this tool? What was the path to it? Is it being deprecated? Will it support the future architecture? Is there a broader tool set on the market for the front-end framework the team actually uses?

Understanding context is not a one-time task. It is perpetual. Standing still is the one move that is reliably wrong, because anything published about strategy, roadmaps, or best practice is already out of date the moment it ships.

The same applies to your own strategies, standards, and practices. They should meet what you know today and stay flexible enough to bend toward whatever arrives next.

Asking why someone bought a tool takes courage and tact

Walking up to a decision-maker and questioning a tool choice is genuinely hard. Most people, though, like sharing their opinions when asked the right way.

Framing decides everything. “This was a garbage choice, what is going on here?” sets you several steps back, especially if the person you are questioning rolled the tool out. The failure-to-success angle keeps respect intact.

Without the question, you stay without the context, and without context you cannot offer a correct solution. Sometimes the honest answer to a question is “I don’t know,” and with AI moving in, that answer will come up more often.

Not deciding is worse than a rejection or a failure. An unknown leaves you with nothing to build on. You cannot lay a foundation on flux.

Winners fail more than losers

People who try, who step into the unknown and experiment, accumulate more failures than people who sit still. The failures are the cost of moving.

The point extends into test design itself. Never trust a test you have not seen fail. A failing test builds confidence that the test actually checks something. Pure success with no hiccups invites more suspicion than a failure that teaches you something.

AI is a green field, and that is the opportunity

For testing, AI is close to a green field. There is some literature and some research, but the working practices, the quality characteristics, the methods, all of that has to be worked out in practice.

The cynicism is understandable. It echoes the automation boom of 10 to 15 years ago, and yes, what testers do today will change. Change happens regardless. Being part of it is where the opportunity sits.

If testers stay out, someone who does not understand the craft will build a tool, sell it to someone who does not do the job, and promise saved time and optimized everything. Testers will be left saying “but no, I don’t understand this,” because they were just doing their job instead of shaping the story.

Quality of prompting and quality of GPT creations become part of the toolkit. The alternative is software quality sliding to the lowest tier, with testers unable to explain why beyond “I told you so.”

What quality means will keep shifting

The end user defines quality, and that definition keeps moving. The media one generation consumes can look terrible to another, yet it meets the wants and needs of the people using it.

Users do not care how quality is achieved. Testers care because they want to ship the best work they can take pride in, for the right people. The holistic balance of verification and validation work will persist. The day-to-day will look wildly different.

With AI-assisted coding producing far more software in the coming months and years, the pressing question becomes who tests it and who advocates for its quality. Even testing the tests becomes part of the picture.

How do you prioritize when everything could be questioned?

Start by targeting a few things. If there are no boundaries and you explore forever, nothing ships, so begin with a small set of hypotheses drawn from initial conversations.

Say you suspect a problem with release quality. Dig deeper. Talk to the people who would know: customer service representatives, the pipeline or DevOps people, the testers. Read the logs. Don’t only talk to people, get access to the tools and look at the evidence directly.

A discovery phase produces tangible outputs, not just talk. Working assumptions to sanity check, observations, an appraisal of the tech stack, the open whys and hows, and problem statements gathered from key people. What is going well? What is a daily pain?

One useful definition of quality is the removal of unnecessary friction. Some friction is necessary. The job is to find what gets in the way without needing to. That friction can live in pipelines, processes, culture, or the technology itself.

The discipline mirrors testing. You would not write an end-to-end test, never run it, throw it in, and call it done. Nobody should trust that. When you uncover organizational context, step through it the same way: validate assumptions with people, slow down where needed, inject failures to understand where things hold and where they break.

The same rule covers AI-assisted testing. Have a plan, a hypothesis, a goal, acceptance criteria. Step through it, validate it, get it reviewed. Never mark your own homework.