test instrumenté

test instrumenté : Test exécuté sur un appareil ou un émulateur avec le système réel, plus lent qu’un test local mais plus proche de la vérité.

Ce terme appartient à la famille « Développement ». La page reprend l’essentiel : à quoi ça sert, comment l’écrire, ce qui se passe quand on l’oublie.

Où intervient test instrumenté dans un projet

Sur un projet mobile, test instrumenté relève des choix de fabrication. Ce n’est pas une fonctionnalité que l’utilisateur verra à l’écran, mais une décision technique qui conditionne le coût des évolutions suivantes.

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

Ce que ça devient dans un cahier des charges

Dans un cahier des charges, test instrumenté n’a pas à être imposé ligne à ligne. Ce qui doit être écrit, c’est l’exigence à laquelle ce choix répond et la contrainte qu’il ne doit pas violer.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Le niveau de tests automatisés attendu, et ce qui déclenche un refus de recette.
• La documentation technique livrée, et à qui elle doit permettre de reprendre le projet.
• L’environnement de recette, distinct de la production, et la liste de ceux qui y accèdent.
• Le format de livraison des sources, des comptes de service et des clés de signature.

Une exigence bien écrite tient en trois lignes et se refuse en une. Si elle ne peut pas être refusée à la recette, elle n’est pas encore écrite.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Les contrôles à prévoir

test instrumenté se vérifie sur pièces, pas sur parole. Une recette sérieuse regarde le livrable, pas la démonstration préparée à l’avance.

• Vérifier que le projet se compile chez quelqu’un d’autre, à partir du dépôt seul.
• Lire le rapport de tests automatisés fourni avec la livraison.
• Vérifier que les clés de signature et les comptes de service sont remis, pas seulement promis.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Erreurs fréquentes

Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.

• Laisser la remise du code hors du contrat, puis découvrir que le dépôt n’est pas transmis.
• Confondre bibliothèque gratuite et bibliothèque sans coût : certaines licences se paient à l’usage.
• Croire qu’un développeur reprend le travail d’un autre sans documentation ni période de recouvrement.
• Traiter la dette technique comme une affaire interne à l’agence : elle sera facturée au suivant.
• Repousser l’arbitrage au sprint suivant, autant de fois qu’il y a de sprints.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• React Native
• Swift
• Kotlin
• ObservableObject
• Modifier

Questions fréquentes

Qu’est-ce que « test instrumenté » ?

Test exécuté sur un appareil ou un émulateur avec le système réel, plus lent qu’un test local mais plus proche de la vérité. Le mot est employé tel quel par les équipes francophones. C’est celui à utiliser dans les échanges avec une agence, y compris quand la traduction française existe.

Comment vérifier qu’une agence maîtrise le sujet ?

Demandez un exemple tiré d’un projet livré, pas une définition. L’écart entre les deux réponses se voit en trente secondes, et il est plus parlant qu’une liste de technologies sur un site vitrine.

Comment savoir si le budget annoncé est cohérent ?

En comparant le périmètre écrit aux fourchettes constatées en France, détaillées poste par poste sur le guide des prix. Un chiffre isolé ne veut rien dire sans le périmètre qui va avec.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.