Why the future of testing looks suspiciously like its past.
Once upon a time, testing was treated as serious engineering.
Then it was deemed expensive, slow, and redundant. QA departments were dismantled, testers were absorbed into agile teams, and the word “quality” started to mean “we run automated checks.”
Fast-forward a few years, and the “shift-left” movement was born — the idea that quality should be considered early in the development process. But if you’ve been around long enough, you’ll recognize that these “new” left-side activities are exactly what QA teams used to do. Just with less ceremony — and a lot more critical thinking.
The Persistent Misconception
There’s a widespread belief in software testing today:
“You need Python, Java, or fancy frameworks to uncover serious issues.”
That’s not true.
Sometimes all you need is a pencil, experience, and the ability to ask the right questions.
Let’s look at a simple example.
A Classic Agile User Story
As a user, I want to log in with my username and password so that I can access the system.
Sounds familiar, right?
But here’s the problem — that’s not a requirement. (Sorry, Agile folks.)
Before you disagree, ask yourself:
- What counts as a requirement versus a specification?
- What must be verified, and what should be validated?
To understand why that distinction matters, let’s walk through a structured engineering approach — the kind QA once owned.
From Business Need to Specification
Business Need (BN)
These express intent, not implementation.
