Testing used to be serious engineering. Then it was deemed expensive, slow, and redundant. QA departments were dismantled.
Then came the so-called shift-left movement — a new name for practices that many QA teams had already been doing for years.
But if you are an old-timer like me, you will recognize these left-side activities as exactly what QA teams used to perform, just with less ceremony and more critical thinking. The industry has a habit of rediscovering old lessons under new labels, and the same challenges tend to reappear in different forms.
There is a persistent misconception in software testing: you do not need fancy new tools, AI platforms, or heavy automation frameworks to uncover serious issues. Sometimes all you need is a pencil, experience, and the ability to ask the right questions.
Take this classic Agile user story:
As a user, I want to log in with my username and password to access the system.
This describes intent but it is not a requirement..
Before you disagree, ask yourself:
- What shall be considered a requirement versus a specification?
- What must be verified, and what should be validated?
The full story starts here: connecting business intent to clear, structured system behavior.
(This is a simplified version of what needs to be done to keep reading time shorter.)
Business Need (BN)
These express intent, not implementation
Requirement (REQ)
Defines what the system must do — not how.
Specification (AUTH, PERF)
Describes how the requirement will be fulfilled.
Asking the Right Questions
To validate the requirement and its specifications, we use a questionnaire based on a required template. The questionnaire is built by QA, so it aligns with the business vision for quality. The answers must be documented and may include "Not applicable", considered with acceptable low risk, TBD, etc. It covers several topics:
- Security and complexity
- Accessibility
- What-if scenarios
- Modal behavior
- Error handling and feedback
- Performance and load
- Legal and compliance
Some example questions:
These questions drive meaningful discussion between QA, developers, and business stakeholders — before a single test case is executed or line of code is produced.
Expanded Specifications (Traceable & Testable)
When done right, every requirement connects to detailed, testable specifications.
Here’s an example subset:
Authentication Protocol
- AUTH01 - The system shall use OAuth2.0 as the authentication protocol
Login Interface
- AUTH02 - The system shall present a login screen to initiate authentication
- AUTH03 - The login screen shall include input fields for username and password
Credential Handling
- AUTH04 - The system shall validate the entered username and password against the identity provider
- AUTH05 - The system shall reject access if credentials are invalid
Two-Factor Authentication (2FA)
- AUTH06 - The system shall support two-factor authentication
- AUTH07 - 2FA shall be available via SMS or TOTP
- AUTH08 - The system shall allow users to select their preferred 2FA method
- AUTH09 - The system shall enforce 2FA before granting access when enabled
Error Handling
- AUTH10 - The system shall notify users of failed authentication attempts
- AUTH11 - The system shall provide a fallback mechanism if SMS or TOTP delivery fails
Performance and Load
- PERF01 - The system shall support authentication for up to 1200 registered users by the end of 2026
- PERF02 - The system shall accommodate a daily active usage rate of 5 percent, equating to 60 concurrent users under normal conditions
- PERF03 - The system shall be scalable to support a yearly growth rate of 12.5 percent, reaching approximately 1350 users by the end of 2027 and 1520 by end of 2028
- PERF04 - The authentication response time shall not exceed 2 seconds for 95 percent of login attempts under expected load
- PERF05 - The system shall maintain authentication availability of 99.9 percent uptime, excluding scheduled maintenance
- PERF06 - The system shall implement rate limiting to prevent abuse and ensure fair resource allocation during peak usage
- PERF07 - The system shall be tested under simulated peak load conditions to validate performance thresholds and identify bottlenecks
Traceability: The Forgotten Art
A traceability matrix links business needs, requirements, and specifications together making it clear why each feature exists and how it will be tested. This used to be the backbone of serious engineering in QA and today’s “shift-left” movement is merely circling back to these foundational principles.
This is what serious engineering in QA looked like.
TL;DR — QA Has Come Full Circle
- Testing used to be structured, traceable, and critical.
- Modern practices like “shift-left” are rediscovering what QA already knew.
- You don’t need complex frameworks — you need discipline, clarity, and good questions.
- True quality comes from understanding the business, not just automating the tests.
Final Thought
New software development methods like Agile, RAD, XP, FDD (...) have brought many valuable ideas to software development like faster feedback, closer collaboration, and a focus on delivering value continuously. Yet challenges often emerge not only in adopting the method itself, but also in the way it is commonly implemented. In practice, essential clarifications, requirements, and quality considerations are frequently overlooked regardless of methodology.
At House of Test, we can help you control your quality through our methodical and disciplined approach.
