Testing role , test automation - will be clubbed with developer role?

I want to here your feedback on the below comments and decision taken by our mgt

At my company, my boss says, "I pay developers to write high-quality code, not to create bugs or slow code. You need to clean up your own mess(actually called shit); why should I ask someone else to do it and jeopardize their career? Everyone values their career, just like you do. QA, test automation, SDET – whatever you call it – is part of your role as a developer, not a separate job.

You might argue that the same person who writes code can’t find bugs, but that’s a mindset you’ve developed and been influenced by others. You need to fix your mindset and your bugs. If you code with bugs, don’t expect me to allocate time for someone else to fix them. You need to manage your time and not expect me to give you 50-100% of a developer’s time to fix bugs in the same code.

I understand that we’re human and mistakes happen, so I allocate 5-10% of development time for future bug fixes, depending on the feature’s complexity. Anything over 10%, you need to find your own time. Clean up your own mess, and you’ll stop shifting blame. This may sound harsh, but it’s the reality that everyone will eventually face, especially in product-based companies. I don’t want to sugarcoat it.

You can keep working in denial and continue to switch jobs until reality hits you hard. All quality and test engineer roles will eventually be merged into equivalent developer positions, and so will the expectations. The choice is yours. But there is no human job role solely focused on testing or QA."

I want to hear your view on this

  • Is the merging of QA/testing roles into developer positions a growing trend in the software industry, particularly in product-based companies?
  • What are the most effective strategies for developers to take ownership of quality assurance and testing throughout the development process?
  • How can developers balance the expectation of bug-free code with the reality that mistakes are inevitable?
  • What are the potential benefits and drawbacks of integrating quality assurance and testing into the developer’s core responsibilities?
4 Likes

Albert Einstein said, “You cannot solve a problem with the same mind that created it .”
That’s not to say the same person can’t address issues or review their work but changing mindset from a creator to a critic takes a lot of discipline. Testing and developer mindsets have different focus for good reasons. I would suspect the long term quality of software developed without specialist critical thought from a tester would be less than it could be.

3 Likes

We did say this
He said

" some other Nobel person also said -change is only constant …so don’t give me those philosophy

Do we or IT work same way as we did even 5 years ? Wake up buddy "

1 Like

I may not agree with how the message was delivered. I agree with the overall premise.

If I as a developer write code and don’t test any of it. How would I know I’m done coding? If I write a couple lines(or a lot of lines) and pass it off. This just screams slowdowns. If I write the code, I should know how to test it. Or better yet. I should have written the Tests First then coded to the tests (TDD).

Now that doesn’t mean QA aren’t needed. They most certainly are. However, I don’t see them merging in with Developers. That’s where like SDETs happen (Software Developer Engineers of Tests), they’re still Software Developers, just with a specialty in Testing Automation.

A strategy to help with this is the 3 Amigos, get the Dev, BA, QA in a room and go over the story(s). See what the test cases are, what can easily be covered in code and automation, what needs to be manually checked. This will help speed up the development, the testing and helping get proper understanding of the requirements from the business.

There is also no such thing as bug free code. It’s just minimizing the impacts of the bugs. Some bugs, I’m okay with pushing to production and creating some defect items to work on later provided they have a very low risk level to the business or the client.

At my company, we are going with the approach if it’s a backend change and has no visible change to the client, or no work flow change. Let the computer do that testing. After 3 Amigos, I know what I need to cover in my automations. If the change affects the UI or the client flow. Then we have QAs test manually so they can see the experience and workflow.

Computers are really good at regression. You tell it exactly what to do and it will do it every time.
Computers suck at testing so let people do the testing, go explore be creative and find the bugs.

EDIT: Also welcome to the community :slight_smile:

1 Like

QA is a mind-set, most developers (sorry to generalise) do not have. Do not get me wrong, they don’t set out to make mistakes and should always review what they have created before allowing others to review, but there are always things that the author/creator does not see.
Sometimes, they are unable to see their own mistakes which is why having a degree of separation is more effective at highlighting these events. The greater the independence, the more effective the review is i.e. another developer reviewing the work, QA team member within the squad/agile team, External QA resource etc

To answer some of your questions;

I don’t feel that is a trend of merging QA with development
Not sure whether this is a strategy, but whenever I create anything such as test case, bug report or email - I do read it back and review at least 3 times before “submitting” - You would be surprised at how much you change by doing so.

1 Like

Thank you team for suggesting …looks like my company getting crazy …thanks again

3 Likes