Auteur/autrice : admin@hightest

Priorisation : que faire quand ça semble trop tard ?

Pour ce troisième article sur les métaphores au service du test, nous allons nous pencher une fois de plus sur l’ennemi juré de la qualité : le temps, qui vient souvent avec ses cousins le rush, le stress et la précipitation. Et si une métaphore nous aidait à nous réconcilier avec ce facteur incontrôlable ?

Problématique

Le sprint est presque fini mais rien n’est vraiment prêt. Toute l’équipe est stressée et ne sait plus où donner de la tête. Freeze : c’est peut-être le moment de se calmer un peu et de faire le point sur ce qu’on peut rapidement finaliser. Vous avez besoin d’un déclencheur pour vous sortir la tête du guidon et aller à l’essentiel.

Métaphore

« Récolter les fruits d’un travail » est une métaphore assez commune. En cette fin de sprint ou d’itération, vous et votre équipe êtes en pleine cueillette. Mais vos paniers ne se remplissent pas très vite et vous vous inquiétez car le soleil est en train de se coucher. La lumière décline, les figues sont de moins en moins visibles dans les arbres et l’angoisse de ne rien cueillir habite chacun d’entre vous. Naturellement, à ce stade, ce sont les figues les plus basses que vous devez récolter, peu importe si elles sont petites. Le « low-hanging fruit« , c’est un bénéfice rapide que l’on peut faire en déployant un effort modéré.

Cette métaphore est souvent utilisée dans la littérature agile, et en particulier dans More Agile Testing. Dans l’objectif de livrer de la valeur à chaque sprint, il est parfois intéressant de se focaliser sur ce qui est rapidement faisable plutôt que sur ce qui serait idéal à long terme. On pourrait utiliser cette métaphore en réunion, par exemple pour organiser des postits énumérant des solutions à un problème. Attention tout de même à garder en tête la notion de valeur, afin de ne pas cueillir un fruit pourri…

Un exemple de schéma :

Si vous êtes pressé par le temps, relevez la tête et pensez fruit !

Priorisation bis : le puzzle logiciel au service de la sérénité

Mais fort heureusement, nous ne sommes pas toujours en guerre contre le temps. Côté test, une analyse d’un logiciel par les risques permet de limiter les situations de stress et de faire au mieux en temps limité. Et cela, c’est encore une métaphore qui va nous aider à le partager.

Problématique

En bon choriste de l’ISTQB, vous connaissez par coeur les paroles de « Les défauts sont regroupés » et de « Les tests exhaustifs sont impossibles« . Vos interlocuteurs n’ont peut-être pas envie de vous les entendre chanter encore une fois. Il vous faut rafraîchir cette même idée avec une métaphore.

Métaphore

Janet Gregory compare un logiciel à un puzzle dont on découvre l’image peu à peu, au fur et à mesure où l’on assemble ses pièces. Elle explique qu’il est possible d’obtenir des informations sur le puzzle sans l’assembler en entier, et tant mieux, car cela prendrait un temps fou. Pour tester dans les temps, il faut se concentrer sur les parties du puzzle qui nous intéressent le plus.

Imaginons que notre tableau représente une réplique, peinte par un contemporain, de la fresque de La Création d’Adam, peint par Michel Ange sur le plafond de la Chapelle Sixtine au début du XVIè siècle. Il est spécifié que la réplique doit être la plus fidèle possible à l’original, nous voulons donc tester si cela a été respecté, en maximisant nos chances de trouver d’éventuels défauts. Alors, voici ce que nous allons prendre en compte :

• La partie du tableau où les doigts d’Adam et de Dieu sont sur le point de se toucher est absolument critique. C’est la plus connue, la plus emblématique de l’oeuvre, celle qui justifie son titre ; c’est l’équivalent du cœur de métier. Il faut qu’elle soit testée.
• Les visages sont des parties d’un tableau qui peuvent être très intéressantes, mais le moindre détail peut ruiner une expression. On va donc assembler ces parties avec une priorité élevée.
• On sait que le ciel est quasiment un aplat, il contient peu de détails. Inutile d’assembler beaucoup de pièces pour pouvoir affirmer, avec un niveau de confiance élevé, s’il est fidèle au ciel original.
• Le paysage où se tient Adam n’est pas aussi uniforme. Il n’est pas utile d’assembler toutes ses pièces si jamais on manque de temps, mais il n’est pas à négliger pour autant.

Les trois puzzles ci-dessous correspondent à des couvertures de test différentes, mais en cas de manque de temps, on comprend que c’est la première qu’il faudra choisir.

Pour approfondir cette métaphore avec son inventrice, rendez-vous sur le blog de Janet Gregory !

Conclusion

Ici, la métaphore nous permet de dynamiser notre exigence de qualité plutôt que de laisser l’exigence de rapidité inhiber nos forces. Même en cas d’urgence, il est profitable de faire une courte pause pour orienter au mieux nos dernières heures disponibles.

Nous espérons que cette petite série d’articles vous aura plu. Nous développerons peut-être à l’avenir d’autres métaphores ; nous espérons avoir bien illustré le fait qu’il s’agit de puissants outils de pensée.

N’hésitez pas à poster vos propres métaphores dans les commentaires !

Découvrez nos autres séries d’articles !

Notre saga du test audiovisuel

Notre série dédiée aux tests de sécurité

Celle dédiée à Protractor

La métaphore en action

« Tu travailles dans le test ! Quels langages tu connais ? »

Dans les prochains articles, nous n’allons pas parler de Python, Java ou Ruby, mais d’un langage que l’on utilise tous les jours en tant que QA : le « langage naturel« . Par commodité, c’est comme ça que l’on nomme le langage que l’on parle aussi bien à la maison qu’au bureau. Mais il n’a rien de « naturel » ; nous allons au contraire nous pencher sur des manières de le modeler, de le ciseler, afin de le rendre plus efficace, plus à même de servir la qualité des projets. Nous allons pour cela nous appuyer sur le procédé de la métaphore.

Pourquoi cette figure de style en particulier ?

La rencontre de deux univers sémantiques

Le mois dernier, sur le blog de la Taverne du Testeur, Marc Hage Chahine filait une longue métaphore sur le métier du test en le mettant en parallèle avec une chasse aux champignons. L’article allie l’utile à l’agréable en poursuivant un but bien précis : donner une explication d’un processus complexe, de façon à ce qu’un enfant de 6 ans puisse la comprendre.

Le résultat est assez réussi. Pourquoi ? Parce qu’en sollicitant un univers sémantique familier, on peut faciliter la compréhension d’un autre univers plus difficile à imaginer. Autre avantage : l’interlocuteur peut poursuivre la métaphore et ainsi alimenter la discussion, beaucoup mieux que s’il n’avait pas ce point de repère. Il peut par exemple se replonger dans un embarras qu’il a déjà vécu (ramasser un caillou qu’il prenait de loin pour un champignon) pour imaginer certaines situations du métier (la frustration des QA qui tombent sur des faux positif).

Et les métaphores sont partout. D’ailleurs, elles constituent souvent le ressort comique des memes et des GIF. Un exemple ?

On dit souvent qu’une image vaut mille mots. Mais ce qui est vrai à l’écrit, avec les graphiques et les illustrations (et, donc, les GIF), l’est donc aussi à l’oral, avec les métaphores. La formulation d’une idée peut avoir un impact notable sur la façon dont le cerveau de l’interlocuteur est stimulé. Ces dernières années, des chercheurs se sont même employés à le confirmer expérimentalement.

Les effets d’une métaphore sur le cerveau

Le psychologue Rutvik Desai, dans un article paru en 2011, a par exemple observé que les verbes d’action, y compris ceux qui étaient présents dans des métaphores, faisaient réagir les zones moteur du cerveau (source [PDF]). Ce qui pourrait signifier que la phrase « Il va falloir qu’on se serre les coudes pour terminer cette campagne de test » est plus stimulante que « Il va falloir qu’on s’entraide […] ». A noter : plus une métaphore est commune, moins elle active les zones moteur du cerveau. Quand on dit qu’on saisit l’intérêt de quelque chose, l’image de la préhension est assez lointaine. C’est comme si le cerveau avait besoin d’un effet de surprise pour que la métaphore joue son rôle.

Des résultats similaires ont été obtenus par l’université d’Emory en 2012 avec des métaphores contenant des références au toucher (source). Là, par exemple, on pourrait remplacer « Votre implication m’a fait très plaisir » par « m’a fait chaud au coeur ».

On voit bien pourquoi les ouvrages de fiction nous donnent l’impression de nous évader ; l’imagination, entendue comme production d’images mentales, peut mettre en action les zones du cerveau impliquées dans les mêmes actions lorsqu’on les vit réellement. De la même manière, on peut aussi supposer que les métaphores, lorsqu’elles sont utilisées au travail (pour susciter l’attention, expliquer une idée, défendre un point de vue, motiver une équipe…) peuvent jouer un rôle intéressant.

C’est en tous cas ce que nous avons pensé en lisant l’excellent ouvrage More Agile Testing (2014) de Janet Gregory et Lisa Crispin. Le propos, truffé de métaphores intéressantes, en est d’autant plus limpide et stimulant. Nous avons donc décidé d’en sélectionner quelques-unes et de les développer dans une série d’articles.

Pour entrer dans le vif du sujet, voici la première métaphore de notre série, qui vous permettra peut-être de résoudre des situations de conflits d’intérêts.

Vélocité : le bus rapide VS le bus efficace

Problématique

Vous en avez assez de ressasser le sempiternel triangle Coût-Temps-Qualité. Dans certains contextes, vous avez besoin d’une autre image pour faire comprendre que la qualité prend du temps au début, mais qu’il serait contre-productif de la négliger.

Métaphore

Parole à David Evans, coach agile (traduit par nos soins) :

« Le management se montre parfois réticent lorsque je préconise d’écrire collaborativement les tests d’acceptation avant de se lancer dans l’implémentation de chaque story. On m’objecte généralement que cette tâche ralentirait la vélocité du développement. Je leur concède qu’en effet, en une certaine mesure, ça ralentit les choses. Cela dit, s’arrêter pour prendre des passagers ralentit aussi le trajet d’un bus. »

Il cite ensuite Kent Beck dans Test-Driven Development: By example (2002).

« Si écrire des tests d’acceptation avant de se lancer dans l’implémentation ralentit une chose, c’est bien la vitesse de création de code qui ne marchera pas. »

La métaphore du bus met en oeuvre un raisonnement absurde :

• Les transports publics sont trop lents
• S’arrêter pour prendre des passagers ralentit les transports publics
• Donc les transports publics devraient cesser de prendre des passagers.

Si l’on suit cette logique, les transports publics gagneront en rapidité mais le résultat final ne correspondra en rien à ce qui était attendu. Les usagers résilieront leur abonnement, congestionneront le centre ville avec leurs voitures personnelles et critiqueront les transports publics sur les réseaux sociaux.

Nous vous proposons de filer la métaphore d’une manière qui vous permettra maintenant de rejoindre votre interlocuteur. Il s’agit d’abonder dans son sens dans la première partie de l’argumentation, mais de proposer d’autres solutions pour accélérer le trajet du bus. La métaphore devient ici force de créativité. En se projetant dans la problématique du bus, on quitte le quotidien du projet et on suscite de nouvelles idées.

Un exemple :

• Les transports publics sont trop lents
• Un ensemble de trajets mal optimisés ralentit les transports publics
• Donc il faut s’atteler à revoir tout ou partie de ces trajets. Autrement dit : existe-t-il des étapes de notre workflow qui ralentissent le projet sans contrepartie ?

Ou encore :

• Les transports publics sont trop lents
• Le trafic des autres modes de transports ralentit les transports publics
• Donc il faut s’atteler construire des voies dédiées aux transports publics. Autrement dit : existe-t-il des facteurs extérieurs qui ralentissent le projet et que nous pourrions limiter ?

La métaphore nous a servi ici à combattre une idée allant à l’encontre de la qualité du projet, de rejoindre son interlocuteur et d’entamer avec lui une discussions sur l’amélioration des processus.

Conclusion

Les métaphores peuvent donc être utilisées pour mieux nous faire comprendre, en particulier lorsque le sujet est complexe. Mieux encore, en nous faisant voir les choses sous un autre angle, elles peuvent initier une réflexion et susciter de nouvelles idées.

Merci au Guichet du Savoir pour les recherches bibliographiques sur la confirmation expérimentale de la puissance de la métaphore ainsi qu’à Audrey Loiseau qui nous a transmis le GIF. Et merci à vous, qui posterez vos propres métaphores dans les commentaires !

Nous publierons prochainement une autre métaphore issue de More Agile Testing.

L’Agile c’est quoi ?    

La méthode Agile n’est plus vraiment à présenter, cette méthodologie basée sur des cycles itératifs a su s’imposer dans de nombreux projets de développements.

Pour rappel, les 4 valeurs fondamentales de la méthode Agile sont :

• L’ équipe : « Les individus et leurs interactions, plus que les processus et les outils »
• L’ application : « Des logiciels opérationnels plus qu’une documentation exhaustive »
• La collaboration : « La collaboration avec les clients, plus que la négociation contractuelle »
• L’ acceptation du changement : « L’ adaptation au changement, plus que le suivi d’un plan »

Et le testeur dans ce contexte ?

Le métier du test est en constante évolution de par l’évolution des technologies, des outils de tests automatisés et des méthodes de gestion de projet.

Dans un contexte Agile, le testeur a une place prépondérante pour le succès du projet.

ISTQB en a d’ailleurs fait un syllabus que vous pouvez retrouver ici.

Comment se positionner ? Quels types de tests réaliser ? Avec qui interagir ?

Nous vous donnons quelques clés du succès qui feront de vous un bon testeur Agile dans cette vidéo :

Vous êtes certifié ISTQB fondation ? vous souhaitez être certifié ISTQB testeur Agile ? Contactez nous !!

Vous aimerez peut-être…

5 graphiques Jira pour mieux communiquer sur les anomalies

Réunion de clôture : un jeu pour finir en beauté !

Respectons le sens des valeurs agiles (blog d’Atlas Management)

 

Une étude annuelle sur le monde du test logiciel

Le premier World Quality Report (en bon français, rapport mondial sur l’assurance qualité) a été publié en 2009 par Capgemini. D’année en année, l’étude s’est étoffée, a gagné en moyens et en notoriété. En 2017, le World Quality Report, c’est :

• 1660 seniors de l’IT interrogés
• 32 pays représentés (dont la France, avec 150 personnes interrogées)
• Une photographie à l’instant T de l’assurance qualité dans les organisations publiques et privées de plus de 1000 employés
• Des focus par thème, mais aussi par type d’entreprise
• Des recommandations pour faire face aux problématiques actuelles du métier

Bref, un panorama intéressant à décoder, en gardant tout de même à l’esprit que cette année l’étude a été commanditée par la Sogeti et Capgemini, en partenariat avec l’éditeur Microfocus. Ce pure-player a notamment développé Silk Test et, plus dernièrement, racheté un large portefeuille de logiciels d’Hewlett-Packard Enterprise, dont Loadrunner. Ce qui n’est pas neutre…

Notre article fait le point sur trois sujets brûlants dans le domaine du test logiciel : les transformations du métier induites par l’émergence de l’agilité, le défi encore peu exploré des tests mobiles et les challenges liés à l’automatisation des tests.

Le boom du test agile

Les chiffres du test agile

En développement comme en test, le World Quality Report révèle que l’agilité a le vent en poupe. 95% des répondants affirment mettre en oeuvre des pratiques de test agile, au moins sur une partie de leurs projets. 37% des entreprises pratiquent le test exploratoire.

Les pratiques devOps aussi sont également en expansion, et sont désormais représentées dans 88% des entreprises interrogées. Cependant, elles ne touchent jamais la totalité des projets, et concernent moins de 20% des projets dans 47% de l’ensemble des entreprises.

De nouvelles contraintes

Face à cette transformation, les forces vives du test tendent à se décentraliser, et affrontent notamment trois problématiques :

• La création d’environnements de test idoines et de jeux de données réalistes, qui notamment respectent les lois en vigueur (« QA teams need to help their organizations comply with new data laws such as the EU’s General Data Protection Regulation », ce qui nous rappelle une fois de plus l’aspect juridique du métier de testeur). Cette problématique rend également difficile l’automatisation des tests et les tests mobiles.
• La réutilisation et la répétition des tests au fil des itérations
• Le manque de méthodologie de test agile

Même si la décentralisation du test présente de nombreux avantages, le WQR conseille aux grandes organisations de conserver un organe central (un « TEC » ou « Test Excellence Center ») afin d’harmoniser les pratiques, de capitaliser sur les réussites et de réaliser des POCs.

Automatisation des tests : un horizon impossible ?

Les chiffres de l’automatisation des tests

Le World Quality Report de 2017 révèle que presque la moitié des entreprises (48%, et jusqu’à 57% des entreprises spécialisées dans les télécoms, les médias et les divertissements), se trouvent trop dépendantes des tests manuels. Et effectivement, le chiffre peut étonner : seuls 16% des cas de test fonctionnels sont automatisés !

Parmi les difficultés le plus fréquemment rencontrées, on retrouve :

• Le manque d’outils et méthodes d’automatisation
• L’intégration de différents outils de tests
• La complexité du cycle de vie du logiciel

Autant de challenges qui freinent l’avancement des projets d’automatisation, et augmentent année après année le manque à gagner.

Des pistes pour mieux automatiser les tests

Face à ce constat, le World Quality Report conseille de s’armer de patience. Le rapport indique que parmi les entreprises ayant mis en oeuvre une stratégie d’automatisation des tests, celles dont la démarche a été la plus fructueuse ont commencé par des projets-pilotes autonomes (à l’inverse d’une approche « big bang »).

Il est aussi conseillé de prendre au sérieux la formation en automatisation des tests des équipes qualité, où d’importantes lacunes sont constatées.

Enfin, la présence d’une réelle stratégie et la transparence des reportings des tests automatisés sont cités comme des critères de réussite majeurs.

Tests mobiles : ça pourrait bouger plus

C’est ce qui ressemble à la cinquième roue du carrosse : 52% des répondants n’ont pas assez de temps pour mener des tests mobiles. 47% pointent un manque de méthodologie dans le domaine, 46% ne disposent pas d’équipements adéquats. 5% des organisations interrogées ne font même aucun test mobile.

Ces chiffres sont étonnants, à l’heure où des solutions open-source telles qu’Appium, ou des IDE performants et gratuits comme Katalon, permettent de mettre en oeuvre à moindre coût des stratégies de test mobile, y compris en externalisant la gestion des hardwares (avec par exemple AWS Device Farm, Xamarin Test Cloud ou Kobiton).

Un point intéressant à relever est que les tests non-fonctionnels sont bien représentés dans le domaine du test mobile :

• 53% des stratégies incluent des tests de performance
• 43%, des tests de sécurité
• 39%, des tests de compatibilité
• 38%, des tests de portabilité,

Contre 48% pour les tests d’interface utilisateur.

Plongée dans le passé : quoi de neuf depuis 2009 ?

L’automatisation des tests était déjà source d’embarras

Certaines choses ne changent pas : en 2009, les entreprises étaient déjà frustrées par leur taux d’automatisation des tests. Le World Quality Report indiquait en effet que 50% des entreprises n’avaient pas atteint leurs objectifs d’automatisation 3 ans après avoir acquis les outils ad hoc. En cause : le manque de plannification, de stratégie sur le long terme et de formation des testeurs. A l’époque, des solutions d’automatisation existaient déjà depuis une quinzaine d’année.

… mais la vision de l’automatisation a mûri

Il existait à l’époque un aspect qui peut maintenant nous étonner : dans l’édition de 2009, la majorité des personnes interrogées pensaient que l’automatisation des tests pourrait aider à réduire la taille de l’équipe de test. Une corrélation qui de nos jours paraît naïve, et qui a d’ailleurs totalement disparu dans l’édition de cette année.

On est sortis de la crise…

Dans le WQR de 2009 transparaît un sentiment d’inquiétude lié à la crise. L’agilité est directement assimilée à un gain pécuniaire, les robots de test semblent voués à remplacer les humains… Il est réjouissant de constater qu’en 2017, ce biais a disparu (au profit d’autres que nous n’identifierons sans doute, hélas, qu’en 2025).

… et on a découvert tant d’autres choses

Pour faire bref, voici quelques mots que l’on ne trouvait pas encore dans la première édition du World Quality Report :

• Mobile
• API
• Load testing
• DevOps (et pour cause, le mot a été inventé deux mois après la parution du WQR de 2009 !)

La sécurité applicative, la performance et le cloud sont brièvement évoqués, mais on ne les retrouve pas plus loin que dans l’introduction. Bref, depuis la première édition du WQR, le métier du test n’a eu de cesse de s’étoffer. Multidisciplinaire en pratique, il l’est devenu de plein droit au fil des années.

Conclusion

Certes, il n’est pas toujours facile de comprendre comment sont générés les chiffres du World Quality Report. « Nous ne pratiquons pas le test agile » : ils étaient 2% à l’affirmer en 2015, contre 31% en 2016 (!) et maintenant 5% en 2017… Mais malgré ce genre de bizarreries que l’on retrouve tout du long, ainsi que quelques partis pris qui s’expliquent par les commanditaires de l’étude (par exemple l’évocation de TMap, mais pas d’ISTQB) le WQR reste un document utile pour prendre la température du monde du test et comprendre les problématiques auxquelles font face aujourd’hui les grandes organisations. Une analyse qui s’avère encore plus intéressante lorsqu’on la met en parallèle avec les éditions précédentes. Alors bonne lecture !

Ressources

World Quality Report de 2009 (pdf)

World Quality Report de 2017 (formulaire de téléchargement)

Vous aimerez peut-être…

Chiffres sur l’accessibilité du web calédonien

Le test logiciel est une protection contre les bugs, mais aussi contre les litiges. Vous avez un doute ? Cet article est fait pour vous.

La loi relative à l’informatique, aux fichiers et aux libertés, indique :

Constitue une donnée à caractère personnel toute information relative à une personne physique identifiée ou qui peut être identifiée, directement ou indirectement, par référence à un numéro d’identification ou à un ou plusieurs éléments qui lui sont propres.

Sous peine de sanctions, ce type de données doit faire l’objet d’un traitement particulier. Toute personne travaillant dans la qualité logicielle devrait valider que les données personnelles sont manipulées de manière légale.

1) Il est obligatoire d’assurer la sécurité des données personnelles

Comme le dit l’article 34 de la loi,

Le responsable du traitement est tenu de prendre toutes précautions utiles, au regard de la nature des données et des risques présentés par le traitement, pour préserver la sécurité des données et, notamment, empêcher qu’elles soient déformées, endommagées, ou que des tiers non autorisés y aient accès.

La loi est sans équivoque : la sécurité des données personnelles relève de la responsabilité de celui qui les traite. En cas d’attaque informatique, l’entreprise victime de l’attaque peut être poursuivie en justice par ses internautes. Double effet kiss cool.

Les QA, connaissant cette problématique, doivent veiller à ce qu’elle soit soulevée au plus tôt, et si possible renforcer la sécurité des informations en pratiquant des tests de sécurité.

2) Le traitement des données doit être transparent

Les utilisateurs doivent être informés de leurs droits. Pouvoir consulter les mentions légales (dont le contenu est également réglementé) est obligatoire.

3) La localisation des données est réglementée

Transférer des données personnelles en-dehors de l’UE a des implications juridiques. Il est important de savoir vers quels pays les données personnelles peuvent être transférées. A titre d’exemple, en mars 2017, il est possible de transférer des données personnelles en Argentine, mais pas en Australie.

4) Envoyer un mail peut être un délit

Envoyer un mail ne coûte rien… mais ce n’est pas toujours autorisé. Il est interdit d’envoyer des mails commerciaux à des adresses trouvées dans des espaces considérés comme publics : pages web sans authentification, forums de discussion, annuaires.

Le cas échéant, si un internaute donne volontairement son adresse e-mail, il faut impérativement lui dire qu’il est susceptible de recevoir des offres commerciales.

Tout courrier commercial doit proposer un lien de désinscription.

Dans les formulaires, les cases à cocher proposant l’envoi de mails publicitaires doivent être décochées par défaut.

Plus d’informations ici.

5) Ne pas crypter les mots de passe peut coûter cher

Il est interdit de conserver en base de données des mots de passe non cryptés, comme Optical Center qui, en 2014, en a fait les frais. 50 000 euros d’amende ont dû être déboursés. Un coût financier mais aussi réputationnel… A cet effet, la CNIL donne des éléments pour mettre les mots de passe en sécurité.

6) Stocker certaines données est interdit

Une donnée sensible, au sens CNIL, concerne un ou plusieurs des aspects suivants de l’internaute :

• ses origines raciales ou ethniques,
• ses opinions politiques, philosophiques ou religieuses,
• ses appartenances syndicales,
• sa santé ou son orientation sexuelle,
• ses données génétiques ou biométriques,
• son passé judiciaire,
• son numéro de sécurité sociale.

Attention, certaines données sont sensibles sans en avoir l’air. Vous demandez à vos utilisateurs s’ils sont végétariens, végans, au régime sans gluten, sans oeufs, sans porc, sans lactose ? Sans le savoir, vous êtes sur le point de stocker une donnée sensible dans votre base de données. Demandez-vous si le risque en vaut la peine.

Le traitement des données sensibles est en principe interdit. Si ces informations sont vraiment nécessaires, leur recueil doit être justifié et nécessite le consentement exprès de la personne. Par prudence, il est conseillé de demander un avis sur les données sensibles à la CNIL, voire une demande d’autorisation (obligatoire par exemple pour le numéro de sécurité sociale). Attention, la réponse peut prendre quelques mois avant d’arriver.

Toutes les données sensibles sont concernées : celles déclarées par les utilisateurs sur le site, celles recueillies « IRL » et informatisées ensuite, et même si ces informations sont prévues pour être utilisées strictement en interne. La CNIL donne une définition précise de la donnée sensible.

7) Il est interdit de placer un cookie sans autorisation

Il est obligatoire de :

• communiquer aux internautes la finalité des cookies
• demander leur consentement (dont la durée maximale de validité est de 13 mois)
• leur fournir un moyen de refuser les cookies.

Et tout cela, avant de générer le cookie.

En savoir plus sur les cookies

Respecter la propriété intellectuelle

8) Les contenus textuels et multimédias doivent être contrôlés

Des questions de bon sens sont de rigueur :

• Les contenus affichés par le système à tester appartiennent-ils à sa société éditrice ? Si non, les autorisations idoines ont-elle été produites ?
• Les crédits sont-ils correctement mentionnés ?
• Le droit de courte citation est-il correctement appliqué ? Le contenu est-il exempt de plagiat ?
• Les personnes dont les photos apparaissent ont-elle donné une autorisation explicite ?

Quelques vérifications bien utiles, qui prendront peu de temps à l’équipe de test et pourront éviter litiges et bad buzz.

9) Les briques open-source peuvent imposer des contraintes qu’il faut respecter

Si le produit comprend des briques issues de programmes open-source, il est essentiel de respecter la licence qui leur est associée. Attention, certains logiciels open-source obligent à partager leurs versions modifiées (par exemple avec la licence GNU GPL).

Conclusion

Certes, les QA ne sont pas des juristes. Dans une vision 360° de la qualité, nous devons pourtant être capables de porter un regard critique sur les aspects juridiques du système à tester. Les champs d’étude sont extrêmement vastes : il faudrait encore parler du droit à l’oubli, des lois propres aux sites de e-commerce… Nous ne saurions assez vous conseiller d’investiguer afin de comprendre jusqu’où les tests peuvent aller.

Bonus

• Une liste de sanctions prononcées par la CNIL. Vous reconnaîtrez des noms d’entreprises françaises célèbres.
• Un célèbre litige dû à une pointeuse non déclarée à la CNIL.

Vocabulaire ISTQB : on fait le point !

Dans le domaine du test comme ailleurs, il est important de bien nommer les choses afin de partager un langage commun avec ses interlocuteurs.

Quelle est donc la différence entre un test de charge et un test de performance ? S’agit-il de la même chose que d’un test de stress ? De robustesse ?… Sans avoir connaissance des définitions précises de ces termes, il est facile de s’emmêler les pinceaux.

Or, il arrive que des sons de cloche ne s’accordent pas, et par exemple que des sites se contredisent entre eux. Pourquoi ? D’une part, parce que les tests se ressemblent et mettent parfois en jeu les mêmes outils. D’autre part, parce que les termes évoquent des choses similaires ; dans la vie de tous les jours, on peut dire qu’une équipe performante est capable de tenir une grosse charge de travail en gérant bien son stress.

Il est donc important de se baser sur une source qui fasse autorité et permette de trancher ! Ici, nous nous réfèrerons au glossaire officiel de l’ISTQB, un « must-have » et un « must-read » pour les testeurs.  Plongeons-nous donc dans les définitions de ces termes !

Qu’est-ce qu’un test de performance ?

Test de performance : le processus de test pour déterminer les performances d‘un produit logiciel.

Performance : degré en fonction duquel le système ou composant accomplit les fonctions qui lui sont affectées dans le respect de contraintes données en ce qui concerne son temps d‘exécution et taux de débit. [d‘après IEEE 610]

Le but du test de performance est de fournir des métriques sur la rapidité de l’application. On veut déterminer si elle est capable d’exécuter ses fonctionnalités en un temps acceptable. La priorité n’est pas de connaître les performances de l’application dans un contexte particulier. Pour cela, un autre type de test peut être distingué : le test de rendement.

Le test de performance répond à la question : l’application est-elle suffisamment rapide ?

Des APIs permettent de diagnostiquer rapidement les problèmes de performances d’une page web. La plus utilisée est certainement PageSpeed, développée par Google. Elle founit un score sur 100, ainsi que des pistes pour améliorer la vitesse de chargement de la page.

Amusez-vous à utiliser cette ressource pour évaluer la performance de votre site web !

Voici par exemple les résultats du calcul des performances du site Testeum :

Qu’est-ce qu’un test de rendement ?

Test de rendement : le processus de test pour déterminer le rendement d‘un produit logiciel.

Rendement : la capacité du produit logiciel à fournir des performances appropriées, relatives au niveau de ressources utilisées dans des conditions spécifiées. [ISO 9126]

Le test de rendement introduit la notion de « conditions ». Le test de rendement permet d’établir un rapport entre performances et ressources utilisées dans un contexte réaliste (ex : plusieurs utilisateurs connectés en même temps, réalisant des requêtes consommant plus ou moins de ressources).

Le test de rendement répond à la question : l’application est-elle suffisamment rapide dans un contexte donné ?

Qu’est-ce qu’un test de charge ?

Test de charge : un type de test concerné par la mesure du comportement d‘un composant ou système avec une charge croissante, p.ex. nombre d‘utilisateurs et/ou nombre de transactions en parallèle pour déterminer quelle charge peut être gérée par le composant ou système

Le test de charge recherche la limite des capacités de l’application. En augmentant graduellement la charge à laquelle est soumise l’application, il est possible d’identifier des paliers. On peut considérer le test de charge comme un pré-requis au test de stress.

Le test de charge répond à la question : quelle est la charge maximale supportée par l’application ?

Qu’est-ce qu’un test de stress ?

Test de stress : Un type de test de performance mené pour évaluer un système ou composant à ou au-delà des limites de sa charge de travail anticipées ou spécifiées, ou avec une disponibilité réduites de ressources telles que l‘accès mémoire ou serveurs [d‘après IEEE 610].

Le test de stress permet d’anticiper les performances d’une application en contexte exceptionnel (afflux non anticipé d’utilisateurs, panne). Un cas d’école : l’explosion des visites sur un site de e-commerce le premier jour des soldes. On peut considérer le test de stress comme une catégorie de test de robustesse.

Le test de stress répond à la question : comment réagit l’application lorsqu’elle est soumise à sa charge maximale ?

Qu’est-ce qu’un test de robustesse ?

Test de robustesse : test concernant le degré pour lequel un composant ou système peut fonctionner correctement en présence de données d‘entrée invalides ou de conditions environnementales stressantes.

Le test de robustesse permet de vérifier qu’une application reste opérationnelle en contexte exceptionnel. Les menaces testées viennent aussi bien d’une charge importante (comme le test de stress) que de comportements non souhaités (flux d’informations incorrectes, de fichiers corrompus…)

Le test de robustesse répond à la question : comment réagit l’application lorsqu’elle est soumise à des inputs ou un contexte exceptionnels ?

Autant de tests non-fonctionnels…

Malgré leur synonymie apparente, les différents termes que nous venons de présenter donnent donc lieu à des tests spécifiques, que nous ne devrions pas confondre afin de maintenir une communication claire.

Envie de passer une certification ISTQB ?

Si vous souhaitez approfondir vos connaissances en test, nous organisons à la demande des accompagnements à la maîtrise d’ISTQB à Nouméa. Hightest est organisme de certification accrédité par le GASQ depuis 2015 et est habilité à organiser des examens ISTQB. Pour plus d’informations, veuillez prendre contact avec nous !

Et pour vos révisions, jetez un oeil à notre article Les 7 principes généraux du test en illustrations et à nos différents quiz en ligne !

Le testeur chargé de l’automatisation des tests est vulnérable à des troubles qui lui sont propres. Il est important de les connaître pour mieux s’en protéger.

La logopathie – Trouble cognitif

Symptôme

Le patient est le seul de son équipe à pouvoir lire les logs produits par ses tests automatisés. Souffrant d’une apparente dissonnance cognitive, il énonce des propos déroutants tels que « Tous ceux-ci ne passent pas mais c’est normal ».

Cause

Trop absorbé par le développement de ses automates, le patient a négligé la qualité du reporting, un élément pourtant nécessaire à la compréhension des résultats des tests.

Complications possibles

• L’équipe devient dépendante de son testeur automaticien. Par conséquent, s’il est absent, il est impossible d’analyser les résultats des tests automatisés.
• Analyser les logs devient si compliqué que, par manque de temps, on ne lance plus les tests automatisés. Tout le temps consacré à ce travail est désormais perdu.
• Dans le pire des cas, on finit par abandonner l’automatisation des tests.

Mesures préventives

• Utiliser un framework de test BDD : Gebish, Cucumber… qui prendra en charge nativement un reporting d’une clarté satisfaisante.
• A défaut, anticiper cette problématique dès le début du projet d’automatisation. Pour chaque étape du test automatisé, générer un log en bon français. Il est également important de faire savoir où se trouvent les reportings, afin que les personnes concernées puissent les trouver en toute autonomie.

Remèdes possibles

Allouer du temps à cette problématique en communiquant sur son importance. Chiffrer les gains de temps possibles en analyse.

Si vous utilisez Selenium, une petite virée sur notre article dédié à la qualité des logs Selenium vous redonnera des couleurs.

Troubles associés

Le documutisme (trouble de la communication). Le patient n’a pas conscience de la complexité de son projet et/ou ressent une aversion envers les tâches documentaires. Il en résulte une aura de mystère autour des travaux d’automatisation des tests. Seuls quelques proches du patient ont été instruits de bouche à oreille et sont en mesure de comprendre, de loin en loin, ce dont il est question.

L’automatite – Trouble de l’identité

Symptôme

Le patient agit davantage en « automaticien » qu’en testeur. Il enchaîne les scénarios et automatise au kilomètre.

Cause

Le testeur chargé de l’automatisation des tests est soumis à une forte exposition à des problématiques purement techniques. Comment cliquer sur le premier bouton visible en ignorant les boutons cachés qui le précèdent ? Comment naviguer entre 2 popups ou plus ? Comment autoriser ou interdire la géolocalisation sur tel ou tel navigateur ? Cette charge cognitive peut le mener à oublier le pourquoi au profit du comment. Le patient devrait, en temps normal, être en mesure de conserver un œil critique sur les scénarios qu’il doit automatiser.

Complications possibles

• Faute de recul, le patient perd un temps précieux à automatiser des scénarios à faible valeur ajoutée.
• Le patient passe à côté de bugs qu’il aurait pu trouver.
• Les reportings perdent en pertinence.

Mesures préventives

Dès le début du projet, prévoir des rôles hybrides. La dichotomie entre le testeur manuel et le testeur automaticien, décriée par certains, pourrait être néfaste au métabolisme de l’équipe de test.

Vu sur https://mrslavchev.com

Remèdes possibles

Redonner une vision d’ensemble de la qualité du produit en introduisant des phases de test manuel et de rédaction de cas de test dans l’emploi du temps du patient.

Troubles associés

Chez le testeur dit manuel, la checklistopathie paralyse les mêmes neurones que l’automatite. Les deux types de malades ont besoin, pour recouvrer la santé, de raviver leur curiosité et leur passion pour le fouinage logiciel.

La scalophobie – Trouble de la motricité

Symptôme

Le patient se trouve face à un projet d’automatisation des tests dont il n’a pas suffisamment étudié la scalabilité. L’architecture est brouillonne et difficile à maintenir. Le patient évolue avec difficulté au sein d’un écosystème qu’il a lui-même créé.

Cause

Avide d’avancer rapidement dans l’automatisation des scénarios, le patient a consacré un temps insuffisant à la conception de l’architecture de son projet d’automatisation.

Complications possibles

• Importantes pertes de temps en maintenance.
• Difficulté à intégrer de nouveaux collaborateurs dans le projet.
• Risques accrus de contracter la logopathie

Mesures préventives

En début de projet, dédier une plage de temps suffisante à la conception de l’architecture du projet. Communiquer sur l’importance de cette phase. S’appuyer sur des design patterns éprouvés, tels que le Page Object (dont nous donnions dernièrement un exemple avec Protractor).

Remèdes possibles

Une bonne refactothérapie !

Troubles associés

La scalophobie de type documentaire, qui affecte les testeurs en charge de la rédaction des cas de test.

Conclusion

Il est essentiel de maintenir une bonne hygiène de vie afin d’éviter les maladies que nous venons de lister. Garder le cap sur les objectifs de l’automatisation, communiquer avec son entourage et conserver un recul sur ses activités permettra au testeur de rallonger l’espérance de vie de ses automates et de booster leur tonus au quotidien.

Bon courage !

Vous aimerez peut-être aussi…

Ce n’est pas un bug, c’est un poème

Les 7 principes généraux du test en illustrations

Le kit de secours métaphorique du testeur agile

Vous avez à coeur de respecter les bonnes pratiques de tests automatisés ? Cette page mémo pourrait vous être utile !