Tester l'autocorrection et le correcteur orthographique avec des données de fautes de frappe contrôlées

La plupart des équipes testent leurs systèmes d'autocorrection et de correcteur orthographique avec le mauvais type d'erreurs. Elles appuient sur des touches au hasard, tapent délibérément du charabia ou copient-collent une poignée de fautes d'orthographe créées manuellement. Le résultat est une suite de tests qui ne leur dit rien sur la façon dont leur système fonctionnera lorsque de vrais utilisateurs taperont sur de vrais appareils.

Le problème n'est pas un manque d'efforts. C'est un manque de données d'entrée réalistes. Les algorithmes d'autocorrection sont conçus pour corriger les types d'erreurs que les humains commettent réellement—frappes de touches adjacentes, transpositions, caractères omis, lettres doublées. Lorsque vous testez avec des erreurs qu'aucun humain ne produirait, vous mesurez la capacité de votre système à gérer des scénarios qui ne se produiront jamais en production. Pendant ce temps, les erreurs que vos utilisateurs feront réellement restent non testées.

Cet article explique pourquoi les données de fautes de frappe réalistes sont importantes pour les tests de qualité, pourquoi la mutation aléatoire de caractères échoue en tant que stratégie de test, et comment construire des jeux de données de test contrôlés et reproductibles en utilisant la génération d'erreurs basée sur la physique.

Pourquoi les erreurs aléatoires échouent pour les tests

L'approche la plus courante pour générer des données de test pour les systèmes de correcteur orthographique et d'autocorrection est la substitution aléatoire de caractères. On choisit un mot, on choisit une position, on échange un caractère aléatoire. “keyboard” devient “keybzard” ou “keyb$ard.” La logique semble valable : vous introduisez des erreurs, et le système devrait les détecter.

Mais cette approche présente trois problèmes fondamentaux.

Les erreurs aléatoires ne correspondent pas aux schémas humains

Lorsqu'un humain tape mal “keyboard,” l'erreur suit la physique du mouvement des doigts. Le “o” pourrait devenir un “p” ou un “i” parce que ces touches sont adjacentes sur une disposition QWERTY. Il ne deviendra pas un “z” ou un “$” car aucun glissement de doigt ne pourrait produire cette substitution. La mutation aléatoire de caractères ignore cela complètement. Elle traite chaque substitution possible comme également probable, produisant des erreurs physiquement impossibles pour un dactylographe humain.

L'autocorrection est calibrée pour des schémas réalistes

Les algorithmes modernes d'autocorrection utilisent des modèles probabilistes qui tiennent compte de la géométrie du clavier. Ils savent que “e” et “r” sont adjacents, donc “thr” est une faute de frappe plausible de “the.” Ils savent que “q” et “w” sont voisins, donc ils pondèrent ces substitutions plus fortement lors du classement des candidats de correction. Lorsque vous testez avec des erreurs aléatoires—des substitutions que l'algorithme n'a jamais été conçu pour rencontrer—vous ne testez pas les chemins de code qui comptent. Votre système pourrait obtenir un score parfait sur les erreurs aléatoires et tout de même échouer sur les frappes de touches adjacentes qui constituent la majorité des fautes de frappe réelles.

Les données irréalistes donnent une fausse confiance

C'est la conséquence la plus dangereuse. Une suite de tests remplie de mutations aléatoires de caractères produira des taux de réussite qui semblent excellents. Votre autocorrecteur gère “keybzard” parfaitement—il n'y a qu'une seule correction plausible. Mais en production, les utilisateurs tapent “keybiard” ou “keyboadr,” et l'ambiguïté est bien plus élevée. Plusieurs corrections valides existent. L'autocorrecteur pourrait choisir la mauvaise, ou ne pas corriger du tout, parce que le schéma d'erreur réel est plus difficile à résoudre que les schémas aléatoires avec lesquels vous avez testé. Votre suite de tests disait que tout allait bien. Vos utilisateurs savent que ce n'est pas le cas.

Génération contrôlée d'erreurs

Des tests d'autocorrection efficaces nécessitent des données d'entrée qui reflètent ce que les utilisateurs tapent réellement. Un simulateur d'erreurs clavier basé sur la physique produit des erreurs ancrées dans l'adjacence des touches, les zones de toucher de l'appareil, la vitesse de frappe et les contraintes biomécaniques des mains interagissant avec les périphériques de saisie. Cela signifie aussi la capacité de contrôler et reproduire ces erreurs avec précision.

Reproductibilité basée sur les seeds

L'un des plus grands défis des tests de qualité est la reproductibilité. Si vous générez un ensemble de variantes de fautes de frappe pour une exécution de test, vous devez générer les mêmes variantes exactes lorsque vous relancez le test après une correction de bogue. La génération aléatoire d'erreurs rend cela difficile sans une gestion soigneuse des seeds. Les générateurs basés sur la physique comme LikelyTypo supportent la génération déterministe basée sur les seeds : le même texte d'entrée, le même profil, le même appareil et le même seed produiront toujours une sortie identique. Cela signifie que vos cas de test sont stables, versionnables et déboguables.

Types d'erreurs ciblés

Différentes fonctionnalités d'autocorrection gèrent différents types d'erreurs. Votre logique de correction des touches adjacentes doit être testée avec des erreurs de touches adjacentes. Votre détection des transpositions a besoin de paires de caractères transposés. Votre gestion des omissions a besoin de caractères omis. Un générateur d'erreurs contrôlé vous permet de vous concentrer sur des catégories d'erreurs spécifiques—substitutions de touches adjacentes, omissions de caractères, frappes doublées, transpositions, erreurs d'espacement—afin de pouvoir tester chaque chemin de correction de manière isolée avant de les combiner.

Scénarios de test spécifiques aux appareils

Un écran tactile de téléphone produit des erreurs fondamentalement différentes de celles d'un clavier physique. La zone de toucher sur un téléphone est plus large, donc les erreurs de touches adjacentes ont un rayon plus grand. La saisie au pouce sur un téléphone introduit des erreurs d'espacement qui se produisent rarement sur un clavier de bureau. Les claviers de tablettes produisent encore une autre distribution d'erreurs. Si votre autocorrecteur dessert plusieurs plateformes, vos données de test doivent refléter les schémas d'erreurs spécifiques à chaque appareil. Tester avec un seul ensemble générique d'erreurs signifie que vous ne validez l'expérience que d'une seule plateforme.

Construire un jeu de données de test

Le processus de construction d'un jeu de données de test de fautes de frappe contrôlées avec l'outil web LikelyTypo suit un flux de travail simple. Voici comment les équipes de qualité peuvent l'aborder.

Commencez par des phrases représentatives

Commencez par le texte que vos utilisateurs tapent réellement. Pour un moteur de recherche, cela signifie des requêtes courantes. Pour une application de messagerie, cela signifie des phrases conversationnelles. Pour un éditeur de documents, cela signifie de la prose de la longueur d'un paragraphe. Le texte d'entrée doit refléter les schémas d'utilisation réels de votre produit, pas des chaînes de test artificielles. Puisez dans les analyses, les transcriptions de recherche utilisateur ou les contenus d'exemple qui correspondent au vocabulaire et à la structure de phrases de votre audience.

Générez des variantes avec différents profils

Ouvrez le générateur LikelyTypo et collez votre texte représentatif. Puis générez des variantes de fautes de frappe en utilisant différents profils de saisie. Un dactylographe soigneux produit des erreurs différentes de celles d'un dactylographe rapide. Un dactylographe qui cherche et frappe fait des erreurs différentes de quelqu'un qui utilise ses dix doigts. En générant des variantes avec plusieurs profils, vous construisez un jeu de données de test qui couvre l'éventail des comportements de saisie de vos utilisateurs.

Variez le modèle d'appareil

Pour chaque ensemble de phrases, générez des variantes en utilisant différents modèles d'appareils. Les erreurs d'écran tactile de téléphone mettront à l'épreuve votre autocorrecteur mobile d'une manière que les erreurs de clavier de bureau ne pourront pas. Si votre produit fonctionne sur plusieurs plateformes, chaque plateforme a besoin de sa propre portion du jeu de données de test générée avec le modèle d'appareil approprié.

Verrouillez les seeds pour les tests de régression

Une fois que vous avez un ensemble de variantes générées qui offre une bonne couverture, enregistrez les valeurs des seeds. Ces seeds rendent votre jeu de données de test entièrement déterministe. Lorsque vous corrigez un bogue dans votre logique d'autocorrection et devez vérifier la correction, régénérez exactement les mêmes variantes de fautes de frappe en utilisant les mêmes seeds. Vos tests de régression seront stables et significatifs parce que les données d'entrée sont identiques d'une exécution à l'autre.

Organisez par catégorie d'erreur

Structurez votre jeu de données de test de manière à pouvoir filtrer par type d'erreur. Regroupez les erreurs de touches adjacentes séparément des transpositions, les omissions séparément des insertions. Cela vous permet d'exécuter des suites de tests ciblées contre des fonctionnalités d'autocorrection spécifiques et d'identifier rapidement quel chemin de correction échoue lorsqu'une régression apparaît.

A quoi ressemblent de bonnes données de test

Considérez la phrase “The quick brown fox jumps over the lazy dog.” Un générateur de mutations aléatoires pourrait produire “Thx quicj broen fox.” Ces erreurs ne vous disent rien d'utile. Personne ne tapera jamais “thx” en voulant dire “the”—la touche “x” n'est nulle part près de la touche “e”.

Un générateur basé sur la physique produit des erreurs comme “Thr quick brown fox jumps over teh lazy dog.” Le “e” est devenu un “r” (adjacent sur QWERTY). Le “the” est devenu “teh” (caractères transposés, l'une des erreurs réelles les plus courantes). Ce sont les erreurs que votre autocorrecteur doit gérer, car ce sont les erreurs que vos utilisateurs feront.

La différence entre ces deux entrées de test est la différence entre tester ce qui compte et tester ce qui est commode. Les données aléatoires sont faciles à générer mais inutiles pour la validation. Les données basées sur la physique nécessitent un outil approprié mais produisent des cas de test qui correspondent directement aux scénarios de production.

Créez vos données de test

Si votre équipe teste l'autocorrection, le correcteur orthographique ou la validation de saisie, la qualité de vos données de test détermine la qualité de vos résultats. Les mutations aléatoires de caractères vous donneront des tests qui passent et des utilisateurs qui échouent. Les erreurs basées sur la physique vous donneront des cas de test qui reflètent la réalité.

La démonstration interactive de LikelyTypo vous permet de générer des données de fautes de frappe contrôlées et reproductibles en quelques secondes. Collez votre texte représentatif, sélectionnez un appareil et un profil de saisie, définissez un seed pour la reproductibilité et générez les erreurs réalistes dont votre pipeline de qualité a besoin. Basculez entre les modèles d'appareils pour construire des jeux de tests spécifiques par plateforme. Ajustez les profils pour couvrir différents comportements de saisie. Chaque variante générée est basée sur la physique du clavier, pas sur du bruit aléatoire.

Vos utilisateurs ne tapent pas du charabia aléatoire. Ils font des erreurs prévisibles, régies par la physique, sur des appareils spécifiques avec des habitudes de saisie spécifiques. Vos données de test devraient faire de même.