Slides Lyon Testing Meetup #8 – Demo « Du cas de test à l’automatisation »
Bonjour
Voici les slides utilisés durant le meetup « Lyon Testing Meetup #8 – Demo « Du cas de test à l’automatisation »
Bonjour
Voici les slides utilisés durant le meetup « Lyon Testing Meetup #8 – Demo « Du cas de test à l’automatisation »
Nous avons vu dans un précédent article que l’objectif premier d’une User Story (US) est de définir un besoin utilisateur recueilli via une expression de besoins qui elle-même adresse un ou des problèmes bien précis. A la différence d’une spécification utilisateur une User Story se veut plus courte, précise et va remplacer la documentation utilisateur que l’on retrouve sur les gros projets.
Nous avions vu dans un précédent article qu’il était possible de mesurer le temps de chargement d’une page web depuis une console navigateur. La donnée remontée est précise mais on reste dépendant du réseau sur lequel on se situe. Il peut être intéressant en effet de mesurer un temps de chargement de page web depuis d’autres endroits de la planète. En effet les mesures depuis la console ne sont vraies que pour votre environnement/votre accès à internet mais comment cela se passe depuis un autre endroit de la planète ? Y a-t-il vraiment un impact ? J’ai envie de répondre « Oui ». Mais allons le démontrer.
Bonjour à tous les participants du second Lyon Testing Meetup, ainsi qu’à tous ceux intéressés par les tests de perfomance,
Un temps de chargement trop long ou un écran qui rame et l’utilisateur va automatiquement quitter le site aussi vite qu’il est venu (on estime à 4 secondes le temps d’attente maximum pour un utilisateur web). Mais avant même que l’utilisateur arrive sur votre page il faut qu’il la trouve et les robots comme Google bots auront tendance à mieux référencer les sites se chargeant en moins de 2 secondes.
Il est donc très important de prendre en compte le temps de chargement d’une page web.
Il existe différentes façon de mesurer le temps de chargement d’un page web.
On retrouve:
Les spécifications sont souvent une cause majeure de l’échec d’un projet. De mauvaises spécifications peuvent entraîner un manque de vision sur le produit attendu, des fonctionnalités redondantes/contradictoires.
Le but de l’utilisation des « user stories » est de permettre de répondre plus rapidement et avec moins de coût au changement rapide des exigences du monde réel.
En méthode agile, la US est écrite pour partager la vision développeur/testeur/projet à travers des revues fréquentes et non formelles en même temps que celles-ci sont rédigées/modifiées.
On retrouve ce partage également dans les cycles en V au travers de la notion des revues d’exigences/spéc très formelle après que celle-ci soit rédigée (moins d’A/R mais processus très figé – pas de modification en direct).
Les « user stories » décrivent les fonctionnalités qui seront utiles. Les « user stories » sont composées de trois aspects (principe des 3C): …
Les tests exploratoires prennent de plus en plus d’importance dans le milieu du test.
Ces tests permettent la libre expression d’un testeur sans suivre un plan de test.
Pour effectuer ces tests pas besoin d’outil lourd donc.
Voici la présentation d’un petit plugin Chrome très pratique « Exploratory Testing Chrome Extension ».