Sudweb, j'en avais parlé il y a 2 ans, en 2012. Cette année, ça se passait à Toulouse, j'y suis donc retourné. Le changement, c'est que j'y étais uniquement en tant que "spectateur".

Vendredi : des conférences et des papotages

Le vendredi, c'est le jour des conférences. Je ne les citerais pas toutes, mais certaines m'ont bien marqué :

  • La culture d'entreprise, vu par Kevin Goldsmith.
    J'ai eu un peu du mal à tout suivre en anglais de bon matin, mais intéressant, et finalement, cette notion de culture est revenu dans beaucoup d'interventions.
  • La sédimentation des données, par Samuel Huron
    Comment afficher simplement des données dans le temps, de façon que le présent compte plus que le passé. Hate de pouvoir tester ça sur l'affichage des résultats de tests.
  • Un cours de dessin de croquis par Eva-Lotta Lamm
  • Deux petites histoires sur pourquoi les commentaires dans le code sont importants
  • Tu peux pas test, un concept pour tester. J'étais sceptique sur le programme, mais Vincent Van Steen a finalement réussi à me convaincre que cette méthode peut avoir un intérêt dans certains cas, pour gagner du temps et de l'argent.
  • Une histoire de print qui finit en web, avec un joli livre responsive ; la dette technique ; les réponses aux stress... et plein d'autres sujets ont été abordés.

Comme toujours, la journée est chargée en contenu riches, intéressants, et chacun y trouve son compte. Les pauses sont là pour échanger sur les conférences, sur soi, son métier... je suis timide, j'ai surtout parler à des gens que je connaissais déjà.

Et pour finir la journée, une conférence débat animée par David Bruant et Pablo Pernot, qui a soulevé beaucoup de questions à base de "mais pourquoi je travaille comme ça", "comment changer l'avenir de la profession", ou encore "quand ça va pas, il faut le dire".

Toute la journée, Romain a réalisé des posters basés sur les contenus des conférences, en live. J'ai trouvé ça impressionnant (que ce soit l'esprit de synthèse ou la mise en page) Sur le débat, il a été bluffant. J'ai hâte de voir le résultats des posters dans les prochaines semaines !

Le soir, j'ai fait l'impasse sur la soirée communautaire pour rentrer m'occuper de mon fils, et me reposer avant le deuxième round du lendemain.

Sudweb 2014 - Un grand bol d'air frais

Samedi : ateliers et échanges

Le samedi à Sudweb, c'est souvent compliqué : des ateliers sont préparés dans les 7-8 salles dispos, et chacun va là où il veut. Avec la règle des deux pieds : "Si ça te plait pas, tu pars, et tu vas voir ailleurs".

Cette année, j'avais un coup de coeur pour un atelier prévu de longue date. Du coup, cela m'a empêché d'aller à un autre qui s'est créé et organisé dans la matinée. Et du coup, j'ai fini par faire une journée sans "technique" :

  • Atelier Légo pour faire des métaphores, étape par étape. Très intéressant, parce que cela permet vraiment de faire passer des idées par construction en 3D. (Un peu comme le cours de croquis de la veille)
  • Atelier DIY : Do it yourself, avec construction par équipe. Mon seul regret : nous n'avons pas eu le temps de finir le device lab à base de tablette que nous avions commencé. Mais clairement, je suis arrivé en regardant mon bureau d'une autre façon lundi matin.
  • Un atelier de travail en groupe avec une kinésiologue, où on a aussi bien parlé acuponcture que de nos frustrations professionnelles.
  • Et enfin, la rétrospective de sudweb. Avec toute l'équipe qui a organisé ça, pour pouvoir dire ce qui nous a plus, ce qui a moins plus, et ce qu'on pourrait faire d'encore meilleurs l'année prochaine.

Sudweb, et après

Rien à dire, j'ai passé 2 supers journées. Je pense que si je pouvais, je ne changerais pas grand chose : j'y étais allé pour avoir un grand bol d'air, entendre parler de quelques technos que je maitrise pas forcément, et m'ouvrir l'esprit à d'autres choses. J'ai tout bon sur toute la ligne. Un grand coup de chapeau à l'équipe qui a organisé tout ça.

Et après ? Lundi, retour au bureau, à la réalité. Le coup de boost de voir autant de gens voulant travailler encore mieux (dans tous les sens du terme) pendant 2 jours m'a remonté le moral. Mardi, j'ai un bon coup de blues, et je me demande si on devrait pas organiser un sudweb chaque semaine.

Il ne reste qu'à attendre les vidéos des conférences pour pouvoir les partager avec les collègues et connaissances pour leur montrer :)

Comme beaucoup de gens, je travaille toujours sur plusieurs projets à la fois. Mon rôle principal est de créer et maintenir des tests fonctionnels automatiques.

Pour gérer tout cela, nous sommes 2 personnes. Mais nous avons aussi des tests manuels à faire avant chaque mise en production de chaque projet.

Quelques chiffres

  • 6 serveurs jenkins : 3 linux, 3 windows. (Uniquement pour les tests fonctionnels)
  • 1 700 scenarios cucumber joués quotidiennement. (soit plus de 20 heures chaque jour)
  • près de 300 jobs jenkins pour les ranger
  • 7 produits principaux, à tester sur 1 à 3 navigateurs + mobile

Cela donne le tournis. Plus le temps passe, plus j'ai besoin d'avoir un affichage synthétique pour savoir si mes tests sont passés ou non.

J'avais dans le passé créer un petit plugin pour afficher mes résultats. Mais chaque projet est légèrement différent, demande des réglages différents, et j'arrivais aux limites de cet affichage. J'avais un écran par projet, soit 7 écrans de contrôle, que j'aurais voulu avoir toujours sous la main.

Plugin jenkins

J'ai donc regardé sur jenkins s'il existait des plugins permettant de lister les résultats au format json. Je n'ai rien trouvé de concluant, j'ai donc codé un petit plugin pour avoir un fichier jsonp qui liste tous les jobs, et pour chacun :

  • son statut courant,
  • les stats du dernier résultat,
  • l'avancement s'il est en cours...

Vous pouvez trouver le code sur le dépôt github.

Console en javascript

Une fois le json obtenu, il restait à le traiter. L'avantage est de pouvoir le faire en javascript, ce qui permet à chacun de gérer ensuite l'avantage à sa sauce. J'ai fait un écran de contrôle pour l'ensemble des projets que je gère.

Et j'ai filé les clefs à une équipe sur un projet, qui a modifié l'écran pour pour avoir seulement les tests fonctionnels de son projet, et a ajouté les tests unitaires sur le même écran.

Et voilà ce que ça donne :

Exemple d'affichage avec le plugin jenkins jsonResult

Exemple d'affichage avec le plugin jenkins jsonResult

  • On peut séparer les jobs dans les différents projets via des expressions régulières.
    Pour l'un des projets, très conséquents, j'ai même séparé par navigateur.
  • On voit bien les tests KO pour chaque job. (en rouge)
  • Les jobs désactivés ou n'ayant pas de résultats sont gris.
  • Les jobs qui sont en cours d'exécution sont en bleu, avec une barre d'avancement sur leur durée estimée.
  • Les jobs qui seront lancés quand il y aura une place pour eux ont une pastille jaune.

Cela fait plusieurs années que j'assure la qualité d'overblog.com :

  • Tests et validation "manuel" pendant des années,
  • Gestion du support utilisateur par forum ou par mail,
  • Mise en place des tests fonctionnels automatiques,
  • Mise en place des changelog,
  • Rôle de proxy Product Owner lorsque l'équipe est passé à Scrum,
  • A l'occasion, j'ai aussi développé des fonctionnalités sur le projet lui-même,
  • Et plein d'autres petites tâches pour assurer la qualité en général...

En début d'année, lors de mon entretien annuel avec ma hiérarchie, j'ai sous-entendu que je commençais à "m'ennuyer" : je n'avais plus assez de défis à me mettre sous la dent.

J'ai aussi demandé des rendez-vous à quelques reprises avec mon "n+2", pour lui exposer des problèmes d'organisation, et aussi mon ressenti sur le produit et sa qualité. (Je n'aime pas l'appeler mon "n+2", mais c'est plus simple pour en parler ici. Il mérite beaucoup plus que cela : il est à l'écoute, et chaque fois je sors de réunion "prêt à en découdre".)

Comment j'ai changé de travail sans bouger de ma chaise

A la recherche du Graal de l'emploi

A ce moment-là, j'ai mis à jour mon CV, mes informations sur les réseaux, et je suis passé en mode veille "un peu plus active" sur l'emploi dans mon domaine.

J'ai rapidement découvert plusieurs choses :

  • J'ai acquis au sein de ma société une autorité "naturelle" dans le domaine de la Qualité, et des tests.
  • J'ai une autonomie très importante pour faire mon travail, et j'aime ça !
  • Les postes dédiées à la qualité et/ou aux tests ne courent pas les rues
  • Certains postes dans le domaine ne me conviennent pas
  • Se limiter à une région géographique limite encore plus les offres

J'ai du coup pensé à changer de carrière pour rester dans ma région, mais je n'avais pas envie de redevenir développeur "lambda" (et qu'on ne me parle pas de chef de projet). Je me suis même demandé pourquoi je restais dans l'informatique (quand je dis que je ratisse, je ratisse large).

Au printemps, j'allais au travail avec un peu moins d'entrain, et avec le recul, je me suis aperçu que je me faisais des montagnes de certains petits tracas sans importance. Mais hors de question pour moi de partir sans savoir où aller.

Comment j'ai changé de travail sans bouger de ma chaise

Le casse du siècle ?

Et puis, au début de l'été, on m'a fait une proposition intéressante :

  • Mettre en place des tests automatiques sur des projets web
  • Travailler en binôme avec quelqu'un déjà en place
  • Travailler sur 5 ou 6 projets web distincts (mais ayant des parties communes)
  • Toucher à des domaines que je ne maîtrise pas : faire des tests sur du flash ou des applications mobiles, de beaux défis !
  • Accompagner les équipes techniques pour améliorer la Qualité

Ce poste paraissait trop beau pour être vrai, mais il était pourtant parfait pour moi. OverBlog fait partie du groupe Ebuzzing depuis plusieurs années. Ebuzzing diffuse un certains nombre de projets. Depuis cet été, j'assure maintenant la qualité de tous ces projets.

Comment j'ai changé de travail sans bouger de ma chaise

Ils vécurent heureux et eurent beaucoup d'enfants

Depuis, j'ai un nouveau travail.

  • Je n'ai pas changé de bureau. Je suis toujours assis au même endroit, avec mes habitudes.
  • Mon "n+2" est toujours le même. Pour moi, c'est vraiment une bonne chose : j'ai appris à l'apprécier, et à le respecter depuis longtemps.
  • Je n'ai pas changé de collègues, mais la liste des collègues avec qui je travaille s'est allongée.
  • Si depuis longtemps je codais "propre" et réutilisable sans même avoir besoin de le faire, depuis cet été je le met en pratique. Le temps "perdu" pour cela a "enfin" été rentabilisé.
  • Travailler en binôme est stimulant. Il ne se passe pas une semaine sans qu'une idée de l'un de nous fasse rebondir l'autre pour affronter un problème particulier.
  • Former mon binôme à mes méthodes de travail est intéressant. Il me permet de voir que certains choix ne sont pas forcément pertinents et logiques. Au bout de 4 mois, j'ai déjà repéré plusieurs fois que l'un finissait la phrase de l'autre : juste parfait à mes yeux.
  • Pouvoir chaque jour travailler sur un projet différent est génial : je n'ai plus de routine (les habitudes sont ma hantise)
  • Même si mon autonomie n'est pas aussi importante qu'avant, j'en ai quand même beaucoup. C'est plus que suffisant. (je connais beaucoup de gens qui voudraient avoir la moitié de celle que j'ai)
Comment j'ai changé de travail sans bouger de ma chaise

Dans notre outil, nous utilisons le langage twig. Cela permet une grande flexibilité, et d'avoir un moteur déjà bien robuste.

Prenons par exemple l'affichage d'une date avec ce code :

    Post.Date|datel(Lang.Get("Default date format"))

Notre outil étant mutli langue, et les formats de date changeant avec la langue, nous utilisons une locale. En pratique, il s'agit d'une chaîne de caractères indiquant le format.

On pourrait avoir HH:mm pour l'heure par exemple.

Dans l'analyse du bug du jour, nous avons un signalement de date fausse sur certaines pages. Après vérifications nous trouvons une page datant du 3 janvier 2010, mais qui est affichée comme étant le 3 janvier 2009.

L'enquête se poursuit en vérifiant les dates des autres pages : la quasi totalité des pages affichent une date juste. On finit par regrouper les pages à problèmes suivant le critères : certaines pages de début janvier de certaines années (mais pas toutes).

Le collègue qui cherchait a trouvé le problème.

Default date format = MMMM d Y

Dans la documentation de datel, Y = year of "Week of Year". Il s'agit de l'année durant laquelle le week end du jour en question a eu lieu.

Il s'agit donc d'un bug visible pour les premiers jours de janvier pour lesquels la semaine commençait l'année d'avant. Tordu non ?

Pour la petite histoire, le code corrigé sans bug donne :

Default date format = MMMM d yyyy

Lorsqu'on teste avec jenkins, cucumber et watir, on obtient des rapports détaillés, qu'il faut lire et analyser en permanence.

Depuis plusieurs mois, nous avons dans nos locaux une télé dédiée à l'affichage de l'état général de l'ensemble de nos tests. Pour cela, le plugin Jenkins Wall Display nous a suffit dans un premier temps. Nous affichons sur la télé une page web qui fait défiler

Au total, sur ces écrans, nous affichons le résumé :

  • Plus de 1 300 test php unit (et leur 5 000 assertions)
  • Près de 500 tests unitaires JS
  • Plus de 950 scénarios cucumber pour les tests fonctionnels.

En outre, nous affichons aussi quelques graphiques sensibles de l'état de la production : nombre de compte crées, etc..

On a beau regrouper toutes ces informations, il arrive un moment où l'affichage n'est plus lisible.

Exemple avec les tests fonctionnels

Exemple avec les tests fonctionnels

Le constat est moins alarmant pour les tests unitaires. Les chiffres exposent bien pourquoi :

  • Tests fonctionnels : 40 jobs jenkins * 3 navigateurs
  • Tests unitaires : 18 jobs jenkins * 2 environnement

Comment afficher proprement les résultats

Je suis parti en quête d'une solution pour afficher tous nos résultats proprement, avec quelques contraintes :

  • Je préférais afficher tous les résultats sur un seul écran par type de tests
  • Je veux pouvoir afficher un résumé ( x tests KO / x tests total)
  • Je veux pouvoir séparer facilement les affichages d'un même type de tests (par navigateur / environnement)

Ma quête fut longue et semée d'embûches :

  • Tentative d'utilisation de l'API, mais c'était déjà trop lent alors que je ne calculais / affichais pas la moitié de ce que je voulais (45 secondes environ)
  • Plusieurs plugin jenkins, mais aucun ne permettant ce que je veux
  • Un Plugin jenkins faisant la moitié de ce que je voulais, mais complètement bugué

Mon premier plugin jenkins

Je suis donc parti à l'assaut de la documentation de jenkins pour coder un plugin fait-maison qui ferait exactement ce que je voudrais.

Ce que j'ai bien aimé dans cette création :

  • Tout en java. Je n'avais pas codé en java depuis 10 ans je pense, et j'ai perdu, mais vite repris mes repères.
  • Bosser sur un plugin que je pourrais diffuser en open-source à la fin :)
  • La possibilité de faire exactement ce que je veux, sans être limité par un plugin déjà fait.

Ce que je n'ai pas aimé :

  • La documentation : elle existe, elle semble complète. Mais je trouve l'organisation moyennement bonne. J'ai plusieurs fois été à la recherche d'exemple de code pour trouver la fonction dont j'avais besoin, que je ne trouvais pas dans la doc.
  • L'installation de maven qui marche du premier coup sur un de mes postes, mais se passe mal sur l'autre.

Au final, ça donne quoi ?

J'ai donc un plugin qui permet de créer une nouvelle "View". On peut y configurer :

  • Les noms des colonnes, et la façon de filtrer les jobs dans chaque colonne, par des expression régulières.
  • Affichage dans chaque colonne du temps pris pour ces tests, du nombre de scénarios en échec et du nombre total de scénarios. (Afficher le nombre de jobs est beaucoup plus simple, mais donne beaucoup moins d'informations : un job en échec pour 1 / 34 est moins grave qu'un test avec 4 / 4 erreurs)
  • Affichage de la liste des jobs en échec (avec le nombre de scénarios)
  • Une colonne à part, qui affiche le temps total sur jenkins (master + slave)
  • Une liste de jobs spéciaux (dans mon cas : ceux qui lancent les autres, la génération de la doc...)

Le plugin est sur github : https://github.com/fabrice31/CucumberJenkins

Et maintenant ?

J'ai configuré le plugin pour fonctionner avec cucumber, puisque je suis au coeur des tests fonctionnels. Il faut maintenant que je me débrouille pour que cet affichage fonctionne aussi bien avec tests php unit (séparés par des regexp par environnement cette fois)

Affichage des résultats de testsAffichage des résultats de tests

Lors de tests, il arrive souvent qu'on ait besoin de "faire le ménage" pour retrouver un état comme à l'origine.
Plusieurs stratégies possibles, en fonction des technologies qu'on souhaite utiliser.

Un par un, à la fin
Après chaque scénario, supprimer ce qui a été ajouté, annuler les modifications une par une.

  • Avantages :
    Facile à mettre en place (on réutilise ce qui a déjà été fait)
  • Défauts :
    Si le scénario plante, on ne remet pas en l'état
    Chaque scénario prend un peu plus de temps (jusqu'au double, dans le pire des cas)


Un par un, au début
Avant chaque scénario, remettre les valeurs par défauts pour le test

  • Avantages :
    Facile à mettre en place (on réutilise ce qui a déjà été fait)
  • Défauts :
    Si la remise à zéro ne marche pas, on ne teste pas
    Chaque scénario prend un peu plus de temps (jusqu'au double, dans le pire des cas)


Tous d'un coup, dans une routine à part
Puisqu'on utilise un outil comme jenkins pour organiser tous les tests, on peut ajouter une routine "à part", qui va se connecter sur chaque compte pour effectuer cette remise à zéro.

  • Avantages :
    Toutes les procédures de remises à zéro sont au même endroit
  • Défauts :
    Un peu plus long à mettre en place
    Demande d'ajouter une sécurité pour ne pas la lancer au mauvais moment
    Ca prend du temps (mais autant que de le faire un par un)



Optimisation : utilisation d'une API

Dans mon cas, nous disposons aussi d'une API publique (en alpha, elle n'est pas encore ouverte à tout le monde)

  • Avantages :
    Pas d'interface web, cela devrait aller plus vite
    Ajoutera "en passant" des tests sur la public API
  • Défauts :
    Je ne maitrise pas du tout Oauth 1.0a (ça me permettra d'apprendre : tant mieux)
    Nous disposons d'un SDK pour faciliter l'utilisation de l'API, en php. Pour des raisons pratiques, je préfère le faire en ruby, le serveur de tests étant déjà configuré pour cela. Je pars donc "de zéro"

Utiliser une API OAuth 1.0a en Ruby

On trouve un peu de documentation pour le faire, et quelques exemples. Quelques remarques sur ces articles :

  • La quasi totalité expose le même code d'exemple.
  • Rares sont ceux qui signalent la version d'OAuth
  • Les exemples se concentrent beaucoup sur "comment se connecter à l'api", et très rarement sur "comment l'utiliser"

Voilà quelques astuces pour utiliser "rapidement" une API OAuth en ruby

Utilisation de gems

Elles facilitent la vie, autant en profiter.
require 'oauth'
require 'watir-webdriver'
require 'json'

Définition de constantes de l'api

OB_API_SERVER    				= 'http://url_server_api'
OB_API_BASE_URL					= OB_API_SERVER+'/public/0.1'
OB_API_ENDPOINT_REQUEST_TOKEN 	= '/oauth/request_token'
OB_API_ENDPOINT_ACCESS_TOKEN 	= '/oauth/access_token'
OB_API_ENDPOINT_AUTHORIZE 		= '/oauth/authorize'
OB_API_MY_CONSUMER_KEY 			= '######'
OB_API_MY_CONSUMER_SECRET 		= '######'

Obtenir la connexion à l'API

# create the OAuth consumer
@consumer = OAuth::Consumer.new( 
    			OB_API_MY_CONSUMER_KEY,
				OB_API_MY_CONSUMER_SECRET,
				{
					:oauth_version		=> '1.0a',
					:site 				=> OB_API_SERVER,
					:request_token_path => OB_API_ENDPOINT_REQUEST_TOKEN,
					:access_token_path 	=> OB_API_ENDPOINT_ACCESS_TOKEN,
					:authorize_path 	=> OB_API_ENDPOINT_AUTHORIZE
				}
			)

# show all debugs in console
# @consumer.http.set_debug_output($stdout)

# get the authorize url
@request_token = @consumer.get_request_token

# Make as if the user authorize the app
# If you make a web app, you should show the link to your user, and let it click it
# browse the authorize url
@browser = Watir::Browser.new
@browser.goto(@request_token.authorize_url())

# connect with account
@browser.text_field(:name => 'email').set("test@test.fr")
@browser.text_field(:name => 'passwd').set("monmotdepasse")
@browser.button(:name => 'loginSubmit').click

# give access
@browser.form.submit

# get verifier token
# browser url contain oauth_verifier_token
oauth_verifier_token = @browser.url.split("oauth_verifier=")[1]

# grant total access
@access_token = @request_token.get_access_token(:oauth_verifier => oauth_verifier_token)

# no more browser needed
@browser.close

Exemples d'utilisation de l'API OAuth

Une fois qu'on est connecté à l'API, on peut l'utiliser. Il faut lire sa documentation, en général assez touffue, pour savoir ce qu'on peut faire (lister / ajouter / modifier / supprimer).

Voici deux exemples "simplifiés" pour mon exemple.

Classique

Afficher les informations sur le blog courant.
    get_url_info =  OB_API_BASE_URL+'/blog/info'
	current_blog_info = @access_token.get(get_url_info)

Avec une option

Afficher la liste des titres des articles en brouillons.
	get_lists_content =  OB_API_BASE_URL+'/blog/posts/draft?limit=20'
	content_list = @access_token.get(get_lists_content)
	# read json results
	result = JSON.parse(content_list.body)
	result['response'].each do | content |
		puts content['title']
	end

Conclusions

Ma routine journalière prenait environ 55 minutes. La nouvelle routine, via l'api, dure environ 90 secondes.

J'ai depuis très envie de l'étendre pour ajouter de nouvelles procédures de remises à zéro.

La documentation est primordiale (que ce soit celle de l'API ou celle de OAuth)

Exécuter une partie des tests

Les scénarios sont taggués pour être lancé par jenkins par la commande :
cucumber --tag @montag
Cela permet de ne lancer qu'une partie des tests. (voir "Tester sur plusieurs navigateurs" pour les détails)


Serveurs

Côté serveur, nous avons 2 serveurs jenkins.
Le principal, une grosse machine debian quadri core, qui exécute jusqu'à 3 jobs en même temps.


Ensuite, un serveur Windows, avec un jenkins "slave".
L'esclave reçoit ses ordres du maître, qui lui demande d’exécuter des jobs particuliers.
Il est sous Windows pour pouvoir les exécuter sur Internet Explorer.

Pour éviter les effets de bords entre les tests sur IE, pas de solution. On vide donc les cookies, le cache, etc à la fermeture d'Internet Explorer.
On ne peut donc pas exécuter les tests pour IE en parallèle sur le même serveur : les sessions se mélangeraient.


Quelques chiffres

Les scenarios sont regroupés en feature, dont le temps d'execution est de maximum 10 minutes.
Dans Jenkins on a 38 "jobs" sur FF (+ 34 sur IE)

Firefox
Chaque jour : 323 scénarios / 2693 step => 3h
IE (1 fois par semaine actuellement, 1 fois par jour bientôt)
Chaque jour : 302 scénarios / 2527 step => 4h 30

Cela représente 227 500 scénarios par an (pour 2 737 heures de tests).

Sans oublier les lancements à la demande de certains jobs.


Comptes utilisateurs

Du côté des scénarios, ils utilisent pour le moment 70 comptes utilisateurs différents (avec des options particulières, etc...)
Un changement prochain de notre offre me fait penser que les tests auront besoin de 100 comptes d'ici 2 à 3 semaines.
Sans oublier de dupliquer tout ça pour nos 2 environnements (test / stable)


Et on ajoute des tests fonctionnels en dehors de ce schéma, pour tester des choses particulière, que ce soit en production sur des points essentiels ou la validité de données particulières.

Et vous, combien vous testez ?

Si vous avez plusieurs tests qui s’exécutent en même temps sur le même environnement (le serveur de test), il faut veiller à bien tester la "bonne chose".

Prenons un exemple de deux tests exécutés en même temps :

@scenario1
Scenario: Test modif pseudo
   Given I connect to my "pseudo" account
     When I change my nickname for "pseudo-tmp"
	 When I publish an article "test pseudo-tmp"
	 Then my published pseudo is "pseudo-tmp"

@scenario2
Scenario: Pseudo can't be empty when you publish
   Given I connect to my "pseudo" account
	 When I change my nickname for ""
	 When I publish an article "test pseudo"
	 Then my published pseudo is "pseudo"

Si les 2 scénarios se terminent "au même moment", nous aurons sur la page de contrôle 2 articles. L'un signé avec "pseudo-tmp", et l'autre avec "pseudo".
Si la vérification vérifie dans tout le contenu de la page des publications et pas seulement le dernier élément, cela pourrait bien se passer.


A un détail près :
- A 10h, le test s’exécute, il fonctionne.
- A 15h, le test s’exécute mais les articles parus à 10h sont peut-être toujours affichés. On aura donc bien un article "test pseudo" sur la page alors qu'un bug sera présent.


Ma solution : ajouter de l'aléatoire dans les tests.
Avant chaque scénario, je crée un token, composé de :
- 2 lettres du navigateur (ff, ie, ch..)
- un nombre aléatoire.
Et je l'affiche en console (bien pratique pour débugguer)

Before do
  $token = Token.new
  puts "Token for this test : #{$token.value}"

  /* je vous fais grace du code pour lancer le navigateur, ... */ 
End

Ma classe Token :
# Use to got random value
# Useful to post a data with random string but keep the value to check it later
# Author:: Fabrice
class Token
  # Create a new token
  # Author:: Fabrice
  def initialize
    @value = "#{ENV['BROWSER']}#{256*256+rand(1024*1024)}"
  end

  # Get the value of the last token
  # Author:: Fabrice
  def value
    @value
  end
end

Ensuite, sans modifier le scénario, on modifie le code des étapes. Lorsqu'on sauve une donnée, on ajoute le token "courant" dans le champ.
title = "#{title} #{$token.value}"

Et côté vérification, on en tient compte également.
def open_article(title, token = false)
  if(token)
    @browser.link(:text => "#{title} #{$token.value}").click
  else
    @browser.link(:text => "#{title}").click
  end
end

Parfois, on a besoin de pouvoir jouer "sans token" pour des points bien précis : on prévoit alors un paramètre pour s'en passer. (Exemple, pour la saisie d'un email)

Ce genre de solution peut aussi vous éviter des effets de bords si vous publiez sur le même compte des articles avec le même titre. (Ceci, c'est un autre test à part entière)

Il y a plusieurs mois, j'avais tweeté "Les bugs, ça coûte cher : Noël sans solde pour des milliers de soldats français"
Source : http://www.lemonde.fr/international/article/2012/12/21/des-milliers-de-soldats-francais-non-payes-a-cause-d-un-bug-informatique_1809606_3210.html

Pour résumer : dans les anciens logiciels de paie des militaires français, il y avait parfois des petites erreurs, des petits bugs, qui étaient corrigés les mois suivants. Mais en 2012, mise à jour complète du logiciel.

Louvois, le logiciel le plus buggué de l'histoire ?

La dernière version du logiciel, surnommée "Louvois" (Logiciel unique à vocation interarmées de la solde) , est tellement remplie de bugs que certains militaires ont de légers problèmes. (Exemples en fin d'article)

Il y a un mois, on pouvait lire dans la presse que les bugs devaient être corrigés pour Noël 2012, mais ne l'étaient pas encore mi février 2013.
Source : http://www.lemagit.fr/technologie/applications/applications-transversales-pgi/2013/02/20/logiciel-de-paie-louvois-la-guerre-de-le-drian-est-loin-detre-gagnee/

On envisagerait donc de revenir à l'ancien logiciel, moins buggué. Mais cela prendrait entre 12 et 14 mois, donc, mi 2014 au mieux.

Une autre source indique que l'armée de l'air paierait déjà ses hommes via un autre logiciel pour éviter les bugs : http://www.marianne.net/blogsecretdefense/Louvois-l-armee-de-Terre-pourrait-revenir-a-l-ancien-systeme-de-paiement-des-soldes_a942.html

Les erreurs occasionnées par Louvois représentent 1 % de la masse salariale du ministère de la Défense, pour près de 120 000 incidents

Le Canard Enchaîné

Et pendant ce temps, dans l'armée de terrain

  • Saisie sur salaire à un miliaire, pour une somme déjà payée au trésor public par le militaire par ailleurs. (Donc, il est dans le rouge, et paie 2 fois). Temps avant remboursement : plusieurs mois.

  • Un homme qui doit faire vivre sa famille un mois entier avec 60 euros : http://storify.com/fabrice31/l-armee-mauvais-payeur

  • Soldes payées avec des mois de retard sur le terrain

  • Primes prévues mais reportées, payées avec plusieurs mois de retard...

  • Sur une compagnie de 120 hommes, pour le même mois, déjà plus de 20 cas recensés avec une erreur sur le solde, de 150 à 1 400 €. (La cause serait la prime versée le mois précédent, considérée comme un trop perçu par le logiciel)

Si des militaires veulent poursuivre la liste, n'hésitez pas, je compléterai avec plaisir cette liste de bugs. (un formulaire de contact anonyme est disponible en bas de page)

L'armée ne paie pas toujours ses militaires.

Et si c'était vous ?

Rappel : les militaires n'ont pas le droit de manifester / faire grève...

Imaginez, si cela ne touchait pas l'armée, mais une société lambda ?

  • Une société privée avec un bug aussi important (même une seule fois) qui ne corrige pas dans les jours qui suivent la situation de tous les salariés : que diront les prud'hommes ?
  • Une société qui a un bug dans 1% des paies qu'elle verse, Sur une petite PME de 20 personnes, cela fait 1 seule erreur de paie tous les 5 mois. 2.5 erreurs par an.
    Pour l'armée, ça représente 3220 personnes par mois. (322 000 emplois en 2007)
  • Imaginez, si ce mois-ci, votre conjoint(e) reçoit un salaire de 60 € à cause d'une erreur de logiciel, et la suite viendra "plus tard", délai non confirmé. De quoi vous passez vous ? Payer votre loyer, vos crédits ? Les couches de bébé ?

Une page facebook parlait en 2012 du problème : Le paquet de gauloises en colère

On peut être un grand nom de la vente en ligne, mais avoir malgré cela des problèmes sur son site web.

Parfois, cela se passe "presque bien" : tout le monde se souvient encore de l'homme nu de La Redoute (une photo présentant un produit avec en fond un homme nu). Tout le monde a rigolé, s'est moqué d'eux. Ils ont corrigé le tir, puis ont lancé un jeu pour trouver certains objets dans d'autres images pour les gagner.

Et parfois, c'est le "drame"

Prenons un cas pratique, qui m'est arrivé.

Je suis client chez http://www.boulanger.fr/ depuis longtemps, j'ai une carte de fidelité, etc. En janvier, j'ai rencontré des difficultés pour utiliser un chèque cadeau sur une commande. J'ai contacté leur support par un formulaire par mail : aucune nouvelle.

J'ai tweeté : une cm m'a demandé une copie du mail et m'a confirmé avoir transférée ma demande à l'équipe technique. Au menu : des problèmes d'ergonomie, de textes pas clairs...

Ce week-end, j'ai reçu un mail pour me dire que mon chèque cadeau n'était pas utilisé. Petit tour sur mon espace client, quelques soucis rencontrés en quelques minutes.

Les commandes fantômes

Page "Commandes en cours", j'ai deux commandes notées "expédiées" :

  • Celle de fin novembre. Que j'ai reçue en décembre, sans souci.
  • Celle de janvier. Que j'ai reçue (en deux fois, l'un des articles était indisponible. J'ai été averti de l'indisponibilité, j'ai choisi d'attendre : 5 semaines avant la livraison)

La saisie impossible (d'un chèque cadeau)

Pour saisir un chèque cadeau, quelques étapes :

  1. Validez votre panier
  2. Au milieu de la page de paiement, cochez oui à la phrase "Vous béneficiez de cartes cadeau, cartes satisfaction ou chèques fidélité ?"
  3. Sélectionnez "Chèque cadeau".
    • Pour les férus d'accessibilité : c'est un div. (L'image de fond est appliqué au div parent)
    • Pour les férus de webperf : l'image est chargée 2 fois, avec 2 adresses différentes.
  4. Saisissez le numéro du chèque (copier / coller, en faisant attention aux espaces)
  5. Saisissez le montant du chèque (Apparement, Boulanger ne connait pas le montant en fonction du numéro de chèque...)
    Attention, pas de format indiqué : 25,10 / 25.10 / 25€10 : bonne chance.
  6. Recopiez un captcha
  7. Validez le chèque

8 moyens de paiements. +1 caché

8 moyens de paiements. +1 caché

Voilà, la page se recharge, referme la partie chèque, et vous passez à la suite. Oui, mais :

  • Si tout va bien, la ligne pour le chèque figure en bas de la page d'après ce qu'ils disent.
  • Si une erreur s'est produite, vous devez :
  1. Au milieu de la page de paiement, il faut cocher à nouveau la phrase "Vous béneficiez de cartes cadeau, cartes satisfaction ou chèques fidélité ?"
  2. Sélectionner "Chèque cadeau".
  3. Regarder si par hasard, une ligne rouge n'est pas affichée. Avec un message d'erreur du genre "Le paiement n'est pas valide". Bonne chance pour comprendre quelle est l'erreur. Si vous tapez le montant "AA" ou un numéro de chèque erroné, vous aurez la même erreur.
Un message d'erreur (enfin, façon de parler)

Un message d'erreur (enfin, façon de parler)

Vous avez demandé le service client, ne quittez pas

En bas de page, un lien contact : je me dis que je vais leur expliquer ce que je pense de leur site.

  1. Je clique sur le lien en bas de page
  2. Une page apparaît avec une liste de 8 "services" pour les contacter. Je clique sur "Contactez Boulanger.fr" (accessibilité : nulle. c'est une image sans texte alternatif)
  3. Une page différente apparaît, avec les 8 services, où celui que j'ai sélectionné est "ouvert". Aucun des choix proposés ne me convient. Je change de service pour "Les produits ou les services (je vous ai parlé de la non accessibilité du site ?). Voilà, je peux choisir un type de contact qui me convient "Question concernant la carte de fidélité"
  4. Et là, alors que je suis connecté, qu'ils ont donc mon adresse, mon numéro de client, mon email, je dois remplir quelques informations.
    • Informations obligatoires (présence de * à coté de l'intitulé) : Nom, prénom, numéro de téléphone (là encore, pas de format... je choisi donc le format international), email, choix du mode de contact de leur part (email ou téléphone), et ma question
    • Le numéro de la carte de fidélité n'est pas obligatoire : ouf.
    • Des cases pour accepter ou non de recevoir des mails de promos de Boulanger et de ses partenaires (avec une ligne en gris sur fond blanc, que j'ai trouvé peu lisible...)
  5. J'écris un long mail (cet article est issu du mail). Enfin, je ne l'écris pas dans le champ : le textarea de 6 lignes, 32 colonnes, non redimensionnable est trop petit pour ma prose.
  6. Je l'envoie. Ah tiens, j'ai un message d'erreur (il est clair cette fois) : je n'ai pas saisi mon numéro de carte boulanger. Même s'il est "logique" de devoir saisir le numéro sur la page de contact à ce sujet, c'est pourtant le seul champ que je ne suis pas obligé de remplir.
  7. Je remplis le champ par mon numéro, qui d'après leur aide (qui apparaît au survol.. accessibilité...) doit faire 10 caractères. Sauf que je peux en mettre 12 ou plus en fait. Le champ n'est pas limité en nombre de caractères.

J'arrive tout de même à envoyer mon mail, et j'ai donc un joli message de confirmation. Par expérience, j'aurais aimé recevoir une copie par mail. Pour ne pas perdre mon message, et l'avoir si on me demande de redonner des infos.

Une fois le mail envoyé

Une fois le mail envoyé

Pour aller plus loin

Après avoir envoyé le mail, j'ai commencé mon article, et j'ai du coup été tatillon : lecture du code source de quelques pages, etc. Quelques trucs qui me chiffonnent en vrac :

  • La page de contact n'a pas de balise "title"
  • A la louche : 4 fichiers css (+2 pour le print), 20 fichiers js...
  • Le design du formulaire de contact en balise table dans une balise table dans une balise table.
  • La vérification des champs provoque un message d'erreur (un seul : c'est une bonne chose) mais est faite en javascript (accessibilité...)
  • Des balises mises en commentaires HTML.
  • La liste des mot-clés (meta keyword) me semble un peu longue, mais admettons. Par contre, le dernier mot-clé est terminé par un point. Étrange.

A la base, je comptais juste faire un achat rapide. Je viens de passer la soirée à faire un audit qualité (bug / ergonomie / accessibilité / webperf) à boulanger. C'est cadeau : je n'ai fait que survoler. J'encourage Boulanger à le faire à fond (ou mieux, à le faire faire par des experts).

(Evidemment, si j'ai une réponse, je la publierais ici)

Partager cette page Facebook Twitter Google+ Pinterest
Suivre ce blog