Realising the Benefits of Test Automation through Effective Tool & Framework Selection
Published on 16 July 13
Diwakar Menon
0
With Test Automation implementation gaining momentum and the myriad of Tools (COTS & Open Source) available in the market today, the choice of tool and the corresponding framework is of prime importance. This decision plays a key role in determining the ROI one can expect to see from Automation. Blindly automating a test pack will not necessarily produce returns. How does one go about deciding the "right-fit"?
In general, there is an innate tendency to fall back on existing frameworks? It's easy, requires minimal technical knowledge and it has worked for 'n' applications - so it will work for this one. This thinking might hold good more often than not - however, with this logic, the behaviour of the application tends to take the back seat and this can prove to be very counter-productive. Application behaviour should act as the foundation for building an Automation Framework, failing which you might find the entire automation structure falling apart.
For instance, consider a standalone application built on Java. Assume one chooses to adopt a hybrid framework encompassing the modular and data driven approaches to automate the application. A few months down the line - the customer decides to change the underlying technology from Java to Siebel. Although both the applications are functionally alike, the existing automation scripts will be rendered redundant - owing to the structure of the application in terms of object identification and hierarchy.
Anticipation of inevitable changes to the application and its behaviour will greatly help in creating a robust framework that accommodates application (and client) temperament. Current trends lean towards a more generic framework that will cater to all your automation needs. While this offers greater speed and flexibility in developing automated test cases, care must be taken to design the framework in such a way that
- Modifying any aspect of the core script layer will not have an impact on the developed test cases
- There is flexibility to plug in Enhancements to the framework and
- Minimal maintenance overhead if the underlying technology of an application changes
Ideally, this sort of framework should be built by disassociating the core scripting layer from application technology and business functionality. Hybrid frameworks encompassing the Keyword and Data driven aspects (5th gen frameworks) - that have the capacity to emulate Business Process Testing behaviour work best in maintaining an Automation suite in turbulent conditions. This also allows one to keep Test Case design to excel sheets and/or test management tools - where they rightfully belong.
Tool selection is slightly more straightforward when compared to frameworks. For starters, a thorough assessment of what the tool has to offer to the current test environment is required. Detachment from the tool is vital in this process - assess a tool for what it can and has to do rather than what it doesn't need to do. A higher level of exposure to one tool will only magnify the "shortcomings" so to speak, of the other. In most scenarios the license cost associated with a tool ranks the highest in the decision tree; pinning the entire decision on cost without giving tool suitability and extendibility their due credit however, will not be conducive.
This blog is listed under
Open Source
, Development & Implementations
and Quality Assurance & Testing
Community
Related Posts:
Post a Comment
