tests is make sure that they are good documentation. This means: make sure that you describe how all the parts of the application you are testing work (or, to put it another way, have a high level of test coverage). The hardest part though is making the tests understandable for people who are not technical. This is where domain-speci c languages (DSLs) come in where you can hide the inner workings of the tests behind human-readable language. Good tests are like good documentation; if they are really good they will use plain English and describe things so well that the person reading them will not need to go anywhere else to ask for help.
So why is it living documentation, rather than just normal documentation? Well, it's living because every time the application you are testing changes, the automated tests change as well. They evolve with the product and continue to explain how it works in its current state. If our build is successful, our documentation describes how the system currently works.
Do not think of automated tests as regression tests that are there to detect changes in behavior. Think of them as living documentation that describes how the product works. If somebody comes and asks you how something works, you should ideally be able to open a test that can answer their question. If you can't, you probably have some missing documentation.
So where does regression testing come into this? Well it doesn't. We don't need a regression-testing phase. Our test documentation tells us how the product works. When the functionality of our product changes, the tests are updated to tell us how the new functionality works. Our existing documentation for the old functionality doesn't change unless the functionality changes.
Our test documentation covers regression and new functionality.