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?

That is not necessary in most cases. Usually it is sufficient to check if Joe's changes did not change the previous behaviour of feature 2345, not if it works as its described in some documentation. So if in doubt, one needs to look at the previous version of the program, assume that this version worked as intended and check if the change to the code kept the old behaviour. Even if the former version contained already a defect here, not changing the behaviour avoids to make things worse.

Of course, ideally one should try to automate this kind of regression testing.

And yes, it is also good to bring the documentation to the test process and compare it with the actual behaviour of the application. But if those two deviate, a "new employee" probably still not know where the failure is - it might be the program, or it might be the documentation. Documentation is often not part of the solution, it can be part of the problem.

Then you asked for the name of

some sort of master documentation of how every aspect of the application functions, from a user perspective.

This is definitely called "user documentation". In your comment, you mentioned some documentation which could "outline finer points than any end-user would necessarily need to know to use our software" - but what should that be?

• Either some detail is obvious from the GUI, then it does not have to be described in the user documentation, and it should be also clear for the developers trying to change something in that area

• Or it is not obvious, but still relevant for the user, then it definitely belongs into the user documentation, since it will be needed to use your software correctly

• Or it is not relevant for the user: then it is an implementation detail, and should be documented in the code.

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?

That is not necessary in most cases. Usually it is sufficient to check if Joe's changes did not change the previous behaviour of feature 2345, not if it works as its described in some documentation. So if in doubt, one needs to look at the previous version of the program, assume that this version worked as intended and check if the change to the code kept the old behaviour. Even if the former version contained already a defect here, not changing the behaviour avoids to make things worse.

Of course, ideally one should try to automate this kind of regression testing.

And yes, it is also good to bring the documentation to the test process and compare it with the actual behaviour of the application. But if those two deviate, a "new employee" probably still not know where the failure is - it might be the program, or it might be the documentation. Documentation is often not part of the solution, it can be part of the problem.

Then you asked for the name of

some sort of master documentation of how every aspect of the application functions, from a user perspective.

This is definitely called "user documentation". In your comment, you mentioned some extra documentation which could "outline finer points than any end-user would necessarily need to know to use our software" - but what should that be?

• Either some detail is obvious from the GUI, then it does not have to be described in the user documentation, and it should be also clear for the developers trying to change something in that area

• Or it is not obvious, but still relevant for the user, then it definitely belongs into the user documentation, since it will be needed to use your software correctly

• Or it is not relevant for the user: then it is an implementation detail, and should be documented in the code or your usual technical documents

Note there is actually no "simple" solution for keeping complex applications manageable. One has to work on several layers for this, like

• training of your devs (especially new developers) so they get a better understanding of how certain features in an application should work from a users perspective

• finding the right amount of documentation - "the more docs - the better" is a fallacy; since docs have also to be maintained

• same holds for "automated regression testing" and "manual regression testing"

• when the app reaches a certain size, modularization can also help - so not every team member may have to know the whole code base in every gory detail, but you have specialists for certain areas (but beware, don't lose sight for the "big picture").

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?

That is not necessary in most cases. Usually it is sufficient to check if Joe's changes did not change the previous behaviour of feature 2345, not if it works as its described in some documentation. So if in doubt, one needs to look at the previous version of the program, assume that this version worked as intended and check if the change to the code kept the old behaviour. Even if the former version contained already a defect here, not changing the behaviour avoids to make things worse.

Of course, ideally one should try to automate this kind of regression testing.

And yes, it is also good to bring the documentation to the test process and compare it with the actual behaviour of the application. But if those two deviate, a "new employee" probably still not know where the failure is - it might be the program, or it might be the documentation. Documentation is often not part of the solution, it can be part of the problem.

Then you asked for the name of

some sort of master documentation of how every aspect of the application functions, from a user perspective.

This is definitely called "user documentation", I have no idea why you think it is not.

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?

That is not necessary in most cases. Usually it is sufficient to check if Joe's changes did not change the previous behaviour of feature 2345, not if it works as its described in some documentation. So if in doubt, one needs to look at the previous version of the program, assume that this version worked as intended and check if the change to the code kept the old behaviour. Even if the former version contained already a defect here, not changing the behaviour avoids to make things worse.

Of course, ideally one should try to automate this kind of regression testing.

And yes, it is also good to bring the documentation to the test process and compare it with the actual behaviour of the application. But if those two deviate, a "new employee" probably still not know where the failure is - it might be the program, or it might be the documentation. Documentation is often not part of the solution, it can be part of the problem.

Then you asked for the name of

some sort of master documentation of how every aspect of the application functions, from a user perspective.

This is definitely called "user documentation". In your comment, you mentioned some documentation which could "outline finer points than any end-user would necessarily need to know to use our software" - but what should that be?

• Either some detail is obvious from the GUI, then it does not have to be described in the user documentation, and it should be also clear for the developers trying to change something in that area

• Or it is not obvious, but still relevant for the user, then it definitely belongs into the user documentation, since it will be needed to use your software correctly

• Or it is not relevant for the user: then it is an implementation detail, and should be documented in the code.