Introduction

Les sites web sont à la fois des systèmes techniques, et des systèmes utilisés par des personnes. Les tests doivent évaluer ces différents aspects:

• Technique:

  • toutes les fonctionnalités marchent quand elles doivent marcher

  • l'enchainement entre toutes les fonctionnalités marche correctement

  • la robustesse

  • la sécurité est gérée

  • le respect de certaines conventions

• Humain:

  • le site propose les fonctionnalités qui répondent au besoin de l'utilisateur dans le contexte du site

  • l'utilisateur peut trouver ces fonctionnalités

  • le site est accessible

  • le site permet de se tromper

  • le site respecte les conventions d'utilisation existantes pour en faciliter l'utilisation

Ce cours est une introduction rapide aux différentes techniques de test.

Qu'est-ce qu'un bug?

Un bug est un traitement ou un résultat non conforme à ce qui est attendu. Ceci implique que, pour empêcher les bugs, il faut faire en sorte que tous les résultats possibles et que toutes les possibilités d'exécution d'un programme soient prévus.

C'est précisément le but des tests. Le traitement attendu peut s'étudier d'un point de vue du programme, et le fait que le système se comporte de la manière attendue par les utilisateurs et en utilisation réelle nécessite d'autres types de tests.

Introduction aux tests unitaires

Le premier niveau de test est au niveau des composants de votre site: les blocs d'instructions, les fonctions, les classes etc. Un composant est un ensemble quasiment indépendant (ex: deux composants pourraient être codés par des personnes différentes) qui communique potentiellement avec d'autres composants.

1) Définir le comportement attendu pour chaque compostant de votre site, en termes d'entrées et de sorties.

La première étape est d'expliciter comment un composant doit se comporter dans (virtuellement) l'ensemble des cas possibles. Dans chaque cas (entrée), il y aura un comportement attendu de la part du module (sortie).

Par exemple, un composant de mon code permet demande un prénom, que l'utilisateur rentre. On peut avoir plusieurs cas de figure en entrée (un champ vide, des lettres avec des accents, des chiffres) et les sorties respectives prévues (ne pas accepter un champ vide et demande à l'utilisateur de rentrer un nom, accepter le prénom, indiquer qu'un prénom n'utilise pas de chiffres).

Livrable: Liste des spécifications définissant le comportement (traitement) et le résultat (sortie) en fonction de ce qui est fourni (entrées)

2) Définir les tests

Il faut ensuite définir les tests possibles de ces composants ou modules, pour vérifier qu'ils ont bien le comportement attendu défini à l'étape précédente. L'idée, en lien avec le point précédent, est de tester tous les cas possibles: lorsque le composant est utilisé correctement ou non, en fonction du comportant attendu dans théoriquement tous les cas.

Livrable: Liste des résultats attendus (sortie) en fonction de ce que l'on fournit aux modules (entrée)

3) Implémenter les tests

Les tests à effectuer sont connus à l'étape précédente, il faut ensuite les implémenter pour pouvoir les exécuter informatiquement. L'idée, en lien avec le point précédent, est de programmer un environnement de test, qui permet de tester les composants avec une serie de tests définis. Normalement, les tests unitaires sont strictement reproductibles à l'identique

Livrable: code prêt à être exécuter pour lancer les codes (donner un certain nombre d'entrées aux modules, et récuperer les sorties/résultats).

4) Faire les tests

Les tests sont exécutés. Selon les résultats, il est possible de passer à la suite, ou les correctifs doivent être apportés et les test repassés. L'idée, en lien avec le point précédent, est d'effectuer les tests programmés. On récupère alors le resultat pour voir si le composant a bien les sorties attendues en fonction des entrées. Les corrections sont apportées le cas échéant et on recommence les tests.

Livrable: le code ayant passé le test, ou un test avec un code corrigé. Un rapport peut être ajouté pour le suivi et la collaboration.

Lien avec l'activité de programmation

Les tests unitaires nécessitent de programmer des bouts de codes relativement indépendants les uns des autres et réutilisables. Cette vision permet, comme cela est le cas dans les méthodes orientées autour des tests et de la fiabilité, de programmer les composants et leur tests en même temps, pour développer directement des composants robustes.

Introduction aux Tests Système

A ce stade, votre système est assemblé et fonctionne techniquement (tests unitaires et tests d'intégrations). Il y a alors un certain nombre de critères qui peuvent être vérifiés afin d'en évaluer l'usage. Une première partie peut être testée en passant par une analyse (persona, parcours utilisateurs que l'on refait sans les utilisateurs, heuristiques). Un ensemble de tests peuvent être faits avec les utilisateurs.

Si l'on se place dans une démarche iterative de conception, les tests systèmes se feront sur les prototypes intermédiaires ou sur des maquettes.

Les cas d'usages

Si cela n'est pas fait au niveau des tests précédents, un certain nombre de dimensions sont à tester:

• Les usages "classiques" en vérifiant des utilisations ou des parcours utilisateurs. On peut utiliser des techniques à la conception (UX, ergonomie francophone) pour analyser les futures utilisations (tri de carte, gestion des connaisances, analyse d'activité, magicien d'oz). On peut également faire de l'observation, ou de la mise en situation. Dans ce cas, on peut laisser l'utilisateur interagir dans un contexte réaliste (écologogique selon l'expression consacrée) ou le mettre en situation: vous souhaitez faire ça, comment faites-vous?

• Les usages avec des erreurs "en toute bonne foi" en recréant le parcours d'un utilisateur qui se trompent à certains endroits (erreur de saisie, revenir en arrière, déconnexion, mauvais clic ou raccourci clavier etc.). En général, le parcours utilisateur permet d'identifier les points clefs où les erreurs doivent etre gérées de manière critique.

• Les usages "malveillants" en essayant volontairement de faire ou de faire faire des actions malveillantes à l'encontre de votre programme.

Heuristiques

Plusieurs heuristiques définissent une liste de critères qui peuvent être vérifiées pour chaque système. Il s'agit de principes de conception générale. Le concepteur peut les utiliser de deux façons: verifier si les principes sont respectés à la conception et les implémenter le cas échéant, ou les utiliser comme hypothèses à vérifier et évaluer lors d'expérimentations.

Heuristique de Nielsen:

10 règles de Nielsen

1. Statut du système visible

2. Cohérence entre le système et le monde réel

3. Contrôle utilisateur et liberté

4. Cohérence et conventions

5. Prévention de l'erreur

6. Reconnaissance plutôt que rappel (mémoire)

7. Flexibilité et efficacité de l'utilisation

8. Esthétique et conception minimaliste

9. Aide à l'utilisateur pour reconnaitre, diagnostiquer et réparer les erreurs

10. Aide et documentation

Heuristique de Bastien et Scapin:

Bastien et Scapin

1. Guidage

   1. Incitation

   2. Groupement / Distinction entre Items

      1. Groupement / Distinction par la localisation

      2. Groupement / Distinction par le format

   3. Feedback Immédiat

   4. Lisibilité

2. Charge de Travail

   1. Brièveté

   2. Concision

      1. Actions Minimales

      2. Densité Informationnelle

3. Contrôle Explicite

   1. Actions Explicites

   2. Contrôle Utilisateur

4. Adaptabilité

   1. Flexibilité

   2. Prise en compte de l’expérience de l’utilisateur

5. Gestion des Erreurs

   1. Protection contre les Erreurs

   2. Qualité des Messages d’Erreurs

   3. Correction des Erreurs

6. Homogénéité / Cohérence

7. Signifiance des Codes et Dénominations

8. Compatibilité

Les normes et les standards

Plusieurs normes et standards existent, en particulier pour le web avec le très représenté W3C.

Le W3C, et ses composants comme le WAI et le WCAG pour l'accessibilité sont des références en standard du web.

Par exemple, un partie de votre code peut être vérifiée avec l'outil du W3C: https://validator.w3.org

Quelques premières informations sur les standards du W3C: https://www.w3.org/International/getting-started/language.fr

Pour l'accessibilité, voici une introduction au WAI (https://www.w3.org/WAI/fundamentals/accessibility-intro/fr) et les règles associées via le WCAG: https://www.w3.org/WAI/standards-guidelines/wcag/fr

En plus des normes explicites et codifiées, on peut reprendre les codes existants ("convention"). Une analyse des sites et des applications équivalentes peut permettre de proposer des interactions cohérentes avec l'existant ou de comparer les interactions du site. A titre d'illustration de l'importance de suivre les conventions établies, voici une experience dite "Evil UX" qui prend à contrepied tous les codes existants: https://userinyerface.com/

Lors de l'évaluation de votre site, vous devez, en général, ne pas prendre à contre pied les conventions d'interactions répendues pour votre public cible. En revanche, il est souvent intéressant de les questionner (les interactions conventionnelles sont-elles optimales/améliorables?) voire de les dépasser (que peut-on proposer de nouveau, même sans faire le contraire des conventions actuelles?).

Dans ce cadre, vous pouvez proposer de nouvelles interactions, et les évaluer en lien avec vos objectifs (critères) lors de tests ou d'experimentation. Un test, en théorie, sert à vérifier ou évaluer quelque chose (hypothèses).

Experimentation

Il est possible de faire plusieurs types d'experimentation pour vérifier des hypothèses. On peut vérifier que l'on atteint un objectif, comparer deux solutions. Parmi les formes possibles:

• Questionnaires standardisés, voici quelques exemples:

  • UX: SUS, UEQ, AttrakDiff

  • Charge mentale: Nasa-TLX

  • Réalité virtuelle: IPQ, VRSQ

• Mesures quantitatives:

  • temps

  • nombre de clic

  • nombre de retours en arrière

  • signaux physiologiques (bpm par exemple, ondes alphas avec un électroencéphalogramme )

• Entretiens, interview, questionnaires, mesures avec vos propres indicateurs

Les tests avec utilisateurs peuvent prendre de nombreuses formes. Il est impératif d'être vigilant sur le fait que l'on évalue bien ce que l'on veut évaluer. Cela vaut pour les cas où l'on dispose d'assez de ressources et de temps, mais aussi en cas de ressources limitées (quick and clean et non pas quick and dirty). Voici quelques exemples de ce concept dans la présentation de la Guerilla UX, qui rappellent des techniques UX classiques et leur version UX : Guerrilla UX de Carine Lallemand