Benefits of QA Engineers who do both manual and automated testing
I've been doing automated and manual testing for almost 6 years now (as well as a brief
stint as a release engineer) and I think the model of splitting a QA team up into pure manual and
pure automated testers has many weaknesses. These are some of the problems I've seen (and heard
about from friends who work at other companies):
1) The automation team doesn't learn the product very well.
2) The automation and manual teams don't communicate effectively about what test cases are actually being automated. One result is that some
work ends up being duplicated by the manual testers which is a terrible waste of resources.
3) The manual testers become resentful because the automation team isn't responsible for the quality of the product after it ships. I.e. they're not held accountable for defects the customers encounter because they provided the higher level testing framework while the manual testers covered the deeper test cases. The argument I've heard is that the automation team did what they were supposed to - they wrote the test scripts and executed them. The issue of whether they automated enough of the testing tasks is almost always too ambiguous to prove one way or the other.
4) The automation team becomes detached from the application development cycle, writing scripts simply for the sake of writing scripts as opposed to focusing on how well they're testing the product. I don't have an endless threshold for manual testing myself and I generally find
automated testing to be much more satisfying, but I've seen testers who are completely absorbed with how "cool" their scripts are without stepping back and assessing how effective they really are. Also, I'm not implying that an automation suite doesn't have its own development cycle because it does, but it is a secondary development cycle. It really only exists to expedite the development of the commercial software that your company sells to generate revenue. A top notch automation strategy doesn't help your customers when your product is a piece of crap.
5) Automation engineers take up an "almost-a-developer" attitude and scoff at the manual testers.
6) You have automation testers who are primarily interested in learning all of the standard test tools just to beef up their resumes because, as we all know, automated QA jobs always pay more than manual positions. Of course, I don't blame anyone for wanting to improve themselves technically (or in any other way) but it is upsetting to see people do this while claiming that they're contributing to the team effort. No offense to anyone, but I've seen consultants do this on more than one occasion - they come in, learn the tool and the "UAT" on the job, write some test scripts and leave the full time employees behind with a big pile of useless code.
7) You end up with manual testers who aren't particularly motivated to stay abreast of the latest technologies and often times don't automate tasks that they should - I'm not talking about writing WinRunner scripts here, I mean something as basic as writing a shell/Perl/WSH script to populate a database with test data or to restore a test server to a base state etc.
I believe that people who can (and will) do both tend to have better technical skills than your average manual-only testers and
are more directed and efficient with their automated testing because they're responsible when clients come across bugs in their areas.
I'd be interested to hear what other Forum Members think about the pros and cons of only hiring people who do both manual and
Re: Benefits of QA Engineers who do both manual and automated testing
I think it's beneficial to break out automation and manual if the potential for duplication does not exist (if keyword-driven automation is feasible, or if there is some other method to tie the automated test and document together).
Beyond that, each type can focus more effectively on what they do. I, personally, have no interest in what the user experience is like, but I do have to study the technology involved in the application in order to code automated tools for it and enjoy it greatly.
I agree with the statement that automated tool coders become like developers, but some of that comes down to professionalism. I've seen some strange requests come my way that makes me wonder how these people keep their job at a software company. But my attitude is also that I want people to find my stuff easy to use, with the features they are looking for, so I accommodate as much as I can. If I give people an attitude, they won't use my stuff, which means we don't automate, which means I could be out of a job. It's positive logic to me.
Manual testers have confided to me that they don't want to be a programmer - they just want to break stuff. You mentioned that some people view automation as just something they need to get on their resume so they can get a job. If the industry supported both types of testers it would become respectable to not have a tool listed and we might start to eliminate some of the rude awakenings that happen when a 'tool expert' turns out to have played around with record/playback for a couple days.
As far as salary - I'm fairly certain that some manual testers in my group make more than I do. They're on the management track, or have been with the company for years, and a headhunter friend has given me the dirt on some departed folks that almost makes me angry at what I make - it's a pittance compared to some of them!
Using a keyword-driven framework allows people to write their own automated test cases - I only provide the app to write the test cases, the automated tool handler, and supporting tool code. So it's really up to the person writing the test case to make it as complex as they want. Often what I have found is those new to testing go for the biggest test cases, and as they evolve they begin to think in terms of modularity and the purpose of the test. Possibly the same could be said for a straight manual test case - it depends on the person writing it.
As far as technical ability - where I work now there are basically three camps. One knows nothing about technology, but they've worked in procurement and know how an order entry process should look like. They're your basic business analysts, but function as testers. Then there are the people who test our server and database technologies, and those people are very technical. Then there are the automators. Each group has their area of study. The business analyst types are still interested in procurement or banking, and they keep up in the industry. The same goes for all the techies.
Getting languages and technology on a resume is probably of interest to most people doing automation, but for me that's survival instinct from seeing what happened to COBOL-only programmers. You do need to keep up. As far as becoming a developer, I have no interest. I think it's different programming for testing than programming for a releasable, saleable product. Product developers answer to the sales force or product management - I answer to my boss. We decide our schedules, not somebody's promise. I'm sure I make less, but I don't care. I got into this because it's my passion, not because I could make money. If I wanted to make money I'd still be a QA manager on a production floor somewhere.
All in all, I've seen QA departments make blanket statements like 'automation is the future' and 'everybody will learn a tool' and I see more fear than excitement on people's faces. I think if it was a given in the industry that people would do both, people would be warned before coming into it. But for people to be properly warned, they would have to be told by a knowledgeable hiring manager that the tools require programming skills, and not talk crap about 'you're going to record and playback scripts'. So I guess it could go either way in the industry - doing both or just one. But it is my belief that both results in people who are true specialists, instead of jack-of-all-trades. In my case, if the industry moved in such a way that required me to do manual testing, I'd find another line of work. Manual testing makes me sleepy and it's not in my best interest or the company I work for that I do that kind of testing.
Re: Benefits of QA Engineers who do both manual and automated testing
I prefer separate groups and I believe they have different skill sets.
However, I believe all manual testers should have basic training on <some> standard automated tools. It helps them write test cases that are easier to hand over to another team to automate.
In addition, if they want to progress and move ahead in the field, they have to understand and have basic competency in automated test technique; someday they might have to lead or manage such an effort.