Systems Engineering for QA: Why the Left Side of the V Model Might Be the Most Important Place We Never Look

By Igor Goldshmidt, Testing & Quality Engineering Expert

When I started in QA, the job felt straightforward: test features, find bugs, repeat. My mission was clear: verify functionality and report what was broken.

But as I gained experience, I noticed something uncomfortable:

The most damaging bugs were created long before the first line of code was written.

They came from unclear goals, inconsistent requirements, architectural shortcuts, and assumptions no one questioned. And we, as QA, were left to clean up the mess.

Then I discovered the left side of the V-Model — and it changed how I think about quality forever.

What’s Wrong with Coming In Too Late?

Most QA professionals operate on the right side of the V-model:

Testing
Regression
Bug reports
Verification

We usually enter the product lifecycle at that point. But by the time we arrive, much of the system has already taken shape—and with it, many hidden issues.

Here’s where those issues typically originate:

Vague or outdated requirements
Fragmented decision-making
Fragile or rushed architecture
A lack of shared understanding

We end up catching symptoms, not root causes.

Introducing: Systems Engineering

Systems Engineering is the discipline that manages complexity across a product’s entire lifecycle. But in simpler terms, it’s about thinking before building.

It starts with the right questions:

What problem are we solving?
What does success look like?
How do components interact?
Where are the risks and failure points?
How will we know the system is behaving as expected?

This isn’t about generating more documentation. It’s about establishing clarity — early.

Rethinking the V-Model

Let’s visualize the V-Model:

Article content — https://builtin.com/software-engineering-perspectives/v-model

The V-model mirrors definition and verification.

Each stage on the left corresponds to a testing phase on the right. However, if the left side is weak, no amount of right-side testing can rescue the product.

Verification vs Validation: The QA Superpowers

Verification Validation Question: Are we building it right? Are we building the right thing? Focus Matching specifications Solving user or business needs Examples Functional tests, API checks Goal alignment, UX evaluation Often neglected? Rarely Frequently — but it’s where QA excels

Validation isn’t theoretical — it’s the QA practice of asking:

“Should we be building this at all?”

The Center of the V: QA’s Opportunity Zone

In a classic systems engineering diagram, there’s a center point where Systems Engineering, Implementation, and Project Management intersect.

Inside that overlap sits:

QA / Verification & Validation / Continuous Improvement

That’s where QA can have the most powerful impact. Not just as a test gate — but as a connector of what, how, and why.

From Theory to Action: 4 Steps Toward Systems Thinking

1. Get Involved Earlier

Push for a seat at the table during discovery, planning, and analysis phases. Ask questions. Shape acceptance criteria. Challenge ambiguity.

Early feedback isn’t just cheaper — it shapes better products.

2. Think in Systems, Not Just User Stories

Move beyond testing isolated features. Think about interactions.

Ask:

How does this affect other modules?
Are there fragile integration points?
What happens when one part fails?

This is how you evolve from tester to systems integrator.

3. Become a Process Improver

QA sees the following across the entire SDLC: dev velocity, flaky tests, messy CI/CD, and untestable specs.

Leverage that visibility:

Share metrics
Identify bottlenecks
Suggest workflow enhancements

Quality isn’t just in the product. It’s in the process too.

4. Validate the Business, Not Just the Code

Every release is an investment. Don’t just test outputs — validate outcomes.

Ask:

Is this solving a real problem?
Will users actually benefit from this?
Does this align with performance, compliance, or risk expectations?

That’s what system-level quality really means.

From QA to Quality Engineering: A Natural Evolution

If you’re still reading, you’re already thinking like more than a tester.

You’re thinking like a Quality Engineer.

And no — that doesn’t mean more testing. It means designing for quality.

It means:

Being involved in architectural conversations
Building testability into systems early
Driving CI/CD quality gates and feedback loops
Aligning testing with risk
Preventing issues instead of reacting to them

Modern systems are too complex to rely on testing alone. They require quality built in from the start.

Final Thought: From Tester → to Systems Thinker → to Quality Engineer

You don’t need a new title to start thinking differently. You need a new lens.

The left side of the V is where assumptions are made, goals are formed, and product direction is set.

That’s where we, as QA professionals, must show up — and lead.

That’s where real quality begins.

References:

At Skipper Soft , we help QA teams and startups shift left — with strategy, systems thinking, and test automation that scales. Let’s build quality from day one.