Deploying to Staging
A staging environment is the deployment target where the release candidate resides. It is considered the “ready-to-go” code that needs to go through any final validation processes, like user acceptance testing. User acceptance testing is where a user, such as a business owner for a process, validates that the service is working correctly. There can be a number of additional differences to test related to the environment configuration as well, such as the target databases and services that the application is connected to. Whereas in the development and QA environments the database and service hooks point to independent test endpoints, a staging environment can point to your production database.
Manual/Exploratory Testing
This is one of the most primitive test types, but at the same time it can produce first-hand results on what the end user will go through, and is useful for your development team to quickly validate or reproduce reported bugs. In the case of microservices, manual testing might involve trying to see whether a specific REST call can cause unhandled exceptions and impact the overall system on a larger scale. However, in DevOps manual testing is rarely used, if at all—it is inefficient in a dynamic environment and prone to missed cases. What can be done manually can often be easily automated.
Manual Testing as a Service
If your organization wants or even requires manual testing—for example, a financial services company that requires a security or compliance audit before a release—one option is to use a manual testing service to do this in as close to an automated way as possible. Rainforest QA (http://bit.ly/rainforestqa) provides “human testing at the speed of automation.” When you promote your app, from QA to staging for example, or from staging to production, RainforestQA can listen to a webhook in your CI system and start a manual test run performed by real live people.