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. It is 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 this video, we are going through the question as to how many functional tests can you run per day for the Page Object course.
Selenium Tutorial – Course Outline
The second question that I asked you was: How many tests can you run per day that will give the correct result with 95% accuracy?
Meaning that, if you run the test 100 times, minimum 95 you of those 100 times are going to give you a correcting pass if it passed successfully, or a failure, if there is a bug or the functionality changer broke your test.
So I provided a bunch of multiple-choice response.
5000+ tests per day, 1001 to 5000, 501, this, all the way down to zero to 50.
Now, think about it yourself.
How many tests per day can you run that would provide you the correct result with 95%accuracy at least?
If it’s 100 % that’s perfect, but I believe that a little bit or error is ok, even at Google they run automated functional tests with some failure rate that is extremely hard to fix.
So, think about it.
How many can you run per day?
Here are all the 35 responses.
2, 4, 5000+ and that does not surprise me at all, it is extremely tough to run 5000+ automated functional tests per day, with 95%accuracy.
I think I’m just starting to get to that level and it requires a lot of hard work, it requires parallel test execution, it requires very complex environment and complex frameworks to be able to accomplish that.
So, these people that can do this, that’s amazing, I would love to talk to you, and figure out how you doing it, just so I can learn from your experience.
3 for 1001 to 5000, 2 for 501 to 1000, 4 for 101 to 500, this is starting to increase our numbers as we are getting closer towards the bottom, 5 for 51 to 100, and then personally for me not surprising at all, 20 people can only run 0 to 50automated functional tests per day with 95% accuracy.
And that not surprising to me at all because that’s exactly what I see at every single job that I go.
I’ve been doing this for many years now, and every time I show up to a position to do automated functional testing, we have no automated functional testing or is so bad that it needs to be rebuild from scratch because everything is so unstable and it’s impossible to run any tests or very few tests with any kind of accuracy.
So, again, that tells me that flakiness for you all is a problem because you can’t write a lot of tests, you can’t write stable tests and therefore you can’t execute a lot of automated functional tests every single day.
And that is a serious problem that we all face as automation engineers.