Tous les types de tests logiciels ne se ressemblent pas. Certains scénarios de test requièrent même des perspectives différentes pour jauger si le logiciel a rempli sa mission. C’est le cas des tests d’acceptation par les utilisateurs, qui diffèrent assez nettement d’une approche technique, comme les tests d’intégration du système.
Il n’existe pas de normes industrielles pour les tests d’acceptation par les utilisateurs (UAT) ou les tests d’intégration du système (SIT). Avec l’UAT, les personnes qui utilisent le système ou établissent les exigences du produit effectuent les tests. L’UAT peut varier considérablement en fonction de l’expérience de la personne avec l’application et de son expérience avec les tests eux-mêmes.
Avec le SIT, une équipe d’assurance qualité évalue si les applications — et leurs nombreux composants — fonctionnent comme prévu avant de les envoyer au client. Les tests isolés, tels que les tests unitaires, échouent souvent à attraper les bogues que le SIT met à jour.
La principale différence entre le SIT et l’UAT se résume à leurs objectifs de test très différents et à l’expérience des testeurs. Le temps est un facteur dans les deux scénarios UAT et SIT. Les testeurs doivent savoir quelle est la différence entre SIT et UAT, ce que chaque évaluation apporte à la qualité du logiciel et qui vérifie chaque test. Lisez la suite pour en savoir plus sur ces processus de test.
Qu’est-ce que l’UAT ?
Avec les tests d’acceptation par les utilisateurs, l’organisation de développement donne la construction ou la version au consommateur cible du système, tard dans le cycle de vie du développement logiciel (SDLC). Les utilisateurs finaux ou l’équipe de développement de produits de cette organisation effectuent les activités attendues pour confirmer ou accepter le système comme viable. La phase d’UAT est généralement l’une des dernières étapes d’un projet global de développement de logiciels.
Certains types d’UAT incluent les éléments suivants :
- Tests alpha et bêta. Avec les tests alpha, les utilisateurs ou les groupes d’utilisateurs testent le logiciel au début du SDLC pour identifier les bogues pendant le développement. Les organisations diffusent le produit dans l’environnement du client lors des tests bêta, ce qui permet de recueillir plus de commentaires et d’améliorer la qualité, mais intervient après que l’équipe logicielle a effectué plus de travail à la suite des tests alpha.
- Tests en boîte noire. L’utilisateur ne voit pas le code interne ou les composants de l’application, d’où l’origine du terme boîte noire. Les utilisateurs doivent évaluer dans quelle mesure le produit répond aux exigences en se basant uniquement sur leur interaction. Les tests en boîte noire sont également un type de test fonctionnel.
- Tests d’acceptation du contrat. Ce type d’UAT se produit lorsqu’un contrat entre le fournisseur et l’utilisateur définit les critères et les spécifications d’un produit. Avec les tests d’acceptation du contrat, l’utilisateur vérifie que le logiciel répond aux critères convenus.
- Tests d’acceptation opérationnelle. L’organisme client détermine s’il est prêt à utiliser le logiciel, en jaugeant des critères tels que la formation des employés, la maintenance du logiciel et la façon dont il gérera les défaillances.
- Tests d’acceptation de la réglementation. Également appelé test d’acceptation de conformité, ce processus vérifie que le logiciel répond aux besoins des utilisateurs en matière de réglementation ou de conformité.
Un inconvénient de l’UAT est qu’il laisse peu de temps aux utilisateurs pour effectuer des tests avant le lancement du produit. Si les utilisateurs trouvent des défauts, ils peuvent ressentir une pression pour accepter le logiciel tel quel plutôt que de retarder un projet. Dans certains cas, les clients attendent le logiciel pendant des mois et sont impatients de le recevoir et de commencer à travailler dessus pour répondre aux besoins de l’entreprise. Cette dynamique pousse les utilisateurs à accepter le logiciel en cours de test, même si les défauts empêchent ou inhibent la fonctionnalité.
Un autre inconvénient de l’UAT est que les utilisateurs ne savent souvent pas comment tester correctement. Les ingénieurs AQ apprennent des techniques qui les aident à passer les logiciels au crible. Les utilisateurs arrivent souvent au clavier sans aucune connaissance de la façon de tester le logiciel — même s’il y a des exigences en place. Ces utilisateurs ont tendance à exécuter des tests de cheminement heureux — et non des cas de test plus impliqués ou des conditions de test intéressantes — soit en raison de leur inexpérience, soit par manque de temps pour réaliser efficacement différents scénarios.
Les utilisateurs doivent essayer de comprendre la dynamique spécifique du projet et déterminer ce qui est adaptable et logique de demander aux développeurs. Si vous ne pensez pas que les utilisateurs puissent gérer efficacement l’UAT, chargez une aide extérieure de cette tâche.
Qu’est-ce que le SIT?
Les tests d’intégration du système, également appelés tests d’intégration, évaluent que tous les composants logiciels — matériels et logiciels — fonctionnent comme prévu dans un système complet. Ce sont les équipes d’assurance qualité des logiciels qui effectuent les SIT, et non les utilisateurs.
Les testeurs qui évaluent la fonctionnalité telle qu’elle est livrée sont généralement préparés à vérifier également la fonctionnalité de l’application en tant que solution globale et intégrée. Le SIT est souvent un processus de test plus technique que l’UAT. Les testeurs conçoivent et exécutent le SIT, car ils se sont familiarisés avec les types de défauts courants dans l’application tout au long du SDLC.
La phase SIT précède l’UAT. Comme l’expertise technique entre les utilisateurs et les testeurs varie considérablement, les deux groupes démographiques sont susceptibles de trouver des défauts très différents entre UAT et SIT. SIT découvre souvent des bogues que les tests unitaires n’ont pas attrapés — des défauts qui reposent sur un flux de travail ou une interaction entre deux composants de l’application, comme un ordre séquentiel d’opérations.
Un petit chevauchement entre SIT et UAT pourrait être souhaitable, en tant que deuxième vérification des fonctionnalités de l’app. Cependant, le fait que le SIT et l’UAT interviennent tous deux à la fin du processus SDLC, près de la sortie de l’application, est souvent le seul point commun entre ces deux formes de test.
Il s’agit d’un test d’évaluation de l’application.