Délivrer du logiciel au high-standard est difficile. Les entreprises doivent accélérer leur rythme et la qualité de leurs livraisons de logiciel pour rester compétitives et développer des offres numériques à valeur ajoutée.

Le Quality Engineering est le paradigme permettant aux entreprises de répondre à ces défis, en contraignant l’ensemble du système aux exigences de qualité. Dans cette interview, nous prenons du recul pour avoir une vue d’ensemble de la qualité et des tests des logiciels.

À partir de son expérience dans l’industrie, Lalitkumar partage un SWOT sur la qualité logicielle ainsi qu’une méthodologie qu’il a construite au fil des ans pour livrer plus rapidement et avec qualité, le « Quality-Conscious Software Delivery » (QCSD).

Nous couvrons les points suivants :

• La typologie principale des problèmes rencontrés avec la Qualité
• Les forces et les faiblesses de la Qualité et des Tests Logiciels
• Les opportunités de mise en œuvre du Quality-Conscious Software Delivery
• Les menaces pour l’évolution de la Qualité dans les organisations
• Les pratiques efficaces pour l’animation de la Qualité
• Feedback sur la Définition du Quality Engineering

Rejoignez la QE Unit pour accéder au contenu exclusif et régulier de la communauté.

À propos de Lalitkumar Bhamare

Lalit a passé 3 ans chez Barclays Investment Bank en tant qu’analyste de test principal et a dirigé leur L&D CoP (pour les tests). Il a été principalement responsable du déploiement des dernières pratiques de test chez Barclays, dans le cadre d’Innov8 (un programme à l’échelle de l’organisation).

Dans le cadre de la relation TCS-Cisco, il a également travaillé en tant que fondateur et directeur du Technology Excellence Group for Testers. Il a travaillé en tant que consultant à la demande pour diverses équipes de projet au sein du groupe Barclays, en particulier pour mettre en œuvre le CDT dans des projets de test.

Lalit est convaincu que sa connexion avec la communauté mondiale des tests et ses expériences de bénévolat l’aident à contribuer aux organisations pour lesquelles il travaille. Cela l’a aidé à contribuer à la construction d’une culture de test sur son lieu de travail.

Il est un testeur qualifié, test manager, formateur, coach et consultant à la demande, tous regroupés dans un seul profil. Son talent créatif (qui reflète ses activités) est une compétence supplémentaire qui l’aide à communiquer efficacement ses idées.

Vous pouvez le suivre sur Twitter @Lalitbhamare et Linkedin.

Antoine : Peux-tu commencer par te présenter ?

Je travaille en Allemagne pour XING, la plateforme de réseau pour les professionnels. J’édite le magazin Tea Time for Testers depuis 10 ans. Je suis également directeur de l’ Association for Software Testing (AST), tout en aidant quelques startups de test. Je publie également le rapport sur le State of Testing. Toute ma carrière professionnelle est dédiée à la qualité logicielle et aux tests logiciels.

Antoine : D’après ton expérience dans l’industrie, quelles principales typologies de problèmes rencontres-tu ?

Un problème majeur est la compréhension de la Qualité en elle-même. Elle est souvent considérée comme allant de soi ou comme une phase particulière des projets. Il est très important de préciser que la qualité ne peut pas être considérée comme un élément secondaire. La qualité doit faire partie du produit avec la conscience de la qualité et l’état d’esprit de l’équipe, peu importe à quel stade de la livraison du logiciel vous vous trouvez.

Je pense que ce problème est répandu. Je le rencontre avec différents rôles dans le logiciel : développeur, testeurs, produit, leadership, etc. 

Antoine : Cela veut probablement dire que la communication est une compétence essentielle en tant qu’acteur de la Qualité ?

En effet, nous avons une réelle responsabilité d’articulation et de communication de la valeur des tests et de la qualité, qui sont des choses différentes. Nous devons aider les dirigeants à comprendre les implications et à prendre des décisions dans ces domaines. Il existe une relation indirecte entre eux et le produit que nous livrerons à la fin. Si vous vous souciez de la qualité, vous devez exprimer correctement la valeur des tests.

Antoine : De ton point de vue, quelles sont les forces et faiblesses de la Qualité ?

Je pense que la force est de reconnaître qu’il y a un problème. La plupart du temps, les acteurs au sein d’une organisation ne se rendent même pas compte qu’il y en a un. Par conséquent, ils ne savent pas quoi résoudre et n’agissent pas sur les bonnes priorités. Ils peuvent perdre un temps précieux à simplement corriger les symptômes au lieu des causes racines. Une fois le bon problème identifié, nous pouvons passer à la définition des plans d’actions.

En termes de faiblesses, le manque de compréhension partagée et de responsabilité pour la qualité. Le manque de responsabilité est en partie la conséquence d’une compréhension peu claire. On entend régulièrement parler d’une responsabilité de toute l’équipe en matière de qualité, mais ce n’est toujours pas un standard dans la réalité. Le monde de la qualité et du test se développent maintenant plus rapidement, mais nous avons du retard.

Cette notion selon laquelle les responsabilités en matière de qualité et de test incombent aux testeurs est fausse. Une approche globale de la qualité est nécessaire, en cascade des responsabilités spécifiques à partir d’une culture qualité commune, y compris les parties prenantes. Les améliorations technologiques sont inutiles tant que cette compréhension et cette responsabilité partagées de la qualité n’ont pas été abordées.

Antoine : As-tu rencontré des contextes où ces faiblesses sont surmontées ? 

J’en ai fait la promotion avec l’atelier Whole Team Quality et le framework Quality-Conscious Software Delivery (QCSD). Je crois qu’il est possible pour chaque membre de l’équipe de faire son travail avec plus de qualité. En fin de compte, les changements cumulés et la collaboration font une énorme différence.

Nous n’avons pas vraiment besoin d’outils sophistiqués ou de méthodes compliquées. Les gens ont juste besoin de savoir comment ils peuvent contribuer à une définition partagée de la qualité à travers leur travail. Nous n’avons pas à faire beaucoup de « travail supplémentaire » pour la qualité. Ce n’est pas un supplément. C’est une exigence dans le travail que nous devons faire, depuis le début.

Antoine : Quelles opportunités identifies-tu pour mettre en œuvre de ce paradigme de Qualité ?

Une condition préalable est que les gens soient prêts à faire un effort et ouverts à faire les choses différemment. De nombreuses opportunités sont disponibles sans nécessiter plus de ressources ou d’outillage. La majorité d’entre elles sont accessibles avec ouverture et formation. Au final, on évitera beaucoup de rustines et de rework. C’est une question d’état d’esprit.

Antoine : Au contraire, quelles menaces identifies-tu ?

Je voudrais mentionner le message partagé dans l’article « We need to talk about testing » par Daniel Terhorst-North, le créateur de Behaviour Driven Development (BDD). Il reconnaît que nous devons parler des tests de logiciels car ils ont été laissés à l’écart dans l’industrie du logiciel au cours des 10 dernières années. Je crois que cela a été un problème central dans notre industrie et doit changer.

Il y a encore une majorité de professionnels qui ne savent pas exactement ce que sont la qualité et les tests. Un écueil récurrent est de considérer les tests comme « tout automatiser ». « faire tout via des tests unitaires ». En appliquant ce raisonnement, des raccourcis sont pris comme « nous n’avons pas besoin de testeurs » ou « nous n’avons pas besoin de personnes affectées à la qualité ». Ce manque culturel, cette ignorance et cette méconnaissance sont les menaces les plus importantes pour la qualité logicielle.

« Il y a un réel besoin de gestion, de changement et d’évolution de la perception de la qualité pour tous les acteurs. »

Lalitkumar Bhamare

Antoine : Quelles pratiques as-tu trouvé efficace pour faire de la Qualité ?

La première est de ne pas dire aux gens quoi faire. Au lieu de cela, montrez et partagez avec eux comment vous faites les choses. Ils saisiront ainsi plus rapidement votre raisonnement, vos idées et vos attentes. Vous ne pouvez pas toujours être la personne qui définit et coordonne les actions spécifiques de l’équipe. Vous devez diriger d’une manière qui permet aux gens de conduire eux-mêmes des changements pertinents. Vous devez être avec eux, vous asseoir et agir pour qu’ils réussissent leurs objectifs.

C’est ma plus grande leçon jusqu’à présent.

Antoine : Intéressant, cela signifie qu’un état d’esprit d’amélioration continue, d’ouverture et d’apprentissage est essentiel pour construire une équipe ? 

Oui, car l’échec est aussi un critère essentiel. Les gens doivent accepter l’échec sans prendre les choses pour eux-mêmes. Dans certains cas, vous devez laisser les gens essayer d’apprendre de leurs échecs. Ils apprendront à faire mieux non seulement dans ce cas, mais dans d’autres situations plus importantes. C’est une façon de les aider à réussir et d’apprendre à changer la façon dont ils effectuent certaines activités.

Antoine : Quelle serait la clé de ta vision de la Qualité, de la QCSD et des priorités que nous avons identifiées ?

Nous ne devons pas nous concentrer sur la Qualité uniquement en termes de produit ; ce n’est qu’une notion de qualité qui entre en ligne de compte. D’une démarche globale à la qualité, il faut considérer les personnes, le projet, et leurs interactions. Il existe une relation profonde entre ces 3 axes, qui s’affectent les uns les autres. Nous devons améliorer les 3 aspects du produit, des personnes et du projet pour réussir dans la livraison de logiciels.

Antoine : Cela ressemble à une tendance des pratiques d’ingénierie, pas seulement logicielles, à trop se concentrer sur l’aspect produit. Nous pouvons facilement perdre de vue la perspective globale des utilisateurs, des autres acteurs et des activités. 

Je profite de cet entretien pour avoir ton retour sur une définition Quality Engineering que nous construisons au sein de QE Unit. « Le Quality Engineering contraint chaque activité du cycle de vie du logiciel à offrir en continu une expérience à valeur ajoutée pour ses utilisateurs.«

Qu’en penses-tu ? Y trouves-tu du sens et des liens concrets avec ton expérience, travail et lecture de l’écosystème ?

Cela résonne beaucoup. Je crois que les utilisateurs ne sont pas les seuls concernés; il y a aussi d’autres acteurs que j’identifierais comme les parties prenantes. Je le reformulerais probablement de cette façon car ils doivent définir et aligner la valeur par exemple. Belle initiative et j’attends le livre avec impatience.

Antoine : Pour terminer, y a-t-il un contenu que tu voudrais partager ?

J’ai écrit un blog sur le Quality Conscious Software Delivery thème, avec divers articles et contenus autour des ateliers et des conférences. J’aide les gens à comprendre les concepts et à partager comment mettre en œuvre le cadre dans leur contexte. 

Antoine : Merci beaucoup Lalit, c’était un plaisir de t’ avoir dans cette interview. Nous attendons avec impatience la prochaine édition trimestrielle du Tea Time for Testers 🙂 

Les principaux points à retenir à travers le Quality Engineering Framework, MAMOS:

• Les Methods doivent aligner la Qualité du Produit, des Personnes et du Projet
• L’ Architecture de la Qualité avec la technologie n’est pas forcément la priorité
• L’ Organization de la qualité nécessite est une “whole team approach to quality”
• Le Management doit coacher et animer les équipes sur la création de valeur globale
• Les Skills d’ouverture, de leadership et d’amélioration continue sont essentiels