I was the only QA in a team and was supporting multiple developers. Since I was mostly overloaded with work, the engineering manager often asked the Devs to help with testing. He refused to hire another QA (contractor or full time). Honestly, manual testing by Devs seemed to be going ok for a few months. So I wonder if its a good idea to let Developers test, provided they are smart and know a bit about testing.
What are the pros and cons which you experienced when Devs helped you with testing regularly ? Please talk about your own experience and avoid hypothetical scenarios.
PS -
It seemed like some of the Devs were unhappy due to all the extra QA work (manual and automation testing) that was added to their scope. In addition, with the use of AI, management expected them to produce even more. Some Devs mentioned they were working a lot of extra hours and were irritable. I understand that Devs should also do more than unit testing and some smoke tests. But, this was not the job requirement when they joined many years ago. Its not clear if the increased responsibility was matched with more compensation.
i wouldn’t use developer testing as a permanent substitute for QA capacity. it works best when developers own checks around the change they made, while QA owns risk discovery, cross-feature behavior, and the test strategy.
for browser changes, have the developer attach the starting state, exact action, expected result, actual result, and first useful console, network, or trace signal. that keeps QA from retesting blind and makes review faster.
the warning in your example is the overtime. if testing was added without dropping other delivery work, the process is not working even if bugs are being found. track escaped defects, investigation time, and after-hours load for a few releases. if all three rise, management has shifted the bottleneck rather than solved it.
Hi Nitin Segal.
It is very strange for me that devs do QAs work. Good thing is that they create unit tests and maybe, do quick check of features before deploying them on testing. If you find obvious things, that could be fixed before deployment, than it is a problem. Here can be a lot of reasons why they have missed, but I do not know how things work behind the scenes there.
I agree with dwaynesamuels about management.
I can only add that I am not engineering manager but I can understand why manager refused to hire new QA, excluding reasons: money, global crisis, not the right time and so on. You, maybe, do not see the full picture.
In general, devs know how to test based on their point of view, experience and so on, but in most of cases they do not look as user on the product, project, app. Sorry, I would not be so sure that what they have tested is ok. It can be ok in scope of the task, but user always can find something new without going out of scope .
One more thing, cruel, but it is necessary to hear, you should not be involved in showdowns between devs and managers. Yeah, I know that your work depends on them too and you can still listen about devs dissatisfaction, but not more. Yeah, I also understand that maybe you want to help devs and subconsciously think that you will break good relationship with them if you don’t. It will not happen in the way you think or imagine. But, if you wish to see all consequences of your involvement, I am not the right person to stop you. In all cases it will be an experience.
Developers are often very good at automating coverage of the things that are believed to be known very well, some teams also get QA to do that but that usually comes with a layer of inefficiency or allows a lack of due diligence from developers, however when it’s this it can normally be moved around between roles provided that due diligence is there.
It is harder though for a developer to context switch into the unknowns, the risks a QA must discover and investigate, part of that is the depth of training needed but it also can go quite deep into a risk and take time, so even if a developer can do this it would likely take the whole project off optimal speed as a result.
Then you have the test your own work angle, this works for the things you know very well but not for the things you don’t, your own bias brings you back to what you do know so having someone with a greater distance from that bias makes that interchange harder. AI testing its own development where the learning was done on the same data also carries that distance and bias risk.
Then finally developers are wonderfully human even when they leverage AI they are fallible, might not have had their coffee that morning, to a QA that is a risk that then will consider as they test.
AI is lowering the bar into other roles activities, QA are doing deeper root cause analysis now as the tools made this easier, some are also now doing code fixes for the things they find.
One thing that has not shown up too much yet is decision making fatigue, if you are actively testing unknowns your critical analysis and thinking are your primary always on skills, developers also have high levels of this skill as the develop the product, taking on more activities could compress the amount of decisions an individual makes in one day so could overload them.
