Automation strategy and an Ideal Framework
By now you must have seen the challenges in automation world and realized the need of a robust framework for everlasting testing strategy. Now lets redefine the automation strategy and review the candidatures for an ideal framework.
Test automation is a fulltime effort, not a sideline.
The test framework must be well thought out. It must be documented. It should be reviewed. It should be tested. It is a full software development project like any other. This bears repeating--again.
The test design and the test framework are totally separate entities.
The test design is the business logic for the application under test. It tell us what to do, how and when to do it, what data to use as input, and what results we expect to find. This doesn’t care whether the application will be tested automatically or manually. On the other hand, the test framework is an execution environment for automated tests. It is the overall system in which our tests will be automated. The development of this framework requires completely different technical skills than those needed for test design.
The test framework should be application-independent.
We should focus our automation framework to deal with the common components that make up our unique applications
The test framework must be easy to expand, maintain, and perpetuate.
One of our goals should be a highly modular and maintainable framework. Generally, each module should be independent and separate from all the other modules. What happens inside one is of no concern to the others.
The test strategy/design vocabulary should be framework independent.
The framework refers to the overall environment we construct to execute our tests. The center-piece is usually one of many commercially available automation tools. In good time, it may be more than one. In some rare circumstances, it might even be a proprietary tool developed or contracted specifically for our test automation needs. The point is, different tools exist and some will work better for us than others in certain situations. While one tool might have worked best with our Visual Basic, Java or C/C++ applications, we may need to use a different tool for our web clients. By keeping a specific tool consideration out of our test designs, we avoid limiting our tests to that tool alone. The overall test strategy will define the format and low-level vocabulary we use to test all applications much like an automation tool defines the format and syntax of the scripting language it provides. Our vocabulary, however, will be independent of any particular test framework employed. The same vocabulary will migrate with us from framework to framework, and application to application. This means, for example, the syntax used to click a button will be the same regardless of the tool we use to execute the instruction or the application that contains the button.
The test strategy/design should remove most testers from the complexities of the test framework.
In practice, we cannot expect all our test personnel to become proficient in the use of the automation tools we use in our test framework. With suitable framework in place the bulk of our testers can concentrate on test design, and test design only. It is the automation framework folks who will focus on the tools and utilities to automate those tests.
