How to Mitigate Risks Before Delivering a Project with Limited Testing?

Question

I’m currently leading a project where I completed 80% of the work myself because I felt a strong expectation from the team to ensure timely delivery. The rest of the team contributed about 20%. Due to complications with local testing, I skipped thorough local tests and relied primarily on integration and QA tests in the dev environment.

The QA tests so far seem to be going well. However, I still have doubts about potential bugs and whether the QA tests cover all critical scenarios.

Our tech lead suggested postponing the delivery to allow more testing and review, but I opposed this, insisting I would take responsibility and lead the delivery. Despite my confidence, I’m now questioning whether we’ve done enough to mitigate risks before moving to production.

What are the best steps to ensure stability and minimize risks at this stage, given the limited testing? How can I better handle similar situations in the future to balance delivery speed with quality assurance?

Answer 1

I still have doubts about potential bugs and whether the QA tests cover all critical scenarios

I opposed this, insisting I would take responsibility and lead the delivery

Despite my confidence, I’m now questioning whether we’ve done enough to mitigate risks before moving to production.

Pick a lane.

Either you think the product is ready for delivery, or you don't. But you're thinking one thing and telling your lead something else (to the point of overriding them and taking on all the responsibility for the failures that can ensue).

You're flitting between contradictory stances and the only consistent behavior I see from you is rejecting doing what you're supposed to do.

• You skipped testing during development,
• You relied on tests that you now tell us you think don't actually cover everything,
• When given extra time to address those concerns you dismiss them and double down against not only your own judgment but that of your tech lead
• You're now rushing to ensure stability and minimize risks, still somehow glossing over the option of writing the tests that you've so far refused to write since the beginning.

Based on what you've presented, your development style is best described by that of an unguided projectile. You make erratic decisions, don't consider the long term ramifications, and state the opposite of what you believe when communicating to your lead.

What are the best steps to ensure stability and minimize risks at this stage, given the limited testing?

Write the damn tests.

Why do we test things? To make sure that they behave according to specifications.
How do we ensure that things behave according to specifications? We write tests.

You're asking how to confirm that things conform to specifications, but somehow still aren't thinking of writing the tests that confirm this. What answer are you waiting for, because clearly you're ignoring the answer that you already know.

How can I better handle similar situations in the future to balance delivery speed with quality assurance?

Let's start with low hanging fruit: if a lead is telling you that they're okay with delaying the deadline to address concrete concerns with the project, concerns that you very much believe to be true, why on Earth would you reject that?

That's not a balancing issue, that's just outright doing the opposite of what you believe and effectively undermining your entire team's project.

For the future, I think you need to revisit why you think tests need to be written in the first place. I can explain my take on it (which I will), but I can't make you believe/understand it; that part is up to you.

While writing tests adds an additional upfront cost to development, they start paying dividends in the future when you start debugging/maintaining/refactoring your codebase. Don't trick yourself into thinking that you'll do it perfectly the first time. You will need to revisit your logic. You will break things when making those changes. You will fail to catch those introduced bugs if you rely solely on your ability to not make mistakes. The tests that you will already have written by the time you're in that stage will tell you exactly what you've broken.

The upfront cost of writing the tests pales in comparison to the added effort from all the extra bugs and difficulties with debugging that you'd suffer from the lack of tests. For any business application with a sustained lifespan, tests are essential to keeping the codebase maintainable.
If a codebase is not maintainable, the application dies and a new one has to be built from scratch. Not only is this a tremendous waste of effort, it will take a long time of developers needing to deal with an unmaintainable mess before anyone will greenlight any rewriting effort (if ever).

If a contractor builds a house that ends up collapsing in on itself two years into the build, the contractor is to blame. "The customer asked me to rush the build" is not a valid excuse for the contractor to build a shoddy house.

Do not undercut the quality of your codebase, because you will cause suffering for anyone who has to maintain your messy results. That will be you and/or your coworkers.

Answer 2

I’m now questioning whether we’ve done enough to mitigate risks before moving to production.

Well, what are those risks? Whether you need more testing, or if you can deliver software which has a certain amount of bugs depends heavily on what can happen in the worst case. Will this lead to a situation where

• two or three users will just have to postpone their work for a day until you delivered a fix (where they can do something else in between, or have some manual workaround)?

• or might this lead to a situation where a whole factory will stand still?

This depends heavily on the type of software you are developing, and your user base. Make a proper risk analysis, then you can compare the costs and time losses of a failure with the costs and time losses for further testing.

Moreover, are you prepared for delivering bug fixes quickly in case a bug blocks production? Is deployment under your control, or is there some other organizational unit involved? What happens when you deploy today, but get sick tomorrow - is there someone else in the team who can take over your role and clean up your mess, ideally without introducing more bugs?

You cannot expect a software to be stable without proper testing, but what you can do is to make sure defects in production can be fixed ASAP. This is usually an organizationsl issue, not a technical one.

Answer 3

Call it beta.

You've managed timely delivery, of everything except thorough testing. You can still release responsibly but only if you're honest about that.

If you can get it in front of customers and get feed back from them you're in a good position. Just make clear that this is an early release snapshot that is still in early testing.

Of course that only works when the software isn't being relied on for something critical. If legal compliance, money or lives are involved take a breath and focus on what makes it critical. You can still release it and call it beta but only if you can keep people from actually using it for these critical things.

In short, customers can make good testers. But only if you can keep their feet out of the line of fire. Remember, they aren't pros.

Answer 4

I’m greatly pleased at all the answers to this question. Just three more points from me:

1. If you want to get project out the door because of whatever reasons, identify the most critical paths. Focus on testing them thoroughly. That way you solidify stability there. Every software has bugs. Yours will just have a little more than expected.
2. If you have some peers who will be willing to lend you a hand, request their support in reviewing the key sections on the critical paths. In that process, you get a software release and they, in turn, get recognition and your goodwill.
3. For future projects, apply the lesson you have learned this time, which is to have automated tests support your development during the development process and not as an afterthought.

---

Don’t be too harsh on yourself during this experience. Learning is a part of all this, even if you are learning a lesson that others think is obvious.

Answer 5

I work in an industry where we write software, but it is impossible to write tests that cover even a large part of the system. This is because we write the software and other people build and wire up the 50 m high cranes that the software runs on. And I can't fit a 50 m high crane in my home office.

But un-tested software isn't perfect (and should be considered broken), and no hardware installation is perfect either. So the solution we (and the rest of the industry uses) is field engineers who travel to the customers sites and are dedicated to getting everything up and running to the agreed upon quality.

If you are shipping untested software, then your position is akin to mine, and somewhere down the line someone is going to have get your software working for your customers. So if you continue to do so, then you need the equivalent of field engineers to make sure your customers are getting working software.

So either you pay now for more testing (so you are shipping a quality project), or you pay later for allocating resources to get the software running.

However, in the pay later process, you are not only paying with $$$, but you are also paying in loss of goodwill from your customers.