English | EN 
No focus on equality, not enough quality. Quality Engineering has a main aim: ensure quality from every perspective to reduce risks and increase business value and users experience. Nowadays, business value is also closely related to social value, and consequently, to citizens experience, as software is an intrinsic part of society. “Reduced inequalities” is one of the 17 Sustainable Development Goals (SDGs) adopted by the United Nations in 2015, which constitute a guide for public administrations and business organizations as a universal call with the time horizon of 2030.
In this context, software quality needs a broader definition and associated actions right now. Traditionally, quality models have been focused on functionality, reliability, usability, efficiency, maintainability, and portability as external and internal quality attributes. However, a wider view is necessary in our today’s aim of a sustainable society (individuals and groups interacting with the maximum personal and social benefit with the minimum expenses, lost opportunities, or discomfort). Since software plays a role in the continuous pursue of a more sustainable society, software development and quality engineering activities necessarily need to revisit today’s driving software quality attributes. In other words, no software engineers should think of software quality without pursuing social equality and without a development and testing strategy to evaluate the contribution of their software to EDI (Equity, Diversity, and Inclusion).
Development and quality engineering processes don’t usually include EDI as mandatory quality objectives through a sufficient and systematically approach. Adapted to software requirements terminology, we advocate for:
- Equity objectives: Stands for fairness (software users are not treated less favorably because of their protected characteristics) and equality of opportunity (every user has the same access possibilities and opportunities when using the software).
- Diversity assumptions: Requires analyzing the diverse user profiles as a subset of society members, which is totally different from a traditional analysis and definition of system stakeholders.
- Inclusion strategy: Only by recognizing diversity during requirements and quality engineering, software may address diversity by driving user interactions in an inclusive environment were (1) no potential users are limited or discarded by entry barriers, and (2) every user that can access the system feels welcomed and equal in contrast with others. Accessibility testing, which is a growing quality engineering focus, is key but only a small part of this strategy, limited to exclusion avoidance due to potential user disabilities. However, inclusion stands for addressing every inequality risk due to income inequality (software pricing model, subscriptions, etc.), geography and cultural diversity (multilanguage features, performance and reliability on different internet connections and devices, content formats, language variants, etc.); social/well-being status (interests, personal treatment, respect, personal assumptions, etc.); education and digital readiness (usability, self-learning features, simplicity, etc.); democracy maturity (data transparency, open processes, etc.); gender (sensibility, fairness, etc.); age (adaptation of usability to different age profiles); or health (accessibility of people with disabilities).
Modern Software Quality Engineering needs to urgently include these quality objectives. No modern software should go into production without a determined and professional (e)quality strategy and (e)quality degree of compliance validation. The reason is simple: better society, better business. Some international standards like ISO 26000 already provide social responsibility guidelines, but they have not been fully transposed yet to software quality models to be systematically applied by means of quality engineering activities. It is important to mention that quality assurance is about reducing risks, and for sure the risks of not applying quality activities (requirements elicitation, software prototyping, ethnographic research activities, testing strategy including equality objectives, etc.) are high and critical, because they may lead to inequity, digital divide, offense, and exclusion; or in other words: exclusion of potential users, unsatisfaction and low-quality user experience that, in turn, lead to business issues.
Sogeti, as a market leader that pushes for software quality, sustainable business, and SDGs contribution, is made by a wide range of professionals capable to collectively build and deploy (e)quality engineering in a professional and systematic way, together with our customers, by building a strong and responsible ecosystem. I propose the following steps to achieve it:
- Creating an (e)quality structured model, built by following a bottom-up strategy with open contributions. The result will be the base to support, in a systematic way, current software development and testing & quality assurance strategies for apps development, evolution, and rebuilding. This model should follow a metamodel (see below), as a base to extend the traditional software quality models. Each (e)quality attribute being defined should apply to one or more diversity profiles and being classified into diversity respect (suitable treatment), inclusive access (access barriers reduction) or equity in use (same opportunities to be accomplish by the system regardless diversity profiles) types. Each equality attribute may be addressed by suggested development and quality engineering activities as a contribution to the reduction of some Inequality risk. For every project, the resultant model should be instantiated as part of the quality strategy implementation.
- Developing an assistant, based on the bottom-up built (e)quality model, to support the quality strategy definition, and a balanced/prioritized application of software development and quality engineering activities. This is the base to revisit quality assurance activities with equality perspective for better software quality.
If you feel, like me, that modern software quality engineering cannot be understood without the “e” of (e)quality engineering, it’s time to act: just write a comment to this post and we will contact you to contribute. I hope to keep you up to date about (e)quality model in near-future articles.
