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?

release and deployment management process for qa

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

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.

Build and Deployment

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.


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.

Recommended Reading

37 thoughts on “What QA Tester Should Know About Release and Deployment Management Process”

  1. Good article. I think above process depend on company to company.As a tester in my previous company deployment process also done by the testers like new binary file hosting and script update. So i think its also a good practice as a qa engineer to identify deployment issues and some of technical areas.
    Finally thanks for sharing your important information.

  2. When Deployment is done then QA team should receive a release note from Dev. team, then QA team has to go through release note then start for doing Smoke test.

    Excellent efforts and thanks for sharing it.

  3. Nice article. Explain each and everything about the build and deployment process.

  4. Nice Article. Just what we do in our company :)

  5. Very well framed explanation!!!

  6. Thank you all for valuable comments.Yes Kanchana,it totally depends on the project what model of deployment they want to follow,in many cases QA needs to take care of deployment and maintenance of test environment,and in many cases separate deployment teams are maintained.

    • Hi All,

      I have some query regarding some of the question asked in interview like :

      1. Which document is used for post deployment or what is the name of that document. And what things does this document include ?

      2. types of testing done in production environment;
      3. types of testing in stagging server, also do we provide negative testing at stagging server;

      Kindly help me to find the answer of above question. Thanks in advance.

  7. Nice Article, seem to be very helpful and so valued,
    Really thank you for sharing


    Great job VIjay and team. Now I stop searching for interview questions in the web. Your every blogs are so
    informative which clears all my doubts. I highly appreciate
    your team’s effort and knowledge. Simple words and live examples.

  9. It’s important to know the technical details of the things you are receiving. the more you know the less you are dependent on others.

    A minimum check should be done at the time of build acceptance and its good to have a separate team who take care of n number of environments having different builds

  10. Thank you Sudeshna & Ahmed.

  11. Very well structured article! Thank you!

  12. Thanks Jacqueline and Karthik!

  13. Can you please explain Deployment process with example?

  14. Nice and very helpful article.

  15. Nice article..explained the process completely in general..but the process varies organisation to organisations.. However this is a very good article to know about the process

  16. Thos is a list of good practices but sometimes reality looks different.

  17. This is a list of good practices but sometimes reality looks different.

  18. Nice Article.. Good information about Deployment process.

  19. Nice job …The deployment process explained in the article is almost similar to the process followed im our company …

    Apprecite ll your efforts in bringing up thi information ??

  20. It is very useful article, thank you Priya very much for your supporting and helping QA community.

  21. Really very informative article. I always like to read SoftwareTestingHelp blogs daily.

  22. What is the difference in deploying code in jenkins.

    Angular app development

    Angular app master

    Angular app release



    beta deploy-develop

    beta deploy-release

  23. having a separate QA and UAT site is redundant and unnecessary in my opinion. it just adds one more unnecessary layer that ends up having to be retested anyway when code it pushes.

  24. As of today many companies follow multi environment before pushing code to Prod. However it takes enormous amount of time if test automation is not implemented. Usually testers spend lot of time running regression testing which should be automated to save testing timelines.

  25. Awesome article Well explained.Thank you, Priya for sharing.

  26. superb explanation .Thank you Priya….

  27. it’s exactly what I was looking for. Thank you a lot

  28. Hi All,

    I have some query regarding some of the question asked in interview like :

    1. Which document is used for post deployment or what is the name of that document. And what things does this document include ?

    2. types of testing done in production environment;
    3. types of testing in stagging server, also do we provide negative testing at stagging server;

    Kindly help me to find the answer of above question. Thanks in advance.

  29. Explained in simple english which everyone can understand. Brilliantly conveyed the content. Thanks

  30. Hi,

    Application deployment has been completed by third party and applications is working fine. Pls help what are thinks need to be take care like backup, sync data from primary location to backup etc…

  31. HI Priya R.
    I am a QA and we follow almost similar deployment routines. But I always had problem explaining it. Thanks a lot for your time and the way you have explained it.

  32. Hi Priya,
    I Would like to add on ” #4. Planned vs. Emergency Deployment” ; In our company we use the term ‘hot-fix’ meaning a deployment can bypass a few stages (i.e. “UAT”) and is directly implemented on Production, whenever there is a blocking issue on main functionality which hampers the end-users to execute their work. (Even QA can miss something ;))
    Off course this hot-fix is first tested, although not a full regression test. So we try to limit ‘hot-fixes’ to a bare minimum.

    And, thanks for the excellent and clear explanation!

  33. This is what i am looking for. Appreciate and Thanks a lot.

  34. I am not clear in this part. Can someone can explain me, please.
    “The QA Test Lead is asked for approval to ensure that change wouldn’t impact any of the existing tests.”


Leave a Comment