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?

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

• Why do we really maintain different environments?
• How does the code is migrated from one environment to another?

I will cover the following topics in this article

1. Why is it important for testers to be aware of the 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 the 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 the QA team is going to identify a lot of bugs that may be tied to the environment or deployment process.

• If Testers are aware of the deployment process, they will understand the importance of completing their tasks within the planned time-frame.
• Testers will get an idea if the issue is really a functionality bug or something caused during deployment say a tester is assigned to test the report feature but when he tries to log in to the website, he is seeing an error which means the environment is down, such issues cannot be considered as functional issues but as environmental. If the tester is aware of the deployment, he can relate the issue to be a deployment issue.
• Many non-issues could be avoided if the testers really are aware of the list that got deployed. Sometimes it does happen you test and reports an issue for areas that never were deployed.

#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.

• DEV – Dev environment is the one created and maintained by Development team for writing the code. The access for this environment is given to the development team only. Usually the QA team doesn’t have access to this environment. This environment is mostly used by Dev team for their unit testing.

• QA – QA environment is the one where the testing actually takes place. This environment is owned by the QA team. The DEV team doesn’t have access to this environment. After design and coding completion, the code is moved to QA environment for QA team to conduct test execution.

• UAT – User acceptance Test is an environment where the testing is conducted by the business users. This is done after the system testing has been completed. The major intention is to test the system from the business point of view. Access to this environment is given only to the business users. However, on some occasions they do seek QA assistance, in such circumstances, QA team is given temporary access to the environment.

• PROD – The PROD environment is the actual live environment which is exposed to the real users and none of the DEV and QA teams have read/write access to this environment. Prod support teams are maintained to solve issues related to the production environment.

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 –

• Ensure the test cases are reviewed and approved
• Ensure the test team is available and resource planning is completed
• Ensure the test data needs are identified

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 –

• The QA team should have received notification from the deployment team about successful deployment and ready for QA.
• The QA team should keep a track of the deployed build.
• Make sure the QA team has the list of changes successfully deployed and also of items not deployed even if they were planned. It may happen that the deployment team couldn’t deploy due to missing details etc.

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.