A server that is as similar as possible to the production server. It is used to install the project every day, for example possibly the
DailyBuild is installed in it. If
ContinuousIntegration is used, then the last good build from the previous day is automatically installed in it.
All developers and probably even the customer do
ManualTests in the
StagingServer. This is useful for having
RapidFeedback on testing how the project is doing and resolving misunderstandings about how the project is doing.
All defects, when detected through
ManualTests, are entered into the
TaskDatabase. When defects are detected through
AutomatedTests, they are
not entered in the
TaskDatabase.
This description sounds more like a
PreProductionServer or
UserAcceptanceTestingServer than a
StagingServer. In my experience, a
StagingServer (or more accurately a staging
environment that can involve many machines) is one to which a system is deployed, smoke tested and then automatically pushed to production. This "push" can be done by switching the staging and production environments in some atomic way so that the staging environment becomes production and the production environment becomes the staging environment for the next release. Or, the system components can be copied from the staging environment into the production environment. And there are many other techniques depending on how the system is clustered or organised for failover.