Data Management in Automation Testing
In this new Techno-Digital age, all of us focus on two major topics: Automation & Data. Let us make an attempt to have a look at them together, i.e. Data Management in Automation Testing.
As with any approach, there can be many alternatives, I am going to put forward an approach which has suited me, in most of the frameworks.
P.S: Since, I have worked more on Banking/FinTech applications, the examples in this post would be around Banking Applications.
- The FIRST suggestion I would have is to try and Generate a Unique Set of Data for every Test Case as much as possible. One should always try to generate the data required for a Test case before the execution and destroy it properly after the usage. This way, you won’t face issues that come with reusing the same data again and again, reducing (if not removing) the possibilities of Data Corruption failures in Automation. I Strongly recommend generating this Data using APIs/BackEnd (micro)services, further helping us in creation of Faster and maintainable data, without having to go through the ever-changing UI screens.
For example, Consider the Test case of Requesting a New card, in this case, a new unique user (created from BE services) would be helpful. This user when created through the API’s would provide us huge leverage in overall Automation execution.
2. While we try to create a Unique Set of Data, practically I do understand that it is not always possible. In such cases, the SECOND question arises: “Data Storage”. In my opinion, Data should always be kept separate from the code and stored in easily maintainable files like .property.
As an example, let us consider storing a set of Test Cards, which are needed to be maintained. This set if maintained in an external file, we would need to change the details (if and when needed) only in this particular file, without having to touch any of the code.
3. Now, the big one: Environments: Most of the banking applications would have multiple environments and it is crucial to consider this while defining test automation data strategy. Let us take a look at managing Test Data on multiple environments in the most flexible, scalable and easily maintainable manner. It is extremely important to split, the file(s), into two categories:
- Common for All Environments
- Specific to a particular environment
The file(s) that we have discussed earlier, could then be created like below:
- One Common File which would be needed across All Environments and can be used extensively
- One file for each of the other environments. For environment-specific files, put each file into its own environment folder
Example: User Credentials to access a crowd-based device platform (or administrator credentials) can be kept in ‘common.properties’ file and URL of the application or a particular backend service should always be kept in the Environment specific property files.
4. The Biggest question in these days of International applications is Localisation:
When it comes to managing Automation Data for different locales, the data should be separated for different locales in the different Environments. We should be extremely careful of keeping the data stored in each of the environments and locale specific files (described above) to the extent of what is required and NOT over-flood the files.
For Example, it’s the various messages displayed on the application, currency of a particular country would be locale dependant, hence, these types of Data should be kept in the locale specific files.
For any automation project, on a high level, if we can keep these above points considered, we would have a stable running automation test cases without much hiccups.
Thank you and Wish everyone all the very best.
