Professional book writers still have proofreaders and editors up to this day, but why is it that there's a rush to drive away manual testers?
There's probably an AI tool somewhere out there to check the book's grammar and spelling errors. But what the AI cannot do (for now) is assure the quality of your book - ensuring consistency, style, voice, the quality of how the sentences are written, and identifying plot holes. How good is the story overall? What specific plot points can be improved? Are the characters well-written? Is there enough build-up before the climax?
Comparing this to software testing, I believe that the same thing applies. Testing beyond what the requirement tells you, beyond what you see in plain sight is where the real value of a QA stands.
However, from time to time you'll see companies or hear some people undermine the value of QA. Some even think you don't need any skills to do this. It's like they're saying you can pick up any random person on the street and they'll be able to do what we do immediately. Basically, making it look like a mindless job? It's insulting and very demotivating to hear, especially the last one because I take pride in what I do and I make sure I do my best in what I do.
Do we need a better term for our role?
When you search for a job posting, you'll see a lot of different terms.
- QA Analyst
- Manual Tester
- Software Tester
- QA Engineer
- etc
But when you look at the list of responsibilities, they're basically the same.
Personally, I don't get it :P
In my experience, I don't see the need to have a difference because we actually do both. I've never been in a team or company where the role of assuring the overall testing process and strategy vs. the actual work to find bugs are separate. Instead of these different role names, it would be a more senior QA driving the first one while the junior ones do the latter.
If I need to pick among the 2, let's just stick to using the term QA. We are "quality assurance". We set the bar of quality in an organization. It's important for a company to understand this so that the QA team can have a spot to voice out and implement the quality bar, and for everyone to respect it and follow through.
All eyes on test automation
Let's take a step back and try to look at it realistically.
Test automation is a tool. You can automate a thousand tests, but if you don't have good tests then how much value are we really getting? On top of flaky tests? On top of the amount of initial investment with regards to the manpower and the amount of time it takes before you actually have a stable suite? On top of the maintenance effort when a new feature impacts an existing test, when the test data is no longer valid when a change in the test framework breaks the tests? What about we switch to Cypress? How about Playwright? Oh let's just go back to Selenium. Oh, a specific step cannot be automated?
The thing is, it takes a lot of effort and skill to have a successful test automation.
In all my years in this field, I haven't seen a test automation effort that actually made me confident that I don't need to check the app manually to ensure it doesn't have issues. Am I just unlucky or is this a normal occurrence? I'd really love to see how a successful one works.
Test automation doesn't assure quality. It's the TEST that assures quality. The automation part just speeds things up. It's important to have a good test automation strategy. The sad thing is in some cases the test automation engineers don't really know how to test. They wait for someone to tell them what the steps are, and what the validation points are before they create the automated test script. They're people who know how to code but have no testing mindset.
The testing mindset should be the center of it all. Before starting any career path related to software testing or being a QA the most important thing is to learn how to test, what to test, how to determine these things, where to look for flaws, and knowing what could make the system break.
Test automation undoubtedly provides value by running a lot of tests in a short amount of time if you do it right.
The pressure to deliver quickly with quality
Companies have a high demand for a QA to have a skill in test automation. Everyone wants speed, and to get out the latest product right away so there's a lot of pressure for a QA team to ensure quality in as short a amount of time as possible.
The problem is that it's not easy for a person who only does manual testing to shift to automation and do it effectively in a short amount of time. I'm not a Dev so I'm not sure if this comparison is correct, but isn't it like you expect your seasoned front-end dev to immediately do the work of a back-end dev effectively? The difference is that it's probably easier for a Dev to make that transition since they already know how to code, but it could be difficult for a manual tester who never had experience writing code before.
This is where the pressure comes in because being able to create a test automation suite with no coding experience is difficult. The solution? Let's have developers create the automation suite. But then, their tests are bad. Thinking about it, this is probably why a successful test automation initiative is rare.
I've read an
article that says this:
“In my experience, great developers do not always make great testers, but great testers (who also have strong design skills) can make great developers. It’s a mindset and a passion. … They are gold”.
As you see, there's a great demand for "full stack QA" - a person who can code but also has a testing mindset.
I wish there could be more support from companies to upskill their QA to learn how to code. Realistically, the QA has to take time outside working hours and spend their weekends learning about coding. Of course, this is admirable and really good if you're passionate about evolving your role. But I acknowledge that not everyone has the luxury to do that, and some people have boundaries regarding their working hours. I wish companies could send QAs to coding boot camps or provide any sort of training that isn't rushed. In our daily work life, we are swamped with requirements to review, discussions to close, features to test, bugs to retest, and processes to improve. I wish QAs would be given the capacity to focus on test automation because it's not something they can be good at if they only have 2 hours a week to do it.
Conclusion
In an organization where the value of QA is continuously questioned, I hope my fellow QAs don't get discouraged. You know your worth. In these difficult times, this is where you need to be strong because you need a lot of energy to make them understand. It's our job to make them understand. Don't be afraid to set the quality bar, don't be intimidated.
As always, there's no universal solution to these QA challenges. It will always depend on you, your management, and your company culture. How your company understands the value of QA is also how they give importance to the quality of the product. If your company already understands the value of QA, that's great. For those who still need a little(?) work, I hope you succeed.