Didn't we just have a thread about how shoddy products are nowadays, bug riddled shitty software being the norm because companies know they can sell something that doesn't work in a lot of ways...
Didn't we just have a thread about how shoddy products are nowadays, bug riddled shitty software being the norm because companies know they can sell something that doesn't work in a lot of ways and people will still buy it?
I can't imagine the size of a QA team and the quality of the product are proportional in any way /s
I'm not 100% sure what it is about this article, but it frustrates me in a way where I read it and walked away from my computer and I for some reason cannot get it out of my head. Going to write a...
I'm not 100% sure what it is about this article, but it frustrates me in a way where I read it and walked away from my computer and I for some reason cannot get it out of my head. Going to write a couple things I disagree with and maybe by the end I'll have figured out why it bothers me more than any other article I don't agree with.
I think part of the reason I'm getting frustrated is because I don't feel like I get the article. Who is this being written for? Based on the fact that this is the tech blog of a company selling an AI-powered testing framework I guess the blog target is "someone in the market for a QA software solution"? Which under that lens explains a lot.
Edit: After writing everything and blowing off steam I think it is a mixture of a couple things
I feel like the article is very transparently written to convince you that their product is most likely the solution to your QA problems.
It feels like it was written in a list format for no real reason. 2/5 of the "reasons" for not hiring more QA people is "hire QA people", 1/5 is a sales pitch for their product.
3.5/5 of the reasons are, in my opinion, bad and/or dumb reasons not to hire more QA people. Please for the love of god hire more QA people. Actually, I'll extend that, please for the love of god hire more QA and UX people.
When you create more (and better) automation
Not shockingly this is the first bullet point because it is the selling point of their product. "You don't need to hire more QA people, you can probably solve your problem for cheaper with software (preferably ours)". This just feels a bit weird to me as a point because it feels like the kind of thing your QA engineers would have already suggested? I haven't met an overworked QA engineer (or any QA engineer at that) who hasn't looked around to find out if there was automation software or a tool to make their job easier. Maybe its for devs who take on more of a QA role, or newer QA employees? "Before you hire more people you should look at if the problem is in fact that your process sucks" isn't really specific to QA, though I suppose none of this advice is really specific to QA, its all general advice that maybe you haven't heard before?
When the problem is with development
I'm very conflicted on this point and it was in here that I knew there was something up with the article that grinds my gears that is beyond just the reasons, because in theory I do think developers (in general) are ass at writing tests and testing before handing releases to QA. So in theory I should agree with them here! But there's just something about it that makes me uncomfortable and disagree with them while agreeing in abstract.
When you train and promote from within
Dating someone in HR I know that internal hires and external hires are treated very differently at a corporate and sometimes a legal level, but this just feels like such a bullshit cheeky way to get more items onto your list. "Instead of hiring someone new for your QA team, hire someone from within your company". That out of the way, this is pretty reasonable advice. Especially the example they gave of hiring someone who has intimate knowledge of what your customers are doing or the common user workflows is a huge bonus for a QA team new hire. 8/10 would suggest.
When you can hire a temp QA tester
Again, this feels like a cheap "well technically I'm right" answer. "Instead of hiring a new employee to help manage the workload, hire a contractor"
When your team is small
I'm getting frustrated again and I'm trying to get better at not commenting on things when I am frustrated so we'll keep this short and just say "I think that advice is bad, and is related to why so many companies have terrible UX and so many bugs. The longer you put off hiring QA, the harder its going to be to diagnose and fix issues."
I agree with this. Also, in regards to your first point, I might have a good way to automate something, but it might take a few weeks, and because I've got 15 other things I need to do I don't...
I agree with this.
Also, in regards to your first point, I might have a good way to automate something, but it might take a few weeks, and because I've got 15 other things I need to do I don't have time to do it and may never, even if it will help in the long run.
If you add someone to my team, suddenly I might only have 8 things to do and actually do have time to automate things. Tada, expanding the team AND automation, it's a miracle.
I have run a software consultancy for 8 years, and the best thing we ever did was add an official "Developer QA layer" into the mix. This simply means, another dev tests another devs code (after...
I have run a software consultancy for 8 years, and the best thing we ever did was add an official "Developer QA layer" into the mix. This simply means, another dev tests another devs code (after code review / PR is approved), and before it gets to classic QA.
I think this had multiple benefits: Developers are good at thinking about non obvious issues "between the cracks", the devs starting thinking (even unconsciously) that their programmer teammates will be finding their bugs, which in turn naturally morphed into people doing their own layer of "self QA" before hand. Now you would have hoped peeps would do all that anyways - but I think think "Dev QA" just made people more mindful of the entire process.
As an overworked QA Tester, please hire more.
In the 4 years since I started we've had 4 coworkers leave and only brought 1 new one in.
Didn't we just have a thread about how shoddy products are nowadays, bug riddled shitty software being the norm because companies know they can sell something that doesn't work in a lot of ways and people will still buy it?
I can't imagine the size of a QA team and the quality of the product are proportional in any way /s
Well hey she doesn't mean NEVER hire testers. The article links to "when you SHOULD hire more people" and that includes, "when QA or Dev asks you to."
I'm not 100% sure what it is about this article, but it frustrates me in a way where I read it and walked away from my computer and I for some reason cannot get it out of my head. Going to write a couple things I disagree with and maybe by the end I'll have figured out why it bothers me more than any other article I don't agree with.
I think part of the reason I'm getting frustrated is because I don't feel like I get the article. Who is this being written for? Based on the fact that this is the tech blog of a company selling an AI-powered testing framework I guess the blog target is "someone in the market for a QA software solution"? Which under that lens explains a lot.
Edit: After writing everything and blowing off steam I think it is a mixture of a couple things
Not shockingly this is the first bullet point because it is the selling point of their product. "You don't need to hire more QA people, you can probably solve your problem for cheaper with software (preferably ours)". This just feels a bit weird to me as a point because it feels like the kind of thing your QA engineers would have already suggested? I haven't met an overworked QA engineer (or any QA engineer at that) who hasn't looked around to find out if there was automation software or a tool to make their job easier. Maybe its for devs who take on more of a QA role, or newer QA employees? "Before you hire more people you should look at if the problem is in fact that your process sucks" isn't really specific to QA, though I suppose none of this advice is really specific to QA, its all general advice that maybe you haven't heard before?
I'm very conflicted on this point and it was in here that I knew there was something up with the article that grinds my gears that is beyond just the reasons, because in theory I do think developers (in general) are ass at writing tests and testing before handing releases to QA. So in theory I should agree with them here! But there's just something about it that makes me uncomfortable and disagree with them while agreeing in abstract.
Dating someone in HR I know that internal hires and external hires are treated very differently at a corporate and sometimes a legal level, but this just feels like such a bullshit cheeky way to get more items onto your list. "Instead of hiring someone new for your QA team, hire someone from within your company". That out of the way, this is pretty reasonable advice. Especially the example they gave of hiring someone who has intimate knowledge of what your customers are doing or the common user workflows is a huge bonus for a QA team new hire. 8/10 would suggest.
Again, this feels like a cheap "well technically I'm right" answer. "Instead of hiring a new employee to help manage the workload, hire a contractor"
I'm getting frustrated again and I'm trying to get better at not commenting on things when I am frustrated so we'll keep this short and just say "I think that advice is bad, and is related to why so many companies have terrible UX and so many bugs. The longer you put off hiring QA, the harder its going to be to diagnose and fix issues."
I agree with this.
Also, in regards to your first point, I might have a good way to automate something, but it might take a few weeks, and because I've got 15 other things I need to do I don't have time to do it and may never, even if it will help in the long run.
If you add someone to my team, suddenly I might only have 8 things to do and actually do have time to automate things. Tada, expanding the team AND automation, it's a miracle.
I have run a software consultancy for 8 years, and the best thing we ever did was add an official "Developer QA layer" into the mix. This simply means, another dev tests another devs code (after code review / PR is approved), and before it gets to classic QA.
I think this had multiple benefits: Developers are good at thinking about non obvious issues "between the cracks", the devs starting thinking (even unconsciously) that their programmer teammates will be finding their bugs, which in turn naturally morphed into people doing their own layer of "self QA" before hand. Now you would have hoped peeps would do all that anyways - but I think think "Dev QA" just made people more mindful of the entire process.