Automated Testing: From "Testing" Activity to "Development" Activity

I think automated testing is moving from something “testers” do to something that “developers” do. This isn’t good or bad, positive or negative. It just is. 

What really got me thinking about this was comparing working with SilkTest versus using Selenium with Java et al. SilkTest is a bit of an older product, created in the late 1990s. A Selenium setup is the relative new kid on the block. Both can be used for automated web GUI testing. 

What are SilkTest’s strengths? 

  • Stand-alone, all-in-one package for GUI testing
  • Uses single, simplified OO language (4Test)
  • Record-and-playback tools are well-integrated
  • Easy organization of tests using test plan files

What are Selenium strengths? 

  • Excellent integration with languages built-in upfront 
  • Built to work with existing web development products
  • Open-source and freely available
  • Easy to use in continuous-integration and automated processes

See any differences?

SilkTest is a tool primarily based on desktop GUI automation. Recently it has tried to build up and refine its web automation abilities. Because it’s primarily a (1990s Borland) desktop testing tool, it assumes that the surrounding testing environment is fixed. The primary ways of writing tests are using SilkTest are using record-playback capabilties (which probably aren’t that good) or scripting tests using the proprietary 4Test language.  4Test is a sort of simplified OO language that is designed around testcase methods and test plans. By simplified, I mean that you can create classes with inheritance, and that’s about it. Plus there’s a large library of built-in functions and methods to do all sorts of things off-the-shelf, as it were.

In short, SilkTest is really designed to be used by testers with coding experience all by itself. 

Selenium, on the other hand, is designed to be more like a browser driver API for a bunch of different languages. In the Java case, Selenium is packaged as a JAR file that may be included in a Java project. Since Selenium is like an API, tests can be written in native languages using all the bells and whistles of those languages. It can also be used with tools such as Selenium Grid to create concurrent and parallel tests on different machines or servers. And of course, since Selenium only   drives a browser, it can be embedded in various parts of continuous integration, where tests, suites, browsers, servers and even test machines can be launched on an as needed basis using various methods independent of Selenium. Record-and-playback tools with Selenium are fairly basic, and not the “core” way of using Selenium.

Obviously tasks of this sort may require some admin or development experience. It would be difficult for a novice tester with little to no coding experience to create, edit and run such tests. Again, I’m not saying this is good or bad, it just is. 

I think this comparison sheds some light to where test automation is going overall. A decade ago, automated tests were mainly the domain of testers, perhaps with no coding experience. Now, if not in the near future, this is no longer the case. Automated testing will require some non-trivial programming skills (test code is code!) or at least some non-trivial coding training. 

Personally, I think this is an indication that automated testing is getting more interested and exciting. The possibilities of automation are becoming greater all the time. Let’s the the right people on the job, whoever they are.