16

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.

Improve this question

7 Answers 7

Reset to default
21

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.

Improve this answer
2
  • 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
    Commented May 4, 2011 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
    Commented May 4, 2011 at 14:35
6

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.

Improve this answer
10
  • 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 ♦
    Commented May 4, 2011 at 14:50
  • even tester are not there to create problems, we just (**mostly) reveal the problems...
    – Tarun
    Commented May 4, 2011 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
    Commented May 4, 2011 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
    Commented May 4, 2011 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
    Commented May 9, 2011 at 21:22
4

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.

Improve this answer
2
  • 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
    Commented May 13, 2012 at 12:50
  • Yeah, I was very naive back in '11. :)
    – Hannibal
    Commented Mar 3, 2015 at 16:29
2

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.

Improve this answer
2

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.

Improve this answer
1

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.

Improve this answer
2
  • 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
    Commented May 4, 2011 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
    Commented May 13, 2012 at 12:54
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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