Pourquoi avons-nous besoin de tests d'acceptation utilisateur (UAT)?

Auteur: Judy Howell
Date De Création: 5 Juillet 2021
Date De Mise À Jour: 1 Juillet 2024
Anonim
Pourquoi avons-nous besoin de tests d'acceptation utilisateur (UAT)? - La Technologie
Pourquoi avons-nous besoin de tests d'acceptation utilisateur (UAT)? - La Technologie

Contenu



Source: Lightcome / iStockphoto

À emporter:

Une fois le logiciel soumis aux tests unitaires, d'intégration et de système, le besoin de tests d'acceptation peut sembler redondant. Pourquoi les tests d'acceptation utilisateur (UAT) sont-ils toujours importants? Ici, découvrez les avantages de l’UAT et pourquoi il est unique.

Demo And Die!

Avez-vous déjà livré une présentation ou une formation à un client et quelque chose se passe à mi-chemin? Ou avez-vous déjà donné à quelqu'un des instructions et réalisé que vous aviez manqué quelque chose, ou cela n'a pas fonctionné comme vous l'espériez? Au cours de chacune de ces instances, vous adoptez le point de vue de l'utilisateur final et travaillez avec le logiciel dans ce personnage. Il est fort probable que vous ayez agi différemment parce que vous pensiez en tant qu'utilisateur plutôt qu'en tant que développeur.


Entrez dans la peau des utilisateurs

L'unique angle de test d'acceptation utilisateur (UAT) est de tester le logiciel en tant qu'utilisateur final. Le logiciel est conçu pour donner aux utilisateurs des résultats tangibles. Par exemple, les sites de commerce électronique permettent aux clients d’acheter des produits. Lorsqu'un client passe une commande, le logiciel de sites de commerce électronique en informe l'administrateur du magasin, afin que l'article sélectionné puisse être extrait et emballé pour l'expédition. Il peut y avoir différents types d'utilisateurs de logiciels. Cette phase de test permet donc à l'équipe de développement de vérifier que les utilisateurs finaux obtiennent les résultats logiciels attendus.

Une brève histoire de l'UAT

Avant l'avènement d'Internet, la plupart des logiciels étaient déployés pour un public d'utilisateurs connus. Si une entreprise développait un logiciel pour un client, un responsable désigné avait le pouvoir de vérifier que le logiciel remplissait les conditions du contrat. Ceci était censé représenter un point où le logiciel était "adapté à l'utilisation", ce qui a été réalisé en sélectionnant des représentants des utilisateurs finaux pour effectuer des tests et fournir un rapport avec les résultats. Étant donné que les utilisateurs constituaient un groupe fermé connu, chacun pouvait être formé à l'utilisation du logiciel, généralement au moyen d'étapes de test très détaillées. La devise du jour était que plus de détails étaient meilleurs.


Alors que de plus en plus de logiciels étaient développés pour les clients sur le Web, le public des utilisateurs finaux devenait plus ouvert. Il n'était plus possible d'identifier et de former tous les utilisateurs finaux probables. La conception logicielle devait donc insister beaucoup plus sur la convivialité et devait être facilement compréhensible, même avec un minimum d'informations fournies. UAT a donc dû changer pour répondre à ces exigences.

UAT vous dit à quel point le système est utilisable

Ainsi, non seulement UAT nous indique l'étendue des fonctionnalités d'un logiciel, mais il indique également à quel point il est utilisable. La plupart des UAT sont mieux exécutés par des personnes qui comprennent l'utilisateur final ciblé qui expérimentera le logiciel avec peu de connaissances préalables et qui peut donner une indication fidèle de la facilité d'utilisation du logiciel et des améliorations à apporter.

Qui peut effectuer UAT?

En tant que logiciel de test, les développeurs se souviennent des détails relatifs à l’écriture du système. Cette connaissance peut influencer les tests et les développeurs peuvent prendre des mesures différentes de celles des utilisateurs finaux, par exemple en effectuant des étapes plus rapidement ou en ignorant des détails précis qui pourraient prêter à confusion pour les utilisateurs finaux. Ainsi, les développeurs ne sont pas les meilleurs candidats UAT. Alors qui est-ce?

De nombreuses organisations emploient des équipes de test spécifiques qui ne participent ni à la conception ni au développement techniques. Les plus petites organisations attribuent les tests au personnel ne faisant pas de développement, comme ceux qui effectuent des tâches administratives, ou utilisent les services d'une entreprise externe. Certaines organisations utilisent ce que l'on appelle des "tests de couloir", en sélectionnant littéralement des membres du personnel qui ne sont pas activement employés dans le projet et en leur demandant d'essayer le système du point de vue de l'utilisateur final. Un exemple serait la commande de produits en ligne.

Après des tests internes, des phases de tests pilotes ou bêta peuvent avoir lieu, le logiciel étant mis à la disposition de petits groupes de "vrais" utilisateurs invités à utiliser le produit gratuitement ou à prix réduit, en échange d'un retour d'informations détaillé.

Pas de bugs, pas de stress - Votre guide étape par étape pour créer un logiciel qui change la vie sans vous détruire


Vous ne pouvez pas améliorer vos compétences en programmation lorsque personne ne se soucie de la qualité des logiciels.

Les étapes UAT progressives avec des publics variés augmentent la confiance en la convivialité du logiciel. Combinés aux phases de développement itératif, plusieurs cycles UAT peuvent être exécutés pour tester les nouvelles fonctionnalités au fur et à mesure de leur livraison, tout en vérifiant les fonctionnalités précédentes.

Les bons testeurs UAT sont curieux de voir ce qui se passe s’ils empruntent différents itinéraires pour atteindre un objectif particulier. Après tout, chacun aborde l'utilisation du logiciel de différentes manières. Si de nombreuses possibilités peuvent être couvertes par un petit groupe de personnes, la confiance du logiciel en mode de fonctionnement est plus grande.

Succès et échec

Les processus UAT doivent vérifier que chaque type d'utilisateur de logiciel obtient les résultats tangibles requis pour les flux de réussite et d'échec.

En cas de succès, un utilisateur final obtient un résultat attendu, tel que la commande d'un produit. En cas d'échec, le logiciel prend en charge l'utilisateur final par le biais d'une certaine forme de scénario d'erreur, par exemple lorsqu'un client fournit des informations de paiement par carte de crédit non valides.

Pour vérifier la fonctionnalité, certaines informations doivent être fournies aux testeurs. Sinon, ils ne savent pas ce que le logiciel est censé faire. Toutefois, pour tester la convivialité, cette opération doit être minimale, en fonction des tâches ou des besoins, tels que l’achat de «x» (produit) et le paiement de «y» (à l’aide des détails de votre carte de crédit). Il incombe aux testeurs de noter les observations, les succès et les échecs.

Avantages UAT

Un bon UAT a pour avantage essentiel de maintenir les coûts de maintenance en cours aussi bas que possible. Il est moins coûteux de résoudre rapidement les problèmes de fonctionnalité et d’utilisabilité. Il est beaucoup plus difficile de corriger un bogue quand il y a plus de code autour pour le test de régression ou si le développeur d'origine est indisponible.

L’UAT exécutée en plusieurs étapes et avec différents types d’audiences de test offre des possibilités optimales d’identifier et de réparer les problèmes d’utilisabilité / fonctionnalités brisées au cours des premières phases de test. Le fait de garder les objectifs UAT au niveau des tâches et des exigences permet aux testeurs d’observer et de remarquer beaucoup plus et même d’essayer des étapes en dehors de la portée fournie par les développeurs.

Les commentaires des cycles UAT peuvent être intégrés aux itérations de développement ultérieures, ce qui augmente la robustesse et la convivialité des logiciels. Même au bon moment, même les phases de test bêta peuvent compléter les activités de marketing et de vente en fournissant des références et des retours d’études de cas.