Assurance qualité en informatique – bien plus que des tests

Les tests en informatique ont de nombreuses significations et approches. Selon le cas d'usage, le paysage système et les exigences, différentes méthodes sont utilisées. L'objectif réel reste cependant toujours le même : garantir la qualité d'un produit pour l'utilisateur final.

Cet objectif peut parfois être perdu de vue dans des projets complexes. Les raisons sont nombreuses :

• Les équipes ne sécurisent que leurs propres systèmes et non l'ensemble du flux métier
• Processus QA absents ou faibles
• Trop peu ou aucune automatisation des tests
• Manque de communication entre les parties prenantes
• Exigences floues ou phases d'hypercare absentes après des releases importantes
• Processus trop rigides ou mal adaptés
• Monitoring et alerting manquants
• Tests unitaires et d'intégration insuffisants
• Complexité système élevée
• Perte de savoir-faire due aux changements de personnel
• Planification manquante des refactorisations
• Processus ou hypothèses obsolètes qui ne sont plus remis en question
• Trop grande distance entre les équipes techniques et le produit final réel

Au cours de ma carrière, j'ai occupé différents rôles et ainsi découvert différentes perspectives sur la qualité et le développement logiciel. Cela m'est devenu de plus en plus clair : la qualité ne naît pas seulement à la fin d'un projet par des tests. Elle naît d'une bonne communication, d'exigences claires, de processus rigoureux, de stabilité technique et d'une compréhension commune du produit global.

Le point de vue du testeur

J'ai travaillé dans plusieurs domaines :

1. Conseil SEO technique
2. Développement logiciel avec JavaScript et TypeScript
3. Gestion des tests et de la validation dans le domaine automobile
4. Développement backend avec Java et Spring Boot

Toutes ces étapes avaient quelque chose en commun : des exigences de qualité élevées.

Le passage du développeur au domaine des tests et de la validation dans un projet automobile dans l'environnement du BMW Crowd Data Collector a été particulièrement passionnant pour moi. Là-bas, j'ai pu relier les deux mondes : développement et assurance qualité.

Alors qu'un collègue effectuait les tests directement sur le véhicule ou sur le banc d'essai, je me concentrais sur :

• L'analyse des logs DLT et des données système
• La création et la pré-analyse de tickets de bugs
• L'analyse et la validation des exigences
• L'analyse de cohérence des données et des erreurs
• Les propositions de solutions pour les équipes de développement
• La coordination entre les différentes parties prenantes

Les outils utilisés comprenaient notamment :

• DLT Viewer
• Kibana
• Jira
• Confluence
• Analyses de logs et de données
• Documentation et processus de ticketing

C'est précisément dans de tels projets qu'il devient évident que les tests signifient bien plus que la simple exécution de cas de test. Un bon testeur n'essaie pas seulement de trouver des erreurs, mais aussi de comprendre :

• Pourquoi un problème survient-il ?
• Quels impacts a-t-il sur les autres systèmes ?
• Une exigence est-elle peut-être manquante ?
• L'architecture est-elle compréhensible ?
• Existe-t-il des risques pour la performance ou la stabilité ?

Planification de scénarios de test

Une partie importante de l'assurance qualité est l'examen structuré de différents scénarios :

• Quels sont les cas standards attendus ?
• Quels cas limites pourraient survenir ?
• Comment se comporte la gestion des erreurs ?
• Quelle est l'efficacité du système ?
• Quelles exigences réglementaires comme RGPD/GDPR doivent être prises en compte ?
• Comment le système réagit-il sous charge ou en cas de dépendances instables ?

Plus les systèmes deviennent complexes, plus il devient important de comprendre non seulement les fonctions individuelles, mais l'interaction de tous les composants.

La qualité comme objectif commun

Pour moi, la qualité n'est pas une tâche isolée d'une seule équipe. Elle naît de la collaboration entre le développement, les tests, l'architecture, la responsabilité produit et les parties prenantes.

Un bon logiciel naît rarement par hasard. Il nécessite :

• une communication ouverte,
• des responsabilités claires,
• une curiosité technique,
• des solutions pragmatiques,
• et la volonté d'améliorer continuellement les systèmes.

Dans les projets informatiques modernes, il ne suffit souvent pas de livrer simplement du « code fonctionnel ». Les systèmes doivent rester maintenables, compréhensibles et stables à long terme — particulièrement lorsque de nombreuses équipes, services et dépendances externes collaborent.

C'est pourquoi je ne vois pas l'assurance qualité comme un frein au développement, mais comme une composante importante du développement logiciel durable.