6 Questions To Ask Before Releasing Software

By Jake Bartlett

Your team has been working hard, iterating on designs, and spending countless hours developing new features. The day has come and they're finally ready to ship. But are things really ready?

How do you know when the software is ready to be released? Who gives the final thumbs up? And what exactly needs to be done prior to the release?

Just as you're always working to improve your product, you should always be working to improve and optimize your release process.

A good release management process can make or break your product and save your team and customers a lot of headaches. Product teams today are obsessed with "shipping fast", which is great, but it's easy to forget some important things along the way.

Product teams are made up of many different people who wear many different hats. Each role sees, touches, uses and is affected by the product in different ways. It's important to consider this before releasing your software, not just "has it been tested?". Although this is a major factor (which is covered below), there's a lot more to releasing software than just building, testing, and releasing.

The better you and your customers are prepared for the release, the happier you both will be.

Here 's a look at some things to consider as you approach release day.

Are the right processes, communication and best practices in place?

The first step to building quality software is having a quality process. If your process has holes in it, your software will too. Take the time upfront to make sure your process actually works and that communication is a priority... you'll save time in the long run and this is a great way to ensure your team is "quality-driven".

Developers should make sure the code they've written supports the requirements they were given. Since they're the ones building the software, they naturally have a good sense of the overall stability of the software before it goes to testing.

Developers can validate the quality of their code by running unit tests after the code has been written. They can also practice test-driven development (TDD), a development methodology where you let the tests drive and influence the code. The development team should always keep close communication with the rest of the team in order to communicate potential risks or areas of concern.

What exactly has/has not been tested, how and why?

Sure, it's the tester's job to test the software, but simply testing and releasing is not enough. You need to know more than "it's been tested" to feel good about introducing new code to production. You must know what has been tested and how it's been tested in order to feel confident in your release.

For example, do you know how much of the software has been tested? Conversely, do you know how much has not been tested and why? Understanding the test coverage (that is, what has/has not been tested) is an important part of the release checklist and ensures the areas that need testing have indeed been tested.

How the software is tested is just as important as whether or not it was tested. If a release candidate has not been tested well, it's very possible you will run into problems post-release.

Has the designer seen the final designs/release candidate?

Designers have an eye for detail and therefore, whenever possible, should always review the final implementation of their work. They can often spot small (but important) issues that can likely be fixed very quickly.

By having the designers involved in validating the release candidate, it gives you the chance to bring the quality level up a notch or two. These small details could be what will make your software more polished and better than your competitor's.

Has User Acceptance Testing been done?

User Acceptance Testing (UAT) testing helps ensure the software adds value to the business and doesn't take away from it. If you're releasing a major update with many new features and functionality, chances are you'll want to coordinate UAT testing to ensure the product owner/client has seen the product and signed off on it.

UAT helps validate the functionality and ensures nothing has been missed that may have been left out of the original requirements. Ultimately, the product owner/client are the ones who can confirm the requirements have indeed been met. For smaller releases, UAT might not be necessary.

Have external factors such as marketing events and holidays been considered?

It's important to consider external factors such as marketing events, holidays, and other high-traffic periods that may have an effect on the software. This can go both ways; maybe it's important to get a release out in time for a certain event where many users are going to be exposed to the website/software.

On the other hand, maybe there's a large risk in making changes to a certain area during a high-traffic period and you actually want to avoid making those changes during that time to reduce risk.

Is your support team prepared?

The better you and your customers are prepared, the happier you both will be. Has support been trained on the new features so they know how to answer questions from the customer? Are they aware of changes that will affect customers so they can set the proper expectations? Is help documentation created and available to the customer?

Customer support issues can be reduced or even avoided when the customer-facing team has the chance to review/approve the release and prepare for the changes. After all, how can support actually provide support if they don't know how something works?

Make sure your support team is aware of any quirks that may raise questions but might not be bugs. For example, does the application require a specific browser or device? Your support team needs to know that. By setting them up for success, you'll receive less questions from them later.

Closing Thoughts

Software releases can involve a lot of work. It's important to put in time upfront and be as prepared as possible for releasing new code.

At the core of every project is the scope, the deadline, and the budget. As quality-driven people, compromising on quality is rarely the answer (unless the release is an alpha or beta release). If scope and deadline can't be changed, an increase in budget may be necessary in order to bring on more resources to meet the scope and deadline.

If scope can be compromised, keep in mind It's better to have a few features that work really well than a bunch of features that will cause problems for users.

Remember, there's more to releasing software than just "build and test". There are a lot of moving parts, people, and processes that go into the decision the release.

About Jake Bartlett

Jake is a software tester and blog contributor for TestLodge test case management tool where he writes about a variety of topics from testing, software development and culture. TestLodge makes it easy for teams to write and manage test documents in a collaborative, efficient way. Try TestLodge today to start organizing your testing process.

Jake is also a Customer Success Manager at Altassian and has experience working with software teams as a quality analyst and project manager in both single product capacities and consulting environments. Connect with him here.