Automated testing goes far beyond just clicking buttons or interacting with elements on a screen. Over time, test automation has evolved, bringing new challenges and opportunities along with it. But the question is: we, test automation engineers, are we adapting those changes? Are we pushing ourselves to think beyond these boundaries? I often reflect to these questions and try keep myself up-to-date with the latest trends and best practices.
The tips or tricks or best practices I am going to share today are nothing from any book. It’s all from my experiences which I or my team felt good to have and thus became my daily life practices while automating anything.
Tip 01: Think beyond POM
POM is good. It’s one of the fundamentals nowadays while designing any automation framework from scratch. But trust me POM is not enough. We are dealing with complex projects and complexity is growing and growing. As a test automation engineer, I love to see myself competing with full stack developers. If I limit myself only with POM then I am definitely falling behind. I believe to truly excel as automation engineer we should have the ability to mix different patterns. Integrate patterns like Factory, Singleton, and Modular alongside POM to address specific needs such as dynamic object creation, shared resources, and separation of concerns. For example, use the Factory pattern to generate page objects or test data dynamically, and Singleton to manage shared driver instances. A very good read I found is this article Time to Move Past POM? 3 Design Patterns That Will Improve Your Test Automation. Nope, I am not really saying to move on of POM but mixing other patterns will definitely improve your framework strength.
Tip 02: Separate elements from page class
As automation projects scale, page classes can become cluttered with hundreds of web element definitions, making maintenance challenging and reducing readability. Instead of keeping all element locators inside the page class, consider abstracting them into dedicated classes or modules. For example, you can create page specific element classes and refer it from the page classes to use them. In my case this is what I did:
Not Recommended
class SigninPage {
get inputUsername() { return $('#username') }
get inputPassword() { return $('#password') }
get signInBtn() { return $('//button[contains(text(),"Sign In")]') }
async login(username, password) {
await this.inputUsername.setValue(username);
await this.inputPassword.setValue(password);
await this.signInBtn.click();
}
}
export default new SigninPage();Code language: JavaScript (javascript)Recommended
signin.locators.js
export const SignInLocators : {
inputUsername: '#userLoginId',
inputPassword: '#password',
signInBtn: '//button[contains(text(),"Sign In")]',
}
<em>Page Class</em>
import { SignInLocators as locators } from 'signin.locators.js';
class SignInPage {
async login(username, password) {
await $(locators.inputUsername).setValue(username);
await $(locators.inputPassword).setValue(password);
await $(locators.signInBtn).click();
}
}
export default new SigninPage();Code language: PHP (php)This approach not only cleans up your page objects but also encourages reusability and easier updates when UI changes occur. Above example I am giving from WebdriverIO with Javascript, but can be implemented in other frameworks like Playwright as well.
Tip 03: Assert with API
UI automation alone may not always provide the fastest or most reliable feedback. Where possible, complement your UI tests with API assertions. By validating application state or business logic directly through API calls, you can catch issues earlier and reduce test flakiness. For instance, after performing an action in the UI, use an API call to confirm the expected backend state or data. This hybrid approach helped us to increase confidence in our tests.
Tip 04: Network Interception
This will complement my earlier point of asserting with API. Some cases you might find yourself in a situation where you need to capture the data which is only related to the current browser session. So getting API response in this case will not be very useful. Network interception would be perfect companion in such scenarios. Network interception is a powerful technique in test automation that allows you to monitor, modify, or stub HTTP requests and responses between the client and server during test execution. Tools like Cypress, Playwright, and Puppeteer provide built-in support for intercepting network traffic. A very good read on this subject matter is this article Network Interception and UI Tests.
Tip 05: Documentation
Maybe the least exciting attribute of test automation but undoubtedly most important one. Clear, concise, and regularly updated documentation ensures that your automation strategy, test cases, and framework decisions are accessible to everyone on the team. This not only helps with onboarding new members but also promotes consistency, reproducibility, and easier maintenance as your suite grows. BDD feature files can be used as live documentation for the test cases. Another best practice is to have comments for your test methods. This comments are very useful while reviewing or refactoring. Comments can be treated as documentation as well.
Tip 06: Shift-left
OK, maybe this not directly falls upon the best practices of test automation. Primarily it’ll will depend on the organization policies, technical road map and on few other attributes, But there are some great values out there for having this approach implemented. Adopting shift-left testing means integrating test automation earlier in the development lifecycle. By collaborating with developers from the start and running automated tests as soon as features are ready—even before full UI implementation—you can detect issues sooner, reduce wait times, and maximize resource efficiency. Shift-left helps prevent bottlenecks and ensures that quality is built in from day one, not just verified at the end.
That’s it for now, folks! I meant to share just a few quick tips from my experience, but it kind of turned into a long read. Still, I want to say that most of these tips have really helped me and my team build automation frameworks that are strong, scalable, and able to keep up with all the changes in software these days.