Effective Management of Automation Test Artefacts
Does either of the above look similar to your automation test repo?
Whether you’re using Behaviour-Driven Development (BDD), Keyword-driven, or any other frameworks (shared in previous article), there’s always a set of test artefacts (such as object repository, test scripts, test data files, test execution suite, test execution results) that you will need to maintain. In most BDD frameworks, there are feature files, step definition files, etc.
If each tester creates their own set of artefacts in their own ways without any standardisation, can you imagine how messy the repository will be? This increases the likelihood of duplicated code, thus making it challenging to locate and reuse existing code efficiently. Hence, establishing clear guidelines will significantly enhance both maintainability and usability.
The following are some guidelines on improving maintainability we’re looking at:
Separating HTML elements from test steps
Almost all HTML elements are used across multiple test cases. Separating them from test steps will eliminate the need to re-identify elements for each test case, thereby saving time. In this way, it is splitting technical aspects (e.g. HTML attributes of the elements) from business flows (test steps). You can update the technical details without having to touch the business logic, which is encapsulated in your test steps. Conversely, if there are changes in the business flow, you can adjust your test steps without altering the elements. For reference, Page Object Model is one of the most common patterns used. This separation makes your framework more modular and easier to maintain and also enhances its scalability as your application grows and evolves.
For common elements that appear in multiple pages, such as top menu bar or footer, it is unnecessary to capture these in each and every page object. Instead, have a common page that contains all the shared elements to prevent duplicate efforts and reduces maintenance overhead. This approach ensures that any change to a common element needs to be made only once, in one location, thereby propagating the update across all relevant test cases.
Organising test artefacts in clear structure
Organising test artefacts into distinct folders creates a visual hierarchy that aids in understanding where each component belongs. Here are some ways to organise the artefacts:
- based on business flows, and/or
- categorise based on modules, application features or individual pages
Considering newcomers may come onboard at any point of time, arranging the artefacts logically is crucial while the second approach provides better clarity. Structuring the artefacts according to the application’s hierarchy makes it easier for them to relate and navigate through the folders.
Having standardised naming conventions
Likewise, having standardised naming conventions (letter casing included) also contributes to a tidy and well-organised automation repository. Consistent naming practices ensure coherence across all files, making it easier to locate specific items and understand their purpose at a glance.
Reusability
The next important yet often neglected point is reusability. Definitely there are similar steps that you will see yourself repeating in different test cases, especially the login and logout steps which are required in almost all test cases. It’s not feasible and a waste of effort to keep repeating the same set of codes in every single test case.
However, just lumping all the similar code into a method/function also doesn’t ensure true reusability; one has to verify that the function can be reused across different test cases. This is particularly critical when there are existing test cases that rely on the code. By ensuring code reusability in this manner, teams can maximise efficiency and maintain consistency across their testing processes.
Refactoring
You don’t have to jump into making each and every piece of code reusable at the start time of your scripting phase. Chances are the more you script, you’ll have a better idea of which and what steps are more reusable.
Allocate time for refactoring periodically to improve your automation testing. Use this opportunity to enhance code readability; having a large block of steps that isn’t easily understandable is counterproductive. By refactoring and ensuring clarity in your codebase from time to time, you can maintain and improve the effectiveness of your automation tests over time.
As the automation repository continues to expand, the possibility of having duplicate codes across multiple pages increases. This can become a significant challenge especially when updates are required due to changes in elements or business flows. Adopting disciplined practices and adhering to a uniform naming convention leads to a tidy and well-organised test repository, which in turn, enhance the reusability and facilitate smoother onboarding for new team members, allowing them to quickly grasp existing processes.
Of course, the list doesn’t only stop here! Go ahead to define and set your standardisation that works best for your project/team to achieve the most effective way to manage your repository. Do feel free to share your thoughts in the comments!
🧙🏼♀ Team Merlin 💛
Application security is not any individual’s problem but a shared responsibility.
