I lead a small but growing team of developers on an iOS application with a server backend. We have comprehensive unit and integration tests on both ends.

As the product grows, I want the onus of "quality assurance" to fall on all team members -- currently, there is a very "throw it over the wall" mentality after development is done.

The question that inevitably comes up is "But what do I test exactly?"

When testing new features, the answer is simple and well-understood: each story has acceptance requirements and for the most part, it's a matter of testing that those requirements are met.

However, as the product gets more complex and the team starts to contain more members who have less than intimate knowledge of the entire app, regressions (at the user acceptance level) become a big problem. How does the new employee know whether Joe's changes broke feature 2345 if he doesn't know how feature 2345 is intended to function?

My thought is that we probably require some sort of master documentation of how every aspect of the application functions, from a user perspective.

My questions are:

• is this a common solution to this sort of problem?
• what is this type of documentation typically called? (it isn't technical documentation per se, it's not code documentation, it not user documentation)
• are there good examples out there of how companies have structured & written such documentation?