Je teste donc je suis

Choisir un thème

Lorsqu'on crée son blog, on regarde souvent les fonctionnalités de l'outil, mais on est surtout intéressé par le thème.

Chacun a une attente particulière d'un thème : on a tous une couleur préférée, un sujet de prédilection (cuisine, technologie, voiture...). Certains aiment également ajouter un tas de widgets facilement, ou pouvoir le personnaliser en changeant une couleur ou une image. Cela permet de se sentir chez soi.

Dans la nouvelle version d'OverBlog, l'utilisateur peut choisir son design, changer les options prévues dans le thème, mais également modifier le html, le css, afin d'avoir un thème qui correspond exactement à ce que l'on veut.

Et la qualité ?

Lorsqu'un nouveau thème est créé pour être proposé aux blogueurs, en tant que responsable qualité, je dois vérifier qu'il s'affiche correctement sur tous les navigateurs, avec toute sorte de contenus. Sans parler d'avoir les options qui permettent de plaire au plus grand nombre.

Lorsque nous avons ajouté les premiers thèmes, j'ai testé manuellement beaucoup de choses, refait les mêmes tests plusieurs fois. Avec le recul, je pense même n'avoir pas fait les mêmes tests sur chaque thème.

L'équipe ayant augmenté la cadence de livraison de thèmes, il y a de plus en plus de thèmes à tester.

Au delà de ça, l'équipe ajoute régulièrement de nouvelles fonctions utilisables dans les thèmes (ex : une fonction article suivant / précédent). Il faut alors faire modifer les anciens thèmes, les tester à nouveau...

Tests en équipe

Du retard s'étant accumulé dans les tests, j'ai décidé de faire participer l'équipe aux tests. Pour cela, j'ai préparé un document comportant une centaine de points à vérifier pour chaque thème, plus ou moins précis.

Certains points sont issus de tests précédents, de bugs s'étant déjà produits. D'autres sont issus de connaissances accumulées dans le domaine depuis de longues années.

Chaque membre de l'équipe a choisi un thème (en veillant à ne jamais tester un thème que l'on a soi-même créé: le test ne saurait être fiable dans ces conditions). Ne restait alors plus qu'à vérifier la checklist.

Checklist : SEO

• Titre du blog sur la home, de préférence en h1
• Description du blog affichée sur la home
• Pas de répétition abusive du titre et de la description du blog
• Sur une page d'article, le titre et le lien vers l'article ne sont pas répétés
• Le title de la page d'accueil inclut le titre du blog
• Le title d'une page d'article contient le titre de l'article
• Le title d'une recherche contient le keyword
• Le title d'une catégorie contient la catégorie
• La meta description contient la description du blog sur la home
• La meta description contient l'extrait de l'article sur les pages "article seul"
• Les widgets et les articles ont des titres de forme h* (h2, h3...)
• Le flux RSS est renseigné et l'url est juste

Checklist : ergonomie

• Le titre est cliquable et renvoie sur l'accueil
• L'attribut title du titre du blog contient la description du blog
• L'attribut title du titre des articles contient un extrait de l'article
• Il y a un lien vers la page contact
• Le champ de recherche a un placeholder
• Un message apparait quand il n'y a pas de résultat
• Lors d'une recherche, les articles sans titre peuvent être ouverts
• Les tags sont affichés par leurs noms, pas par leur url
• Les suites de tags sont séparées par un élément visuel : # , /

Checklist : webperf

• Vérifier que les js chargés sont en nombre limité
• Si une option permet de désactiver une fonction, le JS associé est désactivé
• Les js qui le peuvent sont placés en pied de page
• Poids total de la page inférieur à 3 Mo
• Pas d'erreur 404 dans les fichiers / images

Checklist : options du thème

• Prévoir une option article complet / extrait
• Pas de lien "en dur" vers une url interne à créer par le blogueur
• Pas de saisie inutile de valeur
• Ne pas hésiter à faire changer les couleurs principales du thème
• Si une image est utilisée "par défaut", permettre de la changer
• Permettre de choisir les modules à afficher / masquer
• Penser à l'ajout des comptes de réseaux sociaux
• Les options ont des valeurs par défaut
• Le type des options est adapté
• Prévoir l'ajout de Google analytics / webmaster tools / msn tools

Checklist : widgets

• Prévoir un module listant les pages
• Prévoir un module affichant la biographie de l'auteur, sa ville, son pseudo
• Dans le module "bprofil"io", afficher lien + logo vers les réseaux sociaux
• Prévoir un module archive, affichant les années, interactivité pour afficher les mois
• Prévoir un module tags, qui affiche les tags.d'utilisation

Checklist : article

• Informations de base affichées : titre, date, auteur, tags
• Les images des sections texte sont alignées correctement
• Mise en page correcte : listes (puce + numérotées)
• Mise en page correcte : gras, italique, del, liens
• Mise en page correcte : titres, preformatted
• La section image prend la largeur maximale disponible
• Ajouter une "fancybox" ou script assimilé pour zoomer sur les images
• Le slideshow fonctionne dans la section image
• Les vidéos ne sont pas coupées en largeur
• Le player de musique s'affiche et fonctionne
• Pour une section lien, le lien, la vignette, l'extrait sont placés correctement
• Les citations apparaissent de façon à ressortir
• L'auteur d'une citation est affiché clairement
• Les cartes s'affichent entièrement
• Le curseur indique qu'on peut cliquer sur la carte
• Pour les sections image, vidéos, musique, carte... la description est alignée avec le contenu
• Une suite de sections s'affiche correctement
• Les articles sans titre peuvent être visités (ajout d'un lien "Read more"...)
• Les articles venant de Twitter s'affichent correctement
• Les articles venant de FB s'affichent correctement (image, texte..)
• L'article dispose d'options de partage (Twitter, FB, G+, Pinterest...)

Checklist : autres contenus

• Sur une page d'article seul, on affiche les commentaires
• Sur une page d'accueil, on affiche une information pour indiquer les commentaires
• La zone de commentaire apparait dans toute sa largeur
• Si les commentaires sont désactivés, pas de lien / d'affichage des commentaires
• Sur les pages listant les articles (accueil, recherche, tags...), afficher la pagination
• Quand on passe sur la page 2, ce sont les articles suivants qui apparaissent
• Sur une page d'article, afficher un lien vers l'article suivant / précédent
• La page de contact s'affiche correctement

Checklist : divers

• Si le design est responsive, cela fonctionne
• Les textes affichés passent par la fonction de langue (permet la traduction du thème)
• Pas de textes localisés dans les images (pour faciliter le changement de langue)
• Affichage parfait sur IE9
• Affichage correct sur IE8
• Affichage parfait sur Chrome
• Affichage parfait sur Firefox
• Affichage correct sur Safari
• Les options de commentaires (Disqus, Facebook..) fonctionnent
• Les options des widgets sociaux fonctionnent
• Les options de thèmes fonctionnent pour changer l'apparence : couleurs, police...
• Les autres options sont opérationnelles.

Watir-webdriver est une librairie qui permet de contrôler le navigateur : vous écrivez un code qui vous permet de simuler le comportement d'un utilisateur. Cela vous permet d'automatiser des tests, afin de pouvoir les effectuer systématiquement, sans intervention humaine. Voici une petite demonstration de watir-webdriver. Basique, il vérifie uniquement que le lien contact est bien présent, et que le mot qualité apparait sur la page.

# lutte contre : web.rb:3:in `require': no such file to load -- watir (LoadError)
require "rubygems"

# chargement de la libraire watir
require "watir-webdriver"

# ouvrir un navigateur
B = Watir::Browser.new
B.window.resize_to(800,600)

# Ouvrir le site
B.goto("http://web-quality.over-blog.com")

# Clignotement
B.link(:text, "Contact").flash

# Vérifier que le mot qualité est présent
if (!B.text.include?"Qualite")
  puts "Test Qualite KO"
else
  puts "Test Qualite OK"
end

# Fermeture
B.close

Pour résumer :

• on charge les libraires adéquates
• on ouvre un navigateur
• on va sur le site web à tester
• on effectue des actions et/ou de tests

Et voilà, le tour est joué. Ce code basique ne sera jamais utilisé tel quel : afficher un message d'erreur suffit pour quelques tests, qui prennent peu de temps. Mais pour des tests nombreux et longs, il faut pouvoir disposer d'un rapport d'erreur détaillé, etc.

Lorsqu'un visiteur se promène sur internet, à la recherche d'informations, de produits etc... il ne voit pas ce qui se passe derrière le site web :

• Il ne connait pas le langage HTML
• Il ne connait pas les différences de navigateurs
• Il ne sait pas ce qu'est un problème de charge
• Il ne sait pas ce qu'est la norme du w3c

Par contre, ce qu'il sait, c'est que le site s'affiche mal sur son écran, que le bouton ne fonctionne pas, qu'il ne peut pas créer son compte ou qu'il ne peut pas passer sa commande. Pour lui, c'est un défaut, un bug. C'est une déception pour lui, et il pourrait ne jamais valider sa commande, ou venir à nouveau sur votre site.

Pour faire un site web de qualité, plusieurs choses à respecter : il faut être au courant de toutes les normes (HTML, CSS, JS), des dernières mises à jour des navigateurs, et de leurs limites.

Et bien évidemment, il faut tester en permanence le site pour s'assurer que les nouveautés fonctionnent, mais également pour vérifier que ce qui existait déjà n'a pas été "cassé" par les nouveaux développements.

Cet article n'a rien à voir avec l'écologie, mais beaucoup avec l'environnement.

Lorsque l'on teste un projet web, il faut toujours savoir "où" nous testons : est-on sur un serveur de test ? de développement ? de pré-prod ? de production ?

Lorsque vous êtes en pleine création d'un projet, il est intéressant de définir clairement, le plus tôt possible, les différents environnements et leurs stratégies de tests respectives.

L'intégration continue sera d'autant plus simple que vous aurez défini clairement les règles du jeu.

Environnements pour un projet web

• Environnement de pré-prod : ce serveur doit être stable, mis à jour très régulièrement, comporter toutes les nouveautés.
• Environnement de développement : utilisé par tous les développeurs, il peut être soit centralisé, soit individuel (avec des machines virtuelles).
• Environnement de prod : c'est le serveur qui sera utilisé par vos utilisateurs/clients. Il doit être choyé, aux petits oignons.

Comment organiser le travail (du point de vue de la qualité)

• Les développeurs codent sur le serveur de dév.
• Les tests unitaires (côté php ou js) sont aussi jouer sur le serveur de développement.
• L'environnement de préprod est posé en tant que référent : il est mis à jour régulièrement, avec des versions stables. Pour contrôler sa mise à jour, un outil d'intégration continu (nous utilisons hudson) qui rejoue tous les tests unitaires de tous les sous projets.

Comment organiser les tests fonctionnels

• Pour les tests manuels, en fonction du test, il faut le faire sur l'un des environnements. Il est parfois utile de le faire sur chaque environnement, afin de pouvoir dire "ce bug particulier n'existe pas encore en prod, mais il est apparut sur la pré prod".
• L'environnement de prod peut être utilisé pour vérifier la présence d'un bug, mais ne devrait pas être utilisé pour des tests automatiques.
• Pour les tests automatiques, il y a 2 écoles: Lancer sur la version de pré-prod. Défaut principal : il n'est pas toujours évident de créer des tests fonctionnels avant de voir la fonction tourner réellement. Chaque nouvelle fonctionnalité aura donc ses tests ajoutés dans les jours qui suivront, et pas avant. Faire lancer les tests par les développeurs en environnement de développement. C'est plus coûteux à mettre en place (il faut par exemple former tous les développeurs à l'analyse du rapport de tests...), mais cela peut améliorer la détection des bugs.

Pour moi, ces deux écoles ne s'excluent pas. Je les vois plutôt comme des étapes. C'est d'ailleurs le cas dans ma société : lors de la refonte du projet, il a été décidé que les tests fonctionnels automatiques devront pouvoir s'exécuter partout (y compris la prod). Pour l'instant, ils peuvent être exécuter sur la pré prod, avec une configuration prévue théoriquement pour qu'ils puissent être exécuter sur d'autres environnements. (La gestion de profils de cucumber est parfaite pour ça)

Pourquoi est-il essentiel de connaître les environnements ?

Il m'arrive régulièrement de tester un bug sur un onglet, de faire autre chose, et de revenir dans mon onglet pour avoir d'autres informations au sujet des bugs. Et là, miracle, le bug est résolu. Pourtant, personne n'a modifié le code. Un enquête de quelques minutes permet de comprendre que le bug n'existe que dans un environnement particulier, et que j'ai changé d'onglet par inadvertance.

Cela peut avoir des conséquences plus grave. Pour un projet personnel, j'héberge un forum "privé". J'ai l'habitude de "stocker" ce forum sur mes sites successifs, dans un sous-domaine, et de faire suivre aux utilisateurs la nouvelle adresse, voire de mettre en place une redirection.

Erreur d'environnement

En novembre dernier, j'ai lancé un déménagement. (La qualité de service de mon hébergeur devenait déplorable avec un uptime passant parfois sous les 90%)

• Je verrouille l'accès en écriture sur l'ancien
• Je déplace la totalité des fichiers d'un serveur à un autre, tranquillement.
• Je copie la base de données.
• Je teste avec quelques utilisateurs le nouveau.
• Fin de l'opération.

Jusqu'à ce matin, lorsque j'ai vu un message d'erreur "Can't connect to MySQL server on anciendomaine.com". J'ai mal lu le message, et n'ai pas fait attention, et j'ai attendu quelques minutes, pensant à une maintenance sur mon hébergeur. Puis j'ai fini par réaliser que sur mon nouveau domaine, opérationnel depuis 4 mois, la base de données utilisée était toujours l'ancienne. Du coup, nouvelle copie des bases de données, modification du fichier config.php qui contenait les données pour la base, et voilà, tout est rentré dans l'ordre.

Si mon ancien domaine (et sa base) avait expiré avant que je m'en rende compte, j'aurais perdu une partie de l'historique. Pour un petit forum privé, cela n'aurait pas été trop grave. Mais pour un projet plus important, cela aurait pu provoquer des catastrophes.

Contexte

La société pour laquelle je travaille est en train de refaire son principal projet depuis le début. Au programme : changement de technologies. Nous lancerons ce nouveau projet d’ici l’été, et nous travaillons déjà depuis quelques mois sur le sujet.

Nous avons mis en avant la qualité, avec de l’intégration continue (Hudson, allié à Git), des TDD (Test driven development), des framework robustes : Symfony pour le php, YUI pour le javascript, des tests fonctionnels avec cucumber et watir… Et pour organiser tout ça, on passe à Scrum.

Beaucoup de changements, et les premiers tests sur le serveur de staging nous ont tous donné envie d’aller encore plus loin.

Action

Mais tout n’est pas rose dans notre monde : le serveur de staging n’était pas assez stable à mon goût. J’ai donc envoyé un mail à tous mes collègues concernés afin de mettre au clair la façon de travailler :

• Pas de mise à jour en milieu de journée (le staging est mis à jour chaque nuit avec les dernières versions stables des sous projets).
• Tests en amont, côté serveur de développement.
• Incitation à me consulter pour la mise en place des tests fonctionnels que j’aurais pu oublier.

Et bien évidemment, j’ai précisé dans le mail que j’étais ouvert à toutes les suggestions.

Réactions

Nous avions longuement rabâché qu’il fallait un produit de qualité, que nous devions tous tester le produit de façon à ne rien laisser passer.

En envoyant le mail, je ne m’attendais pas aux retours que j’ai eu. Je savais que certains point "techniques" ne feraient pas l’unanimité. Mais mes collègues ont été très intéressés, et m’ont montré qu’ils pensaient toujours "qualité". L’équipe a échangé pas mal de mail dans l’après-midi (cela faisait quelques semaines que je n’avais pas vu autant d’échange de mails sur un même sujet en aussi peu de temps). Des idées sont venus des développeurs, qui rejoignaient certaines idées d’améliorations que nous envisagions à moyen terme.

Tout cela pour dire qu’au final, la qualité d’un projet web, c’est aussi une histoire d’équipe : une équipe soudée, motivée peut faire de grandes choses dans le bon sens si on lui en donne l’opportunité.