“Oh, by the way, we want to go live with this next Tuesday.” It’s a phrase every experienced tester has heard at some point, usually at a time when the testing work hasn’t even started yet and the calendar is already closing in on the deadline. What follows is a familiar scenario: an exciting new feature, less-than-ideal preparation, and communication that’s awkward, to say the least. The result is predictable: an overworked tester who has to perform under intense pressure against a deadline that, even with the best will in the world, can only be described as utopian.
This article is based on the experience of an M2Q test consultant who encountered this scenario firsthand during a long-term project. It is not an exception, nor is it an isolated incident that happens once and never again. It is a recurring pattern in many organizations, and its consequences extend far beyond a single stressed-out QA engineer. In this article, we’ll take a closer look at why this happens, what it costs, and, more importantly, how organizations can prevent this from happening on a structural level by giving QA a full voice in the planning process from day one.
It’s not an impossible scenario, but it often leads to problems down the road. Especially when QA isn’t brought in until very late in the process and is then told that the launch is already scheduled for four business days from now. Four days to test a feature from start to finish, with the implicit message: if you find any issues, report them immediately, because there’s no time to wait.
For a tester with eight years of experience on the same project—and with the seniority to put that pressure into perspective to some extent—that’s still manageable, though “manageable” isn’t the same as “optimal.” The result of such a time-pressed sprint rarely meets the standard you normally deliver. And then comes the bitter aftertaste: when it later turns out that other teams weren’t ready either, and the deadline is pushed back without mercy after all, an inevitable question arises. Why wasn’t a realistic deadline set from the very beginning?
The answer rarely lies in a lack of willingness. It usually lies in a planning process in which testing is viewed as an afterthought—something that “can be squeezed in” after development is complete—rather than an integral part of the process from the very first sprint.
Unrealistic deadlines are rarely set on purpose. They are usually the result of a series of small decisions: a marketing team that announced a launch date before the scope was finalized, a project manager who underestimated the complexity of the integrations, or a development team that tests the “happy path” but overlooks edge cases. In that scenario, testing is treated as a step you add at the end of the process, rather than an activity that runs parallel to the project from the analysis phase onward.
The result is a schedule that looks sound on paper but, in practice, leaves no margin for setbacks. It does not take into account dependencies between teams, the time needed to create test cases based on functional analyses, or the possibility that an initial round of testing might uncover precisely the critical bugs that take the longest to fix. Once that tightly scheduled deadline comes under pressure, there is no safety margin to fall back on, and QA is usually the first link in the chain that has to make up for it.
That’s exactly the pattern the consultant describes: a team that wasn’t ready, a deadline that ended up being pushed back anyway, and a testing phase that was already under unsustainable time pressure from the start. The irony is painful. If the deadline was going to shift anyway, why wasn’t it estimated more realistically from the start?
The impact of a test phase that’s been planned too tightly is rarely immediately apparent, but it does become noticeable over the long term.
Quality suffers as a result. When a tester is given only four days to thoroughly test a complex feature, there’s a real chance that not every scenario will be covered. Not because the tester lacks knowledge or dedication, but because there simply isn’t enough time to go through all the edge cases, integrations, and negative scenarios. The result is less thorough than what a tester would normally deliver—a level of quality that no one on the team really wants to accept, but that time pressure forces them to accept.
Test debt is piling up. Tests that are carried out superficially under time pressure often leave traces in the form of untested test cases, missing test coverage, or test automation that will have to be “added later.” That debt doesn’t disappear on its own; it gets carried over to the next sprint, and the next, until at some point it becomes a millstone around the team’s neck.
Burnout is just around the corner. A tester who repeatedly faces unrealistic deadlines—and who, in doing so, must constantly absorb pressure that actually originated elsewhere in the process—runs a real risk of becoming overwhelmed. This is especially true for less experienced testers, who lack the same level of seniority to put that pressure into perspective.
Reputational damage, both internal and external. If a go-live ultimately proves unfeasible and the deadline is pushed back, it undermines confidence in the schedule throughout the entire team. Externally, toward customers or end users, the impact is even more severe: a rushed release that turns out to contain bugs after the fact does more damage to an organization’s credibility than a release that is delivered a few days later but is bug-free.
As the consultant aptly puts it: a schedule that is so tightly packed that even the slightest setback causes problems ultimately comes across as less professional than one that allows a little more breathing room but is still met on time.
The real lesson from this story isn’t that testers need to work harder under pressure—because they can always do that, until one day they can’t anymore. The real lesson is that testers deserve a seat at the table from the very beginning, not just once the scope has already been defined and the deadline has already been communicated.
A QA professional has a unique perspective that few other roles within a project possess. He or she knows most of an application’s features inside and out, understands how the various components are intertwined, and can identify—better than anyone else—which scenarios, including the less obvious ones, may be involved with a new feature. That knowledge is not only valuable during the testing itself, but is at least as valuable during the analysis and planning phases.
After all, who is better suited to estimate how much time testing a new feature will actually take than the person who will be doing the testing? Who is better equipped to identify which integrations require an additional round of testing, or which edge cases are overlooked in a functional analysis? A tester who isn’t brought in until after the deadline has already been set can only react to a decision that has already been made. A tester who is at the table from the very beginning can help shape a schedule that is feasible—and remains so.
Dare to push back, be realistic in your assessments, and make your presence felt right from the very start of a project or sprint. You’ve already got a “no”; now you can get a “yes.” That message applies not only to testers themselves but also to the organizations that employ them: make sure that voice actually has the space to be heard.
It’s one thing to acknowledge that testers need to be involved earlier in the process, and quite another to actually put that into practice. Here are a few concrete starting points to help with that:
Involve QA as early as the refinement and analysis phases of a feature, not just during the sprint in which it is delivered. That way, testers can identify early on which scenarios, dependencies, or risks are being overlooked in the functional analysis—often before a single line of code has been written.
Include test estimates in sprint planning, just as you do with development time. A feature is only “ready to be planned” when both development and testing have been realistically estimated—not when only the development time has been determined and testing is simply assumed to “fit in.”
Be sure to build in a margin in your schedule. A deadline that leaves absolutely no room for unforeseen issues isn’t a deadline—it’s a gamble. A realistic buffer ensures that a bug you find won’t immediately derail the entire schedule.
Focus on shift-left testing and, where possible, test automation, so that testing is integrated as early as possible in the development process rather than waiting until the very end. This reduces the likelihood that problems will only be discovered when the deadline is already unnervingly close.
Communicate transparently about risks as soon as they arise. If a team isn’t ready, or if the testing phase takes longer than initially anticipated, it’s better to report this early and clearly than to hope it will resolve itself by the deadline.
This approach requires a cultural shift: treating testing as an equal part of software development, rather than as a necessary but subordinate final step.
At M2Q, we see this pattern recurring with various clients and projects, which is precisely why we strongly believe in the added value of experienced test consultants who are brought in early in the process—consultants with enough seniority to contribute to planning discussions and to challenge unrealistic deadlines. Whether it involves complex government platforms, financial applications, or large-scale digital services, the quality of a release isn’t determined on the day it goes live, but in the weeks and months leading up to it—in the way testing is integrated into the schedule.
A test consultant who is involved from day one doesn’t just deliver better test results. That consultant also helps set more realistic deadlines, identify risks early on, and ease the pressure on the entire team—rather than placing that pressure solely on the tester at the very end. Ultimately, this is in everyone’s best interest: the developers, the project managers, the end users, and not least the tester themselves, who wants nothing more than to deliver perfect quality within a deadline that is actually achievable.
Why are testers often brought in too late in a project? In many planning processes, testing is still viewed as an activity that begins only after development is complete, rather than as a component that runs concurrently with the project from the analysis phase onward. As a result, the time required for testing is often underestimated or does not become apparent in the schedule until late in the process.
What are the consequences of a test phase that is too short? A test phase that is too short increases the risk of incomplete test coverage, a growing backlog of tests, an overload on the testing team, and ultimately quality issues that only come to light after the system goes live.
How can an organization involve QA earlier in the planning process? By involving testers in the brainstorming process during the refinement and analysis phases, incorporating test estimates into sprint planning, and building in sufficient margin for unforeseen issues.
What is shift-left testing? Shift-left testing is an approach in which testing begins as early as possible in the development process, rather than waiting until the end. This allows problems to be detected sooner, when they are still easier and less expensive to fix.
Why is a tester’s input valuable when drawing up a schedule? A tester typically has a broad understanding of how features and systems are interconnected, and can therefore better assess which scenarios need to be tested and how much time that will realistically take.
A deadline that doesn’t take the realities of testing into account isn’t ambitious planning—it’s procrastination by another name. The real solution isn’t to work even harder against an impossible deadline, but to systematically involve QA from the very first planning meetings. Those who take the tester’s voice seriously not only build better software but also create a schedule that’s rock-solid—and one that, when it comes down to it, is actually met.
Would you like to know how M2Q’s experienced testing consultants can help embed quality and realistic planning into your software projects? Contact M2Q and discover how we help organizations like yours treat testing not as an afterthought, but as a full-fledged partner in the planning process.
