Assurance qualité

L'assurance qualité, souvent abrégé QA en anglais, permet de valider qu'un site correspond aux exigences attendues et de qu'il ne contient pas de bogues 🐛. À l'aide de tests manuels ou automatisés, différents aspects du site sont mis à l'épreuve. Le but est d'identifier les erreurs, oublies ou mauvaises interprétations des requis.

Pourquoi est-ce important?

Le plus tôt un bogue est identifié, le plus tôt il peut être réglé. Lorsqu'un site est bien testé, il est fiable, sécuritaire et performant. Ces qualités évitent les mauvaises surprises, permettent de réduire les coûts d'entretiens et contribuent à augmenter le taux de satisfaction/confiance des utilisateurs envers le site.

Par exemple, une assurance qualité adéquate permet d'éviter ce type de situations:

Types de tests

Test visuel 👁

Les designers font attention au moindre petit détail. Il est donc normal qu'ils soient exigeants lorsque vient le moment de traduire leurs maquettes en page web. Malheureusement, étant humain, il est courant que certains éléments ne soient pas parfaits du premier coup:

  • Est-ce la bonne fonte?

  • Est-ce que ce bouton est trop petit?

  • Est-ce vraiment la bonne couleur?

La liste peut s'allonger rapidement, surtout après un certain temps à travailler sur un projet où certains éléments deviennent presque imperceptibles tellement nous sommes habitués de les voir, d'où l'importance d'avoir un regard frais d'une personne externe afin de comparer le résultat produit aux maquettes originales afin de s'assurer que la vision du designer est respectée.

Test de bout en bout ↔️

Du point de vue d'un utilisateur, si j'utilise un site de façon cohérente afin d'accéder à un résultat spécifique, suis-je en mesure de le faire?

Par exemple, pour tester si un système de commandes en ligne fonctionne, si j'ajoute un élément dans le panier, que j'accède au panier, que je confirme mon achat, que j'entre mes informations de livraison et mes informations bancaires, est-ce que la transaction est traitée et si oui, est-ce qu'une page de confirmation me résumant mon achat m'est affichée?

Monkey testing 🐒

Le "Monkey testing" consiste à utiliser un site web comme un singe le ferait. C'est à dire sans compréhension particulière du site, en agissant de façon parfois aléatoire et inattendue.

Par exemple, que ce passe-t-il si je quitte à la troisième page d'un formulaire en cinq étapes? Que ce passe-t-il si j'appuie trois fois rapidement sur le bouton soumettre d'un formulaire d'inscription? Est-ce que trois comptes seront créés? Si je redimensionne ma page après la fin de son chargement, est-ce que son affichage brisera? Ainsi de suite.

Test de compatibilité

Ces tests garantissent que le site web fonctionne tel que spécifié sur différent type d'appareils, systèmes d'exploitation et navigateurs. Généralement, la personne en charge de ces tests a accès à plusieurs appareils en fonctions de la liste établie d'appareils supportés par le projet.

Il est aussi possible que cette personne ait recours à des logiciels permettant de démarrer des machines virtuelles, comme: Browserstack ou encore Cross Browser Testing afin de tester une liste d'appareils très large.

Par exemple: Sur un iPad mini de 3e génération, si l'utilisateur utilise Safari, est-ce que le comportement du site correspond aux attentes?

Test de performance 💪

Un site peut fonctionner, mais avoir des performances décevantes. Il est donc important d'établir des exigences de base et de s'assurer que le résultat est conforme à celles-ci. Par exemple, une exigence pourrait-être qu'un site charge en moins de deux secondes ou encore qu'il obtienne un pointage de 90 ou plus sur un outil permettant de l'évaluer, tel que: Lighthouse ou Pagespeed Insights.

Système de gestion de projet

Dans un système de gestion de projet, par exemple Trello, l'assurance qualité se traduit généralement par l'ajout de colonnes.

Par exemple, dans un projet Kanban classique ("To do", "In progress", "Done") lorsqu'un développeur termine une tâche, il peut la placer à "Done". Indiquant ainsi qu'il a terminé son développement. Cependant, comment savoir si le résultat est visible en ligne ou uniquement sur son poste? L'ajout d'une colonne "Ready to QA" permet d'indiquer que non seulement que la tâche a été complétée, mais qu'elle est aussi disponible en ligne.

Lorsqu'un billet se retrouve dans cette colonne, il devient possible pour une deuxième personne, n'ayant pas été impliqué dans son développement, de valider sa conformité. Il peut donc changer le billet dans la colonne "QA in progress" afin de signaler qu'il entame sa validation.

S'il respecte les exigences, le billet peut finalement être glissé dans une colonne intitulée "Production ready" ou un terme équivalent. Si au contraire la personne remarque que certains éléments ont étés oubliés ou ne fonctionnent pas comme souhaité, le billet est alors remis au sommet de la colonne "To do" avec des commentaires détaillant le ou les problèmes rencontrés. Pour éviter toute confusion, le billet est généralement bonifié d'un libellé, par exemple Bug indiquant la raison de son retour soudain dans la colonne "To do".

Il est aussi possible de créer un nouveau billet pour expliquer spécifiquement un bogue. Cette approche est particulièrement utile si plus d'un bogue est découvert en lien avec un billet. Ainsi, il est plus facile de suivre la progression de la résolution de chaque bogue et éviter de confondre certaines informations.

Rédaction d'un bogue

Lorsqu'un bogue est rencontré et que nous ne somme pas la personne en charge de le corriger il est impératif d'être le plus précis possible dans sa description.

Par exemple, si un problème est rencontré à La Presse et que son descriptif se limite à:

"La page d'article n'affiche pas comme il faut."

Beaucoup de temps risque d'être investi une deuxième fois à cerner le problème.

Où le problème est-il visible?

  • L'application mobile, La Presse+, le site web?
  • PC ou Mac?
  • Sur tous les navigateurs?
  • Dans une résolution d'écran en particulier?
  • etc.

Qu'est-ce qui pose problème?

  • La mise en page est brisée?
  • Une faute d'orthographe est présente?
  • Une image est hors propos ou mal recadrée?
  • La mauvaise personne est créditée?
  • etc.

Exemple de rédaction

Environnement: Site web
Sévérité: Moyenne
Url: https://www.lapresse.ca/mon-article
Système d'exploitation: MAC
Navigateur: Safari
Résolution: 1200 x 700px
Description: Le pied de page est tronqué.
Étapes de reproduction:

  1. Ouvrir la page en 992px de large ou moins.
  2. Descendre en bas de la page complètement.
  3. Agrandir la page pour atteindre 1200px de large ou plus.
  4. Une partie du pied de page devient inaccessible.

Et idéalement une capture d'écran montrant clairement le problème.