Chez Uxopian Software, chaque nouvelle fonctionnalité est accompagnée de tests automatisés et manuels qui vérifient son bon fonctionnement avant même qu'elle n'arrive en production.
Notre démarche repose sur plusieurs centaines de tests automatisés ou manuels, combinés pour couvrir chaque brique de nos produits, de la ligne de code jusqu'à l'expérience de l'utilisateur final.
Ils s'assurent que chaque brique de notre application fonctionne correctement de manière isolée, directement sur la base de code.
Ils vérifient que ces briques fonctionnent bien ensemble une fois assemblées, y compris en mode déployé et interconnecté.
Développés avec le framework Playwright, ils couvrent les fonctionnalités critiques de chaque produit en simulant un utilisateur réel.
Une rigueur au service de votre stabilité. Cette approche nous permet de vous livrer un produit fiable et stable, et d'intervenir rapidement en cas de problème, avant qu'il ne vous impacte.
Cinq familles de tests complémentaires, exécutées à chaque livraison, pour couvrir aussi bien le bon fonctionnement que la sécurité et la performance de nos produits.
Nous combinons deux niveaux de vérification qui s'appuient sur des outils reconnus dans l'industrie : JUnit pour la partie Java et Vitest pour la partie React. Ces tests sont exécutés automatiquement à chaque modification de code, via notre pipeline d'intégration continue Jenkins.
Notre stratégie est fondée sur une analyse par les risques (Risk-Based Testing). La priorisation des scénarios croise trois critères : l'impact métier de la fonctionnalité, sa fréquence d'utilisation et le risque de régression associé. Ces tests simulent le comportement d'un utilisateur réel, de la connexion jusqu'à l'exécution d'actions métier.
Avant chaque publication, l'ensemble de notre code source est analysé grâce à l'outil Mend (analyse SAST). Il scanne notre base de code à la recherche de vulnérabilités connues (CVE) présentes dans les composants et bibliothèques que nous utilisons.
Nous avons développé notre propre outil de test de performance. Il compare chaque nouvelle version à la précédente afin de détecter immédiatement toute dégradation, et nous aide à identifier des axes d'amélioration pour optimiser en continu la vitesse et la réactivité de notre application.
Nous faisons régulièrement appel à un auditeur externe spécialisé, indépendant de nos équipes. La première phase, en boîte noire, teste notre système comme le ferait un attaquant réel, sans accès à notre documentation. La seconde, en boîte blanche, va plus loin : l'auditeur dispose d'éléments précis pour détecter des failles invisibles depuis l'extérieur.
Retrouvez nos analyses sur la qualité, la sécurité et la gestion documentaire, ainsi que l'ensemble de nos ressources téléchargeables.
Aucune version n'est validée tant que l'ensemble des contrôles n'est pas au vert. Voici, en synthèse, la campagne de qualification exécutée avant une version majeure.
Le dispositif de qualification s'adapte au type de livraison. Pour les versions mineures et les correctifs, le cycle est optimisé pour la rapidité de déploiement, sans jamais transiger sur la sécurité et la stabilité.
| Étape de qualification | Version majeure | Version mineure ou correctif |
|---|---|---|
| Vérification de démarrage & fonctions critiques | check_circleIncluse | check_circleIncluse |
| Tests de non-régression | check_circleIncluse | check_circleIncluse |
| Scans de vulnérabilités (Mend) | check_circleIncluse | check_circleIncluse |
| Tests exploratoires complémentaires | check_circleIncluse | removeNon requise |
| Tests de performance | check_circleIncluse | removeNon requise |
| Tests de pénétration | check_circleIncluse | removeNon requise |
Portée de cette politique. Elle s'applique à l'ensemble de notre socle applicatif standard. Elle ne couvre pas les personnalisations ou développements spécifiques réalisés dans le cadre de projets clients, ni les configurations d'infrastructure propres à chaque environnement, qui font l'objet de leurs propres processus de validation.
On a posé quelques questions à notre Head of QA, Elodie Godefroy. Du rôle crucial de son équipe avant chaque release jusqu'aux réalités du terrain, tout en passant par une métaphore culinaire assez unique, découvrez sa vision de la qualité logicielle et les coulisses de son métier au quotidien !
La QA, c'est le dernier maillon de la chaîne, le tampon final qui permet à l'Engineering de faire une release en étant serein. Mon équipe va toujours faire tout son possible pour allier rapidité et rigueur.
Le gros challenge de la QA est de garantir le bon fonctionnement des fonctionnalités principales, tout en délivrant le plus rapidement possible.
Ce n'est pas facile d'exécuter des centaines de tests manuellement tout en restant rigoureux. C'est un vrai métier de garder l'œil critique sur les évolutions et bugfixes, et penser aux impacts directs et indirects possibles. C'est le rôle de la QA de prendre ce recul que personne ayant la tête dans le guidon ne pourrait faire aussi bien.
J'avais une métaphore un peu bizarre qui m'était venue en tête. C'est comme une pièce montée : en QA, on va tester le plus important, à savoir les choux pour que ça tienne. Le caramel ne sera pas toujours testé car on n'a pas toujours le temps ou le délai pour, et ce sont des bugs mineurs.
Et les clients ont chacun leur crème, leur configuration : on ne peut pas contrôler les configurations individuelles de chaque client, et pourtant, de temps en temps, ça va chambouler toute la pièce montée sans qu'on ait la main dessus.
Découvrez comment la suite Uxopian Software sécurise et fiabilise vos processus documentaires les plus critiques.