It has been a while since I last had the time to sit and write a post here, so I guess I am now a bit rusty and hard to start, I have all these crazy ideas fighting in my head and it’s really hard to make them sit in their spot until their turn comes, or just until I have a clear vision of what’s it all about that I want to write for.
I am already one year and a couple of months in the QA business and I can say I learned a lot of stuff and there’s certainly a lot more to learn coming. But I am not a shy guy, I don’t feel I should be for any reason and that’s why I chose to comment on a topic that I feel is going wrong in software testing.
Labels – are you on the manual side or on the automation side?
Well I guess the answer here is a Matrix like one: “There’s no spoon.” in first place. Why do people still label testers with automation and manual? I see this everywhere – “we are hiring people for manual testing only”. So what should that mean? They are hiring “clicking/tapping monkeys”, or that the job there would be boring and not catching up with the latest tendencies in testing? And I see people going extreme when it comes to manual vs. automation testing. I’ve heard stuff like: “It’s a good automation framework but it won’t help you validate if user interface looks good or is usable”. Well, of course it wont, it was never meant to. I feel like many of the testers act like doing automation, they will never do manual testing again or believe that when start doing automation, somebody will probably rip their brains out of their bodies and put them into this Robocop-like suit, where they will never have human feelings ever again and will never be able to simply do exploratory testing or any other manual testing strategy. On the other hand, the “only manual” defenders fail to give a good reason on how you are testing performance with “only manual” testing methods, for example or security or just simple functional tests of the application. I believe that hiring a 1000 monkeys to tap on a button or perform a log in is a way, but let’s stay focused on reality.
The idea is…
What I am trying to say is – it’s not that simple. You know, dividing software testing in manual vs. automation testing isn’t as easy as determining what transmission does your car have. Yes, there is people who are more likely to understand code and complex tools and scripts, and there’s other people willing to touch things and explore them with their hands, but I really don’t think that’s the reason to treat both approaches as if they were something different. Why? Because after all, testing is a mental process, this is what you do in your head, trying to figure out complex scenarios how to expose a system’s weak spots or security issues or whatever. And it has nothing to do with tools, plans or test cases, in other words testing in general answers the questions “What am I doing here? What is my purpose in this team?”. And manual or automation approach is just a “tool” that you are going to use, to fulfill your plan. It really is as simple as that. In other words manual and automation are answering the “How am I going to do it?” question.
Conclusions.
As we think of it, the reasonable way to approach testing as it is – as one whole and complete thing. Even if you are so called “automation tester” you will need to perform manual testing at some point – to check usability or any other non functional aspect of an application. And there’s nothing wrong with that, you won’t loose your reputation as a good “Robocop” if you do some manual tests.
As for the manual testers, you shouldn’t be afraid to do automation at any point. And it really doesn’t matter if the title says manual or automation tester. Does it include coding/scripting skills? Not really, there is plenty of recorders and other tools with user interface that has nothing to do with coding. Does it mean to be technical? Yes, of course this is what QA means in general, you will have to know networking, you will have to know how services work, databases and probably some scripting skills, but it all depends on how deep you want to dive into it. And after all it’s all basic concepts, once you get them, the language, the tool, the project will be just a detail, because you will have all necessary knowledge to tackle the problem.
So how does our perfect QA looks like.
I have a picture, I can show you right now: 
My believe and what I am trying to do as tester is try not to get caught into semantics of phrases like manual or automation tester. To me, testing is an abstraction, it has no form, no taste and no looks, and whatever I do is all up to my creative thinking and imagination. And I like to think of manual and automation testing as the top layer, the application layer of the whole thing, where the abstraction get it’s concrete realization.
If I have to do some tough and time consuming task that consists of doing same action over and over again, I would love to write a script for it and automate it. Other wise I love to poke stuff on my own while getting to know the application, it just comes natural.
So that’s it, this is what I believe, this is what I recommend. Is it perfect? Hell no! Would it work? I don’t know, go ahead and test it, we are testers after all, so “Trust is good, test is better.” I would love to read your opinion on it.
Mr.Slavchev
Senior software engineer in testing. The views I express here are mine, they don't represent any position held by any of my employers. Experience in mobile, automation, usability and exploratory testing. Rebel-driven tester, interested in the scientific part of testing and the thinking involved. Testing troll for life. Retired gamer and a beer lover. Martial arts practitioner.
Follow Me:
This post opened my eyes on these really trivial but so important things! Good post! Thank you!
Thank you, Natalia, for the kind words!
I believe they are not trivial, but basic and foundational. If a tester gets these wrong, many things might screw up. In my relatively small experience, I was asked by couple of folks to help them with problems in their automated checks, when I dug deeper in them, they always turned out as wrong understanding about the nature of testing.