2

In order to put an updated service live we have a test team who conduct SAT, UAT etc and the desktop support team will create a Rapid Install Package (RIP) for deployment. My question is when is it best to carry out deployment testing?

If the desktop support team creates the RIP and then deploys it to the test PCs,

  • if it then fails testing then it has wasted their time
  • but if we wait for testing sign off before building the RIP then the testers have to later validate that the deployment works which doubles up on their time.

What is the best approach here to take with deployment testing to minimize people doubling up on work?

1
  • Can the process of creating the RIP be automated? Commented Jan 21, 2013 at 22:42

3 Answers 3

4

This is where continuous integration comes in very handy. Generally the simplest form of continuous integration is automatically building and executing unit tests every time code is checked in. This is to reduce the amount of time it takes to discover possible build breaks or code level defects.

Similarly, many people extend continuous integration to include deployment and execution of all automated tests. This again, gives you early warning of any potential deployment bugs and functional issues.

Setting up an automated continuous integration environment with automated deployment and functional test cases is a lot of work, so in the case where that is not an option, or too much of an investment and you are relying on a fully manual validation then you probably want to include deployment testing as part of your normal test pass.

I'm confused by your comment about doubling up testing. Do you normally deploy for testing purposes using some other method than this RIP? If so, why? As far as I understand based on your question the order of events would be as follows:

  1. Team creates RIP
  2. RIP Deployed to test PCs
  3. Deployment validation (which most likely has a lot of overlap with functional tests anyways)
  4. Functional testing

If that doesn't sound right, please clarify your question.

2
  • At present the introduction of CI starting but as you said its a lot of work so I am not expecting this to be up and running of all services anytime soon. At present the agreed process is for the development to be carried out and then the developer will install on the test environment, once passed it will go to Desktop Support for the RIP to be built. I believe it has been done this way as previously Desktop Support would build several RIP packages for releases that failed testing so the process was altered to prevent a their time being wasted in future.
    – Tom
    Commented Jan 16, 2013 at 14:15
  • 1
    CI, CI, CI! Start small. CI is a lot of work but the value it supplies is hard to measure. Everyone wastes time with manual deployments. When you get to a certain point where builds, deploys and automated tests are automated together the system can seem almost magical. Commented Mar 5, 2013 at 3:52
1

Whenever the application will be deployed using an installer, I always prefer that the installer be used for every build given to QA. I don't wait for functional completion.

That way, QA repeatedly uses the installer to deploy builds into their test environment. During initial builds, there is little code, so there is little to install. Later in the development cycle, more and more code is installed. When we reach the Feature Complete build, everything is expected to be installed by the installer.

This is what works best for me. Your mileage may vary.

0

Once the application has undergone functional and environmental testing of all the modules including installer and server deploy testing.One can start with deployment testing.

1
  • Please consider improving your answer by adding detail, context, examples, and backing up with references, this would increase your answer's quality. Commented Feb 28, 2013 at 7:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.