What's with the test tools simplification? Where's it stop?

What's with the test tools simplification? Where's it stop? All the tools or posts about tools seem to be doing their best to simplify to the point that everything is point and click and record and playback. Is that actually going to simplify things?

These are some points from the marketing spiel for Original Software's automation tool; TestDrive Gold:

* Easily create test scenarios through a simple point-and-click interface.
* Execute a complete regression test in hours not days, complete with full results, automatic data rules, and analysis.
* Free of any coding language: there is no complex scripting language to learn.
* Self-healing scripts - run your existing scripts over revised or updated versions of your application without hours of re-scripting.
* Complex decision-linked tests can be built that integrate with the server functions to give a complete approach to testing.

OriginalSoftware has taken the simplification to the point that you can't actually view the script (another thing! Is it still a 'script' if it's all graphical?).

There is a post on linkedin about creating a test engine and again:
* Testers should not need to know a programming language
(http://www.linkedin.com/answers/technology/software-development/TCH...)

I think this is a bad thing, IMHO testers should be aiming at knowing a language, not necessarily to the point of being able to code complicated systems but at least to be able to read sections of code and gain an understanding.
BTW I write as someone who does not know a language (but will one day).

I'm not sure but I think that's half a discussion post, half a rant! :-)

▶ Reply to This

Replies to This Discussion

Permalink Reply by Michele Smith on August 14, 2008 at 9:44pm: Hi Tony,
I am going to disagree with your statement that "testers should be aiming at knowing a language...be able to read sections of code..." Even though I have taken a couple of classes myself to get a bit more educated on it, testers are not cookie cutter creations. Diversity is what is the driving force behind a successful test team. If your desire is to learn a code language in order to sharpen the skills you feel are within you, then that is exactly what you should do. But the tester sitting next to you may sharpen his tools with studying Systems Thinking. The tester beside her may sharpen his tools by gaining more domain knowledge in order to test more like the user.
Diversity pays high dividends in the end.; ▶ Reply to This

Permalink Reply by phil kirkham on August 14, 2008 at 9:52pm: seems like the same old marketing spiel of trying to sell test automation snake oil that some people fall for. Some companies wont invest in testers who can actually test and think they can get away with using one of these test automation packages

testers knowing how to code is another question entirely, I'm off to LinkedIn to go read what they are saying...; ▶ Reply to This

Permalink Reply by Tony Bruce on August 15, 2008 at 8:40am: Hi Michele,
You're right, my bad, I should have worded it differently, I didn't mean all testers should go down that path.
I'm all for diversity, a team of different thinkers/workers/testers/skillsets will go a lot further then a team who are all alike.
I was thinking more along the lines of what Phil has touched on, simplifying things to the point that the powers that be will think anybody can do it.
A tester who is interested in automation would be (IMHO) worse off by using a tool which only has a point and click and record and play or only using those functions.; ▶ Reply to This

Permalink Reply by Michele Smith on August 15, 2008 at 9:29am: I can agree with that, Tony. Otherwise the testing is pretty much done by another peice of software, which has bugs (no software is defect free). That could be disasterous.; ▶ Reply to This

Permalink Reply by Sharath Byregowda on August 16, 2008 at 4:33am: Tony,

In my opinion automation testing should complement manual testing. If automation means record and playback and running the same tests over and over again, ask the management a simple question - What is the probability of the same tests finding bugs?

Testers learning a language - Well, I feel this could help a tester make a better decision sometimes. But, some times I feel why cant those planned test scripts be developed by developement team - I am sure it will cost less time and could be less buggy, and testers instead of discussing how to write the script could plan better scripts required for testing.

-Sharath.B
http://testtotester.blogspot.com/; ▶ Reply to This

Permalink Reply by halperinko on August 21, 2008 at 7:56pm: Record & Replay was found useless years ago, as it makes lot's of badly designed tests, which are very hard to maintain.
One must have modular Automation structure in order to really enjoy the benefits of Automation.; ▶ Reply to This