Conférence Nordic Testing Days 2016 — Ma vision en tant que participant

Nordic Testing Days 2016

Les conférences sur le test logiciel se sont propagées très rapidement ces dernières années. Presque tous les pays en Europe ayant la leur, il peut devenir difficile de faire son choix pour assister à ce genre d’événements.

Après avoir eu un très bon retour de la conférence Nordic Testing Days en Estonie de la part d’un de mes anciens managers, j’ai décidé de suivre sa recommandation: eh bien, je n’ai pas du tout été déçu. Voici un petit résumé du contenu de ces deux jours de conférence auxquels j’ai participé.

Il est 9h du matin, ce jeudi 2 Juin, à Tallinn, la capitale de l’Estonie: le public est rassemblé dans la plus grande salle et attend le démarrage de l’événement avec impatience. La présidente de l’organisation monte sur scène, démarre son discours, et dans les cinq minutes qui suivent elle annonce: “On a énormément de nourriture pour les testeurs qui sont venus ici, parce qu’on ne veut pas de testeurs affamés: ils pourraient commencer à ‘démolir’ les logiciels!”.

L’annonce produit son effet, l’audience rit. La journée promet d’être intéressante.

Une audience différente

Nordic Testing Days représente l’intérêt de brasser un public très différent de celui des conférences d’Europe de l’Ouest: la plupart des professionnels viennent des pays baltes — Lituanie, Lettonie et Estonie — ainsi que des pays scandinaves. Il s’agit d’une excellente opportunité de rencontrer de nouveaux visages et d’élargir son réseau professionnel, ainsi que d’approcher le test logiciel de par la perspective de ces nouveaux utilisateurs; certaines des sessions sont justement focalisées sur leur expérience propre.

Comme bien souvent, cette conférence réunit également ce que j’appelle l’équipe usuelle du Royaume-Uni, qui regroupe des testeurs habitués à présenter des sujets dans diverses conférences en Europe. Je peux citer par exemple Bill Matthews, Dan Billing ou encore Stephen Janaway.

Qu’est-ce qui est ressorti des sessions?

Avoir le monopole ne doit pas empêcher la qualité

L’Estonie est surnommée «e-Estonie», surnom qui traduit l’émergence du pays comme l’une des e-sociétés les plus avancées au monde. La session de keynote introduisant la conférence, présentée par Andres Kütt, a souligné cet aspect: Andres est architecte numérique et travaille pour le gouvernement Estonien; Il collabore dans la fourniture de services électroniques pour les secteurs vitaux qui viennent s’interconnecter, tels que la santé ou des institutions de droit. Ceci implique qu’il faut considérer les besoins et les contraintes de ces secteurs afin de fournir des solutions utiles.

Andres a insisté sur le fait de considérer, lorsqu’on recherche à améliorer la qualité de ses services, l’ensemble de l’écosystème qui les utilise: les utilisateurs, les secteurs, les exigences et contraintes différentes qui en émanent. Etant le seul fournisseur de ces services, il a mis en garde contre le danger de la position de monopole, qui peut facilement mener à un manque de partage des informations vis-à-vis des clients et partenaires, et à un refus d’amélioration de la qualité car «les gens n’ont pas le choix et doivent de toute façon utiliser nos services. “

Il a plutôt plaidé en faveur de solutions non dépendantes de la connaissance d’une poignée de personnes au sein de la structure qui détient le monopole, une plus grande souplesse en étant aussi transparent que possible envers leurs partenaires, et ce au moyen notamment d’une documentation précise des API, compte tenu de leurs exigences obligatoires pour assurer la sécurité du système. Une «documentation» très efficace qu’ils ont pu fournir pour expliquer comment extraire des données par le biais de leur service a été faite via la fourniture d’un outil plutôt qu’une spécification écrite: avec un ensemble d’entrées faciles à configurer par les utilisateurs, ces derniers peuvent extraire les données qu’ils souhaitent rapidement. Enfin, il nous a aussi rappelé que la qualité était difficile à définir, et qu’être capable d’«échouer rapidement» apportait des informations précieuses pour l’améliorer.

La sécurité c’est Notre métier

Mikko Hypponen, un expert en sécurité finlandais réputé, a présenté un exposé brillant qui nous a rappelé que la sécurité faisait partie intégrante de notre travail. Il a souligné que toutes les entreprises sans exception ont un aspect logiciel, car même sans créer de solutions informatisées, la plupart des données sont désormais stockées en ligne et vulnérables aux attaques de hackers.

Afin de nous démontrer l’importance à attacher à la sécurité, Mikko a pris à titre d’exemple quelques-unes des plus grandes «attaques» qui ont eu lieu ces dernières années, comme le piratage très récent en Décembre 2015 d’une centrale électrique en Ukraine (pour en savoir plus vous pouvez lire cet article détaillé et très intéressant du magazine ‘Wired’). Cette attaque a été rendue possible grâce à des réactions en apparence inodines de quelques opérateurs concernant une campagne de phishing qu’ils avaient reçu, contenant un document Word malveillant joint: ils avaient simplement cliqué sur un bouton pour activer le malware, exploitant une très ancienne vulnérabilité connue des solutions de bureautique Microsoft.

Mikko a également expliqué que le milieu du piratage avait considérablement évolué, depuis l’acte d’individus isolés dans les années 90 jusqu’à la criminalité organisée en ligne de nos jours, en compétition pour le même ‘marché de la clientèle’. Vous avez sûrement dû entendre parler de leur oeuvre la plus connue, le ‘ransomware’, ce petit logiciel qui verrouille l’accès à vos données contre une rançon.

Pourquoi les ‘mauvais défis’ peuvent nuire à la qualité

Lloyd Roden du Royaume-Uni nous a présenté un «Top 10 des défis auxquels nous sommes confrontés aujourd’hui» dans le milieu de l’informatique en général: en commençant par une vidéo énergique rythmée par ‘eye-of-the-tiger’, il indique que les défis sont très différents selon les personnes, et a souligné le danger des ‘mauvais défis’ qui ont des effets négatifs sur nous, comme le ‘mauvais’ stress.

Au sein de ces défis dangereux trône l’interprétation erronée des métriques par la direction, ou comment bien souvent la quantité prend le dessus sur la qualité. En utilisant l’exemple du nombre de cas de test exécutés pour illustrer cette réalité: le testeur A exécute 30 cas de test par jour, le testeur B seulement 2. Par une interprétation erronée et un raccourci de l’esprit, le testeur A pourrait être considéré comme étant plus productif, pouvant mettre en péril la réputation du testeur B. Cependant, si nous commençons à remettre en cause ces mesures, et allons plus loin dans les détails, on pourrait s’apercevoir que A avait seulement 5 étapes par cas de test avec des pré-requis faciles et rapides à mettre en place, alors que B avait 40 étapes par cas de test avec de nombreuses données de test pré-requises et difficiles à créer à la main, sans aucune aide automatisée pour le faire.

Je me souviens personnellement, en complément du discours de M. Roden, de la présentation ‘Pass or Fail obsession’ de Rikard Edgren lors de la conférence Eurostar en 2012, où il mentionnait que la hiérarchie risquait de se concentrer beaucoup plus souvent sur les couleurs ‘vert’ ou ‘rouge’ représentant les 2 états possibles d’une suite de test à son exécution, plutôt que les résultats réels et la valeur de ce test, qui peuvent cacher un vice malgré le côté vert passant. Par résultats, je veux par exemple parler de nouvelles questions amenées suite à l’exécution, de problèmes observés dans les parties du logiciel qui ne sont pas couvertes par ce test spécifique.

Atelier ‘Tester les algorithmes intelligents: sommes-nous prêts?’:

Les présentations sont intéressantes mais on peut facilement se laisser porter et oublier que la meilleure façon d’apprendre vient avec la pratique: dans ce but, j’ai pu assister à l’atelier de Bill Matthew, dont le but était d’approcher le test d’algorithmes complexes que nous rencontrons fréquemment tous les jours.

L’un des exercices consistait à tester un système de recommandation.

Ce type de système se retrouve sur de nombreux sites web comme celui d’Amazon, qui recommande aux clients sur chaque page de produits d’autres produits, au même titre que le site internet d’une chaîne de télé peut vous recommander d’autres émissions à regarder en plus de celle qui vous intéresse réellement. Le degré d’éloignement des recommandations par rapport au produit qui vous intéresse au premier abord constitue un défi: la fonctionnalité de recommandation doit être construite de manière à éviter des ‘mauvaises’ recommandations; Il n’y a malheureusement aucune règle spécifique capable de déterminer cela, puisque dépendant de chaque utilisateur et donc très subjectif: par exemple si le système recommande de la nourriture contenant de la viande à un végétarien, cela peut être perçu de manière très négative, pouvant aller dans le pire des cas à la perte du client et une augmentation de la mauvaise réputation de l’entreprise.

En gardant ces aspects en tête, nous avons discuté en équipe des stratégies de test possibles. Une fois de plus, puisqu’il n’y a aucune règle spécifique avec ce type de fonctionnalité, il n’y a aucun comportement clair et prédéfini auquel s’attendre, et l’injection de deux jeux de données identiques en entrée avec les mêmes étapes peuvent conduire à des résultats très différents en sortie.

Voici quelques idées intéressantes qui ont émané des groupes:

  • Afin de déterminer comment le système de recommandation se comporte, tester tout d’abord avec des jeux de données restreints et des étapes simplifiées pour observer les résultats: les recommandations peuvent se baser sur tant de critères — la couleur, la taille d’un vêtement — que les tests peuvent vite devenir complexes avec de nombreuses variables. Il faut donc pouvoir démarrer avec des tests simplifiés maîtrisés le mieux possible,
  • Accroître la diversité des données de test en réinjectant régulièrement les données de production, afin de recueillir plus d’informations et de couvrir plus de terrain,
  • Puisque le concept de ‘bonne’ ou ‘mauvaise’ recommandation est très subjectif, il peut être très utile d’établir différents profils de clients; L’analyse des données de production et des tests bêta par des utilisateurs réels permettront de répondre à ce besoin.

Les résumés présentés ici ne reprennent que quelques présentations, il y en a eu bien sûr plein d’autres sur des sujets très variés, comme l’amélioration de la testabilité, ou encore la réduction des problèmes d’environnement. Pour plus d’informations consulter le programme complet de la conférence ici.

Lightning talks ou ‘présentations éclair’: du contenu intéressant

Pour ceux d’entre vous qui ne sont pas familiers avec ce concept, il s’agit d’une courte présentation informelle sans support visuel de cinq minutes maximum, suivie d’une discussion avec le public; Le but de ce format est d’encourager ceux qui n’ont jamais présenté un sujet sur scène à prendre la parole devant une audience. La session s’est tenue en début de soirée après quelques verres afin de rassurer les plus timides.

Du contenu très intéressant a émané de ces présentations éclair, plus ou moins liées à l’expérience personnelle, et amenées par de récentes réflexions. En voici quelques exemples:

Anticiper les anomalies en lisant le code

Avez-vous déjà eu ce moment où vous attendiez la livraison d’une nouvelle version du logiciel à tester car le code était en revue de pairs, et vous vous êtes demandés: “Qu’est-ce que je pourrais encore tester d’intéressant avant la livraison?”

Même si vous ne comprenez pas complètement le code écrit — que ce soit un langage que vous ne connaissez pas, ou que vous ne soyiez pas du tout familier avec la programmation objet -, il est toujours possible de repérer des schémas, des messages d’erreur codés en dur et des boucles de condition. Le participant a expliqué comment, en relisant les ‘pull request’ du code, il avait trouvé plusieurs cas qui n’avaient pas été gérés par le code pour les anomalies dont il attendait la correction, permettant ainsi d’éviter une livraison qui aurait échoué aux tests.

Quitter le test logiciel

Avez-vous déjà ressenti ce sentiment de nostalgie lorsque l’un de vos collègues vous annonçait qu’il ‘quittait’ son rôle de testeur pour prendre un nouveau poste? Il est possible que vous ayiez pensé à ce moment-là qu’il y avait de moins en moins de testeur car moins d’intérêt pour ces rôles… Et si cette nouvelle position leur permettait de répandre plus efficacement cette vision unique de la qualité qu’ils ont acquis au préalable? le participant a essayé de nous dire ici qu’endosser un nouveau rôle n’était pas nécessairement négatif pour le futur du test logiciel, et qu’au contraire avoir par exemple des développeurs ou des chefs de produit avec une expérience de testeur fonctionnel pouvait au contraire avoir plus de bénéfices et d’impact qu’il n’y paraissait.

La spécialisation vs la généralisation

Au cours de leur carrière, les testeurs acquièrent différentes compétences afin de pouvoir résoudre des problèmes pour tester les logiciels… Quelques-uns deviennent même spécialistes dans un domaine bien spécifique: automatisation, test des bases de données, tests de performance, etc. Le participant nous a fait ici réfléchir aux deux concepts: est-ce que se spécialiser revient à rétrécir son champ de vision et se biaiser? D’un autre côté, est-ce que l’on prend des risques à être perçu comme “pas suffisamment technique” si on n’est pas spécialisé pour ses futures perspectives de carrière? En nous rappelant que les deux idées sont compatibles puisque la spécialisation démarre toujours de la généralisation, il a comparé à d’autres métiers, par exemple être une infirmière au départ, qui se spécialise dans l’accompagnement et le traitement des patients atteints de cancer du poumon: votre noyau de compétences et votre objectif déviera peu.

Pourquoi aller aussi loin pour une conférence?

Il y a tellement de conférences en Europe de l’Ouest que vous pourriez vous demander pourquoi j’ai décidé de participer à cette conférence si loin de la France…

A cette question il y a une réponse bien précise: puisque je m’y suis rendu par mes propres moyens et qu’aucune entreprise ne me payait le ticket, j’y suis allé car j’ai été sélectionné en tant que participant pour présenter un sujet bien précis! Cétait donc une excellente opportunité de combiner l’apprentissage et le partage de connaissance avec d’autres testeurs.

Je publierai très bientôt un autre article, où vous en apprendrez plus sur cette conférence mais cette fois du point de vue ‘présentateur’.

Pourquoi devrais-je participer à cette conférence?

En 2012 à Amsterdam j’ai participé à la conférence Eurostar, qui a été la seule autre ‘grande’ conférence sur le test logiciel à laquelle j’ai pu assister. Nordic Testing Days est un peu loin si vous vivez en Europe de l’Ouest, et pourrait ressembler à d’autres, mais je l’ai personnellement beaucoup appréciée pour les raisons suivantes:

  • Les organisateurs sont très accueillants, très arrangeants et très rassurants face aux quelques imprévus qui peuvent survenir;
  • Au travers de multiples jeux et activités proposées par les sponsors et les organisateurs, je me suis senti constamment impliqué et actif en-dehors des sessions de présentation: chasse au trésor, karaoké powerpoint, énigmes à résoudre, etc
  • Le plus important, de la bonne nourriture et des boissons gratuites, même pendant la soirée du jeudi, salutaire après une longue journée d’écoute et de présentation!
  • En tant que présentateur, je me suis senti estimé par l’organisation, et j’ai réellement eu l’impression d’apporter une contribution positive au public présent.

Je dirais avant tout que cette conférence était moins formelle que par exemple Eurostar, qui par sa taille et sa réputation attire un plus grand nombre de sponsors et de professionnels.

Résumé

Sans aucune hésitation je recommande cette conférence non seulement aux testeurs mais plus généralement aux gens qui travaillent dans l’IT. Très bien structurée et organisée, tout en alliant le plaisir et le réseau, il s’agit d’une des conférences les moins formelles à laquelle assister avec pour autant un contenu incroyablement enrichissant et des présentateurs de qualité.

Like what you read? Give Lyon Testing a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.