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
In This Lecture
In the previous video, we learned finally getting the recorded test to run of the page objects in test automation course. In this video, we are going to re-emphasize a few points and conclusions regarding recorded tests.
Conclusions regarding recorded tests
Let me re-emphasize a few points very quickly.
The main point that I want to make to you and I kind of creator’s score sheet to keep track of all this is how many tests actually need to be updated. Whenever there’s a change in our application on their test or any kind of environmental change. And so here I placed a bunch of change agents and then on the right hand side I’m going to display how many recorded tests actually need to be changed as a result of the change agents on the left. So if we change something like the driver we need to update all of the tests basically for everything for you orals for
So if we change something like the driver we need to update all of the tests basically for everything for URLs, for locators, usernames and passwords and synchronization issues basically with record and replay.
The main point is that it sounds extremely attractive that you can click a record button perform a few actions and then rerun your tests after that and it makes it seem really easy. But the problem is that it is not stable. As you could see even after I recorded the initial functional test, I still had to make a few changes to it just in order to get it to run initially.
And that happens all the time.
So that’s the main point is that recorded in replay although it does sound attractive, it is not stable at all because you need to keep up with too many changes and to update all of the tests anytime there’s any kind of change. So now knowing that knowing that maintenance for required a test is extremely tough.
What is it that you can do to improve your automated functional tests and to take them from a recorded level where a ton of changes can break your automated functional tests and decrease and insulate your tests from all of those changes so that you don’t have to update as many tests at once.