What QA Tester Should Know About Release and Deployment Management Process

At our team gathering today, the manager updated inquiring everyone’s preparedness for test execution. He stated that the “code will be prepared for QA by the crack of dawn tomorrow”. I’m curious about what he implied by “code will be prepared”, was he suggesting that developers will implement the code into the QA environment tonight?

The manager was referring to the deployment which is anticipated to occur overnight, with the new code being deployed to the QA environment for subsequent testing.

You might be questioning, what does deployment mean, and what actually unravel during this process?

Review of the Release and Deployment Management Process & Its Significance for the QA team

• What is the reason for maintaining various environments?
• How is code moved from one environment to another?

In this write-up, I will delve into the following topics:

1. Necessity for testers to comprehend the release and deployment process
2. Different settings or environments
3. Explanation of Build and Deployment
4. Scheduled vs. Emergency Deployment
5. QA Checklist – Before and After Deployment

#1. Testers Need to Understand the Deployment Process

Our test execution success is reliant on a flawless deployment. If the deployment squad faces obstacles or encounters errors that bag the successful deployment of the code, it’s highly probable that the QA team will stumble upon many glitches which might be related to the environment or the deployment method.

• Being conscious of the deployment operation allows testers to appreciate the value of completing their tasks in line with the scheduled timescale.
• Testers will be able to identify if a problem is a functionality bug or a deployment process result. As an instance, if an appointed tester for a report feature faces an error when trying to access the website, it indicates an issue with the environment, not a functional bug. Testers familiar with the deployment process can pinpoint it as a deployment issue.
• Having knowledge of the list of deployed changes can assist testers in avoiding reporting false issues. Occasionally, testers might report issues in areas where no deployment occurred.

#2. Various Environments

In the preceding categorization, I have highlighted the four critical environments followed by most companies. Nonetheless, numerous clients establish additional environments like staging, pre-staging, etc. The nomenclature may differ.

• DEV – This is the development atmosphere curated and maintained by the Development team to write the code. This environment is exclusive to just the development team. Generally, the QA team is not given access to this environment. The major use of this environment by the development team is for unit testing.

• QA – The QA environment is the actual testing field. Owned by the QA team, and the development team typically does not gain access. Upon completion of design and coding, the code is transferred to this environment for the QA team’s test execution.

• UAT – User Acceptance Testing (UAT) environment is utilized for testing by business users. This environment is operational post the system testing completion. The primary objective is to test the system from business user’s view. Access to this environment is limited to only business users, although the QA team might be involved in some cases where their assistance is required.

• PROD – This is the live production environment exposed to actual users. The development and QA teams are typically denied read/write access to this environment. The responsibility of resolving production environment issues lies with production support teams.

Recommended reading: Effective Ways to Set up a “Test Bed” and Reduce Test Environment Defects

#3. Understanding Build and Deployment

A build usually includes the compiled package, which could be executable files such as bat or exe, libraries such as dll or lib, and archives such as zip files. The Development team assembles the build and hands it over to the deployment team for installation.

The Development team handles the source code compilation. After creating the build, they position it at an accessible location for the deployment team to deploy across various environments.

When the build is deployed, a notification is sent to the QA team to conduct the Build Verification Testing (BVT). If the BVT is successfully passed, the team then proceeds with the rest of the functional testing.

In organizations with no separate deployment team, the build is given directly to the QA team by the Development team, and the QA team undertakes the deployment. This methodology carries a higher risk, and QA resources need to be technically competent of the overall build deployment process, capable of dealing with issues when they emerge.

Builds are normally recognized by version numbers (e.g., 1.0.01 or 1.0.03). As such, it’s crucial for the QA team to ensure the correct build’s deployment in the environment before initiating testing. Keeping a record of the changes included in each build is a recommended practice.

Having a dedicated deployment team is advantageous as it aids the seamless transition of code amongst environments.

Deployment is the operation of moving code/build from one environment to another. In the present times, most organizations follow an official channel for deployment and own a dedicated team to manage these tasks.

Before deployment day, a meeting involving the developer, development manager, deployment engineer, test lead, and other stakeholders is conducted. In this meeting, the developer explains the changes made and commonly fills out a form detailing the changes and a rollback plan.

If any details are omitted, the changes are not approved for deployment. The team then concludes if the change can be incorporated in the following deployment. The QA Test Lead provides approval, ensuring that the change will not interfere with the existing tests. In this meeting, the final deployment items are planned.

The deployment team works on the approved list on the deployment day. The team operates a set of programs defined in each change form (provided by developers) and sends out a “Deployment Complete” notification.

The “Deployment Complete” notification informs the QA team that the changes/new code are all set for testing.

The deployment team is burdened with the responsibility of moving changes from the development environment to the QA environment. Post completion of QA testing, the code is then moved to the UAT environment. The code movement to the production environment is critical and has to be done outside office hours, as deployment can cause environment downtime which can drastically affect the business.

Typically, production deployments are performed late at night when user activity is minimal.

#4. Scheduled vs. Unpredicted Deployment

All organizations maintain a deployment calendar. Some clients opt for weekly deployments, while others might prefer bi-weekly deployments (e.g., on Tuesdays or both Tuesdays and Fridays). The deployment days could be adjusted in case they fall on holidays.

In the above section, I covered the process followed for planned deployments.

Planned deployments can also have complications. For instance, think of a scenario where new code is deployed to the QA environment but during the sanity test, a critical defect is identified, necessitating the halting of testing. Should the testing team wait for the subsequent scheduled deployment?

To take care of such scenarios, emergency fixes and deployments are undertaken. For emergency deployments, the deployment team does not have to wait for the scheduled deployment day; nevertheless, approval is still required. These approvals are typically obtained swiftly, and the new changes can be deployed to the QA environment either on the same day or as soon as feasible.

#5. QA Checklist – Pre and Post Deployment

Before Deployment:

Test design activities are conducted prior to moving the code to the environment. The availability of code in the QA environment affects test execution. While the deployment team works on deploying the code into the QA environment, the QA team should ensure that the following activities have been completed:

• Test cases have been reviewed and approved
• Test team’s availability and resource planning
• Identifying the requirements for test data

After Deployment:

Once the deployment is complete, the initial task for the QA team is to undertake sanity testing. However, before commencing sanity testing, the following should be ensured:

• The QA team should receive notification from the deployment team indicating the successful deployment and readiness for QA.
• The deployed build should be tracked by the QA team.
• The QA team should ensure they get a list of the successfully deployed changes along with any planned items that were not deployed. At times, the deployment team may fail to deploy certain changes due to lack of details, etc.

Conclusion

I hope this write-up helps you understand the overall release and deployment management process utilized within software development cycles. The process detailed here is a general procedure followed across most organizations, but it’s crucial to understand that various companies might have their unique protocols.

Author: This article was crafted by one of the STH team participants, Priya R.

Did you find this process useful? We would love to learn about the deployment process followed at your organization.