Every time someone needs to change anything nontrivial, like a large feature or a refactor they just code away blindly, hope it doesn’t make anything explode, and then wait for QA to pat them on the back or raise any potential bug? Does this mean your QA team makes a full product sweep for every single feature that gets merged? If that’s the case, you’d need more than 1 QA per developer. If not, you’re now stuck debugging blindly too, not knowing when the thing broke?
I worked with a team like yours at one point, and it was hell 😬 Each new feature is like poking away at a black box hoping it doesn’t explode…
Just dont write tests lol, that’s what QA is for.
This guy’s a business major.
(He just fired half of QA)
Hell no! I love QA, they find all the bugs I make since I dont bother with unit tests. I think every dev team should have 1:1 devs to testers.
Every time someone needs to change anything nontrivial, like a large feature or a refactor they just code away blindly, hope it doesn’t make anything explode, and then wait for QA to pat them on the back or raise any potential bug? Does this mean your QA team makes a full product sweep for every single feature that gets merged? If that’s the case, you’d need more than 1 QA per developer. If not, you’re now stuck debugging blindly too, not knowing when the thing broke?
I worked with a team like yours at one point, and it was hell 😬 Each new feature is like poking away at a black box hoping it doesn’t explode…
On the internet, nobody knows when you’re being sarcastic.
Indeed!
What do you do when QA finds a bug though? Just fix it without writing a test to ensure it doesn’t happen again?
Fix it then hire another QA