Nous voyons émerger de plus en plus de postes d’ingénieur d’assurance qualité (QAE) ou d’ingénieur qualité (QE).

L’industrie du logiciel avait plutôt eu tendance à cloisonner divers rôles de QA ou de DevOps.

Cela m’a amené à me demander ce que l’on attend de ce nouveau rôle de QE dans différentes organisations.

J’avais parfois le sentiment que les positions étaient simplement du marketing de carrières, en ajoutant uniquement «ingénieur» à un rôle d’assurance qualité existant.

En regardant différents postes, le QE est en fait un rôle spécifique que les entreprises recherchent.

Un ingénieur qualité peut être considéré comme un caméléon pour ses divers ensembles de compétences exigés par d’autres disciplines.

J’ai décidé de partager avec vous ses différentes facettes en clarifiant d’abord le pourquoi.

Pourquoi aurions-nous besoin d’un ingénieur qualité ?

Nous pouvons réfléchir d’une autre manière, que se passe-t-il sans un QE ?

Nous avons des rôles traditionnels tels que Product Owner, QA, Software Engineer, DevOps travaillant ensemble sur un produit, partiellement pour entièrement dédiés en termes de disponibilité.

C’est une réalité pour la plupart des organisations qui investissent dans le cycle de vie de leurs produits et logiciels.

Les ingénieurs qualité font sens pour passer à une étape supérieure de collaboration, d’automatisation et de performance d’équipes pluri-disciplinaires.

Pourquoi engager et organiser trois rôles si vous pouvez en avoir un seul ?

Une des raisons pourrait être que vous souhaitiez une continuité d’activité en cas d’absence ou que vous ne trouviez pas ce profil hybride.

Combinant l’ensemble des compétences de divers postes, ils doivent idéalement être dotés de bonnes bases et d’une expérience en assurance qualité, complétées par d’autres que nous verrons par la suite.

La facette de l’assurance qualité

À ses racines, le QE a besoin d’une perspective, d’un état d’esprit et de compétences en matière d’assurance qualité.

C’est en effet là qu’il doit avoir obtenu une vision transversale du développement produit, à partir de l’analyse, des exigences, des spécifications, des tests et de la gestion des défauts.

La connaissance de la découverte et des techniques de test permet également d’avoir une vision holistique des mécanismes de vérification possibles qui peuvent être utilisés, tout en sécurisant la stratégie de test et les plans d’assurance qualité.

Sa valeur principale est de traduire les exigences de l’entreprise, du client et du produit dans le produit concret qui sera construit, en s’assurant que la réalité est adaptée aux vrais besoins.

Nous pouvons résumer les principales responsabilités dans les points suivants :

• Examiner les exigences, les spécifications et les documents de conception technique pour fournir des commentaires pertinents et significatifs;
• Créer des plans de test et des cas de test détaillés, complets et bien structurés;
• Estimer, prioriser, planifier et coordonner les activités de test;
• Identifier, enregistrer, documenter minutieusement et suivre les bogues;
• Développer et appliquer des processus de test pour les produits nouveaux et existants afin de répondre aux besoins des clients;
• Suivez les mesures d’assurance qualité, telles que les densités de défauts et le nombre de défauts ouverts.

La facette de l’automatisation de test

L’assurance qualité et l’automatisation des tests ont des caractéristiques communes, mais diffèrent encore sur des aspects particuliers.

L’accent habituel sur l’automatisation nous permet de développer de solides compétences et une expertise de test dans les différents environnements techniques, tels que le web, le mobile, les api, l’IoT,…

Ils nécessitent une capacité importante de conception de tests automatisés fiables, réutilisables et maintenables qu’ils peuvent implémenter (espérons-le configurés en low-code).

Le cœur de l’assurance qualité est d’aider à savoir ce qui doit être automatisé ou non, à quel niveau d’effort et quelles techniques de test (par exemple, en white-box ou black-box).

Les attentes de la facette d’automatisation des tests sont:

• Concevoir, développer et exécuter des tests automatisés, en utilisant les outils nécessaires;
• Garantir leurs exigences de fiabilité, de réutilisation, de maintenabilité et de performance;
• Automatiser les tests d’API, d’interface utilisateur et d’intégration de système pour valider les exigences fonctionnelles et non fonctionnelles;
• Effectuer des tests de régression approfondis lorsque les bogues sont résolus;
• Analyser la couverture de l’automatisation pour trouver les domaines sur lesquels se concentrer.

La facette de l’enabler de la qualité

Un ingénieur de la qualité a besoin de compétences en communication pour influencer, aider et soutenir les équipes dans le processus d’inclusion de la qualité.

En fonction du produit et des priorités de l’équipe, un QE peut créer, partager et maintenir des outils dont les utilisateurs sont directement l’équipe.

Ils peuvent également agir en tant qu’ambassadeur de la qualité, partageant régulièrement dans le format de discussions ouvertes des informations sur la concurrence, les références et la façon dont l’industrie applique la qualité.

Comme un architecte, ils peuvent également suggérer des améliorations structurelles de produits à partir de leur vision de bout en bout des exigences de qualité des produits et de l’ingénierie logicielle.

Les responsabilités de la facette de l’enabler de qualité peuvent être énumérées comme suit:

• Créer des services qui surveillent les pratiques de code à risque et fournir des informations au développeur avant d’intégrer les changements au référentiel;
• Convaincre les équipes d’architecturer leur code d’une manière différente pour le rendre plus testable, maintenable;
• Travailler quotidiennement avec les équipes produits, développements et opérations pour promouvoir une amélioration continue et un esprit de qualité dans le développement de produits.

La facette de peer de qualité

Avec plus de proximité, de contact et de partage avec les membres de l’équipe, ils peuvent agir en tant que pairs évaluateurs de la qualité.

Ils peuvent intervenir à différentes étapes du développement du produit, ce qui fait une forte différence dans l’alignement transverse qu’ils peuvent fournir.

Par exemple, ils peuvent utiliser leurs compétences en ingénierie des exigences issues de la vision initiale de l’entreprise et du produit, en posant des questions clés tôt.

Ils peuvent ensuite suivre les exigences et leurs traductions tout au long du cycle de vie: spécifications fonctionnelles, spécifications techniques, codage, tests, release.

L’ensemble de compétences hybrides leur permet d’exécuter des techniques de test spécifiques telles que l’exploration et aider au debugging avec l’équipe.

Les responsabilités suivantes sont essentielles, les mécanismes de revue entre pairs étant parmi les plus bénéfiques pour améliorer la qualité:

• Assurer la liaison avec les équipes internes (par exemple, les développeurs et les product owner) pour identifier les exigences du système;
• Travailler avec les équipes internes, dépanner et déboguer les problèmes en production et dans d’autres environnements;
• S’associer aux développeurs pour les former aux techniques de test efficaces (y compris les tests exploratoires).

La facette DevOps

Cette facette vise à intégrer la qualité au cycle de vie du développement logiciel (SDLC) en tirant parti de l’automatisation.

Nous trouverons la mise en œuvre de mécanismes CI/CD traditionnels qui intégreront très probablement des quality gates, issues de leur expérience en assurance qualité.

Leur double vision de la qualité et de l’ingénierie logicielle leur permet d’évaluer directement la stratégie de branching entre les différents livrables de développement et de test.

Complémentaire, leur facette d’automatisation des tests fait réfléchir à la gestion des données de test et de la gestion de l’environnement de test (TDM & TEM) dans la problématique de testabilité.

Ils doivent également avoir le réflexe de penser aux opérations, à la qualité et à la réduction des risques. Par exemple, en concevant le produit pour permettre des A/B tests, du déploiement progressif, des features-flags.

Sa facette DevOps contient les principales responsabilités suivantes:

• Maintenir et améliorer les processus et la configuration CI/CD;
• Analyser et compiler les directives de configuration de déploiement basées sur les performances, la stabilité et d’autres activités de test de bout en bout;
• Maintenir et fournir les environnements nécessaires au développement (environnements de test d’intégration et d’acceptation des utilisateurs), incluant la gestion des données de test;
• Améliorer la pipeline de construction du logiciel avec le bon environnement et intégration pour tester les changements.

La facette Opérations et SRE

Cette dernière facette est un sous-ensemble des opérations et SRE axé sur l’assurance qualité.

Ils ne doivent pas forcément gérer l’infrastructure et la gestion des opérations, mais ils ont sûrement besoin de savoir comment le produit a été construit et est opéré.

Si les exigences de disponibilité de l’expérience client sont de 99,99%, ils doivent vérifier dans les spécifications techniques la traduction en configuration d’infrastructure, comme les déploiements en multi-region.

Même s’il ne s’agissait pas d’une exigence déclarée, la disponibilité du service et d’autres métriques du rapport Accelerate doivent être mesurées (lead-time for change, MTTA, MTTR, CFR).

Nous pourrions voir ces responsabilités comme celles d’un QA:

• Analyser les incidents pour identifier leur cause racine, gérer les problèmes pour éviter les réapparitions future;
• Fournir une visibilité des résultats des tests de supervision, performance et de sécurité par rapport aux exigences du produit, piloté par la valeur et le risque.

Les facettes du QE doivent être attribuées au sein de l’organisation

Nous comprenons qu’un ingénieur qualité est un profil hybride complet.

Un rôle de QE consiste à transversaliser, implémenter et améliorer la qualité et collaboration des produits de bout en bout.

Antoine Craske

Il peut être difficile de trouver de tels profils. Son avenir pourrait être davantage la formation des autres profils pour créer ce mix de compétences.

Les compétences mentionnées peuvent prendre des années à acquérir et plus essentiellement à pratiquer dans un ensemble différent d’environnements pour être suffisamment solides.

Des organisations horizontalisées dites flat, cloud-native, modernes et capables d’attirer les meilleurs talents, peuvent probablement embaucher directement des ingénieurs QE.

Pour d’autres organisations, le chemin de la composition des différentes responsabilités à travers différents rôles peut être la première étape: un ardent défenseur de la QA, un QA devenant un QAE axé sur l’automatisation, un ingénieur DevOps.

De mon point de vue, le point le plus important est d’avoir les différentes responsabilités définies, mises en œuvre et améliorées dans les organisations.

Avoir une, deux ou trois personnes qui composent ces compétences, avec une composition différente par équipe, est un critère secondaire. Maintenir un alignement transverse est plus prioritaire avec des communautés de pratique par exemple.

Quoi qu’il en soit, même si vous trouvez un très bon QE, vous aurez besoin d’un autre pour éviter un point de défaillance unique (SPOF) dans votre organisation.

Votre conception organisationnelle et votre continuité d’activité est également une question de qualité, n’est-ce pas?

Références

https://cloudybt.medium.com/what-does-a-software-quality-engineer-do-eb7b4c9a7f95

https://medium.com/slalom-build/quality-engineer-learning-roadmap-fddfcb77409e

https://world.hey.com/joaoqalves/on-hiring-qa-engineers-75dfa472

https://www.smartrecruiters.com/GuidanceSoftwareInc/80602474-software-quality-assurance-engineer