SharePoint can be configured a number of ways, though I have to admit that this is the first time I've seen Authoring before Testing. Typically, when a dedicated Authoring site is in the mix, it is there for one of 2 reasons: 1) it has different authentication requirements (i.e. Authoring is NTLM but the production site is Forms-Base/Anonymous) or 2) there are security concerns or firewalls in place that only allow content to be moved via SharePoint Content Migration jobs instead of direct DB Access.
Your assumption is correct that Authoring is where content changes are supposed to be made and that nobody should ever change production directly. I would honestly verify that the farm really works the way you think it does. Here are some things to find out:
- What is the authentication method on Authoring?
- What is the authentication method on Production?
- How is content moved from Authoring to Testing to Production? (you
are looking for specifics here, i.e. Timer jobs, manual push, custom
- What databaseserver/instances and content databases are used by Authoring, Testing and
- How isolated is the production farm (i.e. is this an Intranet or is
Production an internet-facing site?)
The answers to those questions should go a long way to understanding what is really going on.
It is also worth mentioning that elevating code changes follows a different path than content changes. That is, code is supposed to follow the normal dev-qa-auth/prod path but content moves from authoring-prod and optionally authoring-qa-dev, depending on the business needs and infrastructure.