In This Course

Did you know that a recent poll revealed that 80% of QA Automation Engineers cannot run more than 100 functional tests daily, with 95% reliability? Furthermore, over 50% of these Automation Engineers struggle to run between 0 – 50 automated functional tests per day!

Functional test automation is a hard job. However, you can make your job much easier by learning a pattern known as the Page Object Pattern. The Page Object Pattern helps to resolve a lot of the problems that other automation techniques cannot. Making your test automation more stable as a result.

This course is designed to teach you how to properly code the Page Object Pattern using Selenium Webdriver with C#.

However, all of the information here is equally applicable to any other functional testing tool because the Page Object Pattern is a universal principle that makes test automation more robust. Similar to other universal concepts such as Don’t Repeat Yourself or Single Responsibility Principle.

Therefore, if you know Object Oriented programming and a different functional automation tool, you can still comfortably follow along with all of the principles and patterns that I lay out in this course.

In this course, you will learn:

– Why other methods such as Record & Replay or Keyword Driven do not work when it comes to test automation

– What the Page Object Pattern is in automation

– Advantages and disadvantages of the Page Objects

– Amazing tips and tricks on how to:

  • Implement the Page Objects using Selenium Webdriver
  • Improve your Page Objects to follow DRY Principle
  • Improve Page Objects to follow SRP Principle
  • Create amazing Page Objects for gigantic web pages

Free Video Course

In This Lecture

In the previous video, we learned about what can we do to fix the problems with recorded functional test of the page objects in test automation course. In this video, we are going through the problems with recorded functional tests for the course.

What are the problems with recorded functional tests?


So we finally got our recorded test to work.

What I’ve also done here for the sake of exemplary purposes is I’ve duplicated these recorded tests. I literally just copied and pasted them to pretend like we actually have a suite of tests and you can just pretend and imagine with me that we have a suite of 500 recorded tests. Not that it’s ever possible to maintain a suite of 500 recorded test. But let’s pretend and imagine 500 is a good amount of automated functional tests to have. And let’s pretend that we have those tests.

And the reason that I want to pretend that we have those tests is because I want to drive a point home in that with a recorded automated functional tests, it is all pure duplication. So if you take a look at the test here compared to the test here compare to this test everything is duplicated.

And of course I copied everything but there is no other way around it. When you record a test you redo all of your steps and you rerecord every single action regardless, there’s no other way about it. So that’s the point. Now keep that in mind because any single change that we have to make as a result of a change in our application and their test is going to affect all of those tests that directly communicate with that application.

So take a look at this test right here test one fix too. What can about this test be affected by the application under test? Something about the application of the test can change that will cause our test to break.

Now if you’re looking at this test and it looks OK to you as if you don’t think that there’s anything wrong with this test, that is completely OK and I actually expect that from you because I’ve been at multiple job situations where people are still using a record and replay to do automated functional testing.

Why wouldn’t they? It seems so attractive when they hear a proposition that you can record your test you can record the steps and then have them running within a few minutes and have a bunch of tests recorded within a few minutes.

That sounds fantastic. I would love that proposition.

But the problem is that when something in the application under test changes, everything about the test can break. For example, a URL¬†can change. Any of the locators here can change. These class names they can change. These IDs can change of course it’s not as likely but it’s possible. The locators can change, the URL can change. Even worse, the usernames and passwords can change as well. One of the worst situations to deal with this data management which is another beast of its own.

But imagine trying to navigate from to test to prod. You have to maintain all those usernames and passwords and you can’t do that in a recorded test. The URL, what you gonna do when you go from dev to test to prod. Are you going to hard code those are rails into your scripts? I’ve actually seen that done.

I’ve actually been at a workplace where we had about 100 or so automated functional test recording. Even though only 30 of them were actually testing any kind of functionality because the other 60, the other 67 percent were just duplication of the first. You know 30 percent of the tests because they had scripts for dev, test, and prod. The scripts were doing the exact same thing. The only difference was the URL.

So now imagine how many lines of code you have to maintain to be able to just look after 30 tests. That’s insane. And so anytime any kind of application change happens it will break all of those tests, and as opposed to fixing it in a single place, now you have to go to three different places for three different scripts to fix your tests.

And that’s the entire point here.

The problem with recording replay is that a single change in your application can drastically affect all of your testings in your application as long as they’re touching it because all of your tests are directly touching the application. They will all be directly affected by a change in that application. And so that’s why everybody says automated functional tests are brittle because of course, they’re brittle when you have a single change that needs to be updated in 500 different instances.

Of course, you’re going to say that it’s brittle. And of course you’re going to throw up your hands in the air and complain

Nikolay Advolodkin is a self-driven SDET on a lifelong mission to create profound change in the IT world and ultimately leave a legacy for his loved ones, community, and the world at large. Today, he serves as the CEO and Test Automation Instructor at and contributes informative articles to leading test automaton websites like and

Pin It on Pinterest

Share This