Let’s imagine an IT project with no testing. None. Zero. No scenarios, no checklists, no “one last look before release.”
The code goes straight to production like freshly baked bread, still warm, full of promise, but someone is already saying: “The client is hungry, there’s no time to check.”
Sounds risky? Of course. Sounds familiar? Unfortunately, very often.
This article is neither a manifesto nor a how-to guide. It’s a story about consequences. About what happens when testing:
- doesn’t exist at all,
- exists in excess,
- or finally starts to make sense
A world without tests: YOLO, enterprise edition
Let’s be honest – the lack of tests has its advantages.
A project without formal testing often means fast deployments, fewer processes, and fewer blockers. Developers are closer to the system, understand its behavior better, and can react more quickly to changes. Many things are “checked along the way”: locally, on a test environment, or even directly in production.
You often hear things like “the dev checked it”, “it’s just a small change”, or “if something breaks, we’ll fix it”. In practice, this means testing done by developers in their spare time, without formal scenarios, focused mainly on happy paths and the code that was just modified.
In the short term, this works. Sometimes it works really well. The problem starts later.
A project without tests is like driving a car without brakes, but with a very loud horn. Technically, you can drive – even fast. The problem is that the horn doesn’t stop the car. In a world without tests, the absence of bugs is just an illusion. They exist – no one has hit them yet, no one managed to report them, or someone decided that “this is just how it works”.
What really happens in such a project?
Bugs show up in production – and not the “cosmetic” kind. These are issues that block payments, delete data, or allow users to see someone else’s orders. Such bugs rarely appear immediately; they surface in specific scenarios or data sequences, and once they do, they directly affect real business processes and cause tangible losses of time, money, or reputation.
The customer becomes the tester – for free, without instructions, and usually without a sense of humor. Users don’t have the tools or knowledge to report issues in a way that’s useful for the team, so the feedback is often vague: “something doesn’t work.” Frustration grows as users stop using the product and start fighting it.
The team puts out fires instead of building the product, and the sprint turns into survival mode. Instead of planning new features, developers and testers spend their time fixing unexpected issues or tracing the source of incidents. The backlog fills up with “fix urgently” tasks, while regular sprint goals are quietly pushed aside.
Trust erodes – once, twice, three times… until someone asks: “Do we actually control this system?” After several serious incidents, stakeholders and users begin to doubt the product’s stability. That doubt translates into resistance to change and discomfort around releases. In such an atmosphere, even small improvements feel risky and require extra validation. A lack of testing does not mean a lack of costs. It only means that the costs appear later – and are far less controllable. Lack of testing hurts immediately. Excessive testing hurts later.
A project story #1: “But it worked yesterday”
The change was small. Really small. A few lines. One condition. “Nothing risky.”
No one tested it because:
- there was no time,
- there were no tests,
- there was no habit of checking the impact of changes.
The next day:
- the process stops halfway,
- data is saved only partially,
- support receives reports they can’t reproduce.
The worst question that comes up is: “So… what exactly broke?”
And no one knows the answer.
What if we tested everything, all the time, everywhere?
After a few situations like this, a reflex reaction appears: “Alright. From now on, we test everything.”
And again, this approach also has its advantages.
Comprehensive testing gives a sense of control, organizes knowledge about the system, and often improves the architecture. Coverage looks great, reports are impressive, and the organization can say that “quality is taken care of”.
The problem is that, in practice, this often leads to overload. In practice, it often turns into test overload.
What does a world of test overkill look like?
- Tests are everywhere.
- Every change triggers a cascade of test fixes.
- The pipeline runs so long that no one waits for the result.
- Tests are red more often than they are green.
The team starts to:
- ignore the results,
- treat tests as an obstacle,
- “temporarily” disable them.
And paradoxically, despite the massive number of tests, quality doesn’t improve. Because testing has stopped being a tool. It has become a goal in itself.
A project story #2: “We have tests, and we’re still afraid”
The project has an impressive number of tests. Coverage looks great.
And yet:
- no one trusts the results,
- every deployment is stressful,
- changes are postponed “until later.”
The tests exist, but they don’t provide a sense of safety. And if tests don’t provide safety, what are they for?
Where is the balance? Risk-based testing
Balance in testing is not about the number of tests. It’s about conscious decisions. Mature testing starts in the mind, not in the tools.
Not with the question: “What else can we test?” But with the question: “What will happen if we don’t test this?”
Thinking in terms of risk changes everything
Instead of testing everything:
- we test what can hurt the most,
- we focus on fragile areas,
- we protect critical processes.
We ask questions:
- What is critical for the user?
- What is critical for the business?
- What changes most often?
- What has already broken before?
Only then do we decide:
- where to test thoroughly,
- where light testing is enough,
- where tests aren’t needed at all.
The tester as a risk owner
This is where the true role of the tester comes into play. A tester is not someone who “checks things.” A tester is someone who asks uncomfortable questions.
A tester thinks in terms of:
- failure scenarios,
- consequences of defects,
- non-obvious behaviors.
They don’t just ask: “Does it work?”
They ask: “What happens if it doesn’t?”
A good tester:
- sees the system as a whole,
- understands the impact of failures,
- helps the team make informed decisions.
They don’t block change. They help introduce it safely.
A project story #3: “Suddenly, things got calmer”
The project had existed for years. There were almost no tests.
The team decided not to start a revolution:
- they chose a few critical areas,
- added simple regression tests,
- started talking regularly about risks.
After a few iterations:
- deployments stopped feeling like a lottery,
- the team started trusting changes,
- the pace of work increased, paradoxically, thanks to testing.
Not because there were more tests. But because the tests finally made sense.
What if the project is already running, and there are no tests?
This is a very common starting point. And, surprisingly, not a bad one.
Introducing testing into an existing project is:
- not a sprint,
- not a revolution,
- but a continuous evolution.
We start with:
- visibility,
- stability,
- conversations about risk.
Not with perfection.
Sii x Salesforce
As a Salesforce partner, we use our expertise and AI-based applications to improve sales, customer service, and productivity in your company.
Salesforce offeringSummary
Not testing means taking blind risks. Testing everything means getting tangled in your own safety net.
Testing wisely means:
- understanding risk,
- understanding the product,
- understanding the user,
- and understanding the team.
Because the best tests aren’t the ones that find the most bugs. They’re the ones that let you sleep peacefully, before the phone rings.
And that’s probably what we all want. 😉
Leave a comment