The primary goal of any IT department is to create the right software, on time and on budget with a high degree of quality. To accomplish this consistently, it is imperative that software releases contain well-known and documented change sets. This article discusses a clear way to articulate the problem as well as areas to focus resources that will result in measurable software quality improvements.
Software quality can be very elusive to IT departments not focusing on it. Many companies I consult with struggle in the search for quality software by directing their resources toward testing and QA departments, when their biggest roadblock is unknown software releases. Without predictable, well-known releases of software, quality can not be created on a consistent basis.
he analogy that comes to mind when articulating the real problem is a Test Driver testing a new release of a car from the Ford engineers. The driver takes the car out on the track and pushes it's limits in handling, braking, power, etc. and finds that the car performs just great. As she brings the car back into the shop and delivers her report, the engineer asks how the heater worked, since the only change on the car was a modification to the heating system, which, of course, wasn't even turned on. The same thing happens in software all the time, and is even exaggerated because oftentimes the Engineers don't even have a grasp of the changes delivered in the release.
Release based Software Configuration Management (SCM) provides an SCM solution where all of the functionality is performed within the context of a release. After all, we develop software with the intent to create a stable release containing functionality. I find two types of SCM capability very helpful in the quest to create well-known change sets for releases: Release Compare and Activity Based SCM. The simple Release Compare allows any user of the SCM tool to compare any two releases or work areas and determine what files are different, and if desired, specifically what the differences actually are. Activity Based SCM, in its simplest form, is managing the relationships between changed files and the business level units of change (i.e. CRs, ARs, defects, etc.). The objective here is to identify exactly what file changes were applied to the software to implement the change request in question. For this to be effective, any change being committed to the repository must have an associated change request selected as part of the check-in process. Depending on the tool, this relationship can be captured in a very non-intrusive way.
Most SCM tools on the market provide functionality to support Activity Based SCM, however the simple Release Compare is more difficult to find. There are a couple of SCM tools available that have effectively put this all together, but remember with any SCM solution, it's not the tool that gives you the solution–it's the process around it that counts.
An effective SCM solution containing a rigorous process supported with appropriate automation will enable the Development group to produce releases that are predictable without impact to their productivity–in fact, very possibly improving productivity and most certainly improving quality. Imagine testing a release of software where you know exactly what changes have been put into the release at a file level as well as a business level. As in the previous analogy, imagine the improved end product if the Test Driver knew up front that the heater was modified, and that it was modified to ensure the entire windshield is defrosted on a 20 degree day within 5 minutes of cold startup. She wouldn't have to worry about testing the engine, handling, or braking, and could really focus in on that heater. She likely wouldn't spend that much time validating the heater if she were uncertain that the brakes hadn’t changed, or the suspension hadn’t been reengineered.
When looking to improve software quality in your organization, don't only look at the process of testing–start with addressing the process where the change originates and follow it all the way to delivery. The common object through this process is the Release–make your Releases predictable and well known, and your software quality is sure to improve.
