Are you afraid of your next software release? Were the previous releases plagued with bugs? Even for features that worked previously? There are ways to avoid this, but they’re often counter-intuitive. Let’s look at what causes these bugs, and how we can break out of this destructive cycle.
Regression Bugs
What you’re experiencing are regression bugs. These are bugs in pieces of the software that weren’t there previously. The cause can be anything from code that has been changed to a system upgrade.
If this is happening continuously, this is very frustrating for everyone involved: users, developers and managers. It seems like we’re constantly fighting small fires. It also hinders our ability to improve the product with new features.
Typical Reactions
A classic approach to deal with this problem is by tightening the screws on the development team. I’ve often seen policies like reducing the amount of releases per month or year, enforcing a stop of development until QA has tested everything thoroughly, and requiring everyone to be present for the release and to monitor it closely.
This may give management a feeling that the problem is being tackled, but it remains a frustrating experience for most involved.
What’s worse, it won’t make too much of a difference.
Automating Tests
One of the first things I always recommend is to build up a decent automated test suite. These tests should do what your QA department is doing before every release. Only, the automated tests can be run over and over again. They also take only a fraction of the time it takes QA to test everything.
This doesn’t mean there is no need for the QA department anymore. They might still find bugs that the test suite didn’t find. But the automated tests give them more time for designing tests in collaboration with the developers, and for running tests that can’t be automated.
Release Faster
It may seem frightening, but once you have automated tests, you should slowly but surely be able to release more regularly. The tests will give you the confidence to do this. At a client, we changed from ad-hoc releases about once or twice a month to weekly releases. We’ve automated everything so that we could even move to faster releases, but weekly is fine for us now.
Strangely, releasing faster is safer. When a release only contains small changes, the chance of breaking things is smaller. And when a bug is introduced, it’s easier to find because there are less changes.
You might think that your team will have a bug on every release. You may prefer having 10 bugs in one big release, than 1 bug every week for 10 weeks straight. But if you combine this with a good automated test suite, you should find that you won’t have a bug every week.
Firefighting
Bug-free software does not exist. So you will still have to fight small fires now and then. That’s why there’s another component you really need to automate: deployment.
When deploying your new software is done by the click of a button, it shouldn’t be too hard to implement a rollback procedure. That allows you to easily go back to a previous working version when you do have a regression bug.
Trust and Professionalism
All of the above requires that you have quite some trust in your development team. If you don’t think you can trust them with this, then your problem is bigger than I can help you with. It’s a culture and possibly a HR problem.
Professional software developers will be able to work in such an environment. They will be eager to!
The post New Bugs on Every Release? appeared first on Red Star IT - Helping Managers Tackle Legacy Code.
Top comments (0)