Programming Paradigms in Test Automation

Programming Paradigms in Test Automation | Microsoft Share Point

Programming Paradigms in Test Automation | Microsoft Share Point — Thu, 14 May 2009 07:03:13 GMT

PingBack from http://microsoft-sharepoint.simplynetdev.com/programming-paradigms-in-test-automation/

re: Programming Paradigms in Test Automation

strazzerj — Thu, 14 May 2009 17:34:25 GMT

"Although many record/playback tools allow 'test developers' to modify the scripted actions to some extent, and possibly even incorporate simple yes/no oracles I think many people view record/playback tools as being slightly more useful than trained monkeys in limited situations."

There are very, very few tools that could be accurately categorized as only "record/playback TOOLS".

Virtually all commercial (and some open-source) test automation tools include a "record/playback FEATURE".

Despite your dismissal, like all features they have their uses and abuses.

Many people view QAers in general as "slightly more useful than trained monkeys". I think it's unfortunate to see someone like you use such derogatory terms.

re: Programming Paradigms in Test Automation

I.M.Testy — Thu, 14 May 2009 19:13:05 GMT

Hi Joe,

I agree there are a plethora of tools that include record/playback mechanisms. I should have not used the word 'tools' since I am speaking about the record/playback paradigm as an automation approach. (I have edited the post to remove the word tool and replace it with paradigm to clarify my thoughts.)

I think you misread my statement. I did not infer that testers are slightly more useful than trained monkeys; my statement infered (mine and) the opinion of people I have spoken with whom have used a simple record/playback apporach to test automation view this automation paradigm as slightly more useful than trained monkeys. I think most testers quickly realize the limitations of the record/playback automation paradigm, and also understand the specific situations where it can add value to a project.

I also think that most professional testers realize that greater success of the record/playback automation paradigm requires the tester to modify the underlying code at least to some extent. But, I would say that modifying the underlying code base obtained from a record playback tool actually moves us closer towards the scripted automation paradigm.

re: Programming Paradigms in Test Automation

verand — Wed, 20 May 2009 09:59:41 GMT

"So, approach which is best?"

There are many factors that should be considered before choosing the right approach. Here are a few:

* Analyze the application/product (Web, OS-Based, Technology...etc)

* Realize what to be tested and what not to be.

* Go through the requirements

* Separate the areas as per the modules.

* Analyze your customer/product needs and thus estimate the development activities. This gives you an idea of number of build releases and testing cycles required.

* Maintenance (Long-term/Short-term)

* Budget

It is not always recommended to have a greater complexity in the design(i respect your thoughts too). But we cannot really get benefited designing and developing Next Generation Automation framework to test a tiny application :-)

Types of automated testing

Agile Testing — Wed, 20 May 2009 20:31:07 GMT

Over at his I. M. Testy blog, BJ Rollison offers succinct definitions of five approaches to automated testing: record and playback automation, keyword or action-word driven automation, scripted automation, procedural automation, and model based automation.

re: Programming Paradigms in Test Automation

plainplow — Mon, 22 Jun 2009 18:44:03 GMT

Could you point us to resources for learning how to use procedural automation and/or the model based automation approach?

re: Programming Paradigms in Test Automation

I.M.Testy — Tue, 23 Jun 2009 18:30:03 GMT

Hi PlainPlow,

I would recommend "Structured Programming" by Dahl, Dijkstra, and Hoare for learning about procedural or structured programming paradigms. Wikipedia also has good pointers to additional info if you search on structured programming and procedural programming. (IMHO, they are essentially synonomous.

For model based testing, I would refer to the Spec Explorer website at http://research.microsoft.com/en-us/projects/specexplorer/. Also a search on Spec Explorer will provide additional learning resources.

re: Programming Paradigms in Test Automation

Rajesh Kazhankodath — Sun, 06 Sep 2009 09:12:18 GMT

I've been working on adopting an "object oriented approach" towards test automation. My guess is that this approach falls somewhere between a procedural paradigm and a model based automation paradidm. We've achieved remarkable level of producivity with this approach. I've blogged about the approach here.

http://elusivebug.blogspot.com/

Regards

Rajesh

re: Programming Paradigms in Test Automation

I.M.Testy — Sun, 06 Sep 2009 09:53:58 GMT

Hi Rajesh,

The development approach used to develop a test case may very well be fundamentally different than the development paradigm used to build a testing framework.

In your post you state, "Since the automation tester will only use the business classes and methods that the automation framework exposes, development of these automation suite is very fast." I could be wrong, but this sounds very much like key-word driven automation.

Personally, limiting testers to a set of predefined methods in a script to drive a test framework that acts as an abstraction layer is simply limiting the ability of an automated test. As Dustin, et. el. stated, automation is a development activity. Well designed automation provides some degree of determinism and reduces the mindless scripting of rudimentary sequential actions.

Also, it seems from your description that your concept of inheritance is primarily based on the ability to reuse code. I have lots of methods that I reused in procedural programming; reuse in of itself does not imply inheritance in the OOP paradigm.

A simple test for inheritance in an OOP paradigm is the "IS A" test; in other words a sub-component IS A specilized version of its predicessor. For example, an automobile is a specialized version of vehicle. 2-door coup IS A specialized version of automobile.

And with regards to polymorphism, I am not sure that I would ever want to call code that can issue the same command to a superclass or interface and get different results. In application programming this is important, but in an automated test I have not yet been convinced of its applicable use. (Assuming we agree that polymophism is not the same as randomization.)