I am going to present a half-day tutorial – “Designing and implementing a Common Test Automation Platform” as a part of STeP-IN SUMMIT 2011 at the following locations:
- Hyderabad – February 11, 2011 at Taj Deccan
- Bangalore – February 16, 2011 at Taj Residency
Please find below the details of the tutorial. You can find the registration details at the STeP-IN SUMMIT website..
With developers’ ever-increasing focus on testing and testers dealing with intricate testing areas, there is a major overlap in their test automation requirements. Developers write a lot of test code and testers are involved in much beyond traditional black box testing. How do we develop a common platform for developers and testers which they can use to automate their tests?
Test Automation Frameworks (TAFs) do not get the treatment (in terms of design) that they deserve. Spending time on understanding the precise requirements and then designing /choosing the framework becomes much more important when a general purpose framework is required. Such a situation is unavoidable when your organization is looking at the possibility of a single underlying TAF that could be employed by multiple teams involved in strikingly different products; their testers are conversant with different programming languages, and they choose or need to employ different tools to support testing.
Challenges in Design
- Is not hard-coded to test a particular product with a hard-coded choice of tools
- Does not force one to write tests in a particular language
- Can support tests written by developers as well as testers
- Provides for mocking options wherein the output of API being mocked can be controlled by the test.
- Has provision for integrating tools like code coverage and profiling tools
- Provides an interface for scheduling and managing tests as well as high level interface to the management
- Has a script generator for easy integration
- Can execute distributed tests across multiple machines that could be physical or virtual
- Integrates with bug management tools, build system and email system
- Provides a script development environment, wherein the same test scripts can be executed in offline (non-deployed mode) and runner (deployed) modes.
What you will learn
This tutorial is focused on the technical aspects of designing a scalable, general-purpose, object-oriented TAF. This in turn means that the contents would mainly comprise concepts that directly translate into an implementation in an object-oriented language. One could choose to write the same thing in the traditional programming way, but there would be further work required on part of the attendee(s) to translate the design. The facilitator will share practical nuggets of test automation knowledge with the audience that he has gained from his practical experience.
The presentation would cover the following areas in above context:
- High Level Snapshot of a TAF which forms the basis of this presentation
- How the framework is employed for catering to testing needs of developers and testers, while providing code coverage results at each level
- Test Encapsulation as the key concept behind the design of framework
- Notes on various aspects of the framework many of which were experimental in nature but worked out well
- From technical perspective, what all was employed in developing the framework
Case Study and Walkthrough/Demo
A practical implementation of Test Automation framework using Python and C/C++ would be used as a case study. This framework is in production for testing a critical product. As a part of the presentation the details related to this specific implementation would be kept constrained to the scope of discussion as a case study only.
What This Tutorial is Not
The tutorial will not attempt to answer the questions of why to automate, when to automate, which tests to automate, automated tests versus manual tests, ROI of automation, etc. So, if the attendee chooses to attend this tutorial, it is assumed that he/she already understands the importance of test automation. This tutorial focuses on how to automate, whereby the “how” part is not about using an existing tool or framework, but rather about designing one.
- Testers involved in test automation
- Managers/Leads looking at building a framework for long term use and as a common platform for testers and developers
- An Open Mindset
- Courage to Explore and Experiment
- Prior experience of any sort in test automation using any language
- A new outlook about test automation framework design
- Getting a high level knowledge about a successfully implemented framework using this concept
Leave a Reply