softify.pro Flow — Testé par COCO

Control. Clarity. Flow.

Tout produit logiciel sérieux finit par développer un second produit derrière le produit.

Les clients ne le verront peut-être jamais. Les visiteurs ne sauront peut-être jamais qu'il existe. Mais les administrateurs, les opérateurs et les développeurs en dépendent chaque jour.

Pour softify.pro Flow, cette application s'appelle Administration — la console opérationnelle responsable de la gestion des utilisateurs, des rôles, des niveaux d'accès, des états d'authentification, des environnements de base de données et des autres configurations qui gardent un déploiement de Flow sous contrôle.

Son écran de connexion porte trois mots :
Control. Clarity. Flow.

Ils ont été choisis à l'origine pour décrire l'expérience que nous voulions que les administrateurs vivent en exploitant le système.

Mais ils décrivent aussi, étonnamment bien, la façon dont nous pensons que les logiciels devraient être testés.

Cela a fait de softify.pro Flow — Administration un candidat évident pour un test COCO en conditions réelles.
Pas une démonstration de laboratoire.
Pas une collection de boutons isolés préparés spécifiquement pour une démo d'IA.
Une véritable application de bureau multiplateforme avec une logique applicative réelle, plusieurs fenêtres, plusieurs bases de données, authentification, permissions, localisation, et suffisamment d'état pour rendre des régressions apparemment mineures difficiles à repérer manuellement.

Pour la démonstration publique présentée ici, COCO a travaillé exclusivement avec des données de démonstration générées. L'application était sous licence pour l'entreprise fictive Presentation GmbH, et aucune information client de production, aucun identifiant ni aucune donnée personnelle n'a été utilisé.

L'objectif était simple :
laisser COCO aborder l'application comme le ferait un testeur et déterminer si l'ensemble du flux de travail administratif se comporte toujours comme le logiciel le prétend.

The Challenge

À première vue, tester une application d'administration semble simple.

L'ouvrir.
Se connecter.
Cliquer à travers plusieurs fenêtres.
Vérifier que tout semble correct.

Cette hypothèse change rapidement à mesure que l'application grandit.

softify.pro Flow — Administration n'est pas un simple formulaire statique. C'est un ensemble de vues opérationnelles interconnectées à l'intérieur d'une seule coquille applicative.

Entre autres choses, un administrateur peut travailler avec :

• des comptes utilisateurs
• des rôles et niveaux d'accès
• des informations d'authentification
• l'état de l'authentification à deux facteurs
• des informations sur le système d'exploitation
• des informations réseau et IP
• la configuration de la base de données
• des options de tri et d'affichage
• la sélection de langue en direct
• des informations d'application et de licence

L'interface prend actuellement en charge onze langues. L'application fonctionne également avec MySQL et PostgreSQL comme bases de données. Prise individuellement, aucune de ces fonctionnalités ne représente un problème de test inhabituel.

La difficulté vient de leurs combinaisons.
Un tableau d'utilisateurs peut fonctionner correctement en anglais mais afficher un nom de colonne obsolète en croate.
Le tri peut fonctionner correctement connecté à MySQL mais se comporter différemment après le passage à PostgreSQL.

Un changement de langue peut mettre à jour la plupart des éléments de l'interface tout en laissant un message d'état non traduit. L'application peut changer de base de données avec succès tout en conservant des informations obsolètes de la connexion précédente. Une nouvelle version peut introduire une fonctionnalité alors que la fenêtre « À propos » décrit encore la précédente. Le programme n'a pas besoin de planter pour que l'une de ces situations soit une régression. En fait, certains des défauts logiciels les plus gênants sont précisément ceux où tout semble fonctionner.

L'application démarre.
La fenêtre s'ouvre.
Le bouton répond.
Mais quelque chose en dessous n'est plus tout à fait correct.
C'est pourquoi les tests de régression répétitifs comptent.

Et c'est aussi exactement le type de travail pour lequel les humains deviennent de plus en plus mauvais après avoir répété la même séquence des dizaines de fois.

Why Manual Testing Becomes Expensive

Tester quelque chose une fois est facile.
Le tester de manière fiable après chaque version pertinente est différent.

Considérez seulement trois dimensions : 11 langues d'interface × 2 bases de données × de multiples flux de travail applicatifs.

Le nombre de combinaisons croît rapidement.
Ajoutez différents rôles utilisateurs, états d'authentification, comportements de tri, changements de configuration et environnements d'exploitation, et la matrice de test devient trop grande pour être traitée comme une simple checklist manuelle occasionnelle.

C'est là que les tests de régression commencent souvent à s'éroder.
Pas délibérément.
Une échéance de livraison se rapproche.
Quelqu'un se souvient que l'application a été testée la semaine dernière.
Un développeur vérifie rapidement l'écran le plus important.

L'allemand fonctionne.
L'anglais fonctionne.
MySQL fonctionne.
L'hypothèse devient :
« Le reste va probablement bien. »

C'est généralement le cas.
Jusqu'à la version où ce ne l'est pas.
COCO existe en partie pour retirer cette hypothèse du processus.

What COCO Actually Did

COCO a démarré softify.pro Flow — Administration à partir d'un état applicatif froid, sans s'appuyer sur un écran préparé à l'avance ni un flux de travail positionné manuellement.

La première interaction a été la même que celle présentée à un administrateur humain : la fenêtre de connexion.

COCO a identifié l'interface d'authentification contenant :

• le nom d'utilisateur
• le mot de passe
• le code d'authentification à deux facteurs

et la ligne juste en dessous de l'identité softify.pro Flow :
Control. Clarity. Flow.

À partir de là, COCO a poursuivi à travers une session de régression définie. Il ne s'agissait pas simplement de déterminer si l'application pouvait être ouverte.

Il s'agissait de vérifier si l'état de l'application restait cohérent en interne pendant que COCO interagissait avec elle.

Authentication Is Only the Beginning

Tester la connexion est l'un des candidats les plus évidents à l'automatisation, mais une authentification réussie à elle seule en dit très peu sur le reste d'une application d'administration.

Une fois à l'intérieur, COCO est passé dans l'environnement opérationnel réel. Il a inspecté l'interface d'administration des utilisateurs et vérifié que les informations attendues étaient présentes.

Cela incluait des données telles que :

• les noms d'utilisateurs
• les mots de passe masqués
• les indicateurs 2FA
• les rôles assignés
• les informations sur le système d'exploitation
• les adresses IP

COCO a ensuite interagi avec le tableau plutôt que de simplement l'observer.
La liste des utilisateurs a été triée par nom d'utilisateur.
L'ordre résultant a été inspecté.
Le point important n'était pas de savoir si cliquer sur l'en-tête de colonne produisait un changement visible.

COCO a vérifié que l'état résultant du tableau correspondait à l'opération demandée.

Cette distinction compte.
Un test fonctionnel demande :
« Le bouton a-t-il répondu ? »

Un test de régression utile demande :
« L'application s'est-elle retrouvée dans l'état correct ? »

Testing the Database Boundary

softify.pro Flow prend en charge plus d'une base de données.

Cela fait du changement de base de données une frontière de régression particulièrement importante.
COCO a fait passer la base de données active de MySQL à PostgreSQL.

Après le changement, il a de nouveau inspecté les informations utilisateur.
Le test cherchait plus qu'une connexion réussie.
Il vérifiait si l'application continuait à présenter les enregistrements attendus et si les informations affichées via l'interface restaient cohérentes.

COCO est ensuite revenu en arrière.

Ce type de transition est facile à sous-estimer.
L'interface utilisateur peut rester visuellement identique alors que la couche de stockage sous-jacente change complètement.
Du point de vue d'un administrateur, cette transition devrait sembler presque banale.
Les mêmes utilisateurs devraient rester compréhensibles.
Les mêmes rôles devraient continuer à avoir du sens.

Le même comportement d'interface devrait toujours s'appliquer.

Cette continuité apparemment sans incident est exactement ce qui doit être prouvé.

Eleven Languages, One Application State

La localisation est un autre domaine où les tests superficiels sont particulièrement dangereux.

Il est relativement facile de vérifier qu'une application peut démarrer dans une autre langue.
Il est beaucoup plus précieux de vérifier ce qui se passe lorsque la langue change alors que l'application est déjà en cours d'exécution et conserve un état.

COCO a changé la langue de l'interface en direct.

La session incluait des transitions entre des langues telles que :
Allemand → Anglais → Croate
tandis que la vue d'administration restait active.

COCO a observé si les éléments de l'interface changeaient correctement sur place :

• en-têtes de tableau
• contrôles
• boutons
• étiquettes
• messages d'état

Le tableau sous-jacent et l'état de l'application devaient également survivre à cette transition.
Cela importe car un logiciel multilingue est fait de bien plus que des chaînes traduites.
Les changements de langue peuvent révéler :

• des ressources oubliées
• des étiquettes obsolètes
• des problèmes de mise en page
• des messages d'état non traduits
• des problèmes d'encodage
• des réinitialisations d'état
• des problèmes de recréation de contrôles

Une fenêtre qui paraît correcte lorsqu'elle est démarrée directement en croate peut néanmoins se comporter de manière incorrecte lorsque l'utilisateur passe de l'allemand au croate au cours d'une session active.

C'est la différence entre vérifier une capture d'écran et tester un flux de travail.

Restoring Application State

COCO a ensuite restauré la configuration de tri par défaut de l'application.

Là encore, le test ne s'est pas terminé avec le clic lui-même.

L'ordre résultant et la confirmation présentée via la zone de statut de l'application ont été évalués. Ce type de vérification peut sembler insignifiant comparé au test de l'authentification ou de l'accès à la base de données.

Ce n'est pas le cas.

Les applications d'entreprise accumulent des centaines de petites transitions d'état de ce genre.
Les utilisateurs s'y fient sans y penser consciemment.
Le logiciel semble fiable précisément parce que ces interactions restent prévisibles.
Les tests de régression existent pour protéger cette prévisibilité.

Testing the Information Around the Software

COCO a également ouvert la boîte de dialogue « À propos » de l'application.

Pourquoi tester une fenêtre « À propos » ?

Parce que la documentation logicielle commence à l'intérieur du logiciel lui-même.
Le numéro de version, la description des fonctionnalités et les informations de licence présentées à l'opérateur devraient correspondre à l'application réellement en cours d'exécution.

Une application peut fonctionner parfaitement tout en présentant des informations de version obsolètes ou en décrivant des capacités qui ne correspondent plus à la version.

Cela ne fait pas planter une base de données.
Cela fait quelque chose de plus subtil :
cela réduit la confiance.

Pour les logiciels d'entreprise, la précision opérationnelle inclut ces détails apparemment mineurs. COCO les a donc vérifiés également.

Control.

Le premier mot du slogan de softify.pro Flow est aussi le premier principe de l'environnement de test.

Control signifie savoir ce qui est testé, par rapport à quel état et avec quelles données.

La démonstration publique de COCO n'utilise pas les données de production des clients.

Elle fonctionne avec des données de démonstration délibérément préparées, dont l'état attendu est connu.

Cela rend les résultats reproductibles.

Cela signifie également que les différences entre les exécutions de test peuvent être étudiées plutôt qu'expliquées comme de simples changements aléatoires dans les données de production.

Plus important encore, COCO est conçu comme un système de test IA auto-hébergé.

Les preuves de test, les captures d'écran de l'application et les informations internes sur le flux de travail peuvent rester au sein de l'infrastructure sous le propre contrôle du client ou de l'opérateur, plutôt que d'être envoyées par défaut à un service cloud tiers sans rapport.

Pour les applications métier internes, ce n'est pas simplement une préférence d'infrastructure.
Cela peut faire partie de l'exigence de test elle-même.

Clarity.

L'automatisation n'est pas particulièrement utile si son résultat final est : FAILED
suivi de centaines de lignes de sortie technique que quelqu'un doit reconstruire manuellement avant de comprendre ce qui s'est passé.

COCO est conçu pour préserver une trace de preuves compréhensible.

Le rapport décrit :

• ce qui a été testé
• quelle interaction a eu lieu
• dans quel ordre elle s'est produite
• ce que COCO a observé
• quel état était attendu
• où le comportement a différé lorsque quelque chose a échoué

Des captures d'écran et des preuves d'exécution peuvent accompagner cette séquence.
L'objectif n'est pas de cacher les détails techniques.

C'est de rendre le résultat compréhensible avant que quelqu'un ne doive ouvrir un débogueur.

Un ingénieur devrait pouvoir répondre à :
Que s'est-il passé ? avant de demander :
Où dans le code cela s'est-il produit ?

Cette distinction raccourcit considérablement l'investigation lorsqu'une régression apparaît.

Flow.

L'automatisation UI traditionnelle raisonne souvent en éléments.

Trouver un sélecteur.
Cliquer sur le sélecteur.
Trouver un autre sélecteur.
Vérifier la valeur.

Cette approche reste utile, mais les applications ne sont pas vécues comme des collections de sélecteurs.

Les gens vivent des flux.

Se connecter.
Ouvrir l'administration.
Trouver un utilisateur.
Changer un paramètre.
Changer de base de données.
Changer de langue.
Vérifier le résultat.

Continuer à travailler.

COCO traite donc la séquence comme un processus plutôt que comme une collection aléatoire de contrôles.

Il suit ce que l'utilisateur essaie d'accomplir et évalue l'application en contexte.

Cela devient particulièrement précieux lors du test de logiciels métier réels, car les défaillances surviennent souvent entre les écrans ou entre les états, pas à l'intérieur d'un bouton individuel.

Un flux logistique peut contenir une commande, une réservation de stock, une opération de picking, un bon de livraison et une confirmation d'expédition.
Chaque écran individuel peut paraître correct alors que le processus complet est erroné.
Le même principe s'applique ici, à plus petite échelle.
La fenêtre d'administration n'est pas le produit.

Le flux de travail qui la traverse l'est.

Evidence Instead of Assumption

L'une des tâches les plus importantes de COCO n'est pas de cliquer. C'est de se souvenir de ce qui s'est passé.
Les tests de régression humains se terminent souvent par une déclaration telle que :
« Je l'ai testé et tout semblait correct. »

Cela peut être parfaitement exact.
Mais plusieurs semaines plus tard, lorsqu'un problème apparaît, les questions utiles sont différentes :

• Quelle version a été testée ?
• Quelle base de données ?
• Quelle langue ?
• Quel état utilisateur ?
• Que s'est-il passé avant le problème ?
• Qu'est-ce qui était exactement visible ?

Dans quel ordre les actions ont-elles été exécutées ?
Les exécutions de test de COCO sont conçues pour laisser des traces.

Cela transforme un résultat de test d'une opinion en quelque chose qui peut être inspecté.
Une exécution réussie devient donc utile elle aussi.
Elle établit un état de référence connu par rapport auquel le comportement ultérieur peut être comparé.

COCO Is Not the Decision Maker

Il existe une frontière importante dans la façon dont nous utilisons l'IA pour tester les logiciels.
COCO n'a pas vocation à remplacer la responsabilité d'ingénierie.

Il ne décide pas de ce qu'une règle métier devrait être.

Il teste le comportement par rapport aux scénarios, exigences et attentes définis pour l'application.
Pour les décisions sensibles impliquant des permissions, des prix, des stocks, des transactions financières ou d'autres états métier critiques, la définition du comportement correct reste une responsabilité humaine.

Cette distinction compte.
L'IA excelle à répéter un test détaillé sans perdre en concentration.
Elle excelle à collecter des preuves.
Elle peut inspecter des écrans, comparer le comportement attendu et observé, et expliquer les divergences.
Mais c'est l'entreprise qui définit toujours ce que signifie correct.

COCO rend cette définition testable.

The Test Nobody Wants to Repeat

Il y a une raison simple pour laquelle l'automatisation apporte de la valeur ici.
Un testeur humain peut tout à fait effectuer cette session de régression.
La première langue reçoit toute l'attention.
Probablement la deuxième aussi.
Puis une autre.
Puis encore une autre.
MySQL a déjà été vérifié.
PostgreSQL doit encore être vérifié.
Le test de tri a déjà été effectué plusieurs fois.
La boîte de dialogue « À propos » n'a pas changé depuis des mois.

C'est vendredi après-midi.

Et l'attention humaine fait ce que l'attention humaine fait naturellement.
Elle commence à optimiser.
COCO ne le fait pas.
Dans l'esprit propre de COCO :

• Je ne me lasse pas de cliquer sur le même bouton dans onze langues. Je ne saute pas le passage PostgreSQL simplement parce que c'est vendredi après-midi. Je ne suppose pas que l'ordre de tri a tenu simplement parce qu'il a fonctionné lors de la version précédente.

Pour COCO, chaque session de régression peut être traitée comme si c'était la première.
Ce n'est pas une intelligence qui remplace un testeur humain.
C'est une automatisation qui protège le testeur humain de la partie du test où l'attention humaine a le moins de valeur.

From Repetitive Testing to Engineering Evidence

L'objectif plus large de COCO n'est pas de maximiser le nombre d'actions automatisées.
Mille clics automatisés n'ont aucun sens si personne ne comprend ce qu'ils prouvent. Le résultat utile est une confiance soutenue par des preuves.

Pour softify.pro Flow, cela signifie être en mesure de dire qu'une version a été testée à travers les domaines opérationnels qui comptent :

• authentification
• administration des utilisateurs
• informations sur les rôles et les accès
• état de l'authentification à deux facteurs
• comportement de tri
• fonctionnement avec MySQL
• fonctionnement avec PostgreSQL
• localisation en direct
• retour d'état
• informations sur l'application
• informations de licence

et que le résultat est conservé sous une forme qui peut être revue par la suite.
Le même principe s'étend bien au-delà de cette application.
Un processus de connexion peut être testé ainsi.
Un flux de réservation peut être testé ainsi.
Un processus logistique peut être testé ainsi.
Une application de bureau multiplateforme peut être testée ainsi.
Les écrans changent.
Les règles métier changent.
Le principe, non :
définir le flux de travail attendu, l'exécuter de manière cohérente, recueillir des preuves et rendre le résultat compréhensible.

Why We Test Our Own Software With COCO

Il y a une autre raison pour laquelle softify.pro Flow compte comme étude de cas COCO.

C'est notre propre logiciel.
Cela supprime la distance confortable qui existe parfois entre une démonstration technologique et les personnes qui la font.

Si COCO est destiné à tester des logiciels d'entreprise, il doit être suffisamment utile pour que nous lui fassions confiance avec les logiciels que nous développons et publions nous-mêmes.

Flow agit donc à la fois comme produit et comme terrain d'essai.
De nouvelles capacités de test peuvent être exercées contre une application réelle.
Un comportement inattendu peut révéler des faiblesses dans l'application, le plan de test ou COCO lui-même.

Chaque côté améliore l'autre.
Cette boucle de rétroaction est bien plus précieuse que la construction de démonstrations artificielles conçues uniquement pour réussir. Un système de test ne devrait pas paraître convaincant parce que la démonstration était facile.
Il devrait devenir convaincant parce qu'il continue de trouver les petites choses que les humains finiraient par cesser de vérifier.

The Result

softify.pro Flow — Administration dispose désormais d'un processus de régression documenté et reproductible que COCO peut exécuter avant les versions pertinentes.

Le test couvre les deux environnements de base de données pris en charge et l'interface en onze langues de l'application, tout en suivant l'application comme le ferait un administrateur, plutôt que de traiter chaque écran comme une cible de test isolée.

COCO produit une trace de preuves montrant ce qui a été testé, ce qui a été observé et dans quel ordre la session s'est déroulée.

Ces preuves peuvent rester sous contrôle local.
Les développeurs obtiennent un point de départ reproductible lorsque quelque chose change.
Les testeurs humains passent moins de temps à répéter des interactions prévisibles et plus de temps à enquêter sur les situations qui nécessitent réellement du jugement.

Et softify.pro Flow reçoit quelque chose de plus précieux qu'un indicateur vert PASS.

Il reçoit la preuve que l'expérience promise sur son écran de connexion continue d'exister après que le code sous-jacent a changé.

Control. Savoir ce qui est testé et garder l'environnement sous contrôle.

Clarity. Comprendre ce qui s'est passé sans avoir à reconstruire un journal d'automatisation opaque.

Flow. Tester l'application comme un processus que les gens utilisent réellement.

Control. Clarity. Flow.

Cela a été écrit pour le logiciel.
Il s'avère que cela décrit tout aussi bien la philosophie de test qui le sous-tend.