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 the introduction and question of the page objects in test automation course. In this video, we are going through on how can we handle automation in an evolving world for the course.
How can we handle automation in an evolving world?
Why is functional test automation so flaky?
What is it about it that makes automated software testing so hard?
Well, I believe it all comes down to the evolution of the web.
Over her what I have done is capture an image from evolutionoftheweb.com that represents all the different technologies of the web, overtime.
On the left-hand side it starts at about 1990’s all the way to the right-hand side, where you can see it’s about 2012-2013.
If you carefully look at this image, you can see that there is a different proliferation of different kinds of technologies, but not only a proliferation, but also an increase integration in to the different technologies.
But not only a proliferation, but also an increased integration between the different technologies.
That’s why you see less colours on the left and as we merge, more to the right.
There is a more of a mess of all of these colours.
So, the reason for the evolution of the web is because of the end user experience.
Everybody how is designing web applications nowadays, wants the end user to have an amazing
user experience, so all the technologies come along that helped the end user to have an amazing user experience.
Technologies such as SVG and Canvas started to come along.
We started developing things such as Drag&Drop and Touch Events.
Think about it, in the 90s there were no tablets, there were no smart phones, there were no touch
screen, and ow there are touch events, and drag&drop events to be able to handle different kinds of functionalities.
We created things such as AJAX, so we can asynchronously be loading different parts of an application, while one part of the page has already been loaded.
Even Angular JS that allows us to execute a bunch of JAVA script files to be able to more seamlessly run the application so that one part of the page can do one thing, and another part of the page can do another thing, and one event can trigger another event, and so on, and so forth.
This is all phenomenal, all amazing progress for the web, but it sucks for us as automation engineers because we are the ones that have to automate against this constant evolution of technologies.
So, that’s why it is extremely hard and functional tests are deemed as flaky because we have to be challenged with all of these different technologies.
How can you handle such an evolving world?
When everything with the web is changing so fast with so many technologies?
How can we keep up and be able to do good functional tests automation?
Well, I’m my personal opinion, I believe that it all comes down to a mind-set change.
And you need to understand, the only thing constant in software development is change.
If you can understand this concept, and believe that changes inevitably coming, then from this point forward, any time you make any kind of update to your functional test, you will need to keep in mind that your functional test is going to experience change, and so you need to able to insulate against the change that is inevitably coming .
And I wish I could remember where I got this quote, I probably read it in a book written by someone extremely smart individual and it stuck with me ever since because I understood that yes this is true and once I got that point, from that point forward I began to take actions to insulate my automated functional test from any kind of changes that are going to occurring in my application of the test.
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 UltimateQA.com and contributes informative articles to leading test automaton websites like SimpleProgrammer.com and TechBeacon.com