+91 7387620624

Framework Standards

Introduction

A Selenium automation framework is more than just a collection of test scripts. As the number of test cases increases, the framework should remain organized, reusable, and easy to maintain. This is achieved by following a set of Framework Standards.

Framework Standards are guidelines that define how different parts of an automation framework should be organized and how responsibilities should be divided among them. Instead of placing all the code inside test scripts, a well-designed framework separates test logic, page objects, locators, utilities, configuration files, and test data into their respective layers.

By following framework standards, teams can easily maintain the framework, reduce duplicate code, improve readability, and make automation scalable.

In this tutorial, you’ll learn the most commonly followed framework standards in Selenium with Python.

What are Framework Standards?

Framework Standards are best practices that define the structure and organization of an automation framework.

They ensure that:

  • Test scripts remain clean and readable.

  • Responsibilities are properly separated.

  • Code is reusable.

  • Changes can be made with minimal effort.

  • The framework is easy to scale and maintain.

Professional Selenium frameworks follow these standards to build robust automation solutions.

Why Use Framework Standards?

Framework standards provide several benefits:

  • Improve framework organization.

  • Reduce duplicate code.

  • Simplify maintenance.

  • Increase code reusability.

  • Improve collaboration among team members.

  • Make the framework scalable.

  • Produce professional-quality automation projects.

Framework Standards Used in Selenium

A well-structured Selenium framework typically follows these standards:

  • The Test Layer contains only the test scenario and assertions.

  • The Page Layer contains page locators and page actions.

  • All locators are stored in one place for easy maintenance.

  • Methods should use business-readable names such as login(), search_product(), or show_message().

  • Utility classes should contain reusable helper methods.

  • Configuration values should be stored separately from test scripts.

  • Test data should be managed independently of the test logic.

Test Layer

The Test Layer should only describe:

  • The test scenario.

  • Test steps.

  • Assertions.

It should not contain:

  • Complex Selenium logic.

  • Repeated locators.

  • Utility methods.

  • Configuration values.

Example

def test_login():
    login_page.login("admin", "admin123")
    assert home_page.is_dashboard_displayed()

The test remains short, readable, and focused on validating a single scenario.

Page Layer

The Page Layer contains:

  • Web element locators.

  • Page actions.

  • Reusable page methods.

Example

class LoginPage:

    def login(self, username, password):
        self.username.send_keys(username)
        self.password.send_keys(password)
        self.login_button.click()

Keeping Selenium interactions inside page classes makes test scripts cleaner and easier to maintain.

Store Locators in One Place

Locators should be stored together inside the Page Object or a dedicated locator class instead of repeating them throughout the project.

Good Example

USERNAME = (By.ID, "username")

PASSWORD = (By.ID, "password")

LOGIN_BUTTON = (By.ID, "login")

When a locator changes, it only needs to be updated in one place.

Use Business-Readable Method Names

Method names should describe business actions instead of Selenium operations.

Good Examples

login()

search_product()

show_message()

checkout_order()

Avoid

click_button()

method1()

action()

test()

Business-readable methods make test cases easier for both testers and developers to understand.

Separate Utilities

Reusable helper methods should be placed inside utility classes.

Examples include:

  • Wait utilities

  • Screenshot utilities

  • Logging utilities

  • Driver factory

  • Configuration reader

This avoids duplicating common functionality across multiple test scripts.

Keep Configuration Separate

Configuration values should not be hardcoded inside tests.

Instead, store them in configuration files such as:

  • config.json

  • config.ini

  • config.yaml

Common configuration values include:

  • Base URL

  • Browser name

  • Timeout values

  • Environment details

Separate Test Data

Test data should be stored separately from test scripts.

Common sources include:

  • Excel files

  • CSV files

  • JSON files

  • YAML files

  • Databases

This makes tests reusable with different input values without modifying the automation code.

Recommended Selenium Framework Structure

Project
│
├── pages
├── tests
├── utilities
├── config
├── testdata
├── reports
├── screenshots
└── logs

A clear project structure makes the framework easier to navigate and maintain.

Practical Example

Suppose an e-commerce application has more than 1,000 automated test cases.

Instead of placing Selenium code inside every test, the team stores locators in Page Objects, keeps reusable helper methods in utility classes, manages configuration separately, and stores test data in external files. This allows updates to be made quickly without affecting the entire framework.

Automation Testing Example

Consider an online banking application.

The login page contains all its locators and actions inside a LoginPage class. Test scripts simply call login_page.login() and verify the expected result. Configuration values are read from a configuration file, while customer data is loaded from Excel files. This separation keeps the framework clean, reusable, and easy to maintain.

Real-World Example

Framework standards are followed in:

  • Banking applications

  • Healthcare systems

  • E-commerce platforms

  • CRM applications

  • ERP systems

  • Government portals

  • SaaS products

  • Enterprise Selenium automation frameworks

Advantages of Framework Standards

  • Improve framework organization.

  • Reduce duplicate code.

  • Simplify maintenance.

  • Increase code reusability.

  • Make frameworks scalable.

  • Improve readability.

  • Encourage collaboration among team members.

  • Produce professional-quality automation frameworks.

Common Mistakes Beginners Make

Writing All Code Inside Test Scripts

Avoid placing Selenium interactions, locators, and utility methods directly inside test cases.

Separate responsibilities into appropriate layers.

Repeating Locators

Do not define the same locator in multiple files.

Store locators in one central location.

Using Generic Method Names

Avoid names like:

method1()

click()

test()

Use meaningful names such as login(), search_product(), or show_message().

Hardcoding Configuration Values

Avoid writing URLs, browser names, or timeout values directly in test scripts.

Store them in configuration files.

Mixing Test Logic with Test Data

Keep test data separate from automation logic by using external data sources.

Best Practices

  • Keep the Test Layer focused on scenarios and assertions only.

  • Store Selenium interactions inside Page Object classes.

  • Keep locators in one centralized location.

  • Use business-readable method names.

  • Create reusable utility classes.

  • Store configuration separately from test scripts.

  • Maintain test data in external files.

  • Follow a consistent project folder structure.

  • Design the framework for easy maintenance and scalability.

Conclusion

Framework Standards provide a structured approach to building Selenium automation frameworks. By separating test logic, page objects, locators, utilities, configuration, and test data into dedicated layers, teams can create frameworks that are easier to understand, maintain, reuse, and scale. Following these standards results in cleaner code, improved collaboration, and professional-quality automation projects.

Frequently Asked Questions (FAQs)

What are Framework Standards?

Framework Standards are guidelines that define how an automation framework should be organized and maintained.

Why should the Test Layer contain only test scenarios and assertions?

Keeping the Test Layer focused on scenarios and assertions improves readability and separates business logic from Selenium implementation details.

Why should locators be stored in one place?

Centralizing locators makes maintenance easier because changes only need to be made in a single location.

What are business-readable method names?

Business-readable method names describe user actions, such as login(), show_message(), or checkout_order(), making test scripts easier to understand.

Why should configuration and test data be stored separately?

Separating configuration and test data from test logic improves reusability, simplifies maintenance, and allows tests to run in different environments without changing the code.

Key Takeaways

  • Framework Standards help create organized, maintainable, and scalable Selenium automation frameworks.

  • Keep the Test Layer focused on test scenarios and assertions.

  • Store page actions and locators inside the Page Layer.

  • Keep locators centralized for easier maintenance.

  • Use business-readable method names such as login() and show_message().

  • Separate utilities, configuration, and test data from test scripts.

  • Follow a consistent project structure to build professional automation frameworks.