Can we say there are job cuts for manual QA with the growing demand for automation.
2 Likes
Hello @ashugupta34480!
I might say that where the types of products built lend themselves to evaluations through automation, less manual evaluation (I wonât say manual QA because one cannot âQAâ anything) may be performed. Indeed, less manual evaluation may not even be necessary fro some types of products.
Presently, I might say that the purpose and use of manual evaluations may be shifting from system/integration types of evaluations towards UAT types of evaluations. As automation methods evolve, even UAT types of evaluations may become more automated.
I believe we may be seeing the start of a tipping point where people who perform manual evaluations may experience changes in their responsibilities. This, in my opinion, has been growing for some time. I believe it is the reason that this forum and other forums (blogs, social media) have entertained conversations about learning to code, learning about system construction, and other up-skilling recommendations.
With the introduction and practice of agile methods, I believe a close collaboration between tester and developer becomes normal; quality is a team sport. In that manner, people in testing roles - manual or automated - not only evaluate product behaviors but become strong advocates for quality during requirement creation, product design, and unit testing.
Joe
4 Likes
I would rather say that sofware testing is a young industry which is constantly evolving to meet the needs of the teams who use it.
I would also say that the practitioners (artists) who are involved in software testing should try really hard to keep up with the evolutions.
I would also say that the room in technology-as-a-whole for those who donât is shrinking.
2 Likes
Somewhat a tangent but since I learned about this last week itâs top of mind for me.
With regards to the question. Does the product do what we want it to do (Verification) there is a huge movement towards automation and rightly so.
With regards to the question. Is this the right product (Validation) there is not really much you can do in terms of automation. And even if we had a huge dip in the 90âs regarding solving the first problem we are slowly recovering. This means that we have time to start advance the second question. There are already movement in that department with Lean Startup and Pretotyping. The shift is that you also need to test your ideas and assumptions to be successful. The number of products that never makes it is still very high. And the principles for how to test those ideas are not unlike those of testing the produced product. So on this regard testers could move more towards that direction and helping bushiness to get feedback on the validity of the ideas on top of the verification of the product.
Then a side note on the first problem as it was presented to me. The number of programmers is doubling every 5 years. Which means that at any given time half of the programmers have less than 5 years of experience. They are bound to continue to make mistakes. And given the rates of how many mistakes we make in terms of the correctness of products does say that no way will automation be more correct hence the need for manual testing will not go away any time soon.
3 Likes
Looking back over the years, this question has been posed over and again, albeit in slightly different formats.
Quality Assistance comes from both Automation and Manual validation. Both are intertwined and neither should be considered as the one and only, the âholy grailâ.
Test Automation and Automated Tests should be designed, in such a way so as that they complement Manual validation, and vice versa.
The benefits of running both work streams far outweighs a single solution and therefore, in my opinion, Automation is not and, more to the point, cannot take away the necessity for Manual validation.
Personally, I donât think we can say there are job cuts for Manual QA, but I do see the need to evolve and adapt, to compliment the ever-increasing world of automation.
4 Likes
There will always be a need for manual testing - scripted and exploratory. If an application is being developed to be used by a human, then it should also be tested by a human. This doesnât mean that we shouldnât be included test automation as well, but we should recognize that test automation is a tool that can enhance testing, not completely remove manual tests.
Will test automation lead to a drop in demand for Manual QA? I hope not, but would it be so bad if demand increased for QAs who can do both manual and automation?.
I donât think that testers should be specializing in either test automation development or manual testing. Iâve only ever been in roles that require both. Understanding the pains of the current test process has helped me improve it using test automation.
A good tester should evolve, develop new skills while not forgetting the old ones.
6 Likes
I am sure compilers removed the need to use programmerâs time to some activities.
Have it caused a decrease of the need for programmers? Probably not.
1 Like
Undoubtedly the testers plays significant role in manual testing to discover the flaws in any application. They also verifies that application features are functioning appropriately and no deviation is there.
In addition, automated execution of test cases is fast and can speed up the testing process. It could be a replacement for manual testing which is tedious and time consuming. However, in quality assurance services organizations, manual testing has a vital role in the QA processes. Manual Testing is the simplest of all testing techniques. A manual tester needs to cultivate a habit of sophisticated about all they see and observe the things. Above all, there is no requirement to use any automation-testing tool.
None of the automation-testing tool have the capability to completely substituting manual testing.
Thus, the assumption that automation testing is eradicating manual testing is not true. Only motives for using automating the testing processes is to save time only. A manual tester should have expanded knowledge as well as interests to learn new things, as it does not harm manual testing anyway.
Hope this information is helpful for you.
1 Like
Ultimately, using automated testing only will deliver applications that work perfectly as long as the users know how to use them. But a user coming to the app cold, without training (if appropriate), will find the app unhelpful at best, and unusable at worst.
A couple of years ago, I encountered a supermarket customer service terminal that I gave up on in disgust. First it needed to read my loyalty card - but the reader was broken. So I had to enter my address manually. But instead of entering the (UK) postcode first and first line of the address second (thus drilling down from an area to an individual address), it asked for first line of address first and then postcode second. But my address appears on different databases formatted differently, and one of them is âwrongâ (not the address I was given when I moved into the property). So I entered first line of address and postcode, only to be constantly told âNo such address at that postcodeâ.
And although this was run on a touchscreen terminal, you were given two fields at the top of the page, and a âNextâ button, in the form of an arrow to the right at the bottom right of the page, like so:
Field 1 (top left of screen)++++++++++++++++++++++++++(top right of screen) Field 2
Next>>>>
So with a touchscreen, youâd expect to touch field 1 to enter text, then touch field 2 to enter text, and then go to the bottom of the screen to touch âNextâ and go to the next page.
Except you didnât. You actually had to use the âNextâ button to navigate from field 1 to field 2, even though it didnât look as if that was the correct workflow. After three different attempts to use this terminal on three different visits, I gave up and wrote to the supermarketâs CEO to say why. It was clear to me that this app had been through automatic testing, because everything worked the way it was designed to. But it was also clear that the app had never been subject to any manual testing, as that would have soon shown that the app was totally useless to even an above-average user (he said, modestly) unless youâd read the specification document!
(I pointed out what my Day Job was, and hinted what my usual invoice for that sort of report would be. 
When they wrote back, the CEO admitted that the app was due to be replaced within the next three months but didnât offer me any money, not even a supermarket voucher. Iâve not tried its replacement yet.)
Automation is great for checking, as a previous poster said. But any app that is only subject to automated testing is going to fail sooner or later when faced with real world users in real world situations. And to prevent that, you need âmanualâ testers. Or you need to be able to explain to your CEO why they are getting snotty letters - or even invoices! - from members of the public.
3 Likes
My personal opinion, is: anyone who doesnât QA as a regular job, doesnât understand QA, canât think like a QA, should never make an executive decision that only automated tests are needed and only QAs who can automate should be hired.
Automation only targets what you specifically ask it to do. Think of a laser beam, that targets a specific location. Now think of how you manually test something. You start with that laser beam, then you start breaking off into different directions, the streams cross, itâs like hitting a mirror with multiple angles. Maybe you find an issue going down this path, or maybe down this path. Or maybe some combination that you didnât expect produced an issue. These paths allow you to think about how to automate it. I can only think of so many automated tests without digging in to the app, which is me manually testing it.
Automation is great for repetitive tasks. If you have a large enough department, cool. I am one QAE on a very busy iOS team. If I only focused on automation, there would be an opportunity cost; sacrifice exploration that allows you to learn the feature, explore the feature, break the feature, and so on or spend 100% of your time building and maintaining automated tests that are time consuming, donât learn, donât self-heal, arenât regarded highly by the devs who break them by accident and offer no challenge once the architecture is mature.
Automate what you can; the parts of your product that must work in order for you to move to production, but if you rely 100% on automation, you will miss 100% of what those tests donât touch.
1 Like
The laser beam is a great analogy for an automated check.
However, a skilled tester does not start with a laser beam. Thatâs an incredibly important distinction. Each time they go through a linear set of actions, theyâre dragging a net of test awareness through each entire page, which gathers the data from dozens of checks for any single action.
A tester does not need any script, any plan, or any test cases to quickly and satisfactorily start testing a feature and provide valuable feedback and bugs in less time than it takes to write a couple simple happy path automated checks.
5 Likes
Yes! I often tell people that when I am testing a feature I am also actively regression testing it by virtue of how many things I touch in a given test.
In terms of the laser beam for manual testers, I do equate this to the mindset of: does this feature work in terms of the requirements? At face value, can I get straight to the end result? If I canât, I send it back. After itâs fixed and I can achieve the desired end result, the net sweep truly kicks in. Otherwise, I have other things that do work to test! 
1 Like
Ha! I tried the âthatâs my day jobâ with Babbel when they recently introduced a new feature that was broken at day one. After giving me the usual uninstall / reinstall run-around I provided them clear repro steps and screen shots and suggested they may want to consider compensation for my time. Ended up with two weeks extra on my subscr
2 Likes
If you have manual testing and no automation testing, it will be slow, but possible.
If you have automation testing and no manual testing, it wonât be possible. How does the automated scripts get made, knowing what tests to do, the journey through the workflow/user journey? By someone manually going through first.
Demand for automation is growing, as it allows SOME testing to be done quicker, allowing you to spend less time testing or get more testing done in the same amount of time.
But if people push for it at the cost of manual testing, it will bloat and there wonât be enough manual testing to feed the automation testing. This will lead to less automation, or their time spent on other activites, such as maintaining their scripts because it canât handle a field moving or being renamed, for exampleâŚ
2 Likes
This talk about âpositionsâ or not is kind of weird. But it is a bit of our nature. Sometimes certain changes are annoying.
About manual test: There is still no way to be 100% automated, we have good numbers in automation, but part of the service is still taking and seeing as a human. Even developers still need to code âmanuallyâ too.
2 Likes
Lots of software is built for humans.
Would you rather the first humans to use that software after itâs coded were your customers, or your employees?
The answer will tell you why automation will never completely replace manual testing.
4 Likes
As always, the details are in the words.
Can we say there are job cuts for manual QA with the growing demand for automation.
If you mean it as pure manual vs pure automation - Then there may be a trend amongst higher management that want the silver bullet of automation.
If you mean.
An individual that can do manual testing inc exploratory, etc and understands when and when not to apply automation. Then that is the individual that I want to hire.
Iâm always of the view point that you need to understand the flow, the process before you can automate it (if needed). Sometimes the test doesnât need to be automated because over time, youâre not going to learn anything new.
What we need to concentrate on, I feel is the upskilling and knowledge of a QA.
They need to be able to communicate effectively with all levels of people, they need to understand their chosen domain. They need to be able to look at things and challenge people, assumptions and processes. For me, that is of a higher value than being able to code.
Yes, being able to code is a benefit, but itâs just another tool in a QAâs toolbox that they can use.
5 Likes