Eight steps for a successful software release

Software releases are never the same, but here are eight steps that will help ensure a great release.

1. Create your team

The first thing you want to do is identify who will be on your team. Most software releases involve the functional roles listed below:

• Project lead
• Technical support
• DBA
• Install manager
• Developer(s)
• Business partner(s)
• Sponsor(s)

Create your team as soon as possible as it always takes longer than anticipated to get a team ramped up for a release, especially with already busy schedules.

2. Review your application and database environments

Always be sure to review test, dev and production environments, to see how consistent they are with one another. If you have different environments, your test results may be invalid. When test results cannot be relied upon, you could very easily have major problems with the production release even though you passed every test case during testing. Think about cleaning up your test and dev sites to be consistent (or as near as possible) with your production environment.

And remember, databases need to be tested as well. Are the versions on all environments the same? Can data be refreshed easily by the DBA during the testing phase? Since your DBA is a critical member of your team, bring them in early to discuss what the release will need and when.

If you know your environments are not consistent, sometimes it is easier to copy over everything from production onto the test or dev environments rather than spending the time analyzing what is on each environment. The decision to copy or not to copy depends on each release. Talk to your team about the pros and cons and you will know what to do after that. If you still are unsure, take it to a vote and have your team help you decide how the environments should be handled.

3. Create a strong test plan and test cases

Test plan

The test plan is a document created for your specific testers. There really is no one way to write a test plan. Just keep in mind who your testers are. Are they super-users or new to the application? Do they understand technical jargon, or do they steer away from the technical aspect of the release? Keep your testing as simple as you can, but be sure to cover everything that was touched by the release; along with a more regressive type of testing (test all of the application, not just the areas that were touched by the developers). Test plans show what will be done during testing, timing of testing and who will be involved.

Test cases

The test cases that you create for your testers become an integral part of the test plan; however, they are usually a separate document and include instructions on what testers are to do. Test cases help direct testers into the areas you want them to test, along with giving testers feedback on what they should be experiencing. If the testers are not experiencing what you say they should, then the test most likely fails. Testers then report their overall results, noting each and every passed and failed test case.

Random testing

In addition to test cases, encourage testers to do random testing, which is letting testers test anything they want, without any restraints. Some of the best bugs and problems are found through random testing.

Failed test results

When a test case fails and it is critical to the release, testers are to report the failure immediately to the project lead, who can then determine if the testing needs to stop while the problem is investigated or fixed, or if testing can continue. Otherwise, test results can be accumulated and shared at the end of testing.

4. Determine voting rights

Voting will help to make sure that everyone’s voice is heard. It’s a great method to ensure that your release is managed by the whole team, and not just by the more vocal members.

Your team members will have different voting rights, depending upon their role on the team. For example, sponsors generally only vote on go/no-go decisions, not what should be in a release package. And you may have many business partners from one department on your team, so you may want to set up voting as a group rather than as individuals so that the department has only one vote.

5. Always include release notes

Release notes generally come from the business requirements document (BRD). If you are working without a BRD, be sure to track what changes are being made to the application and environment as they will be needed for the release notes.

6. Prepare a communication plan early

Communications are critical to all software releases and involve individual communications to one member of your team, and communications to all the users once the release is completed. When you get your team organized, brainstorm who needs information and when. For example, prepare early for your IT alert for the outage window so you’re your service desk and technical support have enough time to prepare the notification. In addition, keep your sponsors involved with the release by regular, high-level status reports.

7. Retain your release documents in one well-organized place

All documentation documents, communications and reports need to be posted and easily accessed by team members. This is important so that everyone understands the change management that has occurred.

8. Always have a back-out plan

No one plans to fail, but when all else fails, be sure to have a back-out plan prepared prior to the installation of the release. Your team members can help you with this plan and it does not have to be difficult or complex. Just be sure everyone knows what they need to do should the install fail or there be too many priority 1 or priority 2 problems after going live. Should you need to back out and reestablish the environment to where it was before the install, your team will need to be notified and, if needed, you can do a quick email vote to determine the course of action.