Tests et qualité logicielle : créer des utilisateurs heureux

Normalement, les tests consistent simplement à trouver des bogues – « la suppression des défauts » – ce qui vaut la peine d’être fait. Mais les tests peuvent aussi consister à améliorer la qualité aux yeux des seules personnes dont l’opinion compte : vos utilisateurs.

Il existe au moins trois critères pour mesurer la qualité d’un logiciel :

• Aptitude à l’objectif : Les applications que nous livrons font-elles leur travail ?
• Processus de livraison fiable : Pouvons-nous livrer ces applications quand nous avons dit que nous le ferions ?
• Faibles coûts d’entretien : Notre organisation peut-elle vivre avec ces applications ?

La mauvaise nouvelle : la seule opinion qui compte sur « l’adéquation à l’usage » est l’opinion des personnes qui doivent utiliser le logiciel au quotidien dans le cadre de leur travail. Si vous n’êtes pas d’accord, rappelez-vous que lorsque (en tant qu’utilisateur) vous interagissez avec n’importe quel logiciel, c’est aussi votre définition de « l’adéquation à l’usage ».

Et tandis que Bugs ne sont pas la seule mesure de l’aptitude à l’emploi, c’est la partie qui agace le plus les utilisateurs.

Le coût des bogues

Par exemple, le principale raison les utilisateurs suppriment une application parce que l’application s’est plantée ou s’est figée ou a simplement affiché un message d’erreur (c’est 61 % de tous les utilisateurs). Bien que la suppression soit assez agressive, Rapports mondiaux sur les tests d’applications que près de la moitié de tous les utilisateurs sont moins susceptibles d’utiliser à nouveau une application si celle-ci fonctionne mal.

C’est pire : la mauvaise opinion de l’utilisateur ne se limite pas à l’application. Près de 90 % des Américains auront une opinion négative de la marque associée à une application peu performante ; près de 80 % des utilisateurs sont moins susceptibles d’acheter sur un site qu’ils jugent peu performant. Ne soyons pas surpris : si vous trouvez un cafard dans votre chambre d’hôtel, vous ne le faites pas dites: « Regardez, il y a un cafard. » Au lieu de cela, vous dites : « Cet endroit est infesté ! et déménager dans un autre hôtel.

Si vous pensez être immunisé parce que vous créez des « applications internes » utilisées uniquement par les employés de votre organisation… eh bien, vous vous trompez. Selon un Enquête G2, la moitié des employés sont mécontents au travail précisément à cause des logiciels qu’ils doivent utiliser. C’est tellement grave que 25 % des employés envisagent de quitter leur emploi à cause d’un mauvais logiciel.

Même si vous vous fichez de ce que pensent les utilisateurs, les bogues coûtent cher et probablement plus cher que vous ne le pensez : le coût d’un bogue en production est généralement sous-estimé.

Dans une entreprise pétrochimique, un « bogue régulier » dans une application (généralement déclenché par un stagiaire d’été utilisant l’application pour la première fois) était supposé affecter un service et coûter une heure de temps à corriger. Lorsqu’un développeur entreprenant a en fait enquêté sur l’effort nécessaire pour nettoyer après le bogue, il s’est avéré que la récupération du bogue s’est répercutée sur trois départements et a pris 8 à 10 heures pour être corrigée – une erreur de 800 % dans l’estimation d’un bogue que tout le monde connaissait et qui se produisait régulièrement.

Donc, nous ne devrions pas non plus être surpris qu’un Enquête IDC ont constaté qu’une heure d’indisponibilité coûte aux petites entreprises au moins 8 000 $ (pour les entreprises du Fortune 500, le coût est supérieur à 100 000 $ de l’heure).

Et les coûts ne se limitent pas aux débours : Parasoft ont constaté que les entreprises qui signalent des problèmes logiciels perdent en moyenne 2,3 $
milliard en valeur actionnariale (lorsque Provident Software a signalé un bogue qui l’a amené à recouvrer moins de la moitié de ses prêts à temps, le cours de son action a chuté à environ un quart de la valeur pré-annonce des actions et le PDG a démissionné).

Et, bien que les bogues soient plus chers et leur impact plus important que vous ne le pensez, le coût de la correction d’un bogue est généralement relativement faible. Ce « bogue régulier », par exemple, a été éliminé en ajoutant une modification au programme, qui a pris moins de deux heures pour coder, tester et publier.

Tester pour augmenter la qualité

C’est, bien sûr, pourquoi nous faisons des tests : Pour trouver des bogues. Mais, vraisemblablement, « adéquation à l’usage » signifie plus que « ne pas exploser » et quelque chose de plus comme « répondre aux besoins de l’utilisateur ». Malheureusement, la définition standard des tests ne vous permet que de « supprimer les défauts ». C’est généralement parce que l’assurance qualité est impliquée trop tard dans le processus.

Si ton AQ les gens sont impliqués le plus tôt possible – si la « définition de terminé » est développée avec l’assurance qualité à la table avec les utilisateurs et les développeurs, alors l’assurance qualité peut réellement ajouter de la qualité. Par exemple, une implication précoce permet à l’assurance qualité de développer les tests qui prouvent la « définition de terminé » afin que ces tests reflètent ce qui compte pour les utilisateurs le seul groupe dont l’opinion compte. De plus, à mesure que l’assurance qualité commence à effectuer des tests exploratoires, elle est en mesure de faire plus qu’une « chasse aux bogues » et peut enquêter activement sur les problèmes des utilisateurs.

Mais le véritable avantage d’avoir QA à la table avec les utilisateurs dès le début vient de permettre à QA d’impliquer les utilisateurs dans le processus de test :

• Si les utilisateurs peuvent participer au développement de tests (à l’aide enregistreurs de testpar exemple), vous obtenez alors des tests dont les résultats intéressent réellement les utilisateurs.
• Au fur et à mesure que l’application change en raison des commentaires des utilisateurs suite aux tests, les utilisateurs commencent à s’approprier l’application : c’est quelque chose qu’ils ont aidé à créer, et non quelque chose qui leur a été infligé.
• Si les utilisateurs impliqués dans les tests sont bien considérés dans la communauté des utilisateurs, ces utilisateurs fonctionnent comme des champions pour l’application et contribuent à son acceptation.
• En ensemençant l’environnement avec des personnes qui ont testé l’application et, par conséquent, savent comment l’application fonctionne, les coûts de formation sont réduits.

Enfin, comme effet secondaire, la perception des bugs en production change. Lorsque les utilisateurs voient le nombre de bogues diminuer au cours de la période de développement, un bogue qui passe en production est considéré comme un « bogue résiduel » d’un nombre beaucoup plus important que ces utilisateurs ont aidé à éliminer.

Bien sûr, tout cela n’est possible que si le QA a le temps de travailler avec les utilisateurs et, comme nous le savons tous, le QA n’a déjà pas assez de temps ou de budget pour faire tous les tests que nous voulons. Les tests automatisés aident ici en libérant des ressources d’AQ de les tests de régression (et positionne l’AQ sur, potentiellement, un test de régression tout). Si ces ressources sont ensuite utilisées pour réellement « augmenter la qualité » aux yeux de vos utilisateurs, alors les tests deviennent une activité à valeur ajoutée.

En d’autres termes : le test passe de « quelque chose que nous devons faire » à « quelque chose que nous voulons faire ».