Le fabricant documente la capacité, l’interface ou la configuration. Ce n’est pas un résultat de test UnitWeave et cela ne garantit pas le fonctionnement de votre application.
Laboratoire de tests / registre de preuves
Laboratoire de compatibilité des appareils SUNMI
Transformez une question de compatibilité en fiche reproductible pour un appareil SUNMI, un build applicatif, ses périphériques et un environnement défini.
Parler de votre projetPérimètre du test / avant le résultat
Testez la configuration réellement prévue pour le déploiement.
La compatibilité concerne une combinaison définie de matériel, logiciel, configuration et conditions d’exploitation. Commencez par le flux important et décrivez l’ensemble pour qu’un autre relecteur puisse le reproduire.
Fiche de validation / champs requis
« Pris en charge » doit avoir une source et un responsable.
Une conclusion positive, partielle ou négative reste liée à la configuration qui l’a produite. Cette fiche apporte le contexte minimal pour comparer un résultat, rouvrir un défaut ou étendre la couverture à un nouveau build.
Un enregistrement UnitWeave daté indique le modèle, le système, le firmware, le build de l’application, les accessoires, la méthode, le résultat et le réviseur.
Un procès-verbal d’acceptation rattaché à un client identifié confirme le flux convenu dans son environnement. Ce résultat n’est pas automatiquement universel.
Certains parcours fonctionnent, mais une limitation définie subsiste. Le parcours pris en charge et le parcours en échec ou exclu sont tous deux consignés.
Un enregistrement identifié indique que la configuration demandée est hors du périmètre confirmé ou ne respecte pas les critères d’acceptation convenus.
Fiche de validation / champs requis
Un test utile peut être reproduit par un autre relecteur.
Une conclusion positive, partielle ou négative reste liée à la configuration qui l’a produite. Cette fiche apporte le contexte minimal pour comparer un résultat, rouvrir un défaut ou étendre la couverture à un nouveau build.
01
Identité de la cible
Notez le modèle, la variante exacte, Android, le firmware, le package, la version et le build de l’application. Le nom d’une famille ne remplace pas la configuration testée.
02
Configuration connectée
Nommez l’imprimante, le scanner, le tiroir, l’écran client, le support, le papier, l’environnement de paiement, le réseau et l’alimentation utilisés.
03
Méthode de test
Décrivez les prérequis, les données, le résultat attendu, les étapes, les répétitions et le résultat observé. Ajoutez démarrage, reconnexion et parcours hors ligne s’ils font partie du flux.
04
Récupération et limites
Conservez les permissions, erreurs, journaux ou captures, comportements de reprise, limites connues et parcours exclus. Les données client, identifiants et binaires de production restent hors de la fiche publique.
05
Décision et responsable
Indiquez le niveau de preuve, le résultat d’acceptation, la date, le relecteur, l’emplacement de la preuve, le responsable support et l’action suivante.
De la question à la fiche
Un parcours court de l’incertitude vers une réponse cadrée.
Le processus rend les inconnues visibles avant l’achat, la certification ou le déploiement et donne à l’ingénierie et au client un point de remise commun.
- 01
Cadrer
Décrivez le flux métier, le marché, la variante, le build applicatif et les critères d’acceptation.
- 02
Préparer
Figez firmware, périphériques, réseau, alimentation, comptes, permissions et données de test avant l’exécution.
- 03
Exécuter
Lancez les cas définis, répétez les parcours importants, testez redémarrage et reprise, puis conservez les observations.
- 04
Publier
Séparez données fabricant et résultats de test, attribuez l’état de preuve, notez les limites et la prochaine revue.
Limite de publication
Un résultat de test est volontairement spécifique.
Le laboratoire rend une décision définie plus fiable. Il ne transforme pas une configuration réussie en compatibilité universelle, certification de paiement ou engagement de support local.
- Une spécification SUNMI reste une déclaration du fabricant et ne devient pas un résultat de test UnitWeave.
- Un modèle, un firmware, un build applicatif ou un ensemble de périphériques ne couvre pas implicitement une autre configuration.
- Certification de paiement, acquiring, fiscalité, importation, données client et service local ont leurs propres responsables.
- Le devis, la fiche d’acceptation et le contrat définissent le livrable, la disponibilité, la garantie et le support.
Commencer par la question ouverte
Besoin d’une réponse de compatibilité avant le déploiement ?
Envoyez le flux cible, le modèle ou la sélection, le build applicatif, les périphériques, le pays et les critères d’acceptation. Nous en ferons un brief de validation cadré.