Test Automation Principles

The following Test Automation principles have been designed to be in line with industry best practices.

Principle	Description
Tests should be expressive	It should be transparent what is being tested by an automated test. Let's leave the guesswork out of this and make the tests expressive and transparent. This helps other Technical Testers, Functional Tests, Developers and stakeholders.
Tests should be independent	Tests should not depend on other tests for the state. Tightly coupled tests erode the value of building and running the tests as a continuous regression safety net due to intermittency issues caused by tests having to run in a certain sequence. Ideally, a test should also be responsible for its own (test) data. Meaning it prepares the test data required and cleans it up again.
Tests should be fast	Only when automated tests run fast, we can run them at any stage and as often as necessary or required. The aim here is to allow for fast feedback. Having to wait hours for automated tests to complete, defeats the purpose. This also means keeping long running e2e tests to a minimum.
Tests should be repeatable	With no changes to a system under test, automated tests should produce the same results consistently. Tests that are not repeatable, or unstable, do not provide a lot of confidence.
Tests should be maintainable	Software products change and so will automated tests. Only a test that is easy to read and understand is easy to maintain. Simplicity is key. See KISS Principle
Tests should be easy to run	If tests are hard to run, we discourage others to utilise them. Goal is to have tests that can be run anywhere at any time. Tests that are easy to run will allow for simpler pipelines as well.
Keep the lights on	Keep the tests maintained and efficient. This also applies to the framework itself by reducing tech debt and keeping it and its dependencies up to date. Having healthy pipelines is part of this as well. Pipelines that look like a Christmas tree (red / green) don't build confidence.
Don't repeat yourself	This principle can be applied to two areas - code and tests. Don't duplicate code to keep it easier to read and maintain, and don't duplicate test coverage. Something that has been verified by one test, doesn't need to be tested again.
No shortcuts	Manual testing is no shortcut if automated tests are broken or don't work. Invest the time to keep the test maintained and healthy. Also, don't run the tests locally if there are (and there should be) pipelines for those tests. If the pipelines take too long to complete, look at optimising them.