Preparing Staging environment for UAT? – Part 2

<< Part 1

Staging Environment

4 Use host entries to verify behavior

Host entries are one of most effective tool that can be used to pre-check how your website will behave on domain. Whether all relative or absolute URL authored or dynamically generated will work and end up in HTTP 200/301/302 responses per needs. Also, there could be restricted have we don’t want to separately purchase domains for UAT environment or make it publicly accessible, so host entries is worth option to try for.

Check out https://technowide.net/2015/02/11/know-how-your-website-behave-on-domain-through-hosts-file/ for more details.

5 Use Stubs or black boxes to verify all third party integration

Integration with third-party apps are very common scenario these days especially in the era of social media and there is a possibility that we don’t want to expose UAT environment to social media. So, stubs play an important role here. Stubs are dummy sub-programs (modules) that help validating integration by just concerning on inputs and outputs. Outputs can be tweaked for both positive and negative test cases through inputs or by changing configuration of these modules and see how our application behaves for them.

6 Focus on Functional & Integration testing

Scope of testing is very important to remain concentrated on the work and be efficient. As a developer or QA person on an application, focus on staging environment should be strictly on Functional & Integration testing. This is not the environment to spend time on proof-of-concept or creative testing as such activities can be performed and related issues should be addressed on lower environment or development machines. At the same time, any functional/integration issue surfaced at this stage cannot be ignored as it may add a potential risk to the delivery. A proper root cause analysis or justification for anomaly is required.

7 Document all configuration settings explicitly

Most of the time, we get a response that it’s working fine on developer’s machine but not on Staging or Production. But we are not delivering developers machine to client 🙂

Configuration setting is most likely the answer to these type of questions. Developers normally do configurations on their machines which at times go undocumented. As a practice, each and every change in configuration setting required to make application work should be listed and added as part of delivery document so that it could be tested on Staging and only valid filtered configurations move to Production.

8 Follow proper process of Configuration management

Change control and code configuration management is most important part of Project life cycle especially when most of projects these days follows Agile Methodology and parallel teams are working on Production issues, UAT phase and upcoming development in same time span. So, avoiding messing up builds that should target only particular environment is utmost required.

Check https://technowide.net/2012/08/03/code-configuration-strategy-basics/ for more details.