Software Quality: How to assess and manage it?

Good quality software is software that works, of course, but not only that, it must also meet expectations, be easy to use, efficient, be able to evolve according to needs, and also, of course, be maintainable.

Beyond verification actions, an environment conducive to quality management is built from the design of the software. Well-designed code will be more easily understandable, reusable, maintainable, and scalable. As a result, anomalies due to misunderstandings or complexity will be reduced.

Software Quality Assessment

The preliminary stage in ensuring the quality of the software is to respect the rules of the art of development: uniform code respecting coding standards, decentralized management of the source code, including the automation of the entire software construction chain. These best practices form the basis for effectively managing the software quality of your project.

But how do you know if these best practices have been applied, and how do you assess the quality of software?

Functional capacity

Evaluate the functionality coverage rate: the software must respect the specifications and above all meet the user's expectations. You can create a requirements compliance matrix, list the functionalities and check if they are implemented and respected with criteria such as suitability, accuracy, interoperability, security, etc.

Reliability

Check the ability of the software to maintain its level of service under specific conditions and for a determined period and in particular

• The frequency of failures due to bugs

• The ability to maintain a satisfactory level of service in the event of any problems

• The ability to restore its level of service and restore the data directly affected in the event of a failure, in how long? with what effort?

The software must be resistant to user error and the following tests must pass:

Unit tests: carried out by the developer himself, they consist of verifying the proper execution of the functions for which he is responsible.

Integration tests: conducted by a dedicated tester, they aim to test the pooling of several components and the sequencing of complete processes beyond simple unit functions.

Full system testing consists of running complete scenarios, representing the use cases of the software, without worrying about the implementation of the underlying components. During the evolution of the system, these scenarios will be replayed in order to validate the non-regression.

Ease of use

Take user feedback into account (contact form, telephone, forum, etc.) to continuously improve the user experience

Perform tests on groups of people

• Acceptance tests are carried out with pilot users, in order to validate the adequacy to the needs and the ease of adoption by those who will have to use the software regularly.

• Ergonomics testing. These tests include both usability and visual appearance

Performance

Check the start-up time: this is one of the keys, even the key to the success of your software, especially for new generations accustomed to obtaining everything quickly and zapping without qualms if the efficiency is not there.

Ensure a satisfactory execution time for the following tests

• Performance tests CPU consumption, the evolution of memory use, number of requests per second, input/output flow… The performance test determines the correct execution by measuring the response times without any particular context. In the case of continuous performance testing, it starts at the beginning of the development phases and is adapted to each stage of the application life cycle, up to full load tests.

• Load testing should be distinguished from performance testing and performed with tools that can simulate many concurrent clients. By increasing the number of users in stages, it detects any limits in system capacity, to validate the quality of service before deployment

Maintainability

Points to check include:

Faculty of analysis: easy to diagnose deficiencies, their causes, or to identify the parts to be improved

Ability to modify: easy to modify, remedy defects, or take into account the environment

Stability: ease of anticipating possible risks during modifications

You should be able to assess a project and its complexity based on the following:

• Number of business entities,

• Number of simple business rules (within an entity),

• Number of advanced business rules (combining several entities for example),

• Number of elements for the user interface (screens, web pages),

• Number of reports (or reports),

• Number of external interfaces,

• Number of calculations or batch processing processes,

• Number of technological variations of each component (rich client, web page, mobile version, database technologies, use of cloud storage).

The number of handwritten or unnecessary lines of code directly affects maintenance costs.

Automation makes it possible not only to limit this risk but also to respect the rules of coding and design.

Software Quality: how to anticipate and manage it?

Here are some actions to take to help you in this process.

Define a repository of good code practices

A uniform, simple, shortcode respecting the rules of the art is not only easier to maintain but is also easier to understand for the development teams. It is therefore essential to define a common repository for the use of programming languages ​​in your teams: Formatting, constructions, API calls, security, data persistence, localization, data cache, business rules, naming convention …everything has to go.

Beyond these good code practices, the implementation of indicators for monitoring anomalies, and traces for their analysis, allows them to be processed more efficiently: when an error occurs in the software, it is important to provide the clearest possible indication of the event and the associated context, in a coherent and understandable manner. Maintenance will be greatly simplified

Adopt decentralized Source Code management

Systems like Git make it easy for teams to collaborate in a decentralized way.

Each person contributes their own copy of the code repository and can push their changes to the centralized system whenever they want/should. Using branches makes it easy to isolate the changes made by each person and use merges to integrate them into the main development branch. The productivity of the teams is optimized, they can thus progress on their respective tasks, work simultaneously on the same file or validate part of the work without impacting that of the others.

Moreover, this method makes it possible to finely and easily observe the modifications made by a person on the code in order to merge them on a development branch and to set up code reviews between the different people on the team. Code review is a great way to:

• Exchange of good practices

• Train new developers

• Detect and correct anomalies

• Foster collaboration

• Maintain a high standard of code quality

Each developer has a local version of the source code, he can follow the history of modifications and above all return to an earlier version in the event of an error or loss of part of the source code. In addition, when several people work on the same source code, project management is optimized.

Set up automated tests

Automated testing aims to minimize testing efforts as much as possible through scripting. … Automated, they can be replayed at any time. The repetitive nature not only makes it possible to test continuously but also to test more and better, in particular, to manually test more advanced scenarios, as well as to be able to test the entire system again in the event of structuring technical or functional changes impacting the whole system. This is particularly the case for unit tests, integration tests, or non-regression tests.

Writing tests allows you to verify the behavior expected by your code.

Each time a modification is introduced into the source management system, automatic tests run quickly in an environment as close as possible to that used in production to validate the proper functioning of the system.

Document the code architecture

Documenting the architecture of the code is providing instructions for understanding the breakdown of the architecture, the main components, their sub-components, and their orchestration, who calls who, ... this documentation must explain the key concepts of the code, diagram the components and their dependencies, describe the commands to run the tests, …

Writing documentation, like writing tests, should be an integral part of a developer's daily life.

Code with up-to-date documentation will be easier to maintain. It is an effective communication tool for teams and a considerable time saver to understand the code.

The starting point can turn out to be the gathering of the following elements

• Documents related to agile methods: report of retrospectives, areas for improvement, sprint/version/functionality correspondence, etc.

• The definition of business terms and the associated rules: the business domain is sometimes more complex to understand than the code itself, especially for a beginner.

• A hardware and system architecture plan: Cloud servers or components, software configurations, platforms (dev/test/pre-production).

• The architecture and structure of the code: especially if the framework is in-house and based on a particular architecture, it is interesting to define the execution path: entry point, an example of information flow, layers responsible for validating the data, persistence, security, etc.

• Database data model: with for example the possible values ​​for the columns. You can also list the rules that exist between two columns (the value of a column that depends on the value of another column). Some tools facilitate the creation of this documentation (tables, columns, constraints, object description) based on object annotations.

• Procedures and checklists: steps to follow during deployment, creation of branches, modification of specific code, code reviews, and checklist of good practices concerning security, for example.

• Change-log of versions: useful for quickly identifying the major changes and features of each version.

• Roadmap: to give the vision with important dates (updates, deployments, meetings, etc.). It can be a schedule shared with the teams.

But also

• Test sets: which user has which right and which configuration on which platform?

• External tool documentation: link to tool initiation tutorials (Git, Frameworks, etc.)

• Suggestion box: or mind-mapping web application to consider all the solutions to the problems encountered and to be able to discuss them in sprints.

The more the documentation is structured and kept up to date, the more it will be a real asset in carrying out a project without major slippage.

Deploy continuous integration

Running a project without continuous integration is like digging a hole without a shovel. Continuous integration is above all the automation of the entire software construction chain

The goal of this modern approach is to progress in stages in order to design the development process more efficiently and to be able to react to changes with flexibility.

Developers check-in their completed code one or more times a day into the source management system, and within minutes the source code is available to everyone. If an error is discovered in the "compilation", in the construction of a component of the software, or in certain automated tests, it can then be immediately located and quickly corrected.

Finally, continuous integration allows above all to:

• Have a well-defined automatic process to reduce the risk of "human" errors