Question

Even with proper testing in lower tiers (unit testing, static analysis, hallway usability testing, etc.) we have to conduct some minimal tests again in PROD once the releases are deployed.

Assuming that we want to block the users during the testing phase. Why? So they won't face any inconsistencies in case some anomaly manifests itself in PROD. e.g., conflicts caused by some automated testing routine, corrupt data, etc.

I've seen applications that are:

  1. Blocked through network rules, i.e., only the IP addresses of the QA users are allowed to access the app.
  2. Blocked by a proxy/SSO server based on their credentials.

I've implemented option #2 as I have more control over the process (since I'm avoiding unnecessary iterations with the Network team), what would be your method of choice? OR do you have an alternative to PROD tests?

Was it helpful?

Solution

Prod testing is important.

Stopping random users from accessing the system while you are conducting prod tests does matter.

Beyond that, so long as you have means that are reasonably simple/straightforwards/reliable and don't introduce new bugs/issues of their own, then there is no need to overthink things.

OTHER TIPS

In a perfect world you have a failover environment... While deploying and testing the upgraded system, production can run on the failover, once you are happy you cut over to the upgraded system.

This comes with the risk that if failover itself fails and you are unhappy with testing you have nowhere to go

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top