In my previous post I've explained what is the "Object Oriented" approach in test automation. Again to clarify, this approach is not a incompatible with with data driven approach. In fact the its complementary and in our framework the all the input data comes from excel-based template files. So Object-Oriented and Data-driven approaches coexist and are complementary. However the same cannot be said about the keyword /action-word driven automated approach. The keyword driven approach the actions words and actions associated with this. This encapsulates the underlying complexity of the automation tool into readable actions that can be automated by a non-programmer.
The object oriented approach however focuses on specific user actions performed on the application. The complexity of the product is encapsulated by this approach rather than the complexity of the automation tool. This means that a automation framework developed with the object oriented approach can never be a generic one, it always has to be specific to the product you are automating. The object oriented approach also assumes the test developer has a sound understanding of object oriented concepts and the programming language.
The design philosophy for Object oriented framework are the following.
- To model the application under test ( AUT ) as classes and the user actions as methods/functions of these classes
- The test suite developers will user these classes and methods and only these classes and methods for test development.
- The exceptions on the application should be handled by the framework and should return the application to a base state after error.
- Any test suites developed by the framework should not exceed 100 lines of code.
- The test suites development should be able to use all the object oriented features supported by the language.
- The test suites should be tool independent. This means that the framework should encapsulate all the tool dependency within the framework. In case a tool migration is required, the framework can be rewritten and the test cases will not be altered.
In the next post, I'll explain the design details and approach of the framework we've developed and the benefits we've achieved with this approach.
2 comments:
The key is to understand how you have been evaluating the results. Could you also consider posting how you analyze the results and value you have been gaining?
@Pradeep,
I'd certainly include information about the result evaluation and value gained by us with this approach in my follow-up post.
Post a Comment