L’orthotypographie, votre prochaine obsession

Cet article a été écrit à 4 mains et 2 cerveaux, par Adrien Lavallière et Zoé Thivet

Dans le monde fascinant du développement logiciel, où les lignes de code s’entremêlent comme des lianes dans une jungle numérique, se cachent de redoutables prédateurs, tapis dans l’ombre, prêts à faire trébucher les QA les plus méthodiques : les bugs orthotypographiques.

Mais d’abord, qu’est-ce que l’orthotypographie, me direz-vous ? Le surnom snob de l’orthographe ? Non, pas du tout : c’est l’ensemble des règles d’usage qui concernent, non pas l’orthographe des mots, mais l’utilisation des règles de typographie, c’est-à-dire de mise en forme du texte. C’est le monde, finalement assez méconnu, des espaces, majuscules, des ponctuations, etc.

Pourquoi c’est important ?

L’attention portée à l’orthotypographie n’est pas (qu’)un délire de QA maniaques. En effet, bien que les défauts liés à cet aspect aient peu de chances d’avoir un impact fonctionnel, ils n’en restent pas moins des défauts visibles par tout le monde, très rapidement et avec peu d’efforts, au même titre que les fautes d’orthographe de manière générale.

Deux impacts possibles : 

  • Chez les bénéficiaires de l’application : baisse de confiance envers le produit. Par une sorte d’effet de halo négatif, la perception générale de la qualité de l’application va pâtir de cette première impression.
  • En interne : baisse de la rigueur de la part des équipes techniques. Puisque telle ou telle maladresse orthotypographique est “passée” une fois, alors (souvent inconsciemment) il devient acceptable de manquer de rigueur sur ces aspects, et peut-être sur d’autres.

Cela ne fait pas envie. Voici donc un aperçu non exhaustif du bestiaire que l’on est amené à rencontrer lors de croisades contre ces défauts !

Les problèmes de majuscules

Que cela soit une mauvaise utilisation des majuscules en début de phrase ou sur les noms propres, les erreurs de majuscules font partie du monde de l’orthotypographie. Elles peuvent parfois avoir une incidence sur le sens de la phrase. Exemple : “Vous aussi vous aimez la Chine ?” et “Vous aussi vous aimez la chine ?” ne mettront pas d’accord les fans de voyages et de brocantes.

Elle collectionnait les lacets de chaussure de tous les pays d’Europe et pour ce faire, parcourait tous les vide-grenier qu’elle pouvait. Elle aimait vraiment la Chine.

Combo ultime : les majuscules accentuées. En effet, c’est un grand sujet de débat dans de nombreux projets informatiques ! Et comme l’explique parfaitement le site du Projet Voltaire sur son article des majuscules accentuées, c’est une controverse qui ne date pas d’hier. Plusieurs raisons expliquent cette absence. En premier lieu, les contraintes techniques : les machines à écrire ne possédaient pas ces caractères, et dans l’imprimerie traditionnelle les caractères étaient souvent indisponibles et leur composition manuelle fastidieuse. Omettre ces accents facilitait l’apprentissage. Mais aussi, certaines personnes trouvaient que les accents sur les majuscules étaient inesthétiques ou perturbaient la fluidité de la lecture.

Toutefois, les technologies modernes ont changé cette manière de penser. À l’ère de l’informatique, il est beaucoup plus simple de nos jours de mettre en place ces majuscules accentuées. En outre, ces absences d’accents peuvent créer des ambiguïtés aussi bien sur la prononciation que sur le sens d’une phrase.

Pour vous aider, voici un petit récapitulatif de ces majuscules “spéciales” (n’hésitez surtout pas à vous servir d’un pense-bête tel qu’un post-it pour ne pas trop encombrer votre cerveau) : 

CaractèreWindowsMac
ÀAlt + 183 ou Alt + 0192Verr. Maj. + 0
ÉAlt + 144 ou Alt + 0201Verr. Maj. + 2
ÈAlt + 212 ou Alt + 0200Verr. Maj. + 7
ÇAlt + 128 ou Alt + 0199Verr. Maj. + 9

A l’abordage !

Les problèmes de ligatures

Pour rester dans le monde des caractères spéciaux, d’autres erreurs comme l’absence de ligature typographique peuvent être remontées. Nous parlons ici des “oe” qui devrait plutôt être sous la forme “œ” (Alt + 0156) ou des “ae” pour “æ” (Alt + 0230). Ce qui permet de dire sans faute que vous avez rédigé votre curriculum vitæ ou bien que vous avez plusieurs œufs dans votre panier !

Meilleurs voeux !

Les problèmes de ponctuation

Tout comme les majuscules, les problèmes de ponctuation peuvent aussi altérer le sens de la phrase.

Exemple : Prenons l’exemple d’une phrase bien connue : « Il est tard. Et si on mangeait, les enfants ? », cela fait de vous une personne responsable, souhaitant la survie de ses progénitures. Alors que dire « Il est tard. Et si on mangeait les enfants ? », fait de vous… Attendez, ne bougez surtout pas – « Oui ? Allô, police ?… »

Point bonus accordé aux personnes qui font attention à la ponctuation des titres et des sous-titres ! Car en effet, ces derniers ne comportent pas de point à la fin même quand il s’agit d’une phrase complète.

Les QA disent les bugs sont très coriaces

Les problèmes d’espacements

Les problèmes d’espacement sont d’autant plus traîtres que les règles sont parfois inversées par rapport à l’anglais.

Exemple :  En français, on ménage toujours une espace insécable (oui, au féminin !) avant le signe des deux points ; en anglais, jamais.

Mais une espace insécable, qu’est-ce que c’est ?

Une espace insécable, c’est une espace qui joue un rôle de “colle” entre le signe qu’elle précède et le signe qu’elle suit. C’est-à-dire que si la phrase est trop longue et nécessite un retour à la ligne, il faudra tenir compte de cette colle.

Si la phrase est “À 19 h 01, le mardi 6 février 2024, elle se dit : « Je le savais ! »”, il y a plusieurs espaces insécables, qui lient les signes suivants : 

  • 19 h 30 (deux espaces insécables : une avant et une après le “h”)
  • mardi 6 février 2024 (trois espaces insécables, une entre chaque mot)
  • dit : (une règle empirique est qu’en français, lorsque le signe de ponctuation est double, il y a une espace insécable devant)
  • « Je (toujours une espace insécable après le guillemet ouvrant)
  • savais ! » (le point d’exclamation est une ponctuation double, et il y a toujours une espace insécable avant le guillemet fermant)

Typiquement, dans un code HTML, vous trouverez des espaces insécables sous forme de  .

« Oh non, ce n’est vraiment pas très beau
! »

Les problèmes de mise en forme

Le dernier type d’erreurs que nous citerons aujourd’hui est celles qui concernent la mise en forme. Et dans cette catégorie, nous pouvons inclure bon nombre d’erreurs tout comme les paragraphes mal indentés, les alignements incorrects du texte ou encore les polices de caractères inappropriées.

Bien évidemment, c’est bizarre

Conclusion

Au travers de ce bref aperçu, vous avez peut-être découvert quelques problèmes insoupçonnés. Encore une illustration que le monde de la qualité logicielle se nourrit de nombreuses spécialités et domaines d’expertise !

À (Alt+0192 ;)) bientôt pour de nouveaux articles !

4 manières de conjuguer green IT et accessibilité

Votre éthique professionnelle vous pousse à réfléchir à des solutions qui soient à la fois inclusives et durables. Et vous n’avez aucune raison de choisir entre green IT et accessibilité ! Dans cet article, nous vous proposons 4 points concrets à passer en revue pour conjuguer ces deux exigences.

NB : cet article ne s’adresse pas spécifiquement aux QA, mais aussi à toute personne impliquée dans la conception et la création de produits numériques !

1. Parlez-en à un stade précoce des projets

L’accessibilité et la performance énergétique partagent un point commun : elles ne concernent pas les fonctionnalités de ce que vous allez offrir (le « quoi »), mais plutôt les caractéristiques de la manière dont votre solution est conçue et fonctionne (le « comment »).

Comme tous les aspects non-fonctionnels d’un produit, elles ont malheureusement tendance à être étudiées trop tard, voire complètement oubliées.

Afin de maximiser vos chances de succès, intégrez ces problématiques dès le cadrage de vos projets, pour établir clairement les objectifs et identifier les ressources nécessaires.

Lors de la conception du produit, faites en sorte que ces sujets soient incontournables. Par exemple, lors de la définition des objectifs initiaux du projet, vous pouvez spécifier des critères d’accessibilité mesurables, tels que la conformité aux WCAG (Web Content Accessibility Guidelines). Pour la performance énergétique, cela peut être un score Ecoindex à viser.

Y penser dès le début est susceptible d’orienter les choix de certaines solutions technologiques, mais aussi de vous faire gagner du temps.

2. Pensez “Less is more”

L’utilisation de produits numériques peut être pénible pour une personne porteuse d’un handicap. Proposer un nombre restreint de fonctionnalités, avec un contenu qui va droit au but et sans fioritures inutiles, représente une réelle valeur ajoutée. D’ailleurs, comme presque tout ce que vous proposerez pour favoriser l’accessibilité, cela profitera également aux populations non porteuses de handicap ! Une expérience plus fluide est un atout pour l’ensemble de votre cible.

Moins de fonctionnalités signifie moins de requêtes envoyées aux serveurs, moins de code à maintenir… Et cela représente donc également un gain en termes de performance environnementale.

Faites l’expérience pour vous entraîner. Consultez vos sites web préférés et demandez-vous : qu’y a-t-il en trop ? Qu’est-ce qui m’est réellement utile ? Vous en ferez vous-mêmes le constat : au quotidien, vous nagez dans les images inutiles (non informatives) et dans des animations qui ne font rien d’autre que vous ralentir. Et aussi, dans les features qui ont pris un temps fou à développer, mais qui ne correspondent tout simplement pas à votre usage.

3. Texte > Image > Vidéo

On dit qu’une image vaut mille mots. Cela signifie communément qu’une image peut transmettre une information beaucoup plus facilement qu’un texte. C’est, en effet, parfois vrai.

Mais d’un point de vue green IT, on pourrait dire aussi qu’une image “coûte” mille mots… ou beaucoup plus, en fonction de la taille de l’image et de sa résolution !

Et c’est sans parler des vidéos, particulièrement énergivores.

Un simple texte est le support qui est à la fois le plus accessible et le plus performant d’un point de vue environnemental.

  • Un texte peut être lu “tel quel”, ou bien être agrandi d’un simple clic, ou encore être lu par synthèse vocale ou même en braille.
  • Il peut être rapidement mis à jour, ce qui réduit à la fois l’empreinte énergétique et le budget de maintenance.
  • Il se charge beaucoup plus rapidement que toute autre ressource.

Cela ne veut pas dire que les images et les vidéos sont à bannir, mais il faudra veiller à ne conserver que celles qui apportent le plus de valeur ajoutée, et à optimiser leur compression.

4. Les valeurs d’abord, les actions ensuite

La performance énergétique et l’accessibilité ne sont pas des sujets anodins. Loin d’être de simples concepts techniques, ce sont des engagements envers un avenir meilleur. Affirmer leur importance au sein d’une organisation, en les portant au rang de valeurs, donne une signification décuplée à la démarche… et certainement aussi, beaucoup plus d’enthousiasme aux équipes, à l’heure où une grande part de la population souffre d’éco-anxiété et d’un sentiment général de perte de sens. 

A lire pour aller plus loin : le manifeste agile radical.

 

Cet article a été écrit dans le cadre de notre participation à la commission NID (Numérique Inclusif et Durable) de l’organisation OPEN NC. Il bénéficie de la précieuse contribution de Xavier Liénart (MSI), dont la relecture a permis d’enrichir le fond de l’article.

 

Découvrez d’autres articles sur l’accessibilité

Testez-vous mieux qu’en 1987 ?

En 1987, David Gelperin et Bill Hetzel publiaient l’article scientifique The growth of software testing dans la revue Communications of the ACM. Un article dans lequel, regardant en arrière, ils définissaient différents seuils où le métier du test a évolué.

Un article de référence

Quel est donc ce découpage temporel ?

Première époque, orientée débogage

Les processus de test ne sont pas traités en tant que tels ; les tests sont effectués de manière ad hoc essentiellement, et les succès ne sont guère reproductibles puisqu’ils dépendent avant tout du bon vouloir et du talent d’individus isolés.

Deuxième époque, orientée démonstration

Pour résumer, on teste pour prouver que le logiciel fonctionne.

Troisième époque, orientée destruction

Ca fait peur, non ? Cela veut dire tout simplement que cette période est marquée par le cliché (toujours vivant) des QA qui sont là pour « tout casser » ! Même si, on le sait, le test logiciel met plutôt en lumière ce qui est déjà cassé.

Quatrième époque, orientée évaluation

L’activité de test donne lieu à des métriques. On la suit de manière formelle.

Cinquième époque, orientée prévention

L’objectif principal des tests est d’éviter en premier lieu l’apparition des anomalies, et ce grâce à des méthodes statistiques.

Les suites de cet article

Ce découpage en périodes historiques a fait date ; il est toujours mentionné notamment dans les documents relatifs au modèle TMMi. En effet, les 5 niveaux de maturité TMMi font écho aux 5 époques mentionnées par les auteurs de l’article.

Mais, bien que ce soit fort intéressant, ce n’est pas le sujet le plus croustillant de cet article ! 😃

En pratique, comment testait-on jadis ?

Une partie un peu moins connue de cet article fait en effet référence à un sondage diffusé à l’occasion de la 4ème conférence internationale sur le test logiciel, qui s’est tenue à Washington en 1987. Préparez-vous à un voyage dans le temps !

Résultats du sondage en anglais

Traduction du sondage en français

  1. Un historique des défauts trouvés pendant les tests est maintenu : 73 % oui / 16 % parfois
  2. Une personne est désignée en tant que responsable du processus de test : 65 % oui / 13 % parfois
  3. Un plan de test décrivant les objectifs / l’approche est requis : 61 % oui / 29 % parfois
  4. Le test est une activité systématique et organisée : 61 % oui / 30 % parfois
  5. Des profils de test réalisent des tests système à temps plein : 62 % oui / 19 % parfois
  6. Le test est séparé du développement : 60 % oui / 20 % parfois
  7. Les tests doivent être rejoués lorsque le logiciel change : 51 % oui / 35 % parfois
  8. Les tests sont conservés et maintenus en vue d’une utilisation ultérieure : 51 % oui / 28 % parfois
  9. Les spécifications et la conception des tests est documentée : 48 % oui / 36 % parfois
  10. La procédure de test est documentée dans le manuel des standards : 45 % oui / 15 % parfois
  11. Un historique des tests joués est maintenu : 42 % oui / 35 % parfois
  12. Le temps consacré aux test est suivi : 40 % oui / 30 % parfois
  13. Les documents de test font l’objet d’une revue par les pairs formelle : 31 % oui / 29 % parfois
  14. Des profils de test réalisent des tests d’intégration à temps plein : 24 % oui / 24 % parfois
  15. Les coûts des tests sont mesurés et suivis : 24 % oui / 19 % parfois
  16. Des formations en test sont fournies périodiquement : 22 % oui / 26 % parfois
  17. Les résultats des tests font l’objet d’une revue par les pairs formelle : 20 % oui / 31 % parfois
  18. Les utilisateurs et utilisatrices ont une forte implication dans les activités de test : 8 % oui / 39 % parfois
  19. Les tests sont créés avant le développement  : 8 % oui / 29 % parfois
  20. Une mesure de la couverture de code est requise : 5 % oui / 16 % parfois

Il faut garder à l’esprit que les personnes ayant répondu au sondage participaient à un congrès sur le test logiciel. Elles avaient donc a minima un intérêt pour le sujet. Cet état des lieux représente donc certainement les pratiques des entreprises les plus à la pointe dans le domaine à l’époque !

Tout en reconnaissant que les pratiques de 1987 avaient aussi, potentiellement, des atouts que nous avons peut-être perdu en cours de route, ces résultats de sondage ne sont-ils pas rafraîchissants ?

De retour au XXIème siècle, comment vous sentez-vous après avoir fait ce petit saut dans le passé ?

Et surtout, d’après vous, lesquelles de nos pratiques sembleront désuètes aux QA de 2059, dans 36 ans ?

Le voyage dans le temps n’est pas fini et nous devons continuer de perfectionner nos pratiques ! 😃

Crédit image : Midjourney

[Témoignage] Cyberattaque & sécurité informatique

2023 commence merveilleusement bien pour Hightest ! Nous avons l’honneur d’accueillir une nouvelle personne dans notre dream team, Alexandrine Philip Brutel. Et qui plus est, nous avons le plaisir de vous livrer ce passionnant témoignage issu de son expérience en qualité logicielle.

Bonne lecture !

La cybersécurité est un sujet crucial dans un monde de plus en plus connecté, où la plupart des informations sont exposées sur internet. Il est donc nécessaire de prévenir le risque, se protéger, détecter, alerter, répondre et remédier à la cybermenace.

Les entreprises et les particuliers doivent prendre conscience des risques liés à la cybersécurité et prendre les mesures nécessaires pour se protéger.

Pourquoi est-ce que je dis tout ça ? Parce que, pour en avoir fait l’expérience, je sais que ce genre de problème n’arrive pas qu’aux autres.

Etions-nous préparés à une cyberattaque ?

Nous étions informés de l’existence de ces phénomènes malveillants, mais malgré tout, non préparés. Que peut-on faire sans l’accès à nos sessions ? Les premiers instants il y a une sorte d’incompréhension. L’attaque a eu lieu dans la nuit ou au petit matin, pourtant, vers 7h personne ne sait encore ce qu’il s’est passé. Impossible de se connecter, que pouvons-nous faire, nous qui avons heureusement fermé nos sessions et sommes déconnectés du système ? Nous nous sentons démunis, je me sens démunie…

Que s’est-il passé ?

Que se passe-t-il ce 24 janvier 2019 ?

Altran, le groupe dans lequel nous sommes consultants, vient de subir une attaque via un « crypto locker », appelé aussi ransomware. Un ransomware est un type de logiciel malveillant ayant pour but de prendre en otage les fichiers d’un ordinateur ou d’un réseau informatique en les chiffrant. Une rançon est alors demandée pour acheter la clé de chiffrement afin de pouvoir récupérer ses fichiers.

Cette attaque a été exécutée grâce à un « code inédit indétectable[1] » par les moyens mis en œuvre par le groupe pour se protéger.

Les sessions restées ouvertes sont une menace de propagation de ce ransomware.

Image générée à l’aide de l’IA Midjourney symbolisant l’aspiration de données

Des conséquences importantes pour Altran :

  • La première, l’obligation de déconnecter ses systèmes d’information (SI) pour protéger l’ensemble de ses clients et ses propres applications de la propagation de ce virus.
  • La création d’un nouveau protocole de restauration spécifique par un fournisseur mondial de services.
  • Une récupération très lente, beaucoup trop lente de ses données.
  • Une perte financière sèche, plus de 20 M d’euros, à 1 mois, fin février 2019 [1]
  • Des rumeurs sur le paiement éventuel d’une partie de la rançon en bitcoins.
  • Des répercussions importantes sur l’organisation même du groupe (Surcharge de travail pour le SI, modification de l’organisation de la TRA…)

La TRA dans tout ça ?

La TRA (Tierce recette applicative), totalement externalisée, se retrouve brutalement à l’arrêt, nécessitant des adaptations rapides avec tous les problèmes inhérents qui peuvent survenir.

Nous travaillons pour la plupart sur des VM (machines virtuelles) via un accès Altran. La déconnexion du SI bloque tous les accès. Comment honorer les délais de livraison des campagnes de tests, des robots d’automatisation, des stratégies à mettre en place, bref, de toutes les demandes clients sans accès à nos postes de travail ?

En 2019, la pandémie n’étant pas encore passée par là, le télétravail reste minoritaire, exceptionnel, voire inexistant. Et pourtant, il va falloir trouver une solution rapide et adaptée à chaque projet. Ceux pour lesquels le télétravail est possible ont pour consigne de rentrer chez eux, emportant sous le bras le matériel de l’époque, des PC fixes ! Pour tous les autres projets externalisés, la solution est de se rendre chez le client.

L’externalisation, qui est alors une solution formidable, devient une solution à double tranchant. L’éloignement des sites clients accentue la difficulté d’une réaction rapide, avec toute la logistique liée aux déplacements des uns et des autres à mettre en place.

Les projets sur lesquels intervient le reste de la TRA se situent à Paris, soit à 350 km. Il faut alors déplacer les consultants, les loger, mais encore faut-il que les locaux des clients permettent cette arrivée massive ! Nous serons donc répartis sur 2 sites, Paris (logés sur place) et Angers (avec des aller/retour quotidiens de

135 km de distance entre Rennes et Angers).

Nous alternerons ces 2 solutions, et nous ferons tous ces trajets, accompagnés d’une augmentation du volume horaire de nos journées, des multiples difficultés de gestion des éléments personnels (enfants, famille…), mais nous n’abandonnerons pas nos projets.

L’attaque dure, et pendant 4 semaines, nous nous plierons à cette nouvelle organisation.

Et après ?

Des solutions pour que cela ne se reproduise jamais !

Y a-t-il eu paiement ou non ? La création d’un nouveau protocole de restauration spécifique par un fournisseur mondial de services a-t-elle été suffisante ?

Cette réponse restera la réponse officielle annoncée par le groupe : Aucun paiement n’a été fait, seulement des discussions avec les attaquants.

« Concernant la rançon, si nous avions payé nous vous dirions que ce n’est pas le cas, et si nous n’avions pas payé nous vous dirions la même chose » plaisante le dirigeant[2]. « En revanche, nous avons communiqué avec les attaquants. Discuter avec eux, cela permet notamment de comprendre leurs véritables intentions. »[3]

En revanche il a bien été créé un nouveau protocole de restauration.

Quoi qu’il en soit, une réflexion sur le long terme se pose et des solutions adaptées sont à mettre en place.

Des questions essentielles doivent se poser pour Altran comme pour toutes les sociétés, telles que :

  1. Qu’est-ce que la cybersécurité et pourquoi est-elle importante pour les entreprises et les particuliers ?
  2. Quelles sont les principales menaces en matière de cybersécurité auxquelles les entreprises et les particuliers sont confrontés ?
  3. Comment les entreprises et les particuliers peuvent-ils se protéger contre les cyberattaques ?
  4. Quels sont les outils et les technologies les plus efficaces pour la cybersécurité ?
  5. Comment les utilisateurs peuvent-ils se protéger contre les attaques de phishing et les escroqueries en ligne ?
  6. Comment les entreprises peuvent-elles sensibiliser leurs employés à la cybersécurité et promouvoir des pratiques de sécurité ?
  7. Comment la cybersécurité a-t-elle évolué au fil des ans et comment est-elle susceptible de changer à l’avenir ?
  8. Quels sont les rôles et les responsabilités des gouvernements, des entreprises et des individus en matière de cybersécurité ?

Toutes ces questions ont abouti au renforcement des protocoles de sécurité accompagnés de grandes campagnes d’information récurrentes. Des tests obligatoires de sécurité sont mis en place avec un taux de réussite supérieur à 75% demandé. Outre ces actions, de nombreux éléments confidentiels sont également exploités et mis en œuvre.

Cette expérience enrichissante, vécue personnellement m’a montrée les dangers réels des cyber attaques. Des attaques insidieuses préparées bien en amont de leur émergence, pour Altran, les attaquants étaient présents dans le système depuis le 27 décembre, avec comme porte d’entrée une application web mal configurée utilisant un mot de passe d’accès par défaut[3]. Cette attaque a, pour ma part, mis en lumière toutes les problématiques engendrées pour le groupe, mais également les difficultés au quotidien pour chacun de nous. Je me dois d’avoir un regard différent sur ces cybermenaces, ce qui m’amène à la conclusion suivante sur la cybersécurité au sens large que nous sous-estimons trop souvent.

Conclusion : la cybersécurité et son avenir

La cybersécurité a connu une évolution rapide au fil des ans, en raison de la croissance exponentielle de la technologie de l’information et de l’utilisation de l’internet dans toutes les sphères de la vie. Les menaces de sécurité ont augmenté en nombre, en sophistication et en impact, et les mesures de cybersécurité ont dû s’adapter pour y faire face.

L’évolution des moyens de protection

Au début de l’ère de l’informatique, la sécurité informatique était largement axée sur la protection physique des systèmes et des réseaux. Les pare-feux et les antivirus étaient les principales solutions de sécurité mises en place. Cependant, à mesure que les réseaux ont augmenté en taille et en complexité, la cybersécurité est devenue plus importante. Les systèmes de détection d’intrusion ont été mis en place pour détecter les activités malveillantes, et les solutions de sécurité basées sur les signatures ont été développées pour identifier les logiciels malveillants connus.

Cependant, ces solutions se sont avérées insuffisantes face aux nouvelles menaces émergentes, telles que les attaques de déni de service distribué (DDoS), les attaques par phishing et les attaques de logiciels malveillants sophistiqués. Les organisations ont donc commencé à adopter des mesures plus avancées, telles que la surveillance des journaux d’activité, la détection des menaces avancées, comme des logiciels capables de détecter les comportements suspects sur un réseau et de les signaler aux administrateurs. Ces logiciels détectent les anomalies pouvant être des signes avant-coureurs d’une attaque de ransomware, permettant ainsi aux administrateurs de réagir rapidement pour limiter les dommages. D’autres mesures sont également mises en place, telles que la cryptographie et la segmentation des réseaux. Cette dernière implique la division du réseau en segments distincts, chacun avec ses propres règles d’accès et de sécurité. Cette approche limite la propagation des attaques de ransomware en isolant les parties infectées du reste du réseau. Les autres moyens techniques sont renforcés et peuvent inclure l’utilisation de solutions de plus en plus sophistiquées d’antivirus (EDR, XDR, …), du patch management[4] des logiciels et des systèmes (à partir d’un centre logiciel par exemple), de la supervision des équipements, en particulier les plus critiques.

Et demain ?

À l’avenir, la cybersécurité continuera à évoluer pour faire face aux menaces toujours plus sophistiquées des cybercriminels. Les entreprises et les gouvernements devront investir davantage dans la cybersécurité pour protéger leurs données et leurs infrastructures critiques. Les pratiques de cybersécurité devront être plus proactives, avec des systèmes de détection précoce et des mesures préventives pour réduire les risques d’attaque. L’automatisation et l’intelligence artificielle joueront un rôle de plus en plus important dans la cybersécurité, en aidant à détecter les menaces plus rapidement et à réagir plus efficacement. La mise en place de systèmes de sécurité adaptatifs et dynamiques sera également essentielle pour faire face aux nouvelles menaces qui émergent constamment.

En outre, la cybersécurité devra également tenir compte de l’évolution des technologies émergentes telles que l’intelligence artificielle, la blockchain et les objets connectés, qui présentent des risques de sécurité potentiels. Il sera donc important d’adopter une approche holistique de la cybersécurité, qui englobe la gouvernance, la gestion des risques et la conformité, ainsi que des stratégies de défense des données. Enfin, la sensibilisation et la formation à la cybersécurité devront être renforcées pour aider les utilisateurs à se protéger contre les menaces en constante évolution.

Les deux domaines impliquant les moyens humains nécessitent une amélioration continue et constante :

Le premier concerne la sensibilisation des utilisateurs aux risques liés à la cybersécurité, impliquant notamment la gestion des mots de passe et l’implémentation d’une authentification à deux facteurs (2-FA). Il est également crucial d’accompagner les utilisateurs dans la prévention des attaques de phishing et d’escroquerie en ligne, en les avertissant contre l’ouverture de courriers électroniques suspects ou frauduleux, en mettant en place par exemple une signature électronique préenregistrée en bas de chaque email envoyé.

Le second concerne la gestion des ressources et des compétences en matière de cybersécurité au sein de l’entreprise, y compris l’allocation de budget pour la sécurité[5], la communication et le leadership de la direction, qui doivent être en adéquation avec l’évolution des menaces.

Merci à Alexandrine pour cet article. La sécurité est l’une des 8 facettes de la qualité logicielle définies par la norme ISO 25010, et elle occupe dans ce puzzle une place très particulière en ce qu’elle se prémunit contre des risques changeants, souvent difficiles à anticiper, et qui se trouvent entre les mains de personnes tierces malveillantes. Pour en savoir plus sur ce sujet, nous vous invitons à redécouvrir les articles que nous avons publiés précédemment sur le sujet :

Sources

[1] https://www.lemondeinformatique.fr/actualites/lire-cyberextorsion-contre-altran-un-cout-estime-a-20-meteuro-74492.html

[2] Dominique Cerruti Dirigeant d’Altran

[3] https://www.zdnet.fr/actualites/ransomware-dominique-cerutti-pdg-d-altran-mon-1er-conseil-assurez-vous-39895949.htm

[4] Merlin NGOUAGNA, Auditeur Cybersécurité, Expert en automatisation, Formation – Acceis

[5] http://www.senat.fr/rap/r20-678/r20-678_mono.html#toc76

Nos 7 astuces de productivité et bien-être au travail !

Pour bien démarrer 2023, nous vous proposons un bouquet de méthodes et bonnes pratiques ! Objectif : booster à la fois votre productivité et votre bien-être au travail. Ces astuces, applicables dans tout métier de l’IT, ont été collectées auprès de nos collaborateurs, et auprès de ceux de partenaires en Nouvelle-Calédonie. C’est donc l’occasion aussi de vous faire connaître quelques visages du monde numérique calédonien !

Gestion du temps, efficacité, montée en compétence… Vous trouverez certainement au moins une bonne idée actionnable dans votre quotidien tout au long de cet article !

Bonne lecture et meilleurs vœux pour 2023 !

1) Maîtriser son temps avec la technique Pomodoro

Pomodoro, qu’est-ce que c’est ?

Clément Flavigny, team leader chez Atlas Management, utilise fréquemment la technique du Pomodoro, qui consiste à travailler sur des périodes chronométrées de 25 minutes séparées par des pauses de 5 minutes. Cette technique a été inventée à la fin des années 1980 par le consultant Francesco Cirillo.

Voici comment Clément s’organise concrètement :

La veille, je classe mes tâches du lendemain des plus importantes aux moins importantes et les programme par créneau. J’entame 25 minutes sur la tâche la plus importante et je mets mon téléphone portable hors de ma vue si besoin. Je consulte mon téléphone et me lève pour dégourdir mes jambes sur les 5 minutes de pause.

Il utilise cette méthode quand il a le temps de classer ses tâches la veille ou le matin même, quand il a des priorités établies, et/ou quand il a plusieurs sujets, missions ou clients.

Ce que ça lui apporte ?

  • Arriver le matin avec de la confiance dans le programme de la journée
  • Savoir que je vais avoir un temps de pause quoi qu’il arrive
  • Être capable à la fin de la journée de savoir si j’ai été productif

Cette méthode n’est pas forcément simple ou rapide à adopter. Clément a mis un an à l’intégrer dans son rythme de travail. Il lui arrive de ne pas utiliser la technique du Pomodoro, en particulier quand je n’ai pas classé mes tâches ; quand je suis en réunion toute la journée, quand je suis en retard.

Il conseille cette pratique aux personnes qui travaillent sur plusieurs tâches ou plusieurs projets, qui se dispersent parfois dans leurs tâches et ont l’impression de n’avancer sur rien.

Pomodoro en pratique

Ses quelques astuces pour les personnes qui voudraient se prêter à l’exercice :

  • Utiliser un minuteur avec une alarme
  • Commencer à essayer lors du télétravail car c’est plus facile d’avoir son alarme que dans l’open space
  • Ne pas hésiter à ignorer les mails entrants durant 25 minutes
  • Dire aux collègues qui ont une question d’attendre la fin de la plage horaire de 25 minutes de travail.

Vincent Lavergne, UX designer chez Tealforge, utilise aussi cette technique. Quand je ne suis pas dans le stress, ça marche assez bien, surtout dans la création où s’acharner ne fonctionne pas.

 

 

 

2) Zapper l’étape « brouillon »

Laurence Marchois, facilitatrice opérationnelle et consultante chez Atlas Management, partage une astuce qui lui permet de gagner beaucoup de temps lors de la rédaction de documents.

Toujours avoir en tête quel livrable final on doit réaliser (CR, étude, etc.) et le créer directement sans passer par des documents intermédiaires. Ca permet de cibler directement les informations qui apportent vraiment de la valeur, et gagner du temps de remise en forme.

 

3) S’inspirer de Scrum (même en solo !)

Ryan Julia, consultant junior chez Atlas Management, s’inspire de la méthode Scrum au quotidien.

Ses sprints durent une semaine et incluent un planning, une revue et une rétro qui ont lieu chaque lundi matin. Lors de cette session, il définit un objectif pour la semaine.

Tous les jours, il procède à un daily. Il y fait le point sur les obstacles et les choses à faire dans la journée.

Il tient à jour un backlog catégorisé et priorisé avec des sujets captés au vol ou encore en attente pour les prochains sprints. Ce backlog mélange les sujets pro et perso.

Cette revue hebdo, je la tire de la méthode GTD (Getting Things Done), un bouquin de productivité. Ca ne convient pas à tout le monde car ça peut paraître « trop cadré pour pas grand chose », mais moi ça m’aide bien.

Autre outil que Ryan utilise : toggl, pour savoir où va son temps, ajuster ses efforts en planning hebdo ou en daily, et évaluer les moments de la semaine ou de la journée où il est le plus productif, afin d’y positionner ses dossiers les plus importants.

4) Lister ses tâches aux petits oignons

Le double avantage de la todo-list

Tenir une todo-list est une astuce qui revient souvent. C’est à la fois bon pour la productivité, et bon pour le moral ! Elodie Luz, consultante experte chez Atlas Management, utilise cette pratique pour s’alléger l’esprit et pour la satisfaction de rayer quand on a fini quelque chose ! Je me sers d’un bon vieux cahier qui me permet au passage de faire une pause d’écran quand je retravaille cette liste ou que je raye au fur et à mesure les tâches réalisées. En complément lorsque je sais qu’une des tâches doit prendre un certain temps de concentration et donc sans être dérangée, je me sers de mon agenda pour bloquer des créneaux sur ces actions.

 

La todo-list Monday d’Antoinette

Antoinette Dubroeucq, consultante cohésion et marque employeur chez Ahonei, plussoie : Ça améliore à la fois ma productivité car ça me rend plus efficace, et mon bien-être car je suis moins stressée d’oublier des choses et j’anticipe ma charge de travail.

Elle note l’ensemble des choses à faire sur la même liste. Elle la parcourt au début de la journée afin de se faire un rappel des tâches qui l’attendent, et la remet à jour à la fin de la journée avec les nouvelles échéances et les évolutions.

Ça m’apporte plus d’efficacité car je n’oublie aucune tâche. Ma productivité est doublée car je ne perds pas de temps à me demander quoi faire aujourd’hui, quelles sont les priorités, ni à me rappeler où en est tel sujet. Tout est déjà écrit. Je me sens également moins stressée car j’ai un visuel de la charge de travail qui m’attend dans les jours / mois à venir. Je peux donc trier les tâches en fonction de leur deadline, de leur complexité, etc.

Antoinette partage avec nous une todo-list quelle a créée sur Monday :

Mais les todo-list ne se ressemblent pas toutes et doivent être créées en fonction du besoin de chaque personne.

Le dashboard Notion de Loic

Loic Hamouda, consultant senior en transformation digitale chez Atlas Management, utilise quant à lui le logiciel Notion pour lister ses tâches.

Je crée des tâches auxquelles j’ajoute des tags (personne à contacter, client pro, perso,…), des deadlines et des points d’avancement.

Il ne lui a fallu que quelques jours pour adopter cet outil, à l’issue d’une formation en ligne gratuite.

Son conseil ? Essayer de réaliser son premier dashboard/template par soi-même. Il est possible aussi de récupérer ceux que les autres utilisateurs mettent à disposition (il y a une très grande communauté).

Voici à quoi ressemble son dashboard :

 

 

 

 

La todo-list quotidienne de Zoé

Zoé Thivet, spécialiste en test logiciel chez Hightest, utilise quant à elle un rudimentaire fichier txt : un fichier par jour. La granularité est assez fine (entre 50 et 100 tâches par jour).

Le bloc du haut contient les tâches réalisées, et le bloc du bas, les tâches à faire.

Dès qu’une nouvelle idée arrive, une ligne est ajoutée dans le bloc du bas. Elle est positionnée plus ou moins haut parmi les lignes déjà existantes en fonction des priorités. Dès qu’une tâche est terminée, elle est déplacée dans le bloc du haut.

Tout au long de la journée, mon attention se focalise entièrement sur la ligne où apparaît la flèche rouge. Autant que possible, je ferme tous les onglets et toutes les applications inutiles à cette tâche. Même si « je pourrais en avoir besoin plus tard » !

En fin de journée, je réorganise le bloc du bas, et les tâches du lendemain sont prêtes. J’utilise ça en complément de mon calendrier.

5) Bloquer des créneaux de travail à l’avance

Cindy Da Silva, chargée de communication/marketing chez Tealforge, programme chaque semaine à l’avance pour s’assurer de produire à temps les livrables demandés. Je prends l’ensemble de mes clients et la liste des livrables à réaliser sur le mois (voire plus). Je fixe un maximum à l’avance les créneaux pour les réaliser et faire le travail attendu. Sans oublier de laisser des moments « libres » pour les éventuelles réunions ou imprévus.

Bastien Serafin, consultant marketing chez Tealforge, utilise aussi cette pratique. J’utilise la technique du time blocking depuis plusieurs années. L’idée est de bloquer mon agenda sur des tâches et de ne faire que ça à ce moment là. Par exemple, je consulte et traite mes mails en début et fin de matinée et en début et fin d’après-midi.

 

 

6) L’art de vivre à la Florian

Florian Michaud, ingénieur QA chez Hightest, dévoile à son tour ses astuces avec les bonnes vibes qui le caractérisent !

Je vais te donner mes quelques tips qui font de moi el maestro de los consultantes :
1- La classique todo-list sur le bloc-notes, pas de superflu on est tranquille
2- Je connecte mon ordinateur ou celui du client à Spotify ou YouTube pour éviter, si je veux mettre de la musique, de devoir sortir mon téléphone et me distraire en consultant mes mails
3- Une pause toutes les deux heures, comme sur l’autoroute
4- Si vraiment je n’arrive plus à me concentrer, je fais une coupure de 5 minutes. Je regarde les infos calédoniennes ou les billets d’avion, ça permet une pause à l’esprit
5- Je mange des pommes en travaillant, ça me permet de me concentrer
6- Boire de l’eau est mon meilleur conseil

7) Faire de la veille avec Feedly

Yann Levy, tech lead chez Tealforge, mène une veille quotidienne qui lui permet de rester à la pointe de ses sujets d’expertise. Pour ce faire, il utilise au quotidien Feedly, un agrégateur de flux RSS.
Concrètement, dès que je trouve une source qui m’intéresse, notamment sur la tech, je la rajoute à mon flux Feedly. Tous les jours je peux voir les trending topics sur les nouvelles technos, des nouvelles manières de s’organiser, de nouveaux plugins, etc. Je l’utilise tous les matins en arrivant au bureau. Je parcours tous les titres, sélectionne ce qui m’intéresse et pousse un peu plus ma recherche dessus. C’est comme les échecs, on comprend son fonctionnement très rapidement mais on met du temps avant de correctement s’en servir ! Un peu #oldschool comme méthode, mais je ne m’en séparerais plus.

Cette pratique permet de centraliser dans un même lieu un grand nombre de sources. Elle épargne donc le travail fastidieux d’ouvrir tous les matins un grand nombre de sites différents.

A vous de jouer !

Et vous, quelles sont les astuces productivité et bien-être qui vous aident au quotidien ? Partagez-les avec nous en commentaire !

17 phrases inspirantes sur la qualité et le test logiciel

Ce mois-ci, sur notre page LinkedIn, nous avons partagé en guise de calendrier de l’Avent des phrases inspirantes sur le test logiciel.

Nous les listons ici pour ne pas les oublier !

Magnifiques fêtes de fin d’année, et que 2023 vous apporte le meilleur de la qualité !

EDIT écrit fin 2023 : ce fut une bonne année. Merci aux personnes qui nous ont souhaité une bonne année, ça a fonctionné !

1. Une définition saisissante du test logiciel

Le test est un processus infini consistant à comparer l’invisible à l’ambigu afin d’éviter que l’impensable n’arrive à l’inconnu.
~James Bach

James Bach est un consultant en test et en qualité logicielle, connu pour sa méthodologie de test exploratoire.

2. A compléter ! Tester, c’est d…

Vous avez déchaîné votre créativité pour compléter cette phrase ! Félicitations aux personnes qui ont imaginé de belles trouvailles !

Quelques-unes que nous avons particulièrement appréciées :

3. La qualité est gratuite

Quality is free. It’s not a gift, but it’s free. What costs money are the unquality things -all the actions that involve not doing jobs right the first time.
~Philip B. Crosby

Philip B. Crosby était un expert en management de la qualité. Il est notamment connu pour sa philosophie de la qualité « Zero Defects » (ZD) et pour son livre Quality is Free (1979).

4. L’automagie n’existe pas

It’s automation. Not automagic.
~Jim Hazen

Jim Hazen est un expert en qualité et un consultant en gestion de la qualité. C’est également un conférencier international et un formateur en qualité logicielle et en audit de la qualité.

5. Pardon pour le gros mot… mais c’est vrai

Tout objectif flou conduit irrémédiablement à une connerie précise.

Cet aphorisme n’a malheureusement pas d’autrice ou d’auteur connu.

6. L’informatique décuple tout

L’homme est sujet à l’erreur. Mais s’il veut vraiment commettre la gaffe absolue, alors là, il lui faut un ordinateur.
~Dan Rather

Dan Rather ne travaille pas dans l’industrie logicielle, mais est un journaliste et un présentateur américain. Il a été présentateur en chef à CBS News pendant plus de 20 ans et est lun des plus célèbres présentateurs de lhistoire des médias américains.

7. Investir ou s’endetter

On améliore rarement la qualité en diminuant les coûts, mais on peut souvent diminuer les coûts en améliorant la qualité.
~Karl Albrecht

Karl Albrecht était un entrepreneur et un expert en gestion. Il a co-fondé la chaîne de supermarchés allemande Aldi.

8. La comparaison la plus inattendue

Les logiciels et les cathédrales, c’est un peu la même chose -d’abord on les construit, ensuite on prie.
~Sam Redwine

Cette phrase a été prononcée au 4ème International Software Process Workshop, en mai 1988.

9. Un rappel important

Ce sont les personnes, et non les méthodologies ou les outils, qui font le succès des projets.
~Lisa Crispin

Lisa Crispin est une experte en test logiciel et en agilité. Elle a écrit de nombreux livres et articles, notamment Agile Testing et More Agile Testing avec Janet Gregory, des ouvrages que nous avons déjà évoqués dans de précédents articles.

10. La base du test logiciel

L’empathie est la base du test logiciel
~Erin Hess

Erin Hess est spécialiste en qualité logicielle, et porte une attention particulière à comprendre les utilisateurs en profondeur.

11. Tests automatisés & tests exploratoires

Les tests automatisés couvrent les inconnues que nous savons possibles, les tests exploratoires couvrent les inconnues… inconnues.
~Jenna Charlton

Jenna Charlton est spécialiste en qualité logicielle et a notamment pris la parole lors de conférences autour du test agile.

12. La métrique à ne pas oublier

Une métrique extrêmement simple : « A quel point avez-vous confiance en cette version ? »
~Lena Pejgan Wiberg

Lena Pejgan Wiberg a notamment écrit le livre « Would Heu-risk it? ».

Pour davantage de réflexions sur les métriques en qualité logicielle, nous vous recommandons de vous plonger dans cet article sur les KPI.

13. Le goût des logiciels

L’amertume de la non-qualité dure bien plus longtemps que le délice d’avoir respecté la deadline.
~Karl Wiegers

Karl Wiegers est l’auteur de plusieurs livres traitant de programmation, mais aussi d’ingénierie des exigences.

14. Ce que veulent les QA

Les QA n’aiment pas casser les choses, mais dissiper l’illusion que les choses fonctionnent.
~Kaner, Bach et Pettichord

Cette citation est issue d’un livre extrêmement dense et rempli d’enseignements précieux : Lessons Learned in Software Testing.

15. Do it right… when it’s time

Peu importe de bien faire du premier coup. Ce qui compte, c’est de bien faire le dernier coup.
~Andrew Hunt et David Thomas

Cette citation est quant à elle issue de l’ouvrage The Pragmatic Programmer. Remarquez la tension avec la citation de Philip B. Crosby !

16. Ce qu’on ne pourra pas automatiser

Les ordinateurs excellent à suivre les instructions, mais pas à lire dans vos pensées.
~Donald Knuth

Donald Knuth est un mathématicien et un informaticien. Il est connu pour ses contributions à linformatique théorique et à lalgorithmique, et est lauteur de plusieurs livres, dont The Art of Computer Programming. Il a créé le système de composition de documents TeX.

17. Le mot de la fin…

Rien dans la vie n’est à craindre, tout doit être compris. C’est maintenant le moment de comprendre davantage, afin de craindre moins.
~Marie Curie

Marie Skłodowska-Curie ne parlait bien sûr pas de qualité logicielle, mais cette citation est parfaitement adaptée à cette discipline qui cherche avant tout à comprendre comment fonctionnent les choses.

Encore une fois, joyeuses fêtes de fin d’année, et à bientôt pour de nouveaux articles !

Révisions ISTQB : un nouveau site pour s’entraîner !

MAJ du 24/07/2023 : Attention, le site ISTQB Online mentionné dans cet article ne semble plus actif. Nous remercions toutefois les personnes à l’origine de cette initiative, espérant que le site reverra le jour prochainement !

Précédemment, nous avons publié des articles permettant de guider de nouveaux aspirants testeurs :

Aujourd’hui, dans cette lignée d’articles, nous avons le plaisir de mettre en avant une initiative très utile menée par deux testeurs. Il s’agit du site istqb.online, créé par Med Aziz Zouaoui et Sarah Sliti, et qui contient des quiz blancs pour réviser les certifications ISTQB. Nous apprécions et partageons cet esprit de partage et de challenge, ayant nous-mêmes quelques quiz blancs à notre actif. C’est donc avec joie que nous échangeons aujourd’hui avec Med Aziz et Sarah !

Hightest : Bonjour à vous deux ! Et tout d’abord, merci pour cette belle initiative. Comment vous est venue l’idée ?

Med Aziz Zouaoui : Tout d’abord je voudrais vous remercier pour votre interview et pour l’aide que vous allez apporter à plein de gens en faisons connaître notre site web.

Je suis un développeur qui a décidé de se lancer dans le métier de test et qui avec l’aide de Sarah, y est arrivé. C’est durant ma reconversion que Sarah et moi-même avons eu l’idée de créer un site web qui serai 100 % éducatif, à but non lucratif, dans lequel tout le monde pourrait s’autoévaluer et s’entraîner avant de passer la certification ISTQB.

Hightest : Comment avez-vous découvert le métier de testeur ?

Med Aziz : Après avoir été un marketer et un développeur CMS, j’ai découvert le métier de test à travers Sarah, et après des séances de partage de connaissance et de coaching je me suis senti dans mon élément et j’ai tout de suite décidé d’intégrer le monde de testing.

Sarah Sliti :  J’ai effectué mon projet de fin d’étude au sein d’un département de software testing. Pendant que je travaillais sur mon projet, on m’a demandé de venir en renfort à une équipe de test pour respecter un délai de livraison pour un client important et depuis j’ai développé une passion pour ce domaine et j’ai décidé d’en faire ma carrière.

Hightest : Que vous ont apporté les certifications ISTQB lors de votre itinéraire de QA ?

Med Aziz : Puisque je n’étais pas un testeur de formation, le monde du testing était inconnu pour moi, mais grâce aux certifications ISTQB j’ai pu affiner mes connaissances et avoir les compétences requises pour exceller dans mon travail.

Sarah :  Les certifications ISTQB m’ont apportée beaucoup de connaissances à propos du software testing. Elles ont mis une structure aux notions que j’ai pu acquérir durant ma carrière. Ces certifications m’ont permis de comprendre les grandes lignes du métier de test ainsi que les détails du processus du test et comment l’intégrer dans le cycle de vie logiciel.

Hightest : Qu’est-ce qui vous plaît le plus dans le métier du test ?

Med Aziz : La fierté de savoir que la place d’un testeur est devenue primordiale au sein d’une entreprise

Sarah : Satisfaire le besoin du client et contribuer à la bonne qualité du produit et au succès du projet.

Hightest : Tous les testeurs sont différents et chacun a son propre « style » de test. De votre côté, comment vous décririez-vous en tant que testeurs ?

Med Aziz : Je suis un testeur méticuleux qui éprouve un plaisir en chassant les bugs.

Sarah : Je suis une testeuse curieuse qui a l’œil pour le détail, organisée dans ses idées avec une bonne capacité d’analyse.

Hightest : Quelles sont les nouveautés que vous prévoyez pour votre site ?

Med Aziz & Sarah :  Intégrer un forum pour plus d’interactivité avec les passionnés de test, partager des idées et bénéficier des expériences des autres.

Hightest : Recherchez-vous des contributeurs pour créer de nouveaux quiz ISTQB et étoffer votre site ?

Med Aziz & Sarah : Nous sommes ouverts à toutes contributions. Vous pouvez nous envoyer vos idées à travers notre site, nous avons ajouté une rubrique pour cela. Nous pourrons discuter et voir ce que nous pourrons faire pour encore mieux aider la communauté du test.

N’hésitez donc pas à visiter istqb.online ! A ce jour, il propose déjà 6 quiz blancs pour s’entraîner à la certification de niveau Fondation.

Merci à Med Aziz et Sarah pour leurs réponses !

Crédit image de couverture : cottonbro

Petites histoires de reconversion dans le test logiciel

Dans notre précédent article, nous partagions quelques astuces pour réussir son premier entretien d’embauche en tant que testeur, et nous invitions à mettre en avant les expériences passées dans d’autres domaines. Aujourd’hui, nous avons le plaisir d’approfondir ce sujet, en partageant avec vous un beau bouquet de témoignages recueillis auprès d’une multitude de QA issus de reconversions. Et vous verrez que beaucoup de ces profils ont exercé dans des domaines très éloignés de l’informatique, et ont su tirer parti au maximum de ces expériences !

Les soft skills sont au cœur de cet article, et nous espérons qu’à votre tour vous prendrez conscience des trésors que vous apportent vos expériences passées.

Bonne lecture, et bon courage aux aspirants testeurs qui nous lisent et se préparent à leur nouvelle carrière !

Sommaire

  1. De l’équipe de foot à l’équipe de test, avec Romain C
  2. Reconversions jumelles, avec A.B
  3. Des tests chimiques aux tests logiciels, avec Sabri Taleb
  4. Luxe, test et qualité, avec Coralie Cebron de Lisle
  5. De la QSE à la QL, avec F.D
  6. Exigence et qualité : de commerçant à testeur, avec David Venjon
  7. En mode test, avec Marion Lemaire
  8. De maître de conf’ à maître Scrum, avec Munaf Abbas
  9. Les savoureuses recettes de Julien Antonio
  10. Du parc d’attractions à l’attraction pour la qualité, avec Naa’ilah Aly
  11. Téléopérateur : l’envers du décor, avec Alvine Kamga
  12. Record & Playback, les enseignements de la production musicale, avec Dino Dona
  13. Le test est le remède, avec Sonia Boutaraamt
  14. Fuel for test, avec Nabil Boulehrouz
  15. Orchestrer la lumière et les tests, avec Sylvain Viole

De l’équipe de foot à l’équipe de test

Ce témoignage de Romain C file la métaphore du football, son premier domaine d’expertise, et qui vient aujourd’hui nourrir sa pratique du test. L’état d’esprit qui en ressort est extrêmement motivant… voire épique !

J’ai pu travailler 2-3 ans dans le secteur du sport avant de prendre un virage à 90° pour travailler dans le monde du test.

Mes premières expériences dans le sport me servent beaucoup aujourd’hui dans le monde du test.

Dans le sport j’utilise :

  • la persévérance
  • la rigueur
  • l’abnégation
  • l’esprit d’équipe
  • la remise en question
  • le dépassement de ses limites
  • l’esprit de compétition

Ces éléments me servent à surmonter les difficultés de projets ou des équipes et je n’aime pas abandonner ou perdre. 😉

Je fais beaucoup de métaphores et d’allusions au sport.

Je considère vraiment ma squad comme mon équipe de foot avec :

  • ses points forts
  • ses points faibles
  • ses individualités fortes
  • les travailleurs de fond
  • les leaders
  • les suiveurs
  • les relayeurs

Aussi, je considère :

  • L’Engineering Manager comme le coach
  • Le QA Engineer comme le milieu soupape, sentinelle
  • Le produit PM/PO comme le créateur de jeu (milieu offensif, attaquant)
  • Les devs comme des attaquants ou des défenseurs selon leur profil
  • Le sponsor métier comme le gardien de but.

Reconversions jumelles

Dans ce témoignage, A.B illustre ce qui pourrait être un proverbe : “tous les chemins mènent au test” ! Elle montre aussi l’intérêt d’avoir pu développer une expertise métier poussée dans un domaine particulier.

A la base, je suis ingénieur en biologie cellulaire et moléculaire, mais il n’y avait pas du tout de débouchés.

Ma jumelle, qui avait fait une école de commerce et est devenue QA, m’a cooptée. 

On a toutes les deux fait des études qui n’ont rien à voir et on se retrouve à faire le même métier !

J’ai fait pas mal de QA dans le domaine médical. Je me mettais à la place du personnel de santé et surtout, je comprenais à quoi servaient les features implémentées.

Il y a aussi beaucoup de logique. Des symptômes qui indiquent un diagnostic et entraînent un traitement. Le traitement a potentiellement des effets secondaires, est-ce que c’est acceptable ou non… ça s’applique aussi à l’informatique.

Maintenant que je ne travaille plus dans le médical, je garde le même esprit de bien comprendre la feature et la même logique. Et je trouve ça hyper cool d’avoir des résultats si rapides (contrairement à un traitement qui nécessite des jours et des jours avant d’avoir un résultat). En une ligne de code, ça peut être résolu 😊

👩👩

Des tests chimiques aux tests logiciels

Sabri Taleb est chimiste de formation et a même réalisé un doctorat dans cette discipline. Dans sa carrière de testeur, il a pu constater des parallèles entre les deux univers. 

La chimie est un domaine passionnant mais parfois surprenant. Il faut être extrêmement rigoureux, curieux et avoir un esprit critique (comme dans le test), contrôler chaque étape de transformation en faisant des analyses qualité (très souvent plusieurs analyses qui viennent compléter ou confirmer que le produit attendu est bien formé) et si nous voyons que ce n’est pas le cas, analyser et comprendre ce qu’il s’est passé et essayer de reproduire l’anomalie (si c’en est une) et modifier les protocoles.

Et même si le protocole est maîtrisé et routinier, un contrôle n’est pas exclu (encore une fois, comme dans le test 🙂 ), même si nous n’allons pas pousser les analyses qualité (une analyse rapide suffit).

De tout ça, il y a beaucoup de similitudes, ce qui fait que j’ai pu me sentir à l’aise dans cette nouvelle aventure. 

En effet, Sabri Taleb s’est retrouvé propulsé dans le monde du test (comme tant d’entre nous !) par une heureuse opportunité… qu’il a saisie in extremis !

J’ai toujours été attiré par ce que je ne connaissais pas. Lors de ma thèse, on m’avait proposé de refondre un site web, j’ai accepté sans avoir aucune connaissance, du coup j’ai aimé rechercher des solutions et tâtonner jusqu’à avoir un site fonctionnel en y ajoutant une fonction qui permettait aux étudiants de s’inscrire en master directement en ligne. Fini les dossiers papier !

C’est un concours de circonstances ; mes expériences professionnelles dans la chimie étaient courtes (CDD) et il n’y avait pas de postes dans ce domaine dans ma région. Privilégiant le côté familial, j’ai donc regardé ce qu’il y avait de disponible dans les environs, et j’ai constaté qu’il y avait des postes principalement de l’informatique.

J’ai trouvé une annonce qui offrait une possibilité de reconversion de bac +5 scientifique en dev Java, j’ai postulé et j’ai été accepté de suite en POEI (une entreprise s’engageait à embaucher après la formation).

A la fin des 3 mois intenses où on apprend la base du développement et des langages, l’entreprise m’a proposé de suivre une autre formation de 3 mois pour faire de la QA.

J’ai d’abord refusé, puis j’ai accepté de suivre la formation le jour de la date de clôture des dossiers.

Et c’est comme ça que je suis devenu QA avec des compétences en automatisation.

⚗️

Luxe, test et qualité

Avant de se reconvertir dans le domaine de la qualité logicielle, Coralie Cebron de Lisle a exercé dans différents domaines, dont la vente de produits de luxe. Ce qui a contribué à forger son exigence qualité.

En tant que vendeuse de produits de luxe, j’ai appris que les petits détails ont une grande importance et c’est dans son ensemble que le produit prend de la valeur, car aucun détail ne doit être négligé. Et c’est bien là qu’on peut reconnaître la qualité d’un produit.

Tout comme dans le test, il est important d’être curieux, à la fois des technologies utilisées et de la façon de travailler de ses propres collègues afin de comprendre comment le résultat final est obtenu.

Ses expériences précédentes ont également eu un impact positif sur son savoir-être : 

Dans mon expérience passée, que ce soit dans le tourisme, ou dans le commerce, être un bon communicant est essentiel au sein de l’équipe, non seulement par la bonne humeur, mais aussi par une facilité d’adaptation à travailler avec des collègues avec des personnalités très différentes.

⌚✨

De la QSE à la QL

Dans ce témoignage, F.D met en évidence les atouts qu’apporte un background QSE à une carrière dans la qualité logicielle.

En tant qu’ingénieur QSE, j’étais chargée d’accompagner les entreprises dans leurs démarches de certification ISO/TS 14001. Ça consistait à mettre en place la gestion des déchets, la gestion des produits chimiques ou encore la veille réglementaire pour la partie environnement. Pour la qualité, les activités étaient du type audit, reporting fournisseur.

Je dirais que les parallèles les plus évidents avec le test logiciel sont surtout du côté qualité. Pour l’écriture des rapports d’anomalies, je m’inspire beaucoup des méthodes de résolution de problèmes : la méthode QQOQCP, les 5 pourquoi, entre autres méthodes… Cela m’aide beaucoup à structurer ma pensée.

Le côté très procédural des certifications ISO m’a aussi permis d’acquérir des compétences en gestion documentaire. Cela n’est pas forcément mis en avant dans le contexte agile mais chez une entreprise cliente qui ne possède pas d’outils de tests, ça peut être un sacré avantage.

Le métier d’ingénieur QSE est aussi un métier de formateur (aux procédures qualité, aux situations d’urgence…) Il m’a permis aussi de savoir comment m’adresser à différents publics (développeurs, product leaders, etc…) pour aller chercher l’information, pour rendre compte d’une anomalie, pour décaler un planning…

📃✅

Exigence et qualité : de commerçant à testeur

Dans son “ancienne vie”, David Venjon était chef de secteur alimentaire. Ce métier consiste à gérer le secteur alimentaire d’un magasin en incarnant les valeurs et l’esprit de l’enseigne.

Dans ce métier, rechercher en permanence la satisfaction des clients est primordial. Il faut avoir le sens du commerce et de la bienveillance. On doit veiller au respect de la politique commerciale du groupe, de la mise en place de l’ensemble des opérations commerciales. Avoir des connaissances en gestion est un plus. Il faut connaître ses budgets, apporter des correctifs si nécessaire et bien entendu, développer son CA. On doit former ses collaborateurs, les faire monter en compétence, recruter le cas échéant. Des notions de droit du travail sont nécessaires, et la rigueur et l’anticipation font partie du quotidien.

Lors de ma reconversion professionnelle dans la qualité logicielle, j’ai analysé mes softs et hard skills acquises tout au long de ma carrière (17 ans) et j’ai synthétisé celles qui me seraient utiles dans l’informatique.

Je retiens les compétences transverses suivantes :

  • analyse ;
  • organisation ;
  • rigueur ;
  • adaptabilité ;
  • diplomatie ;
  • écoute ;
  • initiative.

Toutes mes compétences étaient axées vers un seul et même objectif : la satisfaction du client.

Depuis 2 ans, je me suis appuyé sur ces forces, qui représentaient mon socle de base, mon cercle de confort, afin de pouvoir me dépasser et acquérir de nouvelles compétences déterminantes dans mon nouveau métier :

  • l’investigation ;
  • l’autonomie (encore plus prononcée que dans mon ancien métier) ;
  • l’apprentissage (dans une démarche intellectuelle et non mécanique) ;
  • la réflexion ;
  • le dépassement de soi.

Les compétences transverses sont une valeur refuge sur lesquelles je m’appuie et je me réfugie en cas de difficulté pour mieux rebondir ensuite.

Cela me rend encore plus exigeant et consciencieux dans mon quotidien, ce qui m’a très vite rendu crédible au sein de mon équipe et m’a donc donné de la confiance en moi.

🤝

En mode test

Marion Lemaire a débuté sa carrière en tant qu’ingénieur textile spécialisée en mode éthique ; elle faisait également du stylisme photo et du conseil. Elle a constaté, elle aussi, des ponts entre ces différentes disciplines et le test logiciel.

Il y a évidemment la minutie de l’ingénierie et l’habitude des process, mais au-delà de ça, il y a plusieurs choses :

  • l’aptitude à comprendre un besoin client même quand le client ne sait pas exprimer ce qu’il veut (classique)
  • la facilité à appréhender différents secteurs et à s’intégrer dans une équipe existante
  • l’évident sens du détail
  • la capacité à se mettre dans les chaussures de l’utilisateur final, car dans tout métier on est confronté à l’outil IT (logiciel de modélisation, plate-forme de vente en ligne, etc)
  • l’aptitude à comprendre des règles de gestion complexes (j’accompagnais les démarches d’audit vers la labellisation écologique par exemple)
  • la facilité à être un couteau suisse et un interlocuteur privilégié de toutes les parties prenantes
  • les capacités de communication et de restitution de l’information (j’étais gestionnaire de la fédération des acteurs de la mode éthique)
  • les capacités d’organisation (gérer un shooting de A à Z, c’est pas de la tarte)
  • le rédactionnel (je faisais des piges pour des magazines de mode)

Suite à cela, Marion a suivi une formation à l’EQL (Ecole de la Qualité Logicielle, à Montrouge juste à côté du Beffroi où se tient tous les ans la JFTL). Elle y est ensuite restée en tant que formatrice puis encore recruteuse de profils.

J’ai vu des artistes tatoueurs devenir d’excellents testeurs techniques, des prothésistes ongulaires devenir de géniales fonctionnelles avec un super côté support, et pléthore de profils incroyables comme des scripts dans le cinéma, des thésards en histoire de l’art, des artistes en mosaïque, des astrophysiciens… C’est incroyable les ponts que l’on peut faire !

📸

De maître de conf’ à maître Scrum

Munaf Abbas, ancien enseignant-chercheur, met en lumière par son témoignage de nombreux mécanismes de l’exigence intellectuelle, nécessaire à de bons tests.

Je suis un ancien enseignant-chercheur ayant travaillé pendant quelques années dans l’enseignement supérieur en France et à l’étranger. J’avais un poste fixe à l’étranger, Maître de conférences, que j’ai quitté pour revenir en France, où les postes sont très rares et parfois inaccessibles. J’ai deux doctorats, l’un en linguistique appliquée à la traduction et l’autre en sciences de l’information et de la communication.

Quand je me suis reconverti à l’informatique, ce qui m’a le plus attiré étaient la méthode et la qualité (la deuxième étant en partie une conséquence de la première).

Il y a beaucoup d’éléments que j’ai pu facilement recontextualiser de mes expériences passées : la méthodologie, la rigueur, la planification et le travail en amont sur la conception et sur les échéances. L’évaluation également est toujours présente à l’esprit ; comment on pourrait évaluer les choses, individuellement et collectivement : un produit, un plan ou un process de réalisation. La vision micro du projet se marie ainsi à la vision macro, et jouer un rôle de connecteur par moment m’a bien plu. J’étais, jusqu’à ma précédente mission, Scrum master et testeur en même temps, et mon expérience précédente m’a bien aidé là-dedans.

👨‍🏫

Les savoureuses recettes de Julien Antonio

Ancien cuisinier, Julien Antonio a puisé dans son expérience en cuisine de nombreux réflexes utiles en tant que QA.

L’attention au détail et le souci de la qualité sont importants dans les deux cas.

Côté testeur, il y a le fait de vérifier que ça fonctionne bien mais aussi que ça répond au besoin du client, plus les petits à-côtés qui font partie de la qualité. Par exemple : “Pourquoi ce nouveau bouton n’a pas du tout le même comportement que tous les autres sur la même page quand on clique dessus ou quand on le survole ?”

Côté cuisine, je trouve que de bonnes questions à se poser quand on goûte un plat sont : “Est-ce que c’est bon ? Est-ce que j’ai envie d’en reprendre une deuxième cuillère juste par gourmandise ? Si ce n’est pas le cas, qu’est-ce qui manque, quel est le problème ?” Ce n’est souvent pas grand-chose (un peu de jus de citron pour ajouter une touche d’acidité par exemple) mais ça fait la différence entre un plat correct et un plat où on va se dire « Han mais c’est super bon ! »

Côté développement on insiste beaucoup sur :

  1. Tester tôt et tout au long du développement
  2. La qualité des spécifications.

Côté cuisine on pourrait insister sur :

  1. Goûter tôt et tout au long de la préparation
  2. La qualité de la rédaction des recettes.

Et ça a beaucoup d’importance :

  1. Quand je cuisine avec des proches je les fais souvent goûter régulièrement et se poser la question que j’évoquais plus haut (« Est-ce que c’est bon ? Qu’est-ce qui manque ? »), plutôt que de juste suivre la recette et de ne se poser la question de la réussite du plat qu’une fois que celui-ci est sur la table.
  2. Une recette qui dit par exemple « Laisser réduire quelques minutes, jusqu’à obtenir une consistance proche de celle du miel » est plus utile car plus précise qu’une qui dirait juste « Laisser réduire réduire 5 minutes ». Car, pourquoi 5 minutes ? Pourquoi est-ce qu’on laisse réduire en fait ? Qu’est-ce qu’on veut comme résultat ? C’est sans doute clair dans la tête de l’auteur, mais ce n’est pas du tout explicite dans celle de la personne qui lit la recette. On ne peut pas modifier la rédaction d’une recette, on peut juste être plus sélectif quand on feuillette un livre de recettes avant de l’acheter. Et on peut appliquer la même logique quand on retravaille des specs avant de les confier aux devs : qu’est-ce qui nous semble évident mais n’est pas dans le texte ? Est-ce qu’il reste des ambiguïtés ? Etc.

👨‍🍳

Du parc d’attractions à l’attraction pour la qualité

Avant de rejoindre le monde de la qualité logicielle, Naa’ilah Aly a travaillé plusieurs années à Disneyland Paris. Une expérience humaine très riche et stimulante, qui lui permet aujourd’hui de faire face à de nombreuses situations.

J’ai effectué plusieurs postes à Disneyland Paris, le plus significatif ayant été celui de guest flow. Un peu partout à travers le parc nous étions en charge de gérer les différents flux des visiteurs, cela pouvait se traduire aussi bien par informer les gens, répondre à leurs attentes, assurer leur sécurité durant les parades, contrôler l’accès à certaines zones du parc pendant les spectacles mais aussi se charger de l’ouverture de certaines attractions et de l’accueil du public au sein de ces attractions.

La sécurité était la priorité pour Disney et les vérifications essentielles. Je n’aurais pas pu souhaiter une meilleure préparation pour mon métier actuel. J’y ai appris à faire des vérifications méticuleuses, aidées par l’usage de checklists, à ne pas laisser de détails sans surveillance, à faire les choses de façon logique et ordonnée. J’y ai aussi appris à placer le client en priorité, à faire preuve d’empathie, à dépasser ses attentes. J’y ai gagné également une bonne dose de diplomatie et une expérience dans la résolution de conflits.

C’est un peu grâce à Disney que je peux aujourd’hui vérifier une feature avec précision, en me mettant à la place de l’utilisateur et en rapportant les bugs mais toujours avec le sourire !

🎠

Téléopérateur : l’envers du décor, avec Alvine Kamga 

Forte d’une expérience de téléopérateur, Alvine Kamga en tire une compréhension profonde des impacts d’une mauvaise expérience client, ainsi qu’une forte capacité d’écoute et d’empathie.

Mon expérience en tant que téléopérateur m’a permis de comprendre l’importance de la satisfaction du besoin de l’utilisateur final :

  • En tant que téléopérateur je me trouvais au premier plan, en contact direct avec l’abonné et je faisais face à l’insatisfaction permanente de ce dernier par rapport au service rendu.
  • En tant que testeur je me retrouve de l’autre côté de la barrière et à chaque fois que je travaille j’ai toujours à l’esprit qu’au bout de la chaîne il y a un utilisateur final qui doit être satisfait du service ou du produit qui fait l’objet de mes tests. Ce qui constitue une source de motivation permanente.

Comme je l’ai appris de mon expérience de téléopérateur : “Un utilisateur satisfait est un utilisateur dont le besoin a été compris et résolu.”

🎧

Record & Playback, les enseignements de la production musicale 

Dino Dona a démarré sa carrière dans le monde de la production musicale. Un domaine qui semble éloigné de celui du domaine logiciel, et pourtant, les parallèles sont nombreux entre le processus de création d’un applicatif et celui de la production d’un album.

Lorsque l’on produisait des albums, le rythme était assez semblable à la production d’une application. Chaque titre passait par plusieurs phases : composition, écriture, enregistrement, ajustement, mixage, mastering. Chaque phase était dépendante de la précédente et demandait une validation par toute l’équipe. 

Nous nous fixions un rythme théorique de 2 semaines pour terminer toutes les phases d’un titre. 

Cependant, et contrairement à un produit numérique, la musique ne répond pas directement à un besoin. Son rôle premier est de transmettre des émotions et parfois, un titre qui ne suit pas un chemin de production « standard » comme évoqué précédemment peut être un carton. 

J’ai découvert le test lors de la création d’un jeu pour smartphone dans l’univers de la musique.

Voici quelques softs skills qui m’ont permis de faire une bonne transition dans le monde du test et plus particulièrement sur le rôle de responsable QA :

  • Fiabilité : La nécessité de tenir ses engagements auprès des parties prenantes, être rassurant, tenir ses délais,
  • Aptitude à fédérer : Mettre en place un collectif durable et tirer le meilleur de chaque individu qui le compose,
  • Rigueur : On mise sur un artiste qui lui-même met sa vie en jeu pour atteindre son objectif. Il ne doit pas y avoir de place pour le doute,
  • Débrouillardise : Savoir apprendre et trouver des solutions rapidement,
  • Capacité à être à l’écoute : Comme tous les métiers créatifs, l’humeur de l’artiste prend une place importante, il faut savoir être à l’écoute.

🎼

Le test est le remède

Sonia Boutaraamt a débuté sa carrière en tant que visiteuse médicale, c’est-à-dire porte-parole de laboratoires pharmaceutiques auprès de professionnels de santé. Une pratique qui a développé sa rigueur et ses compétences en communication.

La visite médicale consiste à rendre visite aux médecins généralistes et ou spécialistes, que ce soit en ville ou en milieu hospitalier. Dans mon cas, c’était les deux. Lors de ces visites, il s’agit de leur faire des rappels sur les spécialités du laboratoire (indications, contre-indications, effets indésirables, posologie), leur présenter les nouveaux médicaments et leur parler des études cliniques récentes. 

Les situations similaires dans le monde de la qualité logicielle sont nombreuses. Elles se concentrent notamment dans la collecte des données et leur exploitation, le reporting, la mise en place de KPI pour atteindre les objectifs. Il y a aussi toute la partie bonnes pratiques et l’habitude de passer des certifications ; en effet, nous n’avions pas le droit d’aller sur le terrain si on était pas certifié tous les 3 mois. J’ai gardé ce côté, j’essaye toujours de me faire certifier au maximum.

En bref, les processus ont une même base : bonnes pratiques, certifications, stratégies (stratégie de test / stratégie commerciale) et politique (politique de test du SI / politique commerciale des laboratoires).

💊

Fuel for test

Quelques jours après la parution de l’article, nous avons eu le plaisir de recevoir un autre témoignage tout aussi inspirant. Il s’agit de celui de Nabil Boulehrouz, précédemment caissier dans une station service pendant 10 ans, avant de reprendre ses études et de se reconvertir dans le test logiciel.

Après quelques années dans le test je me suis rendu compte que le contact avec les clients m’avait facilité le travail avec les développeurs et les autres parties prenantes.

En station-service, quand le client se sert en carburant mais ne peut pas payer, c’est assez compliqué. En effet, là où on peut juste abandonner ses courses dans les autres commerces, en station ce n’est pas possible car le carburant est déjà dans le réservoir. Il faut donc toujours trouver un compromis avec le client. Et chaque client est différent. Avec le temps, j’ai appris à m’adresser de la bonne manière avec les clients pour trouver une solution. Cette « compétence » m’a beaucoup servi dans le test, surtout quand je travaille avec des équipes qui n’ont pas l’habitude de travailler avec un testeur. C’est assez délicat de remonter des bugs au début sans que les développeurs le prennent personnellement.

Orchestrer la lumière et les tests

Et encore un témoignage bonus avec Sylvain Viole, qui avant d’être QA engineer était régisseur lumière dans le spectacle.

Au moment de ma reconversion je me rappelle avoir beaucoup travaillé sur les ponts entre ces deux activités sans lien à priori.

Mon ancien métier consistait à préparer, installer, programmer et exploiter le matériel technique nécessaire à l’éclairage d’un événement, spectacle ou concert.

Il y a beaucoup de choses dans cette activité dont je me sers aujourd’hui dans mon métier de QA :

  • Le repérage et la préparation d’un événement correspond à la lecture et au challenge des spécifications d’un produit. Dans les 2 cas il faut être observateur, précis, le plus exhaustif possible et maîtriser le contexte.
  • La programmation séquentielle de lumière (encodage) est très proche de celles de tests automatisés. Dans les 2 cas il faut coder, et factoriser pour simplifier la maintenance.
  • Une répétition générale partage les mêmes objectifs qu’un test end to end.
  • L’alternance de séquences travaillées et non travaillées (dédiées à la veille et l’autoformation) que l’on peut avoir en ESN ou freelancing peut aussi s’approcher des rythmes d’un régisseur lumière intermittent.

Un point déstabilisant en revanche aura été d’intégrer le côté incrémental des choses dans la tech, là où dans la régie technique le livrable devait être complet dès la première itération. (Parfois, souvent, il n’y en avait qu’une…)

Côté soft skills, l’anticipation, autonomie, l’organisation et la précision sont des qualités auxquelles les 2 activités font appel.

Avant de travailler sur la formulation de ces ponts entre la technique du spectacle et la QA, je trouvais le parallèle un peu tiré par les cheveux. Maintenant que ma reconversion est consommée, je le trouve évident.

💡

Conclusion

Le monde du test s’enrichit de la diversité des profils qui rejoignent cette profession. Les expériences passées construisent les soft-skills et permettent également d’aborder ce nouveau contexte avec un regard plus acéré.

Il n’y a donc pas d’hésitation à avoir si ce métier vous attire ; lancez-vous, vous allez faire des merveilles !

Et pour découvrir d’autres aspects du métier du test, rendez-vous sur notre page LinkedIn 🙂

Photo de couverture : James Wheeler

4 clés pour réussir son premier entretien d’embauche de QA

Dans un précédent article, nous vous donnions des pistes pour vous aider à devenir testeur logiciel. Vous avez désormais obtenu un premier entretien d’embauche et votre nouvelle carrière de QA vous tend les bras : félicitations ! Problème : le syndrome de l’imposteur vous guette, et vous redoutez que l’entreprise ne vous retienne pas. Pas de panique, dans cet article on partage avec vous quelques astuces pour que ce moment se passe bien. Mettez toutes les chances de votre côté !

#1 – Partagez votre enthousiasme

Beaucoup de personnes découvrent le test par hasard, par exemple suite à un entretien avec des conseillers Pôle Emploi. Il n’y a aucun mal à ça, le métier est encore relativement méconnu et tous les moyens sont bons pour le faire connaître ! Merci d’ailleurs, au passage, aux personnes qui, sans l’exercer, font connaître ce beau métier.

Toutefois, si vous êtes dans ce cas, il est important que votre discours dépasse cette dimension “hasard de la vie”. Sans cela, votre interlocuteur se demandera, à juste titre, si vous avez choisi le test logiciel par envie ou par dépit.

  • Qu’est-ce qui fait qu’aujourd’hui, vous avez envie de faire du test ?
  • Cette activité vous plaît-elle authentiquement ?
  • Si oui, quelles sont les activités ou les situations précises qui vous font le plus vibrer ?

Vous aurez beau être authentique dans votre motivation, ce qui va compter avant tout c’est de l’exprimer d’une façon que votre recruteur puisse vous croire.

Plus vous serez spécifique et plus vous paraîtrez authentique. 

Par exemple, “Je veux devenir QA car ça me plaît d’améliorer la qualité des logiciels” sonne un peu fade. “J’adore constater qu’un des bugs que j’ai découverts a été parfaitement corrigé”, ou encore “Ca me fait pétiller le cerveau de rechercher la petite configuration qui provoquera une défaillance” c’est tout de suite plus savoureux !

Si vous montrez votre motivation et que celle-ci est sincère, votre enthousiasme aura toutes les chances de gagner votre interlocuteur.

#2 – Assumez toutes les cordes à votre arc

Vous avez un passé de littéraire ? De comptable ? De biologiste ? De prof ? De standardiste ? De cuistot ? De parent au foyer ?

Félicitations, vous faites donc partie de l’écrasante majorité de personnes qui ont débuté leur carrière autrement que dans le test logiciel. Vous avez tout à gagner à assumer pleinement vos expériences passées. Elles ont façonné chez vous un certain regard sur le monde, des exigences qui vous sont propres, une manière d’apprendre, de vous organiser, de communiquer.

C’est une richesse et il est important que vous en preniez conscience !

Vous gagnerez à expliquer à votre interlocuteur les ponts qui existent entre les différentes expériences et disciplines qui jalonnent votre carrière, et le métier du test. Dans le prochain article, nous donnerons la parole à une myriade de QA aux parcours extrêmement variés, qui vous parleront des apports de leurs premières disciplines. Préparez-vous !

#3 – Démontrez vos qualités de testeur

Emna Ayadi, spécialiste en test logiciel, a mis en lumière 4 catégories de compétences indispensables aux testeurs du XXIème siècle (les 4C) :

  • Esprit critique
  • Collaboration
  • Communication
  • Créativité

Même si vous débutez dans le monde de la qualité logicielle, vous avez déjà certainement des “success stories” à partager en rapport avec ces soft kills, que ce soit dans votre passé étudiant, professionnel, associatif, ou de loisirs.

En lien avec les qualités citées ci-dessus, illustrez celles dans lesquelles vous vous reconnaissez le plus par des actions que vous avez pu mener précédemment.

#4 – Faites part de votre curiosité

La curiosité est une qualité extrêmement valorisée dans le monde de la qualité logicielle. C’est normal ; vous allez devoir vous intéresser à des domaines fonctionnels que vous ne maîtrisez pas encore, faire l’effort d’aller dans le détail, apprendre à utiliser des outils qui changeront d’année en année…

Et le hack, c’est que la curiosité s’appuie justement sur ce qui, en tant que débutant, peut aujourd’hui vous faire peur : le fait de ne pas tout savoir !

Au cours de l’entretien, faire part d’éléments précis qui éveillent votre curiosité permettra à votre interlocuteur d’en savoir davantage sur votre motivation et ce sur quoi votre profil tend. Encore une fois, plus vous serez spécifique, plus vous irez loin dans les questions, et plus vous aurez de l’impact. Un exercice possible est de préparer une question, et de trouver une question supplémentaire pour l’approfondir. Par exemple, après avoir posé la question “Quels outils utilisez-vous ?”, vous pouvez aller plus loin : “Selon quels critères les avez-vous choisis ?”

Ou encore, après la question “Combien de personnes constituent l’équipe de test ?”, demander “Quel ratio visez-vous entre les devs et les QA ?”.

Une curiosité sincère démontre également, sans qu’il y ait besoin de le formaliser ou de forcer le trait, une certaine humilité.

Développer une attitude de curiosité est donc “tout benef”, lors de l’entretien mais aussi tout au long de votre parcours… que nous espérons riche en succès !

D’autres ressources pour aller plus loin

Cet article s’adresse aux testeurs débutants, qui veulent décrocher leur tout premier poste de testeur. Il existe cependant d’autres articles que nous vous conseillons de lire également, même s’ils ne se focalisent pas sur le cas particulier de la première embauche. Nous souhaitons partager avec vous deux d’entre eux :

Il ne nous reste plus qu’à vous souhaiter un entretien agréable et enrichissant. Tirez-en le maximum, et n’oubliez pas qu’une réponse négative ne signifie pas que l’histoire est terminée ! Si le courant est passé, gardez contact ; cela pourra mener, quelques années plus tard, à de belles collaborations. You never know!

Pour découvrir d’autres contenus sur le métier du test, abonnez-vous à notre page LinkedIn 🙂

Tests non fonctionnels : quelques ressources pour vous lancer

« Les compères dans leur Fiat font sécher leurs mains en utilisant les portes. »

Qu’est-ce que c’est ? Une formule magique ? Une chaîne aléatoire générée par une IA ? Un extrait de chanson absurde ?

Rien de tout ça : c’est notre moyen mnémotechnique pour se souvenir des 8 aspects de la qualité logicielle définis par ISO 25010 !

Les com(patibilité)per(formance)es dans leur Fia(bilité)t fon(ctionnalité)t sec(urité)her leurs main(tenabilité)s en utilisa(bilité)nt les port(abilité)es.

Compatibilité, Performance, Fiabilité, Fonctionnalité, Sécurité, Maintenabilité, Utilisabilité, Portabilité.

Ces 8 aspects sont tous importants, mais l’un d’entre eux est comme un arbre qui cache la forêt : l’aspect fonctionnel. Eh oui : quand un produit numérique est créé, on veut avant tout savoir “s’il fonctionne” !

Toutefois, il est important d’avoir en tête les 7 autres aspects, qui se focalisent sur comment le produit fonctionne : rapidement, joliment, sécuritairement, compréhensiblement, simplement…

Cet article donne quelques clés pour comprendre ces types de test avant de vous lancer. Les ressources partagées sont issues de nos propres travaux ainsi que d’autres ressources francophones, pertinentes et faisant autorité dans le domaine de la qualité logicielle. Nous étofferons avec plaisir cette liste avec vos suggestions, alors n’hésitez pas à nous en partager.

Bonne lecture !

Compatibilité

Portrait robot du problème de compatibilité

L’applicatif fonctionne bien sur la machine du développeur (héhé !) mais rencontre des problèmes dès qu’il se trouve sur le même environnement qu’un autre logiciel du système d’information ? Il a du mal à communiquer avec d’autres systèmes dont il dépend ? Il présente certainement un problème de compatibilité !

A quoi ressemblent des tests de compatibilité ?

Bien souvent, les problèmes de compatibilité sont découverts “par hasard”, ou plutôt “par nécessité”, quand l’applicatif est installé dans son environnement cible. Mais en fonction du produit (notamment ceux nécessitant une installation locale chez chaque client), il peut être nécessaire de procéder à des tests systématiques. Cela consiste à imaginer différentes configurations que pourrait rencontrer l’applicatif, et vérifier si chacune d’elle permet un comportement nominal de celui-ci. Des tests de portabilité sont alors souvent également nécessaires (voir la section dédiée).

Pour aller plus loin :

Fiabilité

Problèmes de fiabilité : kézako ?

Les utilisateurs ne font pas confiance à l’applicatif ? Il plante à chaque fois qu’on saisit une valeur qu’il n’attend pas ? Il est régulièrement indisponible ? Il est incapable de se rétablir après avoir “crashé” suite à une forte affluence ? Il y a certainement un problème de fiabilité !

Comment tester la fiabilité ?

La fiabilité donne lieu à des tests de diverses natures.

Certains tests visent à mettre l’applicatif et son environnement en difficulté (coupure réseau, indisponibilité d’une ressource tierce…) afin de vérifier l’adéquation de son comportement et sa capacité de récupération.

Des dispositifs de monitoring peuvent également être mis en œuvre afin de vérifier la disponibilité de l’applicatif au fil du temps.

Pour aller plus loin :

Performance

La performance, qu’est-ce que c’est ?

L’applicatif est trop lent ? Il ne tient pas plus de 15 utilisateurs simultanés ? Il y a certainement un problème de performance !

La performance regroupe un certain nombre de termes utilisés au quotidien au sein des DSI : charge, robustesse, stress, rendement… 

Pourtant, chaque terme a une signification différente et peut mener à des types de test différents.

Vous vous perdez dans la sémantique ? Pas de panique, faites un petit tour par cet article de désambiguïsation qui vous permettra d’y voir plus clair grâce aux définitions de l’ISTQB !

Quels types de tests pouvez-vous réaliser ?

Les tests les plus courants pour cet aspect de la qualité sont les “tirs de charge”, qui consistent à simuler l’utilisation de l’applicatif par un certain nombre de personnes. Le type d’utilisation peut être spécifié, et des rapports sont générés de façon à comprendre quelles ressources sont les plus susceptibles de créer des lenteurs voire des indisponibilités en production.

Quelques outils connus : JMeter, Neoload, Gatling.

Pour aller plus loin :

Sécurité

Bugs de sécurité : des bugs pas comme les autres ?

Les bugs de sécurité, aussi appelés “failles”, ont une place un peu à part dans l’inconscient collectif, car ils mettent en jeu non seulement l’applicatif, son environnement et ses utilisateurs, mais aussi des acteurs bien spécifiques, communément désignés sous le noms de hackers, pirates ou utilisateurs malveillants !

Ces anomalies peuvent être de natures très différentes. On distingue communément les défauts présents dans l’applicatif (on parle tout simplement de “sécurité applicative”), et ceux qui concernent son environnement ou son réseau.

Techniques de tests de sécurité

Parmi les techniques spécifiques les plus courantes pour effectuer des tests de sécurité, on compte le pentest ou penetration testing (des tests souvent outillés qui consistent à s’introduire dans un système) et les scans de vulnérabilité, qui comparent un existant avec une bibliothèque de failles connues et plus ou moins communes. Tandis que les pentests nécessitent souvent des connaissances assez poussées, il est possible de mettre en œuvre rapidement et à peu de frais des scans de vulnérabilité. Toutefois, l’un ne remplace pas l’autre.

Des tests de sécurité peuvent être facilement mis en œuvre lors de la conception de tests d’API ; il suffit alors d’imaginer des scénarios “interdits” (exemple : essayer de changer le prix d’un article en utilisant l’API en étant connecté en tant que simple client !)

Pour aller plus loin :

Maintenabilité

Repérer les problèmes de maintenabilité

L’applicatif connaît de nombreuses régressions ? L’intégration de nouveaux développeurs se fait lentement et dans la douleur ? Les devs historiques rechignent à retourner sur le projet ? Ca sent la problématique de maintenabilité !

Comment gérer les défauts de maintenabilité ?

La qualité de code est étroitement liée à cet aspect de la qualité logicielle ; toutefois, ce n’est pas parce que la qualité de code est essentiellement une responsabilité des développeurs, que les testeurs n’ont pas de rôle à jouer pour faciliter la consolidation de la maintenabilité.

Les outils de qualimétrie peuvent être des alliés dans la détections de problèmes de maintenabilité. SonarQube par exemple détecte 3 types de problèmes de code : les bugs, les vulnérabilités et les “code smells”. Cette troisième catégorie permet de détecter des aspects qui trahissent un manque de maintenabilité au sein du code.

Un travail collaboratif de définition de bonnes pratiques de développement est également un investissement très intéressant pour la qualité à long terme du produit. Cela peut prendre la forme de revues de code classiques (simple et efficace !), mais cela peut aussi être outillé avec des solutions telles que Promyze.

Pour aller plus loin :

Utilisabilité

Le spectre des problèmes d’utilisabilité

L’utilisabilité est un aspect passionnant de la qualité logicielle, qui s’intéresse avant tout à l’expérience subjective de l’utilisateur. Et “subjective” n’est pas un gros mot ! Cela signifie simplement qu’il est nécessaire ici de se positionner dans une situation spécifique. Celle, par exemple, d’une personne qui n’a pas forcément les mêmes informations que nous, le même vécu ou encore les mêmes caractéristiques physiques (dans le cas des tests d’accessibilité).

Comment obtenir des retours d’utilisabilités crédibles ?

Une des grandes difficultés qu’un testeur peut rencontrer au moment de rapporter un bug d’utilisabilité est le risque de se voir rétorquer “C’est subjectif” (sous-entendu “Cela n’est pas un bug, cela ne sera pas corrigé”). Il est donc important de s’appuyer sur des arguments solides et si possible soutenus par des ressources tierces (états de l’art, témoignages utilisateurs…)

Comme pour la portabilité (voir section suivante), le crowdtesting (ou test participatif) est en mesure d’apporter rapidement des informations qualifiées sur l’utilisabilité des applicatifs.

Pour aller plus loin :

Portabilité

Les signes de problèmes de portabilité

L’applicatif fonctionne bien sur Windows 10 mais pas sur MacOS ? Sur Chrome mais pas sur Firefox ? Le design est magnifique sur écran d’ordinateur mais horrible sur smartphone ? Quand on parle de portabilité, il s’agit exactement de ce type de problèmes !

Démarrer une démarche de tests de portabilité

L’ennemi n°1 de la portabilité, c’est… de ne pas faire de tests de portabilité. Certes !

L’ennemi n°2, c’est de se disperser.

En effet, la combinatoire des environnements (système d’exploitation, version d’OS, navigateur, taille d’écran…) empêche la plupart du temps de tout tester. La portabilité donne une belle illustration du principe général du test “Les tests exhaustifs sont impossibles” !

Pour asseoir une stratégie de tests de portabilité efficace, il est nécessaire de s’appuyer sur des chiffres. Quelles sont les configurations les plus plausibles dans notre cas ? Quels sont les 20 % de configurations (à la louche !) qui nous permettront d’être confiants sur 80 % des cas ?

Des outils de tracking des utilisateurs sont alors très utiles (par exemple, Google Analytics pour un site web permet de connaître quelques éléments sur les habitudes de navigation des utilisateurs).

Une fois cet état des lieux réalisé, c’est le moment de se lancer. Plusieurs possibilités peuvent alors être envisagées :

  • Avoir recours à des fermes de devices ou de navigateurs (des services en ligne qui mettent à disposition des environnements dédiés à ce type de tests)
  • Investir dans de nombreux devices de test (c’est beaucoup plus onéreux ; la plupart du temps nous déconseillons cette pratique)
  • Faire appel à des crowdtesteurs. L’avantage ici étant que les retours ne concerneront pas seulement la portabilité, mais aussi d’autres aspects de la qualité logicielle.

Pour aller plus loin :

  • Comprendre les enjeux liés à la compatibilité : Article sur la Taverne du testeur
  • Nous avons testé pour vous deux services cloud permettant de mettre en œuvre des tests de portabilité : pCloudy et BrowserStack.
  • L’extension Lighthouse de Chrome permet de passer en revue des aspects tels que la performance, la portabilité et l’accessibilité.
  • La portabilité et la compatibilité sont souvent étroitement liées, car elles s’intéressent toutes deux à la variété des configurations logicielles et matérielles dans lesquelles l’applicatif va être utilisé. Toutefois, ce sont deux notions à distinguer. Voici donc un paragraphe (en anglais) sur la différence entre compatibilité et portabilité.

Par où commencer ?

Eh oui, cela fait beaucoup d’infos ! 

Connaître les 8 aspects de la qualité logicielle est un bon début. Pour la suite, nous vous conseillons ces étapes pour faire de vous un cador des tests non-fonctionnels :

  • Faire connaître ces 8 aspects à votre équipe (en partageant cet article par exemple !)
  • Discuter collégialement des différentes facettes de la qualité vis-à-vis des applicatifs que vous testez au quotidien
  • Identifier les tests non fonctionnels prioritaires pour chaque applicatif
  • Vous former et mettre en œuvre ces tests au sein de votre stratégie globale !

Tout cela étant dit, nous vous souhaitons bon courage dans votre périple ! Si vous avez des questions ou besoin d’aide, nous vous conseillons de poster un message sur le groupe LinkedIn francophone très réactif Le métier du test. Au plaisir de vous y retrouver !

Bon courage dans votre exploration et souvenez-vous que le test regorge toujours d’occasions d’apprendre !