02/24/2016
in Quality
How to improve software quality
Table of Contents
In our previous post we defined quality as “the degree of conformance to explicit or implicit requirements and expectations” and took a closer look at the different terms of the definition. During this examination it became clear that quality starts with thoroughly defined requirments. In this post we want to go one step further and show which steps can be taken to improve quality.
Quality requires acceptance criteria
A huge step into the right direction to improve quality is to determine acceptance criteria for requirements. By doing so you get measurable criteria that you can compare your product with. Once the acceptance criteria are known, the development team can take steps to ensure that the criteria will be met. For example they can add new aspects to their Definitions of Done (DoD) or they can write unit and integration tests. Below we want to show you some measures you can take to improve your software quality covering the whole software development life cycle.
Analyse requirements
During the analysing phase you should do these things:
- Involving customers and stakeholders: As already mentioned, it is vital to involve customers and stakeholders as early as possible in the development process. This way you learn about requirements and expectations and you get feedback about the product. This reduces the risk of “last minute adjustments”.
- Determination of acceptance criteria: In the last post we already mentioned that it is very important to have measurable criteria. Each defined requirement must have at least one acceptance criterion to ensure that quality can be evaluated.
Design your software development pipeline
During the design phase you should think about the development pipeline including these things:
- Design of system architecture: Often it seems necessary to produce first results quickly, but if you take your time at the beginning to design the architecture of the application you can safe a lot of time later. With a thoroughly designed application you are “prepared” for changes and extensions that will come up.
- Set up of quality gates: Quality gates are metrics about your code. By using static code analyses, e.g. with SonarQube, you can constantly calculate key figures about the code. Often used metrics are for example “Code Coverage”, “Number of Bugs”, “Share of Commented Code” or “Code Duplications”. If the quality gates aren’t met the application cannot be build.
- Set up of development process: In addition to quality gates and the system architecture you should think about your software development process. It might be necessary to adjust your default process to meet your customers requirements. Your process should set rules for branching, execution of automated tests, commit and build frequency.
Implementation of your quality metrics
Once you have designed your development pipeline and quality gates you have to figure out how to fulfill your goals by implementing them in your pipeline:
- Tracking of metrics: Determining acceptance criteria is only the first step. You should also transfer the acceptance criteria into code analysis metrics that you can track.
- Determination of Definitions of Done (DoD): The DoD are an important part of Scrum, but even if you don’t use Scrum you can use them. They define all necessary steps that are required to finish a task and mark it as done. Elements can be mandatory tests, non-functional requirements or quality gates.
- Reduce complexity: Generally spoken: Complex code is more likely to contain defects and it is more difficult to add new functionality and to understand it. Therefore it is advisable to aim on a low complexity. Complexity can for example be measured with Cyclomatic Complexity by SonarQube.
- Implementation of automated tests: It’s not advisable to aim for a 100% test coverage of your code, but use automated tests wherever it’s useful and effort is appropriate. You can automate integration, or performance tests as well as UI tests. When you start using for example unit tests it’s not advisable to add tests to the whole code at once, but whenever you add new parts to the code or change older one.
Use tests to ensure Quality
After you’ve implemented your quality metrics you have to test your software to determine whether it meets the criteria:
- Usage of manual tests: Test all aspects of your application and use different approaches for that. There is no ‘One fits all’. Use manual tests to evaluate the user experience and for tests that can not be automated easily.
- Usage of automated tests: Execute your automated tests regularly to ensure that the product works properly. Depending on how long it takes to execute them you have to decide at what time of the day and how often you can execute them. The execution of tests shouldn’t slow down the development.
- Involving customers and stakeholders: It isn’t enough to involve stakeholders at the beginning of the project, they should also be involved during the development and the testing of the product. As soon as there is something to see stakeholders should be asked for their feedback.
During the development of the product you can run through this cycle several times, e.g. when you’re using Scrum after each sprint. By taking these measures you are shifting your software development process towards a quality oriented framework. Quality is a holistic approach, therefore the measurements are starting with requirement analysis, cover code conventions and development processes up to testing all parts of the software development process need to be considered. Although it might take some time to get used to the new process and it might seem like you are proceeding slower, you’ll normally regain this time until the end of the project because you’ll have fewer changes and a satisfied customer.
Quality is measurable acceptance criteria
As mentioned before the important thing about quality is that you find acceptance criteria that are measurable. Quality is not about the number of bugs in an application but about the degree of conformance with the defined requirements and expectations (of course, a high quality product is supposed to be ‘bug free’, because bugs mean that the product doesn’t work as expected and that results in a low degree of conformance with the specifications). In this post we showed several measures that you can take to ensure that your product will have a high quality.
