What QA Tester Should Know About Release and Deployment Management Process

In our team meeting today, the manager checked with everyone on their readiness for test execution. He mentioned the “code will be ready for QA by tomorrow morning”. What did he mean when he said “code will be ready”, does it mean the developers are going to write the code in QA environment tonight?

He actually meant that the deployment is planned to be done at night and the new code will be deployed to the QA environment for testing.

Many of you may now ask, what deployment is and what do they really do in it?

What You Will Learn:

Overall Release and Deployment Management Process & Importance for the QA team:

(image blogzimbalam.co.uk)

I will cover following topics in this article –

  1. Why is it important for testers to be aware of release and deployment process?
  2. Different environments
  3. What do you mean by Build and Deployment?
  4. Planned vs. Emergency Deployment
  5. QA Checklist – Before and After Deployment

#1. Why is it important for testers to be aware of deployment process?

Our main job of test execution depends on how successful the deployment was. If the deployment team faced challenges and encountered several issues and couldn’t deploy the code properly, it will surely indicate QA team is going to identify lot of bugs which may be tied to environment or deployment process.

#2. Different Environments

In above classification I have covered the 4 most important environments which most organization follow, however, many clients maintain a lot more environments like staging, pre-staging etc. Also, the naming convention might differ.

Also read => How to Effectively Prepare “Test Bed” and Minimize the Test Environment Defects

#3. What do you mean by Build and Deployment

A build mainly contains the compiled package which could include the executable bat, exe, the libraries like dll, lib, and archives like zip files. Development Team creates the build and provide it to the deployment team for installation.

The compilation of the source code is mainly taken care by the development team and after they have generated the build, they place it at some specified location which is accessible by deployment team for deploying to a different environment.

Once the build is deployed, QA team is notified to do the build verification testing (BVT) and if it is successful, the team performs the rest of the functional testing.



In some organization where they do not maintain a separate deployment team, the development team provides the build to QA, and QA team themselves complete the deployment. There is a big risk involved, in such cases QA resources should be technically sound to understand the overall build deployment process and also should know how to remediate if an issue occurs.

Builds are maintained using numbers say 1.0.01 or 1.0.03. So, it is possible that build 1.0.01 may be running DLL v0.2 and build 1.0.03 may be running DLL v0.5. It becomes important for QA team to ensure that the correct build is deployed in the environment before the testing starts. It’s always a good idea to keep a track of changes provided as a part of each build.

Maintaining a separate deployment team is always a good practice as it helps for smooth movement of code from one environment to another.

Deployment is a process through which the code/build is moved from one environment to another. Most of the organization these days follows a proper channel for the deployment, and maintains a separate team who takes care of all these.

Prior to the day of deployment, a team comprising the developer, development manager, deployment engineer, test lead and other business stakeholders meet. In the meeting, the developer is usually asked to describe his/her change. They usually need to fill a particular form with details on the changes and rollback plan.

In case some details are missed, the changes do not get approved for deployment. The team then decides if the change can be part of the next day deployment. The QA Test Lead is asked for approval to ensure that change wouldn’t impact any of the existing tests. In the meeting, the final deployment items are planned.

The approved list is worked upon by deployment team on the day of deployment. The team runs a set of programs as defined in each of the changes form (provided by developers) and then sends out the communication as Deployment complete.

The Deployment Complete message provides an indication to the QA team, that the changes/new code is ready to be tested.

It is the responsibility of the deployment team to move the changes from DEV to QA. After the QA testing completes, the code is moved to UAT. PROD data move is the most important part and it has to be done during off hours, because during the deployment the environment needs to be brought down and it has to be done with utmost care since this could have severe impact on business.

Most of the Prod deployments are done late-night when the chances of the environment being hit by end users are less.

#4. Planned vs. Emergency Deployment

Every Organization maintains a deployment calendar. Many customers follow once-in-a-week deployment and many go for a bi-weekly, say the planned deployment should happen only on Tuesdays or it may happen on Tuesday and Friday. The days for deployment may change if the planned day for deployment falls on a holiday.

In the above section, I have covered the process that is followed for any planned deployment.

The planned deployments can have its own challenge. Think of a case, where new code is deployed to the QA environment and during sanity test the team identifies a blocker defect and testing has to be stopped. Does the testing team wait for a week until next deployment?

To handle such situations, emergency fix and deployments are done where the deployment team doesn’t need to wait until the planned deployment day. They do need to follow and seek approval even for emergency deployments but these approvals usually happen fast, and the new changes can be deployed to QA environment on the same day or as soon as possible.

#5. QA Checklist – Before and After Deployment

Before Deployment –

The entire test design phase takes place before the code is actually moved to the environment. It’s the test execution that depends on the code availability in the QA environment while the Deployment team works on getting the code deployed in QA, the QA team should ensure to have completed below activities –

After Deployment –

After deployment, the very first thing we as a QA team do is to get started with our Sanity test. But before we start our sanity test, we should ensure following has been taken care –

Conclusion

Hope the above article gave you an idea about the overall release and deployment management process followed as a part of the overall software development cycle. This was just a generic procedure followed in most of the organizations, however many customers have different protocols.

Author: This awesome article is written by STH team member Priya R.

Did you find this process helpful? Let us know about the deployment process that you follow in your organization.