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.
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.
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.
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)
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)
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).
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.
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.
Le deuxième niveau de test est au niveau de l'intégration des composants de votre site entre eux: les blocs d'instructions, les fonctions, les classes vont être mis ensemble pour produire un résultat de plus haut niveau. L'articulation de deux composants ou plusieurs d'entre eux vise normalement à faire une action. L'idée est de verifier que l'action de plus haut niveau est bien gérée.
Par exemple, un composant de mon code permet demande un prénom, que l'utilisateur rentre. Un autre permet de créer une ligne dans une base de données, dans la table Utilisateur. Il va falloir tester que l'action "création de compte" qui articule les deux fonctionne correctement. En d'autre termes, l'idée est de verifier que l'enchainement entre les composants produisent les sorties voulues en fonction des entrées.
Dans l'exemple, ne seront testés que les entrées via le premier composant pour ne verifier que les sorties du deuxième.
Comme pour les tests unitaires, on définit les comportements attendus selon les cas, et on note les résultats attendus. On écrit les tests correspondants. Enfin, on code ou on réalise les tests pour vérifier que les résultats sont ceux attendus et on corrige, valide et/ou rédige le rapport de test.
Les tests d'intégration sont des tests de plus haut niveau, et se font une fois que l'ensemble des composants a été validés via les tests unitaires. Il est intéressant de les valider dès que les tests unitaires ont été faits.
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.
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.
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.
Statut du système visible
Cohérence entre le système et le monde réel
Contrôle utilisateur et liberté
Cohérence et conventions
Prévention de l'erreur
Reconnaissance plutôt que rappel (mémoire)
Flexibilité et efficacité de l'utilisation
Esthétique et conception minimaliste
Aide à l'utilisateur pour reconnaitre, diagnostiquer et réparer les erreurs
Aide et documentation
Guidage
Incitation
Groupement / Distinction entre Items
Groupement / Distinction par la localisation
Groupement / Distinction par le format
Feedback Immédiat
Lisibilité
Charge de Travail
Brièveté
Concision
Actions Minimales
Densité Informationnelle
Contrôle Explicite
Actions Explicites
Contrôle Utilisateur
Adaptabilité
Flexibilité
Prise en compte de l’expérience de l’utilisateur
Gestion des Erreurs
Protection contre les Erreurs
Qualité des Messages d’Erreurs
Correction des Erreurs
Homogénéité / Cohérence
Signifiance des Codes et Dénominations
Compatibilité
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).
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