Dealing with a dedicated QA team who are always behind schedule

Posted by LunchWhole9031@reddit | ExperiencedDevs | View on Reddit | 33 comments

I got a new job at a company that develops safety-critical software for industrial use. We are required by law to follow a certain development process. The process mandates that every feature is tested by a member of the QA team. Developers do not write their own automated tests. Unit tests are difficult to write due to the nature of the product. Instead, we are instructed to test the happy path and some basic error paths manually and then turn our code to the dedicated QA team for testing. The problem is that testers (and also developers to a much lesser degree) are absolutely bogged down in bureaucratic work that stems from the regulations we need to follow. As a result, testers are always behind schedule when it comes to testing our PRs. I've recently gotten into a situation where a tester started testing a feature 3 months after I finished dev work on it. This is somewhat rare, but a latency of 3-6 weeks is common. This results in me being pretty stressed most of the time because PRs pile up and there are almost always multiple features in flight at the same time. I cannot relax because dev work on a feature is pretty much never finished until a tester has the time to test it. There are almost always bugs that are uncovered during testing, because the product is quite complicated. Last month, this resulted in me trying to fix bugs in 4 different PRs at the same time, when the testing team finally got the time to test them. I'm really starting to grow annoyed by this. Our managers always push us to start working on new features even though the previous ones aren't done (fully tested and PRs merged).

Reply to Post

33 Comments

[-]

drnullpointer@reddit

It seems your development team does a damn hard job of figuring out and being responsible for the regulations. No wonder they are behind schedule. Please, whenever you work with a QA team remember, that most of these people would be developers if they could. They are in QA because they couldn't get a job as a developer. This is not to demean people who work in QA. QA is important job, especially in cases like yours where there is regulatory pressure. This is to say they probably have less knowledge and experience and development skill than typical software developers. And what this means you guys need to be patient and understanding. \> There are almost always bugs that are uncovered during testing, because the product is quite complicated. My task, as a developer, is to deliver working code. If I am hasty about development I am essentially pushing work towards QA/operations teams. And eventually future self. \> Developers do not write their own automated tests. Unit tests are difficult to write due to the nature of the product. Unit tests might be difficult to implement, but that does not justify not testing the product you are developing. There are many different ways to test the application and unit tests are only one of them. I typically make sure to put together some kind of end to end functional test harness for the application I am working on. This harness is supposed to verify \*externally observable\* behavior of the application. In other words, the properties of the application that others might see and rely on but without relying on internal properties that nobody cares. This way, I can easily refactor a lot of application without changing any code while still understanding the application works correctly in every situation. Without knowing more about your application it is hard to suggest what testing strategy you should take. The only thing I know is that you guys (developers) should make sure you have a good way to verify your product is correct and that the QA team is only responsible for double-checking that you did correct job. It is after all Quality \*Assurance\* team.

[-]

LunchWhole9031@reddit (OP)

The QA team already writes all kinds of tests. So if I did write my own, I would be basically duplicating their work. And "wasting effort" in the eyes of management. Also, we aren't responsible for the regulations, the government is...

[-]

drnullpointer@reddit

Again. I. As a developer. Would never turn untested code to testers. Unless you guys are some kind of exception and can write code and not make any mistakes, you should test the code you wrote. Any bug is the cheaper to fix the earlier in the process they are detected. Majority of problems should be solved in design and implementation, well before the code goes to QA.

[-]

LunchWhole9031@reddit (OP)

Great, I wouldn't either at my ideal job. This is, however, the way my company works. I cannot change the company.

[-]

drnullpointer@reddit

Well, there you have the problem. It is not "QA team who are always behind schedule", it is a company that does not understand development process.

[-]

flwwgg@reddit

| Developers do not write their own automated tests. Unit tests are difficult to write due to the nature of the product. Hmm, can you share more info? This is very very strange.

[-]

LunchWhole9031@reddit (OP)

I guess a better way of saying this is that the culture is that the dedicated QA team takes care of unit tests as well. It would be possible for a developer to learn how to use the testing framework to write those. Problem is that there is some amount of bureaucratic work that the QA team needs to do before the tests can be written.

[-]

forgottenHedgehog@reddit

Before they can be executed, maybe. But why before they are written?

[-]

LunchWhole9031@reddit (OP)

Every test is written according to a formal document, which must be authored by a member of the QA team, so there's a dependency on that.

[-]

forgottenHedgehog@reddit

And what prevents you from writing tests for your internal use so that you don't have to wait with possibly broken shit for three months?

[-]

LunchWhole9031@reddit (OP)

1. Difficulty of writing unit tests for some of the features. The product is written in C, runs on a specific OS, all that sort of stuff. It's not like I can easily create mocks like in a mature OOP language like Java / C#. 2. Our managers don't give us the time to write tests.

[-]

umboose@reddit

Point 1. is frankly unbelievable in 2025 unless you have some insane hardware dependency. Point 2. is a red herring, because QA sign-off is the rate limiting step, not feature development. Unless you start following the advice others are giving you in this thread, management would be better off making devs redundant and hiring more QAs. Be careful OP!

[-]

endurbro420@reddit

Pretty simple here. “Managers don’t give us time to write tests” -> QA testing takes a long ass time. You have a management problem, not a QA problem.

[-]

flundstrom2@reddit

1) Its usually possible to create unit tests/mocks for code written in C or C++. If you're in a regulated field, you are - at least indirectly - forced to separate the pieces of software into safety/non-safety or secure/non-secure parts anyway. Lack of separation between components just makes it harder to prove to the Notified Body that a change in component A doesn't affect component B. If you DO experience issues caused during merging/rebasing, it is a clear sign that two unrelated features are indeed related, and - in order to conform to the regulations - the feature needs regression testing by qa again. The difficulty aries if you rely on complex sensor inputs or fast real-time behavior, external systems you cannot control/emulate. 2) Then it's up to the managers. I know it's frustrating not getting feedback on if the feature works as intended. But if the managers rather catch the bug late in the process, rather than early, then you've got to adjust the development process accordingly. If your managers are fine with waiting weeks for feedback from qa, then they'll have to bite the bullet and wait for you to have time to fix the bugs, deal with the fact additional delays will be caused by your context switches, dealing with multiple branches etc. If you aren't allowed to test to Current Good Manufacturing Practice before handing off to QA, then consider it part of your job to hedge any request to start another feature that you cannot guarantee timely delivery until pending features have been approved by QA, and whenever they report an issue, you need to hedge that fixing it will either be delayed until the current feature is code complete and sent to QA, or the current feature will be delayed until QAs bugs are fixed. The question to the manager shall always be "what shall be DE-prioritized" A broken implementation of a process cannot be fixed by breaking the developers.

[-]

lppedd@reddit

Does QA test manually? How do they write test cases?

[-]

Abject-Kitchen3198@reddit

Writing tests should be a net gain, not loss. It's rarely easier to test everything manually every time we make a code change than writing few tests and run them. And if you can write code that can run on a certain language on a certain platform, you should certainly be able to write code in the same language that executes that code and checks results that are returned. Might be harder if there are interactions with external devices for example, but that's where you would use mocks and still cover most of the code.

[-]

serial_crusher@reddit

Every test performed **by the QA team** has to follow that process, right? If developers do their own testing beforehand, surely that doesn't need anyone's sign off? You should build up a culture of automated testing on the dev side, and let devs own it as if they would in a company that just didn't have a dedicated QA team. Devs test their work until they're satisfied with it, and only then do they ship it to QA. QA can develop and execute their own test plan when they're ready. You should be able to get two benefits here: - devs spending more time testing slows the flow into QA's backlog and gives them more time to clear it - devs spending more time testing makes it more likely a feature will pass whatever tests QA comes up with, reducing overall turnaround time.

[-]

FetaMight@reddit

Look at it this way then; \* Unit tests are to accelerate the developers \* QA tests are for compliance If you don't use unit tests for compliance reasons you can write them yourselves and speed up your process by reducing the chance of regressions reaching QA.

[-]

Abject-Kitchen3198@reddit

Could they write this before the code is written if the requirements are known?

[-]

CuriousConnect@reddit

Your business will die a death by a thousand cuts with this level of process.

[-]

rovermicrover@reddit

Not if everyone in the industry has to follow the same rules and regulations. Planes, medical devices, military ordnances and etc have different consequences for failure than an e-commerce software.

[-]

LunchWhole9031@reddit (OP)

It won't, due to reasons I won't get into.

[-]

hanuruh@reddit

QA takes care of unit tests??? What?? > It would be possible for a developer to learn how to use the testing framework This is straightforward, developers *should* know how to write unit tests, like what you are on about. There's something really wrong in your development flow. How do you know your stuff works? You deploy the code to a testing environment every time? You test in production?

[-]

LunchWhole9031@reddit (OP)

I know there's something really wrong in our development flow, that's why I made the post in the first place :D Like yeah, everyone is telling me it's fucked up, but I already know that... :D

[-]

jpec342@reddit

Devs need to write their own unit tests. It just has to be that way. QA can use the testing framework needed for compliance, and write those tests in addition to the ones the devs write, but devs need to be writing unit test with whatever basic unit testing framework provided by the language/framework.

[-]

deefstes@reddit

Yeah, I think that's your problem right there. Humans trying to test every scenario are always going to be slow. For as long as you can't solve the problem of automated testing and unit testing, you're going to deal with this problem of QA capacity.

[-]

serial_crusher@reddit

> The process mandates that **every feature** is tested by a member of the QA team Does the process mandate the same for bug fixes, internal tooling, refactors that make the code more maintainable etc? You can slow down new feature work and focus on bug fixes and DX, if they don't have the same bottleneck. If done right, that stuff can also decrease the amount of back-and-forth with QA because you'll be writing better software with fewer bugs. If management is demanding new features and deadlines, you need to have a come to jesus talk with them about where the bottleneck is and how they'll need to spend more to widen it.

[-]

neums08@reddit

If developers do not write their own tests, they will have no incentive to ensure the code they write is _testable_. QA should be for user acceptance testing. Having QA write unit/integration tests for code someone else wrote is horriblely inefficient.

[-]

hanuruh@reddit

Yes, idk how this is obvious. I thought this was a subreddit of experienced devs?

[-]

Sensitive-Ear-3896@reddit

If you have 2 devs, and you and dev b push PR's can you help QA test Dev B's PR and have Dev B help QA test yours? Sell it to managers, that PRs will merge faster.

[-]

Basic-Kale3169@reddit

It looks like a management issue. Either reduce the number of developers, or increase the size of the QA team. Having dev and qa out of sync is terribly inefficient and a recipe for disaster. It also looks like your management is incompetent at interpreting the regulations here.

[-]

rabbitspy@reddit

In my experience, manual QA sign-off should not be a prerequisite for merging a PR. Instead your QA team should test and certify a specific commit, perhaps by cutting a new release branch from that commit and having fixes made directly against that branch during the certification process, after which you merge that release branch back into your trunk branch. It’s going to be very difficult to change the process though. Company run like this are generally not very open to process improvements. They don’t have the risk appetite for it.

[-]

Eogcloud@reddit

The core problem is that management is optimizing for feature throughput without accounting for the cost of context-switching and the delay in feedback loops. Making that cost visible and proposing WIP limits are your best levers here, IMO. *Push back:* When asked to start new work while multiple features await testing, explicitly state the risk: "I have 3 PRs in testing. If bugs are found simultaneously, my capacity to fix them quickly will be severely limited." Frame this as a delivery risk, not a personal complaint. Management may not realize the compounding effect. *Limit work-in-progress:* Propose a WIP limit for yourself. "I won't start feature N+2 until feature N is fully merged." This creates backpressure that makes the bottleneck visible to management. If they override you, at least you've documented the concern. *Front-load quality: * Even without formal unit tests, you can be more rigorous. Spend extra time on manual testing before handoff. Write detailed test notes for QA showing what you verified. The goal is to reduce the discovery rate during QA testing, which reduces context-switching later. *Context documentation: * When handing off to QA, write extremely detailed notes: key decisions, edge cases you're aware of, areas of uncertainty. When bugs surface weeks later, this helps you reconstruct your thinking faster. *Ask about the regulations: * Are unit tests actually prohibited, or just not mandated? Sometimes "we don't do X" is cultural rather than legally required. If automated tests are permitted but not required, you could write them anyway to catch issues before QA.