If an online shop changed the login process, or changed a link on the homepage to a button, your clever human brain could still work out how to login or click the button.
Your test automation suite is not quite as clever as that. If the link changed to a button, or the wording of the link changed, the test will likely not find the button and fail.
Automation tests can be pretty inflexible and when things change they just can't cope, so we need to keep that in mind when writing our tests. We have to accept that they'll need to be regularly maintained, and design our test suite to be easy to do so.
How do we do this?
In manual test cases, you have an ultimate goal, and a set steps to follow to get there. Each step will have an action to complete, and an expected result for that action. The test will pass or fail dependent on the result of all of the steps. In test automation you'll have exactly the same concept, but the actions are called methods. You write and store methods separately to the tests and expected results so you can reuse and maintain them.
In order to do this, we create "Page Objects" to store our methods (actions) on a per page basis, and then our Tests will link to these methods and we can wrap them in assertions to see if they work or not.
For each page on your website you'll create a page object class. It will contain any test methods (actions) that you might do on that page such as identify a form field, enter data, click links and look at the page title.
Comparing this back to a manual test, these are the actions part of the test step, not the expected results. For these page objects, we don't care about pass or fail, it doesn't matter if the link works or not, that's taken care of in the test. Methods are actions such as "Click on login link" or "Enter login information and submit". We can even have a method for "check for a message at the top of the page" which isn't a test, we've not said if there should be or not, we're just looking to see if it is there.
This keeps all of the coded automation actions in one easy to find place and makes them very easily reusable, which improves maintainability, reliability and visibility.
This is where we actually create and define our tests and expected results. From within a test, we can "call" the methods on our page objects. This makes writing tests very fast, and you can reuse every method/action you have written as often as you like.
A manual test might look like this
Then the automated test would look like this
And when executing the test, it would call out to the Page Objects and execute the methods on those pages.
How does this make the Test Automation Suite maintainable?
At the start of this post, we talked about changing a link on the homepage from a link to a button.
In a manual test, we'd have to know where all of the steps are that need to be changed and we'd need to go to every test case, and update every test step that says to click on the link.
In our automation test suite, we know the link is on the home page. We go to our home page object, find the method that says to click the link, and update it to click a button. Voila. One easy to find action is changed and the entire suite is up to date.