Process for creating an automation test framework and how to go about automation testing

Every automation tool will give you the ability to record a series of actions so that these can then be played back and you can create a script out of these. However, this is a very basic level of test automation, which does not provide you any flexibility. This process has its uses when you are creating a simple testing strategy whereby you have to take a few scenarios where you do not expect variations or changes, and you can record these sequences and then use them again and again. However, when you need to make changes or modify values, then the cost of doing so starts increasing tremendously. This is a time when you should evaluating the use of creating testing frameworks for you automated testing. Just the process of starting to design a test automation framework will ensure that you are starting to work through your requirements methodically, and will prevent your team from ending up in a mess (a typical example of a mess is when you have a huge number of unconnected automation scrips with their own needs for maintenance, with poor documentation leading to a disaster when people change).
How do you go about creating test automation frameworks ? Before we even go down this route, we should consider some of the benefits that you would get if you were to have an automation framework / or in the examples below, more of an automation strategy:
- You start to separate your data from tests, something that makes it easier to manipulate different types of data (very useful when you want to test the same test with a wide range of data)
- You can look towards reusing functions (building reusable functions can eventually help in saving a lot of time and make the building of these functions more efficient)
- You prevent a situation where you end up with a huge amount of test cases with high maintenance requirements; maintaining these scripts become easier (very useful when you have teams with high personnel changes or attrition rates)
- You will also start evaluating as to which stage is it practical to start building an automation test plan - in some cases, you may delay till the major elements of UI changes are done and over
- Refinements to the manual test cases are avoided later, instead the necessary adaptation of test cases to automation needs is done when they are getting generated; this saves a lot of effort later