Managing Software Quality

We all aim to build software with zero defects, but that can prove to be expensive, time consuming and next to impossible if the correct processes, checks and balances are not in place. This short article is to identify the key points in the process to focus on in order to help ensure that defects are manageable.

What Requirements?

They key points in this area is how they are gathered, documented, agreed and just as importantly communicated to the development team. This has a large impact on what the perceived quality of the software and whether it in fact 'delivers', but this has to be balanced with the required timelines. A typical example would be use cases, these for most software builds are essential. Use cases document what the users need from the system and how they will use the system, this in turn educates the developers (which mostly do not have direct contact with the sometimes high profile end users) and QA and in turn increases the changes of delivering software that is fit for purpose. Using a system to manage requirements (documenting, sharing, signing-off, etc..) for larger builds is also recommended, there are many off-the-shelf systems that cater for this. Find the time or risk these end users becoming irate when their requirements are not met.

Speed or Quality?

The amount of time pressure impacts the build quality...fact! Trying to get key features delivered might be more important to the business than how robust the system is in the short-term. That priority also might change over time and what is important is that the stakeholders are deciding what the focus should be on. Some type of systems have no room for defects and in those scenarios having the business putting severe time pressure on their development team will not produce the results they are after. The management of the development team need to be in regular open communication with the stakeholders in order to be singing off the same hymn sheet. This will in turn impact the choices of project methodology (Agile or Waterfall), the testing process and the list goes on and on.

Testing 1,2,3

QA needs to be tailored to the project, but the underlying theme is that if the developers and QA do not have accurate information on how the system features will be used, regardless of how much time and effort is spent, they will still most likely not deliver a polished system. Other key issues for me are environment and ensuring that the development and test environment mirror, as much as possible, the production environment. The final critical element of testing is the structure. The process of producing, consuming and scope of test plans, test cases and test reports should be agreed so that the process of testing is as efficient as possible, saving time and money that can be used in improving the quality of the product.

Measure

The final point that I want to make within the context of this article is to measure the defects within alpha and beta testing and also UAT. This allows a more objective and less emotional view to be taken on the actual quality of the software. Stats that I like seeing are release work items, issues reported and most importantly categories of any reported issues e.g. requirements related, environment related and delivery related. Keeping these stats over a few releases greatly improve the ability to manage the development life cycle. Interestingly we see the greatest impact on the stats to be lack of use case scenarios and this is true across project methodologies.

George Toursoulopoulos is a technology specialist and Director at Synetec, one of the UK’s leading providers of bespoke software solutions.