lecture de 9 min
Mettre à l'essai un système POS sans une allée de caisse complète peut sembler risqué au départ. Les vrais commerces ont des lecteurs, des imprimantes de reçus, des terminaux de paiement, des permissions et toutes sortes de comportements propres au lieu. Pourtant, pour une grande part du travail quotidien de développement et de QA, on peut encore mettre un POS à l'essai de façon efficace sans avoir chaque appareil sur le bureau.
Beaucoup plus que ce que les gens croient. Vous pouvez valider la recherche de produit, l'ajout au panier, les changements de quantité, les règles de rabais, l'affectation du client, le retour du curseur, la gestion des erreurs et de nombreux cas limites vus par le commis, sans toucher au vrai lecteur.
La clé est de séparer la logique du flux de travail de la validation matérielle. Si le problème porte sur la réaction du POS à une entrée, à un changement d'état ou à un résultat de recherche, un essai logiciel suffit en général à le trouver. Si le problème porte sur les lecteurs, les imprimantes, les terminaux ou les restrictions USB, c'est là que le passage matériel devient nécessaire.
Dans la plupart des systèmes POS, le lecteur est la première dépendance qui inquiète. Heureusement, c'est aussi l'une des plus faciles à bien simuler, parce que beaucoup de lecteurs se comportent comme des claviers.
Ça fait d'un outil d'émulation de lecteur de code à barres un solide point de départ pour les essais POS. Vous pouvez piloter le même champ de recherche ou la même entrée d'article qu'à la caisse et vérifier comment l'écran réagit lorsque les valeurs arrivent vite, avec ou sans Enter à la fin.
Le moyen le plus simple d'obtenir une couverture superficielle est d'essayer un seul produit du chemin heureux. Une meilleure approche consiste à créer une petite matrice de types d'articles qui reflète le comportement du POS dans de vrais flux de travail de commerce.
Je veux en général au moins :
Ça compte, parce que les bogues POS se cachent souvent dans les règles d'affaires, pas dans le balayage lui-même. Si votre jeu d'essai est trop simple, l'écran peut sembler stable alors que le vrai flux de travail ne l'est pas.
Une session POS n'est pas un essai unitaire bien rangé. Les commis vont vite, cliquent dans le mauvais champ, rebalayent des articles, ferment les invites trop tôt et travaillent sous pression. Si vos cas d'essai sans matériel ne modélisent pas cette réalité, votre couverture aura l'air meilleure qu'elle ne l'est.
Essayez des scénarios comme ceux-ci :
Ce sont des échecs réalistes, et ce sont exactement les cas qu'un émulateur de code à barres aide à répéter sans fatigue.
Pour les essais POS, j'aime trois couches :
Ça concentre le temps de matériel coûteux sur le petit ensemble de bogues qui exigent vraiment des appareils. Les développeurs peuvent éliminer la plupart des défauts de flux de travail en local, la QA peut vérifier des scénarios plus larges dans l'environnement intermédiaire, et les spécialistes du matériel peuvent se concentrer sur les problèmes au niveau de l'appareil.
Les essais sans matériel sont puissants, mais ils ont des limites. Il vous faut encore de vrais appareils pour :
Être honnête sur ces limites rend le reste du processus plus solide. Le but n'est pas de prétendre que le matériel ne compte pas. Le but est d'arrêter de gaspiller du temps de matériel sur des problèmes qu'on aurait pu attraper plus tôt.
L'erreur la plus courante est d'attendre une allée matérielle complète avant de mettre à l'essai quoi que ce soit de significatif. Ça paraît prudent, mais ça retarde en général les bogues au lieu de les empêcher. Si une recherche de produit échoue parce que le champ perd le curseur après une invite de rabais, le matériel ne rendra pas ce bogue magiquement plus facile à comprendre.
Un autre problème courant est de n'essayer qu'un seul chemin heureux et calme. Les vraies sessions de caisse sont bruyantes. Les gens balayent vite, répètent des articles, reculent sur des invites et changent de flux de travail. Vos essais POS sans matériel doivent refléter cette réalité, sinon ils manqueront exactement les problèmes que le personnel remarquera en premier.
Imaginez un écran de caisse où le balayage d'un produit doit ajouter l'article, mettre à jour le panier et ramener tout de suite le curseur dans le champ de recherche. Vous pouvez valider l'essentiel sans matériel :
Ce n'est qu'une fois ce passage réussi que vous avez besoin du lecteur physique pour la confiance finale. Cet ordre fait gagner du temps et rend en général la session matérielle plus utile.
On peut mettre des systèmes POS à l'essai sans vrai matériel bien plus efficacement que beaucoup d'équipes ne le supposent. Commencez par une simulation réaliste du lecteur, jumelée à des données d'essai stables, et concentrez-vous d'abord sur le comportement du flux de travail. Utilisez ensuite le vrai matériel pour l'ensemble plus étroit de problèmes que seuls les appareils peuvent révéler. Cette approche est plus rapide, moins chère et en général plus disciplinée que de s'appuyer sur le matériel dès le départ.
Prochaine étape utile
Si vous voulez mettre ces flux de travail à l'essai, commencez avec l'outil Barcode Scanner Emulator et revenez ensuite au reste du blogue pour d'autres modèles d'essai.
lecture de 9 min
Un guide complet des émulateurs de code à barres : leur fonctionnement, leurs utilisateurs, leur place dans les essais de lecteur, et les endroits où ils ne conviennent pas.
lecture de 9 min
Une revue concrète des meilleurs outils d'essai de lecteur de code à barres pour les développeurs, les équipes QA et les ingénieurs POS, avec les vrais compromis et des conseils de montage.
lecture de 8 min
Un guide concret, étape par étape, pour se servir d'un émulateur de lecteur de code à barres durant les essais de lecteur, les flux de travail QA et les essais POS, sans matériel réel.
