Factors That One Should Keep In Mind While Building A Fresh Test Automation Project / Framework
In the last Framework series, we have seen How To Explain Test Automation Framework In The Interview. Today we will see the factors that one should keep in mind while building a fresh test automation framework.
What are the factors that one should keep in mind while building a fresh Test Automation Project / Framework?
Honestly, I initially had a tough time answering this correctly.
The above title, being a very famous software testing interview question, may have answers that would range from person to person.
The main problem arises when, the interviewer, who thinks some specific factors as indispensable while developing a new Test Automation Project / Framework may not be satisfied by your idea of “the most essential parameters for developing a new Test Automation Project / Framework”. Especially if you miss quoting similar to his/her notion.
Then shall we presume that this question is subjective?
No, it is not. We have to understand that, there are certainly some major factors that always need to be kept in mind while building a new test automation project.
However, the way one weighs the importance of each factor and has had the experience while building one project, add the little tinge of variation in understanding.
With a dozen of personal interview experiences, being at both the sides of tables, I have mentioned below a comprehensive list of things that one should keep in mind while building a fresh test automation project/framework.
Know all about the application under test
Since you will be automating the test cases for a particular system, it is imperative that you have ample knowledge about it.
It is important for you to know the answers to the following questions,
- Is the application stable?
- Are enough manual tests run executed on the same?
- Whether the application under test is Web or Windows or Mobile?
- What are the data flows, processes, and inputs that are required?
The key is that you familiarize yourself with the application very well by making notes of the requirements and on the basis of these two, simultaneously think of how the automation will assert and verify them.
You may have understood the requirements and have read documents outlining the entire application, nevertheless, commencing exploratory testing will give you a better glimpse of the internal workflows of the system.
Just knowing how the application works, should not be your goal, you should also start to understand how things are wired up internally.
The dedicated resources and target audience
Once you know you are well off with the application under test, try to get answers for questions like,
- Is there a dedicated automation team, if yes, how many resources are put in it?
- What will be the structure of the team be like?
- Who is the audience for the test reports?
- How big is the target audience?
- What kind of test reports will be expected?
It is essential for a test automation engineer to know these from the start, because of the following reasons,
- If the automation team will be limited, then perhaps, the team won’t face a huge challenge while working on the daily automation tasks. However, if the team is huge and distributed, then a couple of challenges may arise when working coherently. In such cases, the versions of the framework or scripts need to be maintained. This can be done either in a local repository or in a versioning tool. As a number of people will be working on the same framework, easy monitoring of changes made to the software code can be achieved.
- Coming to the test report’s part, considering the target audience’s preference and technical exposure, the granularity of reporting, logging, ability to transform reports to other storage/format, or even to mail it to individuals, etc can be decided. On the basis of this, the test framework can be designed from the start.
Budgeted Cost and deciding the right tools
The budget constraints are one of the most important things to keep under consideration. This is because, it will be directly associated with the selection of the automation tools since the cost will be involved in licensed products, upgrade version payments, setting up the test environment (in case external software and hardware are required) as well as the maintenance of the tools.
Hence, it is always recommended to make get a clear picture of the budget of the project, and based on that, the selection of the tools can be made.
Realistic Expectations or Test Automation Scope
It is very crucial that before you start with developing a test automation framework, you as well as the management and the project team must decide upon the expectations out of the automation framework.
It is wise to start off by keeping realistic expectations and defining the test scope beforehand.
Following are some pointers that the test team should discuss and agree upon,
- It is not possible to achieve 100% automatic tests.
- To automate each and every test case is an unreachable goal.
- The benefits of test automation can be reaped only after multiple cycles of test
- execution and expecting an immediate ROI is a myth
- A separate ramp-up time should be given for tool selection, framework creation.
Design
Deciding on the design of the Framework type is another pivotal task. This is essentially decided by the type of input of test data to the test scripts.
Following are some of the commonly used test automation framework,
- Data-Driven Automation Framework
- Keyword Driven Automation Framework
- Modular Automation Framework
- Hybrid Automation Framework
- Linear Scripting Framework
- Behavior Driven Development Framework
- Well Organized Framework
- Configuration Options
- Framework Versioning
- Extensibility and Maintenance
Read more on Types of Test Automation Frameworks
Test Scripting Best Practise
Lastly, coming to the most ground level yet the most important point, the test scripts and data handling tasks.
It is highly recommended, that handling of test scripts, test data, libraries, and other utility files should be done separately and the code is mostly preferred to be written in an object-oriented manner. This allows the reusability of the code along with other benefits derived from OOPs concepts.
Some of the scripting standards that are widely used are as follows:
- To build an object repository : (example: web elements locators stored in OR.properties file)
- To design a common function library : (example: to keep all the common operations in one file)
- To write test cases using an integrated test management tool : (example TestNG)
- To parameterize the test: (example: to keep a separate data source file)
- To keep the generated file and screenshots saved
- To generate a test report
- Test automation framework integration with CI/CD tools: (example: the ability to integrate with tools like Jenkins or TeamCity)
I hope this helps you all. Bonus point: the better you understand the concepts the better you will explain your answers.
Author’s Bio:
A Senior Software Test Engineer with a Government entity based in Singapore and a published co-author, Sainy Banerjee Pal, has an extensive Software industry experience of 6+ years in domains such as SAP, Electronics, Telecom, AFC, E-commerce and writes for several leading websites. You may often find her scribbling notes, reading articles, passionately explaining concepts to others or at https://medium.com/@sainy.banerjee09.
Here I have hand-picked a few posts which will help you to learn more interview related stuff:
- Where you have applied OOPS in Automation Framework
- Data Driven Framework in Selenium WebDriver
- Page Object Model with Page Factory in Selenium
- Selenium Tutorial
- Manual Testing Tutorial
- SQL Tutorial for Software Testers
- Performance Testing Tutorial
- Security Testing Tutorial
- API Testing Tutorial
- Postman Tutorial
