How To Improve Junior QA Engineer’s Position In The Market?
Few days ago I had a privilege to read a discussion about should novice QA person be allowed to write tests for automated execution. I enjoyed the different opinions very much and I saved my opinion for this article. I think it would be too lengthy to share. The premise was that this complete newbie QA engineer should not take part in automating tests. The reason behind such opinion is simple. They do not have the experience to decide what to automate which can cause more problems than joy. The QA engineer has to have some experience with testing under his belt to be able to know which tests are valid to automate and which ones to skip. I started thinking about this and spent quite amount of time trying to agree and disagree with this opinion. The following is my criticism of the the current state and an answer to the question – how to improve QA engineer’s position?
The context matters
I would say that in such contexts where there is just a single QA engineer in a development team the above premise makes a lot of sense. Someone without experience cannot make good decisions about automated tests in such environment. But again, we all have to start from somewhere, maybe just as a QA engineer performing just manual testing? In general I am not a fan of such environment where there is a strict division between testers executing tests manually and those who write automated tests. I would be against such style of quality team distribution as I don’t see it effective.
What about situations where there are multiple QA engineers working together in the same team? Here we have some authority which can help in the situation from above. Of course, it depends on the knowledge and ability of the senior colleague. These situations with multiple QA engineers in the same team are not so often. Why not, where is the problem?
The problem
I am the problem. And not just me, but also other QA engineers who are already working in this line of work for some time. What do I mean by that? Let’s try to see things from different perspective.
Older generations of developers with 30+ years of experience used to do programming, DevOps, testing, everything. But things have changed in the past 30 years. When the business owners said that developers cannot do everything on their own, they got help. At first, testing was moved to a separate role. Then someone said that developers cannot do operations and suddenly we got DevOps as a separate role. Also, someone said that architecture of the system should be decided by the most experienced developers. We got solution architects, we got SQL developers, the division between front-end and back-end developers, etc. This was an evolution of the programming roles. Today when we want to setup an ideal team we would hire one architect, a few developers full-stack or FE and BE, then we need someone to do the DevOps part and finally we need 1 QA engineer.
One QA engineer can cover everything, we don’t need more than that. Of course, this one QA engineer would have to cover manual testing and writing automated tests, setting up pipelines in CI/CD tool. He would have to understand and engage with performance testing, security checks and design best practice. He must be familiar with different architectural styles for creating robust test automation frameworks. API understanding is a must of course.
The consequences
Now, every senior QA engineer knows pretty much all of this because we never had any other options. When I was told that my team should adopt performance testing, I sat down and learned enough about it to do it. The point is, whenever we face a challenge we find ways to conquer it. This is not sustainable. The developers started delegating parts of their work to other team members. We still do everything on our own. Then we copy/paste posts on LinkedIn how people who want to hire person who knows JS, Java, C#, Typescript, Python, Selenium, Cypress, Cucumber, Jmeter, Jenkins, Azure DevOps, Docker and Kubernetes are not looking for a single QA engineer but an entire QA team.
This is our fault. All of us who just pick up whatever falls in front of us.
We are the reason why junior QA engineers face so many technologies they have to know to get a job. They simply cannot meet the expectations of such market.
On the other hand there are double standards in the industry. No one asked should junior developer be given the task to write code and push it to main branch? Why is that? Because there are mechanisms which would prevent creating any mess. Developers follow different practice. They work in teams, they do ensemble programming, in worst case scenario they perform code review. The code review is mandatory not just for junior developers, but senior developer’s code is also a subject to code review.
Do QA engineers do pair programming? Do we perform code reviews? In small percentage of companies probably yes, but the disparity between these practices in team of developers and team of QA engineers is huge.
The fix
How to improve QA engineer’s position? We must change our approach to what we do. It appears that we diminish ourselves by not deploying mechanisms which were recognized by best practice. Hiring junior and total beginners for a role of QA engineer with idea to write automated tests is not a problem. We, the so called seniors of the industry must create such environment where knowledge transfer and on-boarding are performed seamless. It is our job to create such processes and mechanisms so the junior QA engineer cannot make a bad decision which would slow down the development process. They should learn from us how to ask proper question. We need to fight for better work conditions for junior QA engineers then those we had when we started. We need to fix our mistakes.
