Please watch the video before commenting.
Amongst other comments...'manual testing does not require a huge amount of skill...writing automated tests does'.
Please feel free to leave your thoughts!
There's so much confusion about what "manual" testing is... Even from people who claim to have "advanced" from that field...
Also, why would there be only 2 growth paths? "Automated testing or management, pick one..." --> I choose testing.
The future in "manual" testing can be seen all around us: people want software that meets their (business) needs, and they expect that software to be predictable, as with all machines. What better way to know what your software does than by testing it?
Sadly, many people, including many testers, (still) view testing as what ISTQB and other certification schemes claim it to be: the design and execution of possible/likely scenarios where software can go wrong based on what is stated in a requirements document. In other words: error guessing, based on an old statement of what the software should do, instead of finding new information about what the software actually does so it can be shared with the stakeholders. (And they claim *that* is "structured" testing, just because it's more easily "manageable".)
Even the "test management tools" buy into that scheme. I recently had a demo of one of the big tool vendors. I asked them what they improved for managing a more exploratory approach for testing. The answer was somewhat lacking, as I expected, and the workaround appeared to be to (mis)use the "bug" customizability to be able to somehow log the information that might lead to another interesting test/bug... And all of the major tools I know of, have a similar problem: no support for helping to manage actual testing.
Anyway, people who "advance" from "manual tester" to "test automator", or "developer" for that matter, I think might be better off in that field if they consider it an advancement. And people who "advance" from "manual tester" to a "manager" function might also be better off there. I used to be a developer, and I think it's a boring job; and I have no interest in going the managerial route.
I will, instead, advance myself as tester, and in the meantime try to work on changing how our field is being viewed. And that's quite the challenging job I hoped it would be :-).
Not everything can be automated or should be automated. More than that, until computers are capable of saying "that's funny... I wonder what's going on there" and digging into a newly presented problem, there will be a need for manual testers who are skilled with exploratory testing and know when to discard a script and explore (vs when to note down the oddity and come back later).
I'm skilled on both sides of the fence: test automation and manual testing. I can honestly say I've found more potentially serious issues during manual testing than I've ever found during automated testing (by several orders of magnitude). More than that, I've found problems by reading specifications, use cases, user stories and other such documents. I've alerted other stakeholders of potential problems during project kick-off meetings. These are things automation can't do.
The need for skilled manual testing will not go away. The reluctance of many businesses to recognize this is a different problem, and the reluctance of some in the test community to recognize it a different problem again.
I like the heartfelt responses from Sarah and Kate.
I'd ask you to watch to the video again, but substitute the words "manuel testing" with "developing". It will make as much (or less) sense as the original.
The bottom line of the video is: if you want to grow, you need to learn new things. I can agree to that, all the rest I'd like to discard.
I too agree that there will always be a need for manual testers. There's a lot you can do with automated testing, and for particular types of tests tools are a necessity, but there´s so much to testing that's done best by good old-fashioned critical thinking, asking the right questions and looking at what's NOT specified.
This comes from someone who's on the test automation side, by the way. I just happen to know the limits of my profession :)
I echo Beren's comment about Sarah and Kate's responses. But back to the video - as a manual tester with training as a developer (I originally took the BA route because I prefer to work with the business/customer), I acknowledge the perception presented of manual testing and Sarah's observation that it's pervasive - even in the QA industry. As others have pointed out - there is always a need for gifted and talented manual testers as well as automated testing. My firm addressed that head on a couple of years ago, acknowledged the value of testing and created a dual career path option in QA - manual and automated - with growth potential for promotion in both. I can totally agree with the video that you have to own your career advancement - make the investment, commit to become the best at whatever you aspire to do. It will involve investment of your time and money outside of your employment. Be honest - your firm is not in the education business, but provides goods and/or services to customers.
When we say "manual" and "automated" we know what we mean, but there's not really any such thing as "manual" or "automated" testing. It's just testing using, to some degree, tools.
When this guy says "manual tester" I think he means "tester who doesn't use many tools, doesn't code, doesn't use automatic check execution" etc. He's probably thinking of someone who follows scripts in the ISTQB sense. In this sense it does require fewer skills than real testing. I also think that "writing automated tests", by which I think he means "designing and writing useful and maintainable automatic check execution code", is difficult.
He has, as I think that most others here have spotted, created a world for himself where people choose between ISQTB "manual" testing and automatic check execution creation. There is another way to look at it, and that's to be a tester. Someone who uses tools when it's appropriate (and understands their limitations), and knows how to learn about and investigate software.
That's exactly the problem. There's a difference between skilled manual testing and mindlessly following a script.
Unfortunately, a lot of businesses - and sadly, too many testers - don't recognize that difference, and don't adjust pay scales and the like accordingly. The "any warm body" view of testing is fatally flawed, not least because software testing, like developing, is a wicked problem: there is no simple "correct" answer, no one true technique, and a really good tester can almost sense where there are problems (which is really a matter of observing a whole lot of small cues at a subconscious level and focusing on them without being consciously aware of what's going on).
If you give ten top-notch developers the same set of requirements/user stories/specifications, you'll get ten different solutions that all do the job well.
If you give ten top-notch manual testers the same piece of software to test, they'll all go about it differently, using different inputs, different strategies and so forth - but they'll all find any critical flaws and a fair number of other issues as well.
Many businesses haven't worked this out yet. Neither have many developers or testers - and that is where our education efforts need to start. If our community doesn't recognize our skills, how can we expect others to recognize them?
I completely agree that it's an educational effort. Maybe we should stop referring to ourselves as "manual testers", putting the idea into people's heads that we are the opposite of "automation testers" unable to use tools, granting some respect to the idea that this split dichotomy exists and is valuable, or even that the terms are meaningful in a constructive way.
If we talk instead of being a skilled tester who knows how to leverage a wide variety of tools including automatic check execution ("automation", if we have to hold on to the term) we can be seen to be both ends of the spectrum, and hopefully therefore everything in between, and more, given that we can perform skilled exploratory testing and use a wider variety of tools.
While it might be valuable to reclaim "manual tester", I think it's the same battle against "automation". The terms are incredibly adhesive, and it might be better to create a community of skilled software testers, and make ourselves known as those instead. Abandon "manual tester" as a silly term, and give "tester" or "skilled tester" or "test expert" or some such term a future that fits into an evolving industry. We have to give another alternative to "get out of manual testing into automation".
I'm hoping that the survey we are doing 'What Do Testers Do?' will clarify what it is testers do! Please fill it in (multiple times if there are not enough spaces). We will collate the information and produce something useful (article, video or infographic, perhaps?) that can be shared across the globe - and especially to developers!
This is what I see John had to say: 1. he had personal experience with companies that puts tester equal junior programmer (my company used to do similar, when I started but have changes 10 years ago). 2. He says demand on test automation experts is high and so is a salary, which I can’t disagree. 3. If you are stuck in testing role and want to advance (and you are failing to advance as a tester), then test automation is most probably your choice.
I can't disagree with that message. What I dislike however (and so many of us I think) is John's soreness. Let me explain. As far as I understand John have failed (or never attempted to) to advance as tester himself and we could feel his soreness in the message he is trying to deliver. Of course his soreness offends us. But I feel for him, don’t you?
So True Ainars "poor him" that is exactly how I felt after watching the video ". He seems to have built a very strong opinion based on what he has been thru.
I agree with Sarah that part of the problem is that even amongst us tester there not a consensual vision of what manual testing really is. When we get better at removing the perception that manual testing === absence of skills within our own circle we'll do a better job explaining it to "outsiders".
We also need to stop separating testers into sub groups. I use automation in my testing but I also do a lot of non automated testing but testing is not a predictive discipline. Good testing requires skills
The idea that if you can't code you get into testing and "work you way up" to development needs to be removed as well.
The bigger problem is that while we come up with these concept inside our industry the outside world is forming its concept of testing, how they see it and defining it for us.