QA du code source : ce n'est plus seulement pour les développeurs

Il y a vingt ans, lorsque je travaillais dans l'industrie automobile, le directeur d'une usine disait souvent : « Nous avons un jour pour construire une voiture, mais notre client a toute une vie pour l'inspecter. La qualité était de la plus haute importance. En effet, dans des secteurs plus matures comme l'automobile et la construction, l'assurance qualité est une considération clé qui est systématiquement intégrée dans le processus de développement de produits. Bien que cela soit certainement motivé par la pression des compagnies d'assurance, cela est également dicté - comme l'a noté ce directeur d'usine - par la durée de vie du produit qui en résulte.

En ce qui concerne les logiciels, cependant, des cycles de vie plus courts et des mises à niveau continues signifient que l'intégrité du code source est souvent négligée au profit de nouvelles fonctionnalités, de fonctionnalités sophistiquées et d'une vitesse de mise sur le marché. Les chefs de produit donnent souvent la priorité à l'assurance qualité du code source ou la laissent aux développeurs s'en occuper, malgré le fait qu'il s'agit de l'un des facteurs les plus critiques pour déterminer le sort d'un produit. Pour les chefs de produit soucieux de construire une base solide pour le développement de produits et d'éliminer les risques, il est essentiel de définir et de mettre en œuvre une évaluation systématique de la qualité du code source.

Définir la « qualité »

Avant d'explorer les moyens d'évaluer et d'appliquer correctement un processus d'assurance qualité du code source, il est important de déterminer ce que signifie la « qualité » dans le contexte du développement logiciel. Il s'agit d'une question complexe et à multiples facettes, mais par souci de simplicité, nous pouvons dire que la qualité fait référence au code source qui prend en charge la proposition de valeur d'un produit sans compromettre la satisfaction du consommateur ni mettre en danger le modèle commercial de la société de développement.

En d'autres termes, un code source de qualité implémente avec précision les spécifications fonctionnelles du produit, satisfait les exigences non fonctionnelles, garantit la satisfaction des consommateurs, minimise les risques de sécurité et juridiques, et peut être maintenu et étendu à un prix abordable.

Compte tenu de l'étendue et de la rapidité avec lesquelles les logiciels sont distribués, l'impact des défauts logiciels peut être important. Des problèmes tels que les bogues et la complexité du code peuvent nuire aux résultats d'une entreprise en entravant l'adoption des produits et en augmentant les coûts de gestion des actifs logiciels (SAM), tandis que les failles de sécurité et les violations de conformité des licences peuvent affecter la réputation de l'entreprise et soulever des problèmes juridiques. Même lorsque les défauts logiciels n'ont pas de résultats catastrophiques, ils ont un coût indéniable. Dans un rapport de 2018, la société de logiciels Tricentis a constaté que 606 défaillances logicielles de 314 entreprises représentaient 1,7 billion de dollars de perte de revenus l'année précédente. Dans un rapport de 2020 qui vient d'être publié, le CISQ a estimé le coût des logiciels de mauvaise qualité aux États-Unis à 2 080 milliards de dollars, avec 1 310 milliards de dollars supplémentaires de coûts futurs encourus en raison de la dette technique. Ces chiffres pourraient être atténués par des interventions antérieures ; le coût moyen de résolution d'un problème lors de la conception du produit est nettement inférieur à celui de la résolution du même problème lors des tests, qui est à son tour exponentiellement inférieur à celui de la résolution du problème après le déploiement.

Manipulation de la patate chaude

Malgré les risques, l'assurance qualité dans le développement de logiciels est traitée au coup par coup et se caractérise par une approche réactive plutôt que proactive adoptée dans d'autres industries. La propriété de la qualité du code source est contestée, alors qu'elle devrait être considérée comme la responsabilité collective de différentes fonctions. Les chefs de produit doivent considérer la qualité comme une fonctionnalité ayant un impact plutôt que comme une surcharge, les cadres doivent prêter attention à l'état de la qualité et y investir, et les fonctions d'ingénierie doivent résister à traiter le nettoyage de code comme une « patate chaude ».

Ces défis de délégation sont aggravés par le fait que les méthodologies et les outils existants ne parviennent pas à résoudre le problème de la qualité du code dans son ensemble. L'utilisation de méthodologies d'intégration continue/livraison continue réduit l'impact d'un code de faible qualité, mais à moins que CI/CD ne soit basé sur une analyse de qualité approfondie et holistique, il ne peut pas anticiper et traiter efficacement la plupart des risques. Les équipes responsables des tests d'assurance qualité, de la sécurité des applications et de la conformité des licences travaillent en silos à l'aide d'outils conçus pour résoudre une seule partie du problème et n'évaluer que certaines des exigences non fonctionnelles ou fonctionnelles.

Tenir compte du rôle du chef de produit

La qualité du code source joue un rôle dans de nombreux dilemmes auxquels un chef de produit est confronté lors de la conception du produit et tout au long du cycle de vie du développement logiciel. La dette technique représente de lourds frais généraux. Il est plus difficile et plus coûteux d'ajouter et de modifier des fonctionnalités sur une base de code de faible qualité, et la prise en charge de la complexité du code existant nécessite des investissements importants en temps et en ressources qui pourraient autrement être consacrés au développement de nouveaux produits. Alors que les chefs de produit équilibrent en permanence les risques par rapport à la vitesse de mise sur le marché, ils doivent se poser des questions telles que :

• Dois-je utiliser une bibliothèque OSS (logiciel open source) ou créer des fonctionnalités à partir de rien ? Quelles licences et responsabilités potentielles sont associées aux bibliothèques sélectionnées ?
• Quelle pile technologique est la plus sûre ? Qu'est-ce qui garantit un cycle de développement rapide et peu coûteux ?
• Dois-je donner la priorité à la configurabilité de l'application (coût élevé/délai) ou implémenter des versions personnalisées (coût de maintenance élevé/manque d'évolutivité) ?
• Dans quelle mesure sera-t-il possible d'intégrer des produits numériques nouvellement acquis tout en maintenant une qualité de code élevée, en minimisant les risques et en maintenant les coûts d'ingénierie à un faible niveau ?

Les réponses à ces questions peuvent avoir un impact sérieux sur les résultats commerciaux et la propre réputation du chef de produit, mais les décisions sont souvent prises sur la base de l'intuition ou de l'expérience passée plutôt que sur une enquête rigoureuse et des mesures solides. Un processus approfondi d'évaluation de la qualité des logiciels fournit non seulement les données nécessaires à la prise de décision, mais aligne également les parties prenantes, renforce la confiance et contribue à une culture de transparence, dans laquelle les priorités sont claires et convenues.

Mettre en œuvre un processus en 7 étapes

Un processus complet d'évaluation de la qualité du code source aboutit à un diagnostic qui prend en compte l'ensemble complet des déterminations de la qualité plutôt que quelques symptômes isolés d'un problème plus vaste. La méthode en sept étapes présentée ci-dessous est conforme aux recommandations du CISQ pour l'amélioration des processus et vise à faciliter les objectifs suivants :

• Trouvez, mesurez et corrigez le problème près de sa cause première.
• Investissez intelligemment dans l'amélioration de la qualité des logiciels en vous basant sur des mesures de qualité globales.
• Attaquez-vous au problème en analysant l'ensemble complet de mesures et en identifiant les améliorations les meilleures et les plus rentables.
• Considérez le coût total d'un produit logiciel, y compris les coûts de possession, de maintenance et d'alignement des réglementations de licence/sécurité.
• Surveillez la qualité du code tout au long du SDLC pour éviter les mauvaises surprises.

1. Mappage du produit au code : retracer les fonctionnalités du produit jusqu'à leur base de code peut sembler une première étape évidente, mais étant donné la vitesse à laquelle la complexité du développement augmente, ce n'est pas nécessairement simple. Dans certaines situations, le code d'un produit est réparti entre plusieurs référentiels, tandis que dans d'autres, plusieurs produits partagent le même référentiel. L'identification des différents emplacements qui abritent des parties spécifiques du code d'un produit est nécessaire avant qu'une évaluation plus approfondie puisse avoir lieu.

2. Analyse de la pile technique : cette étape prend en compte les différents langages de programmation et outils de développement utilisés, le pourcentage de commentaires par fichier, le pourcentage de code généré automatiquement, le coût de développement moyen, etc.

Outils suggérés : horloge

Alternatives : Tokei, scc, sloccount

3. Analyse des versions : sur la base des résultats de cette partie de l'audit, qui consiste à identifier toutes les versions d'une base de code et à calculer les similitudes, les versions peuvent être fusionnées et les doublons éliminés. Cette étape peut être combinée à une analyse des bugspots (points chauds), qui identifie les parties de code délicates qui sont le plus fréquemment révisées et ont tendance à générer des coûts de maintenance plus élevés.

Outils suggérés : cloc, scc, sloccount

4. Examen automatisé du code : cette inspection examine le code à la recherche de défauts, de violations des pratiques de programmation et d'éléments à risque tels que les jetons codés en dur, les longues méthodes et les duplications. Le ou les outils sélectionnés pour ce processus dépendront des résultats de la pile technologique et des analyses de versions ci-dessus.

Outils suggérés : SonarQube, Codacy

Alternatives : RIPS, Veracode, Micro Focus, Parasoft et bien d'autres. Une autre option est Sourcegraph, une solution de recherche de code universelle.

5. Analyse de sécurité statique : cette étape, également connue sous le nom de test de sécurité statique des applications (SAST), explore et identifie les vulnérabilités potentielles de sécurité des applications. La majorité des outils disponibles analysent le code en fonction des problèmes de sécurité fréquemment identifiés par des organisations telles que OWASP et SANS.

Outils suggérés : WhiteSource, Snyk, Coverity

Alternatives : SonarQube, Reshift, Kiuwan, Veracode

6. Analyse des composants logiciels (SCA)/Analyse de la conformité des licences : cette revue consiste à identifier les bibliothèques open source liées directement ou indirectement au code, les licences qui protègent chacune de ces bibliothèques et les autorisations associées à chacune de ces licences.

Outils suggérés : Snyk, WhiteSource, Black Duck

Alternatives : FOSSA, Sonatype et autres

7. Analyse des risques commerciaux : cette dernière mesure consiste à consolider les informations recueillies lors des étapes précédentes afin de comprendre le plein impact de l'état de la qualité du code source sur l'entreprise. L'analyse doit aboutir à un rapport complet qui fournit aux parties prenantes, y compris les chefs de produit, les chefs de projet, les équipes d'ingénierie et les cadres supérieurs, les détails dont ils ont besoin pour peser les risques et prendre des décisions éclairées sur les produits.

Bien que les étapes précédentes de ce processus d'évaluation puissent être automatisées et facilitées via une large gamme de produits open source et commerciaux, il n'existe aucun outil existant qui prend en charge le processus complet en sept étapes ou l'agrégation de ses résultats. Étant donné que la compilation de ces données est une tâche fastidieuse et chronophage, elle est soit effectuée au hasard, soit complètement ignorée, ce qui peut compromettre le processus de développement. C'est à ce stade qu'un processus d'inspection approfondi des logiciels s'effondre souvent, ce qui fait de cette dernière étape sans doute la plus critique du processus d'évaluation.

Choisir les bons outils

Bien que la qualité des logiciels ait un impact sur le produit et donc sur les résultats commerciaux, la sélection des outils est généralement déléguée aux départements de développement et les résultats peuvent être difficiles à interpréter pour les non-développeurs. Les chefs de produit doivent être activement impliqués dans la sélection des outils qui garantissent un processus d'assurance qualité transparent et accessible. Bien que des outils spécifiques pour les différentes étapes de l'évaluation soient suggérés ci-dessus, il existe un certain nombre de considérations générales qui doivent être prises en compte dans tout processus de sélection d'outils :

• Pile technologique prise en charge : gardez à l'esprit que la majorité des offres disponibles ne prennent en charge qu'un petit ensemble d'outils de développement et peuvent entraîner des rapports partiels ou trompeurs.
• Simplicité d'installation : les outils dont les processus d'installation sont basés sur des scripts complexes peuvent nécessiter un investissement technique important.
• Rapports : la préférence doit être accordée aux outils qui exportent des rapports détaillés et bien structurés qui identifient les problèmes majeurs et fournissent des recommandations pour les correctifs.
• Intégration : Les outils doivent être sélectionnés pour une intégration facile avec les autres outils de développement et de gestion utilisés.
• Prix ​​: Les outils sont rarement accompagnés d'une liste de prix complète, il est donc important d'examiner attentivement l'investissement impliqué. Divers modèles de tarification prennent généralement en compte des éléments tels que l'effectif de l'équipe, la taille du code et les outils de développement impliqués.
• Déploiement : lorsque vous pesez sur site par rapport au déploiement dans le cloud, tenez compte de facteurs tels que la sécurité. Par exemple, si le produit évalué traite des données confidentielles ou sensibles, des outils sur site et des outils utilisant l'approche d'audit en aveugle (FOSSID) peuvent être préférables.

Continuer

Une fois les risques identifiés et analysés méthodiquement, les chefs de produit peuvent prendre des décisions réfléchies concernant la hiérarchisation et le tri des défauts avec plus de précision. Les équipes pourraient être restructurées et les ressources allouées pour résoudre les problèmes les plus émergents ou les plus répandus. Les "showstoppers" comme les violations de licence à haut risque prendraient le pas sur les défauts de moindre gravité, et l'accent serait davantage mis sur les activités qui contribuent à la réduction de la taille et de la complexité de la base de code.

Ce n'est pas un processus ponctuel, cependant. La mesure et la surveillance de la qualité des logiciels doivent se produire en continu tout au long du SDLC. L'évaluation complète en sept étapes doit être effectuée périodiquement, les efforts d'amélioration de la qualité commençant immédiatement après chaque analyse. Plus un nouveau point de risque est identifié rapidement, moins cher est le remède et plus les retombées sont limitées. Placer l'évaluation de la qualité du code source au cœur du processus de développement de produits permet de concentrer les équipes, d'aligner les parties prenantes, d'atténuer les risques et de donner au produit ses meilleures chances de succès. C'est l'affaire de chaque chef de produit.