I’ve posted a checkout test plan template at this link.

Checkout Testing Defined

Checkout testing has a very specific purpose – that is, to verify that a deployment (usually to a Production environment) was successful.  Checkout testing is concerned with making sure that the deployed system is complete, stable, and in working order.  Checkout testing is not concerned with finding defects within the developed code – hopefully the code went through numerous testing phases (e.g. unit, system, UAT) that identified all of the issues already.

Think about the typical weekend deployment – the technical team does all of the code migration activities, then usually one or two people are responsible for making sure things work.  The last thing you want after a long deployment weekend is to get a call at 8:00am Monday morning from a user complaining that the system doesn’t work, right?  Making sure that doesn’t happen is the purpose behind checkout testing.

Why Document a Test Plan for Checkout Testing?

If you take a look at my template, you’ll see that it is not a large document – so it shouldn’t take a lot of time to produce the document.  Why do it?  Two main reasons:

  1. Rather than let your checkout testers just wing it, if you put some time into planning the checkout test you’ll stand a better chance of making sure you don’t miss something.
  2. Having a documented checkout test plan will save you time and effort across deployments.  You’ll be able to pull out the previous deployment’s plan when the next release comes.  You can also improve the plan by making sure you perform lessons learned checkpoints at the end of your project (e.g. was something missed during checkout testing?  If so, document it so it gets into the next version of the plan).