Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

Having a development background, I am convinced that record and replay testing tools have their drawbacks, especially by making tests brittle. See Automated Testing != Record-Playback Tool for a good summary:

Record-playback scripts are more expensive to maintain because the code they generate is long, complicated, not object oriented and must be further manipulated to put into reusable components.

Given that a stable framework is offered to QA , is it a reasonable expectation for them to code automated tests? I will obviously assume that they will have at least some programming background.


Update: I am interested only in the QA bits specific to automated testing. I am very well aware of the benefits of manual, exploratory testing, but that is out of scope for this question.

share|improve this question

7 Answers 7

up vote 18 down vote accepted

To answer your question, yes, if someone has the skill then QA should code tests.

Beyond the simple question is a bigger issue. As a professional test engineer you need to know when automated/coded tests are right to use on a project. Do you need full on automation, a quick script, some home-grown tool or do you need a manual test plan executed by a tester? And on any given project the answer could be any/all of these in some combination.

I would never discourage test engineers from coding, but make sure they have the understanding to know when it is appropriate to use and when it isn't.

share|improve this answer
    
Thanks for your answer. I am assuming that Q&A does exploratory/manual testing as well. This question only regards automated regression tests. –  Robert Munteanu May 4 '11 at 13:30
1  
I voted for CKLEIN's answer & would like to add 1 thing. You state "Given that a stable framework is offered to Q&A..." I would have to disagree in that this is not a "given." I rarely have a "stable" environment for testing. –  Laura Hensley May 4 '11 at 14:35

The obvious answer is YES, but then there is the why ...

IMHO IT industry still generally views testing as a job that anyone can perform with minimal technical skills. A lot of testers are hired with no programming skills required, no industry specific knowledge, just X number of years in testing, good communication skills and some experience with a particular test tool vendor’s product.

Imagine a dialogue between a test driver and an engineer going something like this:

“The new car feels a bit funny at the front”

“What do you mean by funny?”

“Well I turn the round thinngy in the there …”

“oh you mean the steering wheel”

By comparison, a test driver that understands how a car works can have a much more meaningful conversation with the engineer:

“It has mid-corner understeer, after turn in.”

“Ok we can solve that by increasing camber slightly or adjusting the rear springs.”

“Let’s try the spring adjustment, as changing camber will also effect tire wear.”

The technical tester, or tester with deep domain knowledge in addition to great testing skills is much more effective than the non-technical equivalent as they have similar, equivalent or superior knowledge to the engineer but simply a different focus and specialist skills.

This is an abridged version of a blog post I made on this subject - here.

Record and playback is primarily to get entry level tool sales. I have managed teams where we run 1000+ tests a day, with not a single recorded test in sight.

share|improve this answer
    
From the developer's point of view, do we really need yet another group of people telling us how we should be writing our code and solving our problems? Mind you, a developer's job is to solve problems. We already have our managers (who write little code,) their managers (who write even less,) the spec writers (who are convinced that crash course in programming 10 years ago qualifies them to tell us exactly what to code up,) and you want to throw the testing crew in there too? No, please, no! –  corsiKa May 4 '11 at 14:50
    
even tester are not there to create problems, we just (**mostly) reveal the problems... –  Tarun May 4 '11 at 15:58
    
@glowcoder - Not sure what kind of industry you work in, but it surely seems to be not so great environment. The question of whether QA should be able to program is not related to the development work, it is about automated testing. –  Suchit Parikh May 4 '11 at 17:45
1  
@glowcoder in my experience, great coders crave good feedback. The feedback I give is normally at the requirement or feature level, not at the implementation level as that is a key testing function, to verify and validate the developers creative interpretation –  Bruce McLeod May 4 '11 at 21:39
2  
"The technical tester, or tester with deep domain knowledge is much more effective than the non-technical equivalent" - the problem I have with this, is that it leaves out testing skills. Given the choice between 3 people, one with outstanding technical skills, one with outstanding testing skills, and one with outstanding domain knowledge - then 9 times out of ten, I'll pick the outstanding tester w/o deep technical or domain knowledge. They'll know how to learn what they need. (Of course, ideally I want all three in my team). –  testerab May 9 '11 at 21:22

As some of the commenters have already mentioned that it depends on the industry, company and individual teams.

If the person is hired as a tester, they may not have any programming background and their job might not require any coding skills. I worked in an online gaming company where this was the case. It was same when I worked for the IT department of a bank. If it is in the technology industry, the emphasis on automation is much greater and the knowledge of programming is becoming a necessary skill. However, again a tester hired to perform front-end testing might get away without programming.

If the person is hired as a QA Engineer, then programming skills and the ability to automate becomes a must.

share|improve this answer

I see it this way, being able to know multiple facets of testing is +1. This not only earns reputation to you in team but also gives you some insight as to high developers think and develop. And at times end up in injecting a defects. It is absolutely reasonable to expect testers to code tests especially when they have some programming experience. Remember test automation could save you lots of time which you could otherwise use .... may be in exploratory testing to find new defects.

share|improve this answer

Yes!

When it comes down to it, an automated test is a software product. The deliverable is a piece of code, and it's completely reasonable to expect that the people responsible for creating automated tests actually know how to write test scripts.

share|improve this answer

Yes, they should.

It is extremely hard to get sufficient data in reasonable time about software quality just by clicking around. When you have a large project, scripts that automate regression tests save enormous amount of time. When you have a software that generates complex reports, manual comparison of related reports can be tiresome and unreliable. Database testing is impossible without SQL knowledge.

And I did not get to performance testing.

share|improve this answer
2  
I would disagree. Did you heard of exploratory testing? Talk with James Bach about it, he will tell you how it works. :) Also... Performance testing is not realy and area for a Manual Tester. That's why i said, it depends on what kind of people you hire. –  Hannibal May 4 '11 at 13:09
    
I'd agree with Hannibal here, but would also add, SQL knowledge seems to be a bit of an oddity in that testers with very good/outstanding SQL knowledge can sometimes describe themselves as "non-technical" or "non-coders". So you may find a team of "manual" testers, who actually have pretty decent SQL skills once you start looking at what they actually do. I've always considered some degree of SQL knowledge absolutely critical for a tester in any of the environments I've worked in, and most of my colleagues would have described themselves as manual testers. –  testerab May 13 '12 at 12:54

It realy depends on the people you as company Hire.

If you have testers with coding skills then you can expect them to code.

But if you have Manual Testes who never used or heard of Java ( exaggarating ofc ) then don't expect them to code automated tests OR if they want to learn it... Well that's a long process 'till they get to the point in which they can write proper tests.

Try using Cucumber...

http://cukes.info/

It makes writing tests easier AFTER it has a framework in the background with most capabilities already coded. It's like LEGO. Just put together the pieces.

share|improve this answer
    
You still need to know what the pieces you're putting together mean. Otherwise you don't know what your test is really doing. Yes, you can start at the "writing scenarios" level and gradually get more familiar with implementing them, but having been learning Cucumber I wouldn't ever ever recommend a tester just "plug the bits together" - better to pair an inexperienced coder with an experienced coder, then they can learn. –  testerab May 13 '12 at 12:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.