Page Object Model vs Screenplay Pattern: Lessons from the Field

By Eduard Dubilyer , CTO at Skipper Soft .

1. When and Why the Page Object Model Was Created

When I first entered the world of test automation, frameworks were in their infancy. The code was tangled, the logic scattered, and maintenance was a nightmare. The Page Object Model (POM) emerged as a response to this chaos—offering a simple and clean way to organize automated tests.

It gained popularity in the Selenium ecosystem around the early 2010s. The idea was to encapsulate UI elements and page-level interactions into reusable classes, reducing duplication and simplifying updates when UI changed.

What is it? POM maps each screen (or page) to a corresponding class that knows how to interact with the elements on it.

Structure Example:

public class LoginPage {
    private WebDriver driver;
    public LoginPage(WebDriver driver) {
        this.driver = driver;
    }
    public void enterUsername(String username) { /* ... */ }
    public void enterPassword(String password) { /* ... */ }
    public void clickLogin() { /* ... */ }
}        

Pros:

• Easy to understand and implement
• Reduces code duplication
• Centralizes UI updates

Cons:

• Can get bloated with logic
• Test logic sometimes sneaks into page classes
• Doesn’t scale well for large or behavior-driven teams

2. Why the Screenplay Pattern Was Born

A few years later, as our projects grew at Skipper Soft and more teams joined the QA efforts, we hit POM’s limits. We needed something more expressive, more modular. That’s when we met the Screenplay Pattern.

Born from the Serenity BDD community (mainly in Java) and inspired by the Actor model from software design and theater, Screenplay was created to improve readability, reuse, and test maintenance.

What is it? Instead of pages, you think in Actors, Tasks, and Abilities.

Structure Example:

public class LogIn implements Task {
    private String username;
    private String password;
    public static LogIn withCredentials(String user, String pass) {
        return new LogIn(user, pass);
    }
    public void performAs(Actor actor) {
        actor.attemptsTo(
            Enter.theValue(username).into(USERNAME_FIELD),
            Enter.theValue(password).into(PASSWORD_FIELD),
            Click.on(LOGIN_BUTTON)
        );
    }
}        

⚠️ Style tip: Use clean indentation to make screenplay scripts more readable and expressive.

Actor Alex = Actor
    .named("Alex")
    .whoCan(BrowseTheWeb.with(driver));
Alex.attemptsTo(
    LogIn.withCredentials("user", "pass")
);        

Pros:

• Highly modular and scalable
• Encourages business-level test readability
• Easy to reuse and combine tasks

Cons:

• Higher learning curve
• Initial setup feels heavy for small teams or projects

3. When to Use What: Real Use Cases

Example: Testing Login Flow

Using POM:

LoginPage login = new LoginPage(driver);
login.enterUsername("user");
login.enterPassword("pass");
login.clickLogin();        

Straightforward, clear. But what if we want this behavior in 10 different test flows? You start duplicating steps or pushing logic into the test method.

Using Screenplay:

Actor Alex = Actor
    .named("Alex")
    .whoCan(BrowseTheWeb.with(driver));
Alex.attemptsTo(
    LogIn.withCredentials("user", "pass")
);        

You describe what Alex does, and the logic lives in LogIn. You can reuse this across scenarios, just as we did in a recent Skipper Soft client project where multiple personas performed similar tasks.

Bonus: Role-Based Access? Use Screenplay.

One of the strongest use cases for Screenplay is systems with complex role-based access, such as admins, users, and dashboard managers.

In POM, managing these roles often leads to duplication and confusion. In Screenplay, each user type is simply a different Actor with specific Abilities:

Actor Admin = Actor.named("Admin").whoCan(ManageSystem.with(adminDriver));
Actor User = Actor.named("User").whoCan(UseFeatures.with(userDriver));        

Testing access, roles, and permissions becomes natural, readable, and easy to maintain.

When to Use POM:

• Small to mid-size projects
• Single QA engineer or small team
• Fast prototyping

When to Use Screenplay:

• Large teams, or growing QA department
• Domain-driven, long-term test suites
• High test reuse, personas, or behavior-focused testing
• Role-based access testing

4. POM vs Screenplay — TL;DR

5. Real-World Analogy

POM is like giving someone a map with instructions for every street and turn: "Go 100 meters, turn left, press buzzer."

Screenplay is like giving an experienced assistant a goal: "Go to that building and drop off the documents." The assistant already knows how to do each step.

6. Five Takeaways for Automation Engineers

1. Start with POM if you’re building from scratch in a lean environment.
2. Move to Screenplay if you’re growing a team or handling multi-user behaviors.
3. Don’t mix logic and UI even in POM. Keep responsibilities clean.
4. Model real user behaviors as tasks for better readability and reusability.
5. Invest in patterns early – it pays off in maintainability and speed.

7. Final Thoughts

At Skipper Soft , we’ve built solutions for both small startups and enterprise platforms. The pattern you choose can shape your QA strategy for years. My advice? Think beyond just making tests pass. Think about who will read, maintain, and extend them.

If you’re unsure which model fits your project, I’m happy to share what worked for us and help you design the proper framework.

Let’s talk testing strategy. Reach out at skipper-soft.com or connect with me on LinkedIn.