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.)

Sunday, September 06, 2009 2:53 AM by I.M.Testy

http://elusivebug.blogspot.com/

Regards

Rajesh

Sunday, September 06, 2009 2:12 AM by Rajesh Kazhankodath

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.

Tuesday, June 23, 2009 11:30 AM by I.M.Testy

Monday, June 22, 2009 11:44 AM by plainplow

Wednesday, May 20, 2009 1:31 PM by Agile Testing

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

Wednesday, May 20, 2009 2:59 AM by verand

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 approach 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.

Thursday, May 14, 2009 12:13 PM by I.M.Testy

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.

Thursday, May 14, 2009 10:34 AM by strazzerj