Pourquoi les tests de produits doivent-ils durer si longtemps?

Cian est un auteur invité de notre partenaire truematter – des experts en expérience utilisateur qui aident leurs clients à gagner en efficacité et en engagement.

Il peut être tentant de réduire les tests de produit pour obtenir un produit de qualité supérieure. porte plus vite. Pourquoi devrait-il prendre si longtemps, de toute façon? Cian O'Connor explique pourquoi il s'agit d'un coin que vous ne devriez jamais couper.

Au moment où vous atteignez les dernières étapes de la création d'un produit numérique, vos heures sont généralement courtes et votre échéance proche. Vous faites tout ce que vous pouvez pour arriver à temps et dans les limites du budget. Et vous rencontrez toujours un obstacle de taille: vous devez vous assurer que tout fonctionne. Vous devez effectuer des tests de produit, ou ce que nous appelons des tests d’assurance qualité (AQ).

À ce stade avancé du projet, il est tentant de couper les angles pour atteindre la ligne d’arrivée. Vous vous demandez peut-être si votre équipe de développement a vraiment besoin de tout le temps nécessaire. Serait-il si mauvais de réduire leurs heures de test afin que vous puissiez déjà commencer?

La réponse courte est: oui. Si vous réduisez les heures de test, vous serez désolé. Je vais vous dire pourquoi.

Il y a de nombreuses années, je travaillais sur un projet avec un retard important. Chaque jour, le projet était retardé, cela coûtait plus cher à l'entreprise. Je suis sûr que vous connaissez cette situation. Peut-être avez-vous essayé de résoudre un problème similaire de la même manière que notre chef de projet: pour tenter de sauver le budget, il a décidé de réduire les tests d'assurance qualité.

Pendant un bref instant, cela a sauvé le projet. Notre chef de projet était un héros. Mais la réalité s'est installée lorsque le premier utilisateur a essayé d'utiliser notre logiciel. Soudain, le manque de tests devint douloureusement évident. Le lancement du produit a été un désastre complet et total. Pas génial pour nos utilisateurs ou pour l'entreprise.

Alors oui, vous devez tester si vous voulez un logiciel de qualité (ou même tout simplement utilisable). Mais franchement, économiser en réduisant le temps consacré aux tests est tentant. Après tout, faut-il vraiment prendre autant de temps?

Si votre équipe de développement est compétente, pourquoi leur code contient-il autant de bogues? Peut-être avez-vous simplement besoin de meilleurs développeurs pour créer des produits numériques sans bugs. Ensuite, vous réduirez le temps et l’argent dépensés en tests.

Faux.

Ne blâmez pas vos développeurs

Votre équipe de développement n'est pas le problème. Une équipe de développement différente aurait encore besoin de tout le temps nécessaire pour effectuer des tests approfondis. C’est parce que la plupart des problèmes logiciels ne sont pas causés par les développeurs. Ils sont généralement causés par:

• Données erronées
• Bibliothèques, navigateurs ou matériel tiers buggés
• Utilisateurs interagissant de manière inattendue avec les logiciels

Rien dans votre équipe de développement ne peut empêcher totalement ces problèmes de se produire. Seul un processus d'assurance qualité complet permet de détecter ces problèmes avant qu'ils ne se transforment en problèmes pour vos utilisateurs et votre entreprise.

Alors, que diable font vos développeurs avec toute cette période de test? Ils luttent contre les problèmes très réels et très complexes liés à la création de tout nouveau site, application ou suite logicielle.

Les données sont imprévisibles

Les logiciels sont toujours en ruine lorsque les équipes de développement parviennent enfin à intégrer des données réelles. C’est l’une des lois du développement à la peau de fer. Et peu importe la façon dont votre équipe planifie à l'avance, vos développeurs vont toujours trouver des données qui enfreignent les règles établies. Ils trouveront des données manquantes quand on leur dira que cela ne pourrait jamais arriver. Ils découvriront des manières imprévues d'utiliser les données.

Vos données sont le reflet du monde réel et, malheureusement, le monde réel est un endroit complexe, désordonné et imprévisible qui refuse de lire vos exigences. [19659004] La seule solution à ce problème est de tester votre code avec des données réelles. Cela vous aidera à identifier et à résoudre les problèmes avant que vos utilisateurs ne les trouvent. Couper ce coin peut signifier un échec pour votre projet, vos utilisateurs et votre entreprise. Donnez à vos développeurs le temps de réparer ce qui se casse. Les acheter en beignets ne ferait probablement pas de mal non plus.

Vous ne pouvez pas contrôler les outils tiers

Hormis créer de tout nouveau projet numérique à partir de zéro avec du silicium brut et du cuivre, vous devez vous fier à des outils tiers. ont déjà effectué une partie du travail pour vous. Mais chaque élément logiciel et matériel tiers sur lequel repose votre projet vous trahira. Cette bibliothèque supposée gagner du temps aux développeurs aura peut-être un bug obscur. Certains bizarreries bizarres dans le système d’exploitation vont casser chaque lien de page. Et inévitablement, votre site Web aura fière allure, sauf si vous le visualisez dans ce navigateur Web obstiné.

Ces problèmes ont été créés par d’autres développeurs d’une société différente et votre équipe de développement doit leur trouver des solutions de contournement. Ce n’est ni glamour ni excitant, mais c’est essentiel pour que des produits utilisables de haute qualité parviennent à la réussite. Et oui, cela prend du temps.

Les utilisateurs ne sont pas fiables

Le problème des utilisateurs est qu'ils ne font que rarement ce que vous souhaitez qu'ils fassent. Dès que vous mettez votre produit devant une personne réelle, elle fera quelque chose que vous n'auriez jamais anticipé. Et si vous n'avez pas fait de tests approfondis, ils endommageront certainement votre site ou votre application.

Chaque utilisateur cassera votre produit différemment. Certains sont des clickers compulsifs. D'autres ont des caractères dans leurs noms que votre base de données n'acceptera pas. Certains essaieront de taper War & Peace dans votre champ "Commentaires", ce qui fera que votre serveur rampera dans une boule et mourra. Il existe un million de façons d’abuser de votre produit. Vos utilisateurs en trouveront la plupart.

C'est pourquoi de nombreux produits connus et populaires, tels que Adobe Photoshop, ont de longues phases de test bêta. Avec suffisamment d'utilisateurs interagissant avec le produit, la plupart des bogues seront éventuellement trouvés. Mais vous n'avez probablement pas le luxe de milliers d'utilisateurs qui souhaitent tester votre site ou votre application gratuitement.

Heureusement, la plupart des entreprises ont au moins une personne qui aime casser des objets. Faites-en votre testeur QA en chef et laissez-les faire. N'oubliez pas qu'ils ont besoin de temps pour résoudre les problèmes et que votre équipe de développement a besoin de temps pour les résoudre.

Résoudre les problèmes numériques avant qu'ils ne deviennent des problèmes professionnels

Si vous voulez que les gens utilisent votre produit numérique, il doit fonctionner correctement. . C'est aussi simple que ça. Broken est inutilisable. Les tests d'assurance qualité consistent à identifier les problèmes imprévisibles très tôt avant qu'ils ne deviennent des problèmes d'expérience utilisateur et donc des problèmes pour votre entreprise.

Ce processus peut être long, mais il est tout aussi important que toute autre phase de création de votre site, de votre application ou de votre site. Logiciel. Ne réduisez pas les heures de QA en pensant que vous économisez du temps ou de l’argent. Vous vous retrouverez avec un produit buggy et inutilisable et vous devrez toujours passer du temps et de l’argent à régler des problèmes après le lancement de votre produit désastreux.

Vous voulez en savoir plus sur la création d'un excellent UX? Découvrez quelques astuces pour vous assurer que votre application présente une expérience utilisateur exceptionnelle dans ces entretiens avec Dean Schuster et Bekah Rice .