Issues Related to Testing on a Production Server with SQL:
| No | Description / Explanation |
|---|---|
| 1) | Switching between Connection Strings |
| Many database applications rely on hard-coded connection strings to access the database. To test and run a database application in the same environment in this scenario, multiple copies of the database must be made with respective connection strings. These connection strings can become confused. | |
| 2) | Switching Between Ports in IIS (if Microsoft) |
| The different versions must exist in different folders, which are accordingly pointed to different IIS (or Apache if not Microsoft) entries. These settings can become reversed. “http://localhost:85” may lead to the test version now, but a change an IIS can point that same entry to the production. | |
| 3) | Easiness to Enter Wrong URL (end user error) |
| If on the same network, it is still possible to enter the wrong url (http://server1 vs http://server2) if one does not use localhost. It already has been noted that ports can be changed, but even without changing them, end user mistakes are easy. It is a larger error to mistype a url than a port. Additionally, security settings can knock undesired users out of the wrong server to prevent mishaps, which totally prevent the user from even being able to access the environment. | |
| 4) | Queries with Hard Coded Database Names |
| Even with connection strings that are external, it is still possible to write queries (in SQL Server for instance) which have the actual database written inline, within the query. The connection string may be set correctly, however the query will still use whatever database it is written to use. The scenario of hitting the wrong server due to inline code is much less likely than the wrong database. | |
| 5) | Stored Procedures which Cross Databases |
| Some applications utilize more than one database, which store compiled stored procedures. The stored procedures may have code that crisscrosses back between the two databases. With two instances of an application running (both with their respective databases), this potentially is a recipe for disaster. | |
| 6) | Restore Point Mechanisms |
| Often different versions are switched between productions and live due to the specific needs at the time. A restore point mechanism, whether Windows System restore or another, could reset settings related to the application. Windows System restore does not interfere with data (only settings), but other restore point mechanisms may. With live data on the server, the risks are greater. Due to historical circumstances that changed, the test can become the production and the production the test. | |
| 7) | Load/Performance |
| Without having a separate environment for the test system, slowed performance on production while running tests will always be a potential issue. To truly alleviate this problem, however, it may be necessary to have separate physical servers, not virtualized servers. | |
| 8) | Being Present when Unrelated Problem Occurs |
| On a production environment, the potential exists for a problem to arise that has nothing to do with the changes being made by a particular user. However, the mere presence of the user is enough to bring initial suspicion, an avoidable scenario if the user is not there. |