SQL Server Team-based Development - Red Gate Software

Chapter 3: Change Management and Source Control
Security in a QA system should be more stringent than in most development systems.
In order to ensure that the tests are valid, changes can't be introduced. This means that
developers and QA operators should not have the ability to manipulate objects. You may,
however, want to allow them to manipulate data.
Performance testing
The performance testing environment is sometimes combined with QA, but this is
generally inadvisable. Separating performance testing from the more general business
testing of QA allows for more flexibility in both testing processes.
The idea of a performance test is not to carefully simulate a production load, although
that is a part of the process. Instead, you want to measure performance under an everincreasing
load, as measured in transactions per second, user connections, data volume,
and other metrics. You want to see, not only how the application behaves under load,
but also where and how it breaks. This can be a time-consuming process when done
properly, which is one of the main reasons why it needs to be separated from the standard
QA process. In order to provide a reliable set of test results, deployments should be from
a version or label within source control, as described in more detail later, in the Source
Control section of this chapter.
Security on the performance testing server can be somewhat flexible, but again, once
testing starts, you don't want changes introduced. It's probably better to treat it like a QA
system and not allow data definition language (DDL) operations against the databases on
the server.
User Acceptance Testing
User Acceptance Testing (UAT) is a lot like QA testing but, whereas QA is focused on
careful verification of the quality of code, UAT involves business operators and end-users
manually testing the system to ensure it performs in ways they anticipated.
68