Home > Work > An example checklist for a software release

An example checklist for a software release

I mentioned previously how I found using a checklist helped enormously when I was responsible for managing releases last year. As we identified issues I added them into the checklist for next time and after a few months the process was pretty tight and a contributory factor to the overall success of the project.

As time went by I developed several checklists for different purposes; of these the one I used most often was to release a build from the development team to our test team. I hope it might be a useful starting point for others, so I’m setting it out below.

Of course, it’s not fully comprehensive. It reflects the issues we experienced on our project – another project might have a very different set of experiences and would need to add other checks or remove some of mine. In summary I was seeking to minimise errors in the following:

  • QA to ensure the development team had followed processes and provided a full audit trail;
  • All software components were as expected, and nothing else;
  • Packaging the release and accompanying documentation.

We followed a traditional waterfall process, but with short iterations (often a release every week or two). I’ve removed most application specific detail, however we had two development teams for the application and the reporting suite respectively and I’ve retained the distinction as it is quite a common one.

Test Release Checklist

  • Check all new code has Peer Reviews and Unit Tests.
  • Update all defects in Quality Centre (QC) by checking against the list of fixed defects supplied by team leaders, setting ‘Fixed in Version’ to current release.
  • Derive a list in QC to use in release note (use Export All to save to Excel) and also easily to update at the end. Needs formatting in Excel – add grid and format cells to align Top, save it for later use in Release Note.
  • Check all QC defects can be traced back to a Unit Test. Check also whether Unit Tests have sufficient coverage (i.e. if an extra branch in code, that both are being tested, not just new case).
  • Consider if defects should be a Change Request, and whether they involve a spec update (which implies a CR).
  • Are there any dependencies on other systems – upstream or downstream – or infrastructure? If so will need to liaise with client team to ensure everything is aligned for Production release.
  • Prepare Release Note.
  • Check out in CVS – directly on the UNIX box by running a checkout script, which also produces a listing of changed files since previous release.
  • Check all expected changes are in CVS.
  • Check all updated files are expected for release, if anything else has been identified need to decide on action – either trace it back to a defect and add it in if necessary or exclude it.
  • Save listing of the all the CVS changes since the last release for the record.
  • Check release notes/emails from application teams. Check versions are consistent with email and CVS. If nothing apart from versions has changed then no further action, however if configuration settings have been updated then need a change to Installation Guide and also need to specify new settings in Release Note.
  • Are there any Hotfixes since last tagged release? If so, do any involve anything other than a DML update? See Hotfix log.
  • DDL changes – do a diff on database DDL build scripts. Ensure all changes are included in migration script (and vice versa) and also traceable to a defect. Ensure we are not dropping any production data as part of this (e.g. User Roles, Reference Data) unless this has been agreed and tested. Also have there been any Hotfixes with DDL since the last tagged release?
  • Reporting components – are there any changes to parameters, LOVs etc to feed into Release Note or Installation Guide?
  • Raise any defects required to cover gaps, e.g. document updates outstanding (and note in section 2.3 of release note).
  • Run CVS check again just to check no last-minute changes have been introduced to CVS.
  • Tag release (excluding anything that isn’t required).
  • Check a couple of different files in release to check tag has worked properly, and especially the files/directories that have been retagged manually.
  • Update defects in QC.
  • Send out email formally releasing build.
  • Update Release Summary sheet in Log.
  • Write up notes of release including any issues encountered for later dissemination.
  • Make any updates identified in Release/QA documentation.
  • A couple of days after release, send out review email to project team leaders of how the release went.
Categories: Work Tags: ,
  1. April 9, 2013 at 9:41 am

    It’s hard to come by experienced people on this topic, but you seem like you know what you’re talking about!

  1. March 29, 2010 at 7:18 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: