Software Testing in the Staging Phase of Deployment

Staging is the last phase in the deployment process before delivering to Production. While most of the detailed, time-consuming testing that assured that all the sections of the application worked to specification was performed in the previous stage, Integration Testing, there is still more to be achieved. Staging is the final dress practice before the release to Production.

Creating the Staging Environment

A significant factor in Staging testing is that the computing environment in which testing is to take place must meet the Production environment as is fairly possible. This indicates that machine configurations between Staging and Production must meet up. In addition, server software, database, and storage resources must balance as well. If you’re testing in a hosted environment, preparing the staging environment up usually includes no more than creating some temporary virtual machines or container deployments. Organizations that have their computing resources on-premise and operate directly with hardware will have a more difficult time building the Staging environment. Getting Staging hardware match its Production counterpart can be time-consuming and expensive. The likewise is true of software configuration. The cost of using premises, bare-metal devices can be motivation enough to move to a virtualized environment. Holding up VMs, containers, and device emulators is a whole lot simpler and cheaper than having to obtain and provision boxes, tablets, and cell phones.  This is one of the purposes Amazon released AWS Device Farm.  

Organizations that are operating in the cloud using a service provider such as AWS, Azure, or Google Cloud have an simpler time creating the staging environment. Typically the effort is no more than completing scripts that produce the essential computing environments, do environment orchestration and then insert the initial data and files into the appropriate data and file storage services. This kind of ephemeral provisioning presents a reliable approach to building apples-to-apples environments when conducting tests in Staging. Also, ephemeral provisioning is cost-effective in that the value of the testing environment is incurred only when the test is being managed. The best method is that once staging tests are run, the environments are stopped until the next testing session. Once a test environment is stopped, organizations are not paying for very expensive test environments that are not being utilized.

Testing in the Staging Environment

Once the staging environment is established, the next step is to run the tests. As mentioned above, the heavy lifting was performed in Integration Testing. The range of tests in Staging is to assure the application below test meets business requirements and expectations. Thus, the usual tests conducted are smoke tests and user acceptance testing (UAT).

Smoke Testing

A smoke test, also known as a sanity test, is a fast test that is performed by a script or human that assures that the application under test works to minimum expectation. For example, a human-run smoke test includes logging into the app and doing some usual activities such as carrying out a search or exercise a standard feature. This is down and dirty testing. The goal is to ensure that the usual and obvious features work as expected. The assumption is that if the main features work, so should the more difficult ones in the application’s feature stack. Of course, this all is based on the presumption that rigorous, time-consuming testing was taken back in Integration.

User Acceptance Testing

User Acceptance Testing (UAT) is concentrated on the business. The software does not arise by magic. There is a buying party, either internal to the organization or an external consumer. Their requirements must be satisfied. UAT is the point where the business confirms that the application meets expectations. Typically a tester in UAT is a business user or product manager. In addition to strengthening the basic functionality works as expected, the tester will verify that the application’s presentation satisfies branding, locale, and style standards. For example, this implies ensuring the proper fonts are used, that the graphics meet company criteria, and that the overall usability of the product is satisfactory.

Again, Staging is the last test session before the production release. Thus, ensuring that the business is satisfied with the code that is about to be delivered for public consumption is a paramount matter.

The Value of the A/B Approach to Production Release

In the old days of waterfall testing, all the characteristics of an application were delivered at once and the test method was hierarchical– code to test to deployment. If the test failed, it left all the back in the release chain. Today we practice a different strategy. We are in a continuous release cycle, in which we ship one small characteristic at a time and test in an iterative way.

The idea of continuous, pre-production testing has lost over into the Production release. Whereas in the past the release of a current version of code replaced all the previous code, today we often deliver a new version to a small portion of the user base and then, if all goes well, increase that user base until the new version has 100% release penetration. For instance, for every 100 requests to a website, 10 of those users will be guided to the new version of code, while the remaining 90 are direct to the old version. This method is called A/B testing.

A/B testing is helpful in a variety of ways. First, the only valid test environment of software is the real world. All the testing that appears before release is based on opinion. While pre-release testing will discuss most issues, it won’t discuss every operational issue, particularly when it arrives to code that is subject to the whimsy of human interaction. Thus, releasing code to a subset of all users presents the random interaction needed for real-world testing without opening up the whole user base to a potentially bad experience.

The second benefit is one of comparative analysis. Remember, in an A/B test condition, both versions of code are completely operational. Usage Data is being collected. Once data is gathered, analysts can estimate and analyze the usage results. A/B testing might show that users are spending less time involved with the new code as opposed to the earlier version. Or, overall performance might be slower. Once these facts appear to light, it’s comparatively simple to revert all web traffic to the older version until the issues of the newer version can be discussed.

Putting It All Together

Staging is a significant part of the deployment testing method. It’s the place where technology and business come together. Although the operational testing method is nowhere near as wide as that of Integration Testing, the insights collected from the tests conducted by business-oriented testers present important information about the overall viability of the software to be delivered. Most software is designed to meet a real need and those requirements are usually best known by the folks operating the business. Their acceptance counts. However, there is one group whose acceptance adds even more. Those are the expected users of the code. Incorporating A/B as a section of the release cycle presents the additional insights needed to making code that counts. Producing code that counts is what it’s all about. 

Need some guidance in software testing? Choose to team up with a QA services provider like TestUnity. Our team of testing experts specializes in QA and has years of experience implementing tests with different testing software. Partner with our QA engineers who can help your team in adopting the best suitable testing practices. Get in touch with a TestUnity expert today.

TestUnity

Testunity is a SaaS-based technology platform driven by a vast community of testers & QAs spread around the world, powered by technology & testing experts to create the dedicated testing hub. Which is capable of providing almost all kind of testing services for almost all the platforms exists in software word.