I have an open headcount for the highest level tester position at my company. We are hoping to get someone with test automation skills. Most of the candidates are making me yawn. Few are enthusiastic enough to have read anything about their own craft, and fewer are interested in deep discussions.
One resume that grabbed my interest was from a career developer that claims to want to try her hand at being a tester. She is mainly interested in writing test automation code...but she never has. Prior to an interview, my devs and I were enthusiastic. Afterwards, we realized this candidate had no testing experience (other than experimenting with unit tests) and most feared our team could end up with a good developer but a weak test automation stack instead of a good tester who could provide instant gratification via sapient UI tests.
A dev wanting to cross over... How rare of a thing is this? Am I missing a great opportunity by not hiring the dev? Or is this a dev that just couldn’t cut it as an application developer…hoping to cut it as a test automation developer?
I can’t help but wonder, is it easier to teach a developer how to be a good test automator or to teach a good manual tester how to be a good test automator?
My opinions do not reflect those of my employer.
Subscribe to posts
RSS
Popular Posts
-
After attempting to use Microsoft Test Manager 2010 for an iteration, we quickly decided not to use it. Here is why. About 3 years ago we f...
-
Data warehouse (DW) testing is a far cry from functional testing. As testers, we need to let the team know if the DW dimension, fact, and b...
-
I recently read about 15 resumes for tester positions on my team. None of them told us anything about how well the candidate can test. Here...
-
Want your bug reports to be clear? Don’t tell us about the bug in the repro steps. If your bug reports include Repro Steps and Results se...
-
When someone walks up to your desk and asks, “How’s the testing going?”, a good answer depends on remembering to tell that person the right ...
Labels
- Teamwork (86)
- bugs (81)
- process (66)
- software testing career (49)
- automation (45)
- writing tests (38)
- Personal Excellence (37)
- Managing Testing (33)
- questions (31)
- language (29)
- testing metaphor (23)
- Tools (19)
- STPCon (10)
- heuristics (10)
- Test Cases (9)
- test blogs (9)
- CAST (8)
- Presentations (8)
- Test This (8)
- metrics (8)
- Rapid Software Testing (7)
- Silliness (7)
- Data Warehouse Testing (6)
- Kanban (6)
- STARwest (6)
- Testing Conferences (6)
- Agile (4)
- Bug Report Attributes (4)
- Don't Test It (4)
- Stareast (4)
- documentation (4)
- Failure Story (3)
- Lightning Talks (3)
- Testing Related Ideas (3)
- You're A Tester (3)
- Performance Testing (2)
- Podcast (2)
- ATDD (1)
- BDD (1)
- HATDD (1)
- Meetups (1)
Who am I?
- Eric Jacobson
- Atlanta, Georgia, United States
- My typical day: get up, maybe hit the gym, drop my kids off at daycare, listen to a podcast or public radio, do not drink coffee (I kicked it), test software or help others test it, break for lunch and a Euro-board game, try to improve the way we test, walk the dog and kids, enjoy a meal with Melissa, an IPA, and a movie/TV show, look forward to a weekend of hanging out with my daughter Josie, son Haakon, and perhaps a woodworking or woodturning project.
My other passion is woodturning.
Test blogs I try to read
My test automation lead is a developer who came over to the dark side. She had obvious raw innate tester though processes. I've been able to leverage and mentor her along the tester lines, and she's brought excellent developer rigor and insight to the team.
Is it easier to teach a mechanic how to be a race car driver or is it easier to teach a race car driver how to be a mechanic. There is no right, canned answer -- except that it depends highly on the individual at hand.
My (biased) opinion is that it's easier to teach a tester to automate than an "automater" to test. In constructing automated tests, most of the abstract and theoretical understanding is required in the test script construction. Converting the test script into code is simply technical wizardry.
Now, if you tell me that you're doing primarily white-box automation, I could be swayed in the other way.
For a more quantitative measure, look at how much training each would require to reach your ideal skillset. Obviously this doesn't take into account critical things like personality and work ethic.
All of that being said, if this is your most senior test role, I wouldn't find either type of candidate successful. Finding truly outstanding people is difficult and time consuming, but critically important for the impact it can have throughout your test organization.
Like with all questions and answers, it depends. The nice thing of someone being a developer and switching to testing is that they know the common mistakes developers make. Like in the game of chess, if you know the moves of your opponent, you have a good chance of winning. Having this knowledge you can exploit the mistakes being made. I was a developer and switched to testing and as a result of my experience, I'm typically finding bugs that a common mistakes made by developers. For example, in the context of web apps, trimming white spaces on user input, boundary testing inputs, passing javascript script tag on the get params, etc
Has the thought of a keyword driven framework for automation come to mind? This way your testers do not need to code as much
I'm disappointed I wasn't considered for the position. What do I have to do to be a QA person?
This post has sort of motivated to try and see if I could cut it as a UI automation test developer; and so I think I might try to automate the latest "sharing" feature developed for testing.
In my opinion, it is easier to teach a developer how to be a good test automator. However, there are few caveats:
1. A developer will not be a "..good tester who could provide instant gratification via sapient UI tests." Meaning, a developer will not be a good manual tester. So, if you are planning to use a developer for both manual and automated testing, it will probably not work
2. A developer will have better scripting skills than a tester who is being taught to become an automated tester. And scripting skills are the most important for automated testing, in my opinion
3. A developer will have a better understanding of important concepts of automated testing, such as code reuse, separating test script from data and gui objects, and functional decomposition
4. A developer will be better with integrating an automated testing tool with application under test. Knowledge of html, css, and sql is very important
5. If you have a strong set of Test Cases, so a developer simply follows it and automates it, it will help
6. What are the chances that a developer simply buying time to find a better paying, development position?
Mike Girenko
Agree with the comment above - as a dev turned tester I'm well aware of all the mistakes devs used to make and test for them. When I do write automated tests then my dev background makes it easier to write structured tests, build up libraries etc all of which a tester needs to learn to do
Like many here have said, developers *can* make good testers, but it shouldn't be assumed that a good developer will be a good tester (indeed, good enough for a senior position) if they have no other testing experience.
Testing is 80% personality and 20% technical skill. If you don't have the peculiar kind of analytical mind, or the genuine passion for testing, that good testers must have, no amount of technical know-how will turn you into a good tester.
I'm also normally wary of developers-turned-tester. While I know many former developers who are excellent testers, I've come across my fair share of devs who were mediocre in their development role and saw testing as an easy way out.
Like a previous commenter said, it depends on the individual's experience and aptitude. However, in my experience, it is usually easier to teach a developer to be a good tester than to teach a manual tester to be a good test automator. Some people just do not have the aptitude for programming, and test automation is software development and needs to be treated as such to be successful. In the individual case, if the tester has a good programming background, like a CS degree or knows a particular programming or scripting language well, then it may be better to train the tester to be an automator.
But more and more, I think the role of the manual tester who has no programming chops is going by the wayside. Even if you are not talking about a strict automation role, the average testing assignment really does requires some scripting ability, even if it's just parsing log files, or accessing an API to seed a test db with data.
From my perspective, developers can be good testers. However, person who is willing to change his career from being a developer to a tester must consider it seriously. It is totally a different world and mindset. Those kinds of developers are called SDTE or SDT in some companies. These guys are willing to go into QA side to accomplish their dream and goals. Not hiring someone because of his development skills is not a good excuse to use in this matter. Having different skills and personalities in your team might increase the efficiency and locating some overlooked issues in the application. On the other hand, teaching how to code to your test team can be possible. But my question here is that “’is your test team really willing to do that as in developer wants to be a tester?” In my projects, our developers are writing automated scripts for the test cases. Meanwhile, reading those test cases helping them to understand the quality side of our applications. There are lots of different ways of creating your team structure. But as I mentioned before, having different variety of thinking in your team will increase the productivity and your credits in the company.
"Do Developers Make Good Testers?"
I think first we need the answer to a more basic question.
Who is a good tester ?
Without knowing who a good tester is we cannot determine if a Developer can be Good Tester or not.
I myself turned from development to testing so I am able to relate to this question somehow.
I believe developers make good automation testers as their coding skills can come in handy. But as a Black Box Exploratory tester a developer mind has its own limitations.
Thanks
RP
PS: It would be great if you could share your views regarding "Who is a Good Tester" in your one of next blog posts.
I second the comment about the developer needing to throughly consider the career change before becoming a tester. It's a different world, but it's still part of the same universe. We recently had a contractor cross over from development into our test department, and she was totally convinced that the change was what she wanted. During her time here, she was one of the most thorough and productive testers on our team, and she went on to find another job in testing after her contract here had expired. She was already an exceptional worker, though, so I feel she would have performed well under any circumstances.
After some period of instruction, I have a performance tuning/QA exercise that I give to developers and testers. Less then 5% of developers that attempt this exercise are successful without some significant level of intervention. Of the testers, about 70% are successful without intervention. This difference seems to hold across cultural boundaries as I get the same results in Asia, North America, and Europe. The only conclusion is that testers come to the table with a rigor and mindset that developers appear to lack.
Regards,
Kirk