The goals of automated testing
Testing is more than creating a safety net. Let’s talk about its multiple facets.
In an agile mindset, the team is responsible for the delivered software. In this scenario, QA is ensured by the whole team. Automation is a core tenet of DevOps culture, meaning developers should write automated tests. Manually testing everything does not scale up and is incompatible with continuous delivery. QA-specialized people should be doing other types of work like exploratory testing, usability testing, acceptance testing, etc.
Automating everything — from build to tests, deployment and infrastructure — is your only way forward. The Practical Test Pyramid
According to the xUnit Test Patterns book, there are multiple goals of test automation:
Tests as specification
Tests are like the floor plan of a house (although in software development, we can iterate); they define the system’s behavior, or in other words, what is expected: as soon as tests go green, they lock the implementation to that contract (design by contract). That’s how precious and precise a test is, given that it enforces a specific implementation (the how) to faithfully respect that spec (the what).
I know this sounds ridiculous; but consider. If somehow all your production code got deleted, but you had a backup of your tests, then you’d be able to recreate the production system with a little work. Test First
Tests are a self-verifying executable specification since you can run them, and they will automatically report the outcome. In RSpec and BDD, tests are called specs for that reason. Each test should execute only one action on the test subject. Also, that action may have multiple side effects, but each test should assert only one.