Dans cet article, Christelle Lam, férue de test et en poste chez Hightest depuis 1 an, explique la valeur ajoutée qu’apporte un logiciel de gestion des tests par rapport à un simple fichier Excel. Bonne lecture !
Dans le métier du test, il est fréquent de rencontrer des équipes où le cahier de tests et les rapports d’anomalies se trouvent sur un fichier Excel.
Pourquoi avoir choisi d’effectuer ce travail à l’aide d’Excel ?
Je pense que bien souvent, c’est par manque de connaissance des logiciels existants très utiles à la gestion de tests.
C’est un logiciel qui permet de gérer le cycle de vie des tests de la création de cas de test, à l’organisation de suites de tests jusqu’à l’exécution des tests, d’assurer la visibilité et la traçabilité des tests et plus si affinités.
Précédemment, nous avons parlé de Squash TM, mais il y en a d’autres comme HP ALM, Azure Test Plans, TestRail, TestLink, Refertest…
Du coup, pourquoi utiliser un gestionnaire de tests plutôt qu’Excel ?
Voici quelques raisons !
Gestion des scénarios de tests
Un gestionnaire de tests offre généralement des fonctionnalités avancées pour la gestion des scénarios de tests tels que la création structurée des scénarios, l’organisation hiérarchique, la gestion des versions, l’assignation des scénarios, le suivi de l’exécution, l’historique des résultats, la génération de rapports, l’intégration avec d’autres outils, automatisation des tests, permettant aux équipes de créer, organiser, exécuter et suivre les résultats de tests de manière plus efficace que ce qui est possible avec Excel.
Collaboration facilitée
Un gestionnaire de tests facilite la collaboration entre les membres de l’équipe de développement et de tests. Il offre souvent des fonctionnalités de partage, de commentaires et de suivi des modifications, ce qui peut être difficile à réaliser de manière efficace avec Excel.
Intégration avec d’autres outils
Les gestionnaires de tests sont souvent conçus pour s’intégrer facilement avec d’autres outils de développement tels que les systèmes de gestion de versions, les environnements de développement intégrés et les outils de suivi de problèmes. Cela crée une intégration fluide de processus de développement global.
Génération de rapports de test
Un gestionnaire de tests fournit généralement des fonctionnalités avancées de génération de rapports, permettant aux équipes de tester de manière plus approfondie et de produire des rapports détaillés sur les résultats des tests. Cela peut être plus complexe à réaliser avec Excel.
Réutilisation des scripts de test
Un gestionnaire de tests permet souvent la réutilisation des scripts de test, ce qui signifie que les tests peuvent être adaptés et exécutés à plusieurs reprises sans avoir à tout recréer à partir de zéro, ce qui peut être fastidieux avec Excel.
Gestion des données de test
Un gestionnaire de test peut offrir des fonctionnalités pour gérer efficacement les données de test, par exemple en séparant clairement l’espace de rédaction du scénario de test, et l’espace de déclaration des différentes données de test qui seront utilisées pendant la campagne. Excel ne permet pas cela facilement.
En conclusion, bien qu’Excel puisse être utilisé pour des tâches de base de gestion des tests, les gestionnaires de tests offrent des fonctionnalités plus avancées, une automatisation accrue et une meilleure gestion globale du processus de tests dans des environnements de développement logiciel complexe.
En espérant que cet article t’en a appris un peu plus et que dorénavant tu souhaites te faciliter la tâche en voulant utiliser un gestionnaire de tests plutôt qu’Excel.
N’hésite pas à prendre contact avec nous pour en discuter 😊
L’image de la couverture a été générée avec Midjourney
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.
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ère
Windows
Mac
À
Alt + 183 ou Alt + 0192
Verr. Maj. + 0
É
Alt + 144 ou Alt + 0201
Verr. Maj. + 2
È
Alt + 212 ou Alt + 0200
Verr. Maj. + 7
Ç
Alt + 128 ou Alt + 0199
Verr. Maj. + 9
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 !
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 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 .
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.
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 !
Dans l’article précédent, nous présentions la démarche qui nous a animée ces derniers mois chez Hightest dans l’optique de mener un audit green IT et d’accessibilité sur l’ensemble des sites web de Nouvelle-Calédonie. Dans cet article, nous allons voir les résultats du premier audit que nous avons pu mener sur la base de la liste de quelque 2400 sites web calédoniens que nous avons pu constituer !
Outillage
Pour mener l’audit green IT sur cette liste, c’est l’outil d’analyse EcoIndex qui a été utilisé, sur conseil de notre confrère Xavier Liénart, expert du domaine. Il s’agit d’un outil open-source et sans visée commerciale, développé et mis à jour par le Collectif Green IT.
EcoIndex a permis d’obtenir, pour chaque URL testée, les informations suivantes :
Un score
Une note
Le poids de la page
Le nombre de nœuds sur la page
Le nombre de requêtes envoyées au moment du chargement de la page.
Un élément important à avoir en tête est que ce sont uniquement les pages d’accueil des sites web calédoniens qui ont été analysées.
Penchons-nous un peu sur ces différents indicateurs.
Un score et une note green IT ?
Le score et la note sont calculés par EcoIndex lui-même et n’ont pas de valeur en-dehors de l’outil. Ils permettent simplement de se faire une première idée (ou une première frayeur…)
Le poids d’une page ?
Le poids d’une page web représente la quantité totale de données que le navigateur doit télécharger pour afficher la page complète. Ainsi, plus il y a de contenus multimédias, plus la page « pèse » lourd. La consommation est encore plus élevée sur des réseaux lents et/ou des appareils mobiles (car l’appareil doit rester actif plus longtemps).
Pour optimiser le poids d’une page web, il est en général recommandé de compresser les images, de minimiser le code CSS et JavaScript non essentiel, et d’utiliser des techniques de chargement asynchrone pour réduire la quantité de données transférées.
Mais au-delà de l’optimisation, un travail de réduction est à envisager. Cette image, peut-on s’en passer ? Idem pour les animations.
Le nombre de nœuds d’une page ?
Les nœuds d’une page web sont les différents éléments de sa structure (le « body » d’une page HTML est un nœud, une image est un nœud, un paragraphe est un nœud…). Un grand nombre de nœuds entraîne une charge de travail plus importante pour le navigateur et une consommation d’énergie accrue. Dans une optique green IT, il est donc recommandé de réduire le nombre de nœuds, ou éventuellement d’utiliser des techniques de chargement progressif de la page.
Le nombre de requêtes envoyées par une page ?
Une page web est un document, qui bien souvent fait appel à d’autres documents pour bien s’afficher. Une image doit s’afficher dans la page ? Une requête est envoyée au serveur pour aller la chercher. Une feuille de style ordonne l’apparence de la page ? De la même façon, ce fichier doit être récupéré sur le serveur. Un script permet d’afficher telle ou telle animation ? Même chose. À noter que ces requêtes peuvent être envoyées sur le même serveur que celui qui héberge la page, ou sur un autre. Regrouper les fichiers ou utiliser la mise en cache sont des techniques préconisées pour réduire l’impact environnemental lié à ces requêtes. Mais aussi, évidemment, simplifier la page et son fonctionnement.
Alors, les résultats ?
Un constat a pu être fait très tôt dans l’analyse : beaucoup des meilleures notes ont été attribuées à des sites en construction qui avaient échappé à notre filtre. Nous avons donc écartés ces sites car hors de notre périmètre cible, ce qui a fait descendre la taille de l’échantillon à 2231. Cela rappelle que ce n’est donc pas parce qu’un site est « écologique » qu’il est écoconçu; cela peut être simplement parce qu’il ne propose guère de contenu !
Suite à cet ultime écrémage, l’analyse EcoIndex lancée sur les sites web calédoniens a permis de constater les résultats suivants.
Des scores en courbe de Gauss triste
Sur EcoIndex, les scores des pages sont notés de A à G. La lettre A est attribuée aux sites les plus économes, la lettre G est attribuée aux sites les plus énergivores et impactants au niveau écologique.
La note la plus fréquente est E, ce qui tire la courbe de Gauss vers le côté obscur.
La répartition est la suivante :
Note
Nombre de sites
A
89
B
195
C
431
D
524
E
562
F
341
G
89
Les chiffres !
Poids des pages
Alors qu’EcoIndex préconise un poids maximum cible de 1,084 mégaoctets pour une page web, la moyenne des pages calédoniennes analysées est de 4,087 Mo, et la médiane à 2,824 Mo.
À titre de comparaison, EcoIndex partage les résultats de l’ensemble de ses >200 000 analyses précédentes (donc, sur un échantillon beaucoup plus vaste que la Nouvelle-Calédonie), et ceux-ci révèlent un poids médian de 2,41 Mo.
Nombre de noeuds
Pour ce qui est de la complexité des pages, basée sur leur nombre de nœuds, EcoIndex préconise une cible de maximum 600 nœuds. La moyenne calédonienne est à 810 nœuds, et la médiane à 617, c’est-à-dire un score très proche de la cible. La médiane de l’ensemble des pages web analysées par EcoIndex est à 693.
Nombre de requêtes
Combien de requêtes envoient les pages d’accueil des sites web calédoniens ? En moyenne, 98, et le nombre médian est de 86. Le nombre médian pour l’ensemble de tous les résultats EcoIndex est de 78, avec une cible préconisée de 40 requêtes.
Et maintenant… la question qui tue !
Est-ce pire qu’ailleurs ?
Difficile de consulter ces résultats calédoniens sans se demander : « Faisons-nous pire qu’ailleurs ? » Au sein de la commission NID, c’est une question qui s’est posée dès le début : aurons-nous la possibilité de comparer les résultats avec ailleurs ? C’est donc une chance qu’EcoIndex partage les chiffres obtenus sur les autres sites !
Mais quelle conclusion tirer de ces chiffres ? Les écarts sont-ils significatifs ? Parole à notre confrère Thomas Avron, de la société Apid ; datascientist, il est accoutumé à ce type de questions.
Parole à Thomas Avron
La question que l’on va se poser sur l’échantillon des sites de Nouvelle-Calédonie est la suivante : sa distribution est-elle la même que celle de l’ensemble des analyses faites par EcoIndex ?
Poids des sites
Nous savons que le poids médian de l’ensemble des sites analysés par EcoIndex est inférieur à celui des sites du territoire. Comme nous n’avons pas la certitude que la distribution de notre échantillon suit une loi Normale (la fameuse courbe de Gauss, centrée sur la moyenne et en forme reconnaissable de cloche), nous allons donc utiliser un test non-paramétrique pour voir si la distribution des données est la même pour les deux groupes (EcoIndex et NC)… Ou si elle est différente.
Le test utilisé est le test U de Mann-Whitney aussi appelé test de Wilcoxon. Et d’après ses résultats, on peut dire que la médiane de notre échantillon de sites calédoniens est significativement différente de la médiane des poids de l’ensemble des sites analysés par EcoIndex !
Aïe ! Comme notre médiane est significativement au-dessus du total des sites analysés, on en conclut que nos sites locaux sont globalement plus lourds que ceux de l’extérieur. Et ce n’est pas un effet statistique.. La bonne nouvelle est la suivante : avec un tel résultat, on ne peut que s’améliorer !
Nombre de nœuds
Pour ce qui est du nombre de nœuds, nous sommes bons élèves : nos pages (avec le même test non paramétrique que pour les poids médians) sont significativement moins complexes. Pour autant, avec un nombre moindre de nœuds, nous avons des pages plus lourdes. Mais l’étude des écarts types révèlent que dans l’échantillon calédonien, il y a une très forte variabilité ! Que ce soit pour le poids, la complexité, ou le nombre de requêtes.
Nombre de requêtes
Et pour ce qui est du nombre de requêtes, il est significativement plus élevé dans les pages d’accueil de nos sites web calédoniens. Devons nous en conclure que tous les sites calédoniens sont moins “green” que leurs homologues du reste du monde ? En moyenne on le pourrait mais il faut se méfier des moyennes. La variabilité forte de l’échantillon calédonien révèle tout de même que nous avons des sites web très bien classés et qui se défendent bien au regard des objectifs, pourtant ambitieux, d’EcoIndex. Alors haut les cœurs ! Nous avons des efforts globaux à faire mais la compétence pour faire des sites de qualité est là !
Conclusion à six mains
Ce comparatif ne joue pas en notre faveur. Plus lourds alors que moins complexes, un plus grand nombre de requêtes… les sites calédoniens dans leur ensemble ne sont pas les bons élèves du green IT.
Et au-delà de ce comparatif avec les autres sites, l’objectif à avoir en tête est bien celui proposé par EcoIndex ; à ce titre, seule une très faible proportion de sites passe le test avec succès. Quand il s’agit de performance environnementale, nous n’irons nulle part, collectivement ni individuellement, si notre unique souci est de “ne pas faire pire que les autres”.
Sensibilisons-nous donc au plus tôt aux bonnes pratiques d’écoconception des sites web, et s’il n’est pas possible d’améliorer l’existant dans l’immédiat, engageons-nous à en faire une priorité sur tout nouveau projet !
Xavier Liénart, MSI : expertise green IT, conseil technique notamment sur le choix de l’outil, contribution aux articles
Maeva Leroux : suivi de l’audit et animation de l’équipe, contribution à l’audit, conseil, veille technologique
Thomas Avron, APID : expertise en statistiques, interprétation des résultats, contribution au présent article
Mehdi Hassouni : commanditaire de l’audit dans le cadre de la commission NID du cluster OPEN NC
Le contact Hightest est Zoé Thivet : pilotage de l’audit et de la rédaction des articles, constitution du jeu de données, collecte automatisée des résultats EcoIndex
Et bien sûr un grand merci au Collectif Green IT pour son outil EcoIndex !
Pssst… ce n’est pas fini ! Sur le même échantillon de sites, un audit sera mené prochainement sur l’accessibilité !
Nous en parlions précédemment ; l’écoconception et le green IT de manière générale représentent désormais un aspect crucial lorsqu’on se lance dans la création d’un produit numérique, quel qu’il soit.
En 2024, ces concepts sont encore trop méconnus du grand public (et aussi des personnes qui travaillent dans le secteur informatique !) alors même que ces problématiques concernent tout le monde. Alors comment faire pour que tout le monde se sente réellement concerné ? Notre hypothèse : en donnant des chiffres précis qui permettent d’y voir plus clair ! D’où l’intérêt de lancer un audit sur l’ensemble des sites web de Nouvelle-Calédonie.
Oui, tous les sites web actifs dont l’extension est en « .nc » !
Et dans un premier temps, on va vous dire comment on a procédé pour trouver cette liste de sites !
Avertissement préalable : la page web que vous êtes en train de consulter n’est pas écoconçue. Si lancez une analyse dessus, vous ne trouverez pas un bon résultat. Nous ne nous déchargerons pas du problème en disant que les cordonniers sont les plus mal chaussés ; c’est une problématique que nous avons en tête et qui sera présente lors de la prochaine refonte de notre site web. Fin de la parenthèse ; bonne lecture !
L’origine de cet audit
Pendant quelques mois, notre société Hightest a consacré du temps, à titre bénévole, à une commission nommée NID au sein du Cluster OPEN (Organisation des Professionnels de l’Economie Numérique de Nouvelle-Calédonie). Pourquoi NID ? Pour Numérique Inclusif et Durable, ce qui englobe des questions aussi larges et passionnantes que l’accessibilité, la performance environnementale des sites web, l’accès au numérique au plus grand nombre, ou encore la valorisation du matériel informatique inutilisé. Une opération d’envergure de la commission NID, la Grande Collecte Numérique, a permis par exemple de donner une seconde vie à un grand nombre de PC qui « dormaient » dans nombre d’entreprises (dont Hightest !) ; ces PC sont désormais au service d’associations locales.
Parmi les nombreux projets de cette commission, il existait un souhait de réaliser un audit de performance environnementale des sites web calédoniens. Une mission que nous avons acceptée, en même temps que celle d’auditer l’aspect accessibilité. Nous avions déjà effectué un exercice similaire en 2018 avec ces premiers chiffres sur l’accessibilité des sites calédoniens.
Nous avons pris plaisir à travailler sur ce projet et espérons qu’il permettra de favoriser de meilleures pratiques en termes de performance environnementale des sites web.
Le principal challenge a été de trouver le bon jeu de données, car c’est bien de vouloir faire un audit, mais quels sites analyser ? Etonnamment peut-être, c’est le chantier qui a pris le plus de temps et de réflexion, et qui est retracé dans cet article ; ce qui a suivi a été une part de gâteau.
Critères de sélection des sites à analyser
Pour mener à bien cette sélection de sites, les quelques lignes directrices suivantes ont été respectées :
Analyse de tous les sites dont l’extension est « .nc », avec acceptation du risque qu’une petite partie de ces sites pourraient être des sites non calédoniens
Il a suffi de saisir le xPath « //a[contains(@href, ‘.nc’)] » et de récupérer le texte des résultats. Près de 7000 URLs ont ainsi été récupérées très rapidement.
Ces URLs ont été stockées dans un fichier csv, après avoir été préalablement préfixées par « http:// ».
Vérification des codes de statut HTTP
Cette première liste n’était que notre matière première brute : il s’agissait en effet uniquement de noms de domaines, et non pas des sites web effectivement liés à ces noms de domaines. Il peut arriver qu’une personne ou une organisation achète un nom de domaine et n’en fasse rien. Il n’y a donc pas d’analyse à envisager sur ce genre de donnée vide.
C’est à ce moment que nous avons utilisé un autre outil pour vérifier ces noms de domaines : Postman. Postman est un outil de développement et de test qui permet notamment d’interagir avec des API et d’envoyer des requêtes HTTP à des serveurs pour tester la disponibilité des sites web.
Dans notre cas, c’est ce deuxième usage qui nous a intéressé.
Une requête très simple a été créée dans une nouvelle collection Postman, c’est-à-dire un ensemble organisé de requêtes qui peut être lancé selon des paramètres spécifiques. Cette requête a été programmée pour contrôler les codes de statut HTTP de chacune de ces URL. Ce que l’on recherche, c’est une liste d’URL renvoyant le code 200, qui signifie que l’adresse a pu être atteinte avec succès. Un log d’info a également été ajouté pour pouvoir récupérer facilement le résultat des tests à la fin.
La collection a ensuite été jouée en utilisant, en donnée d’entrée, le fichier des URLs mentionné précédemment. Il n’y a plus qu’à attendre ! Voici à quoi ressemblent les résultats dans la console Postman :
Cela a beaucoup allégé la liste, puisqu’elle est passée de 6908 noms de domaine à un peu moins de 4000.
Mais ce n’est pas fini !
Validation des sites
Tentative 1 : screenshots en folie
Afin d’optimiser les résultats de l’audit, nous souhaitions laisser hors de notre périmètre d’étude les sites en construction. Nous avons donc imaginé une solution automatisée, qui génère un screenshot de chaque page d’accueil et range ce screenshot dans un dossier. Cela avait pour objectif de faciliter la revue des sites, en permettant de visualiser rapidement les screenshots sans avoir à ouvrir un navigateur, attendre que la page charge, etc.
Nous n’aurions peut-être pas eu l’idée d’utiliser JUnit et Selenium pour réaliser ce travail si nous n’étions pas en contact avec ces outils à longueur de journée. Cela peut peut-être donner l’impression que « pour qui possède un marteau, tout ressemble à un clou » ! Mais peu importe ; ce code jetable a bien rempli son usage, et nous avons pu générer les screenshots voulus.
Le dossier de sortie, en train de se remplir de screeenshots :
Est venue ensuite la partie la plus fastidieuse : consulter chaque screenshot afin de dresser la liste finale des URL. Comment faire pour que cette analyse dure le moins de temps possible et surtout ne soit pas un calvaire pour la ou les personnes qui s’en chargent ?
Tentative 2 : affinage de la liste en automatique
Après une première tentative d’analyse à l’œil humain, il est apparu que cela prendrait beaucoup trop de temps ; non seulement parce que la liste était longue, mais aussi parce que beaucoup de screenshots révélaient que le site était en construction (ou tout simplement vide) et qu’il fallait donc l’écarter. Pas question d’infliger ce travail rébarbatif à qui que ce soit !
Il a donc été temps de trouver une solution de « dégrossissement » automatique, qui permette de filtrer davantage ces sites. Qui dit « automatique » dit aussi « moins fin » ; nous courions donc le risque de passer à côté de certains jeux de données légitimes. Tant pis : done is better than perfect.
Voici la nouvelle règle pour la génération des screenshots, inspirée par les conseils de Xavier Liénart (merci à lui !) :
La page web doit contenir au moins une image
La page web doit contenir au moins un lien interne (typiquement : onglet de menu)
La page web ne doit pas contenir certains termes très spécifiques tels que Plesk (le nom d’une interface de gestion de serveurs très répandue, et qui signale de fait que le site est en construction)
Le script Selenium est donc ajusté en fonction :
Après lancement de ce script, le nombre de sites à analyser à considérablement baissé. Nous voilà à présent avec un peu moins de 2400 screenshots. Après analyse d’un échantillon aléatoire de ces screenshots, le résultat est concluant et ne nécessitera pas de nouveau filtre.
Cette liste de sites est donc désormais notre outil de travail, notre précieux !
À ce stade, il n’y avait plus qu’à lancer l’audit sur cette liste de sites, ce dont nous parlerons dans le prochain article. À très bientôt !
L’informatique en Nouvelle-Calédonie est, comme partout, un secteur très dynamique et en constante recherche de nouveaux talents.
Ce qui est dommage, c’est que ce territoire est encore à ce jour assez méconnu, et que beaucoup de personnes passent encore à côté de ce choix de vie pourtant fantastique !
C’est donc avec beaucoup de plaisir que nous avons concocté et animé ce webinar avec Céline Quevilly (Tealforge), Elodie Luz (Atlas Management), Laurent Rivaton (Addo).
L’idée était de faciliter la prise de décision en donnant un maximum d’informations concrètes sur le territoire et son tissu numérique. Nous avons parlé sans tabou aussi bien des bons moments que des éventuelles galères que l’on peut rencontrer en découvrant le territoire.
Vous souhaitez provoquer des discussions de fond sur le thème de la qualité logicielle, entre des personnes qui travaillent ensemble mais n’ont peut-être jamais eu l’occasion d’en parler directement ? Cet atelier est fait pour vous !
Lors de cet atelier, les personnes vont :
Exprimer des représentations, besoins, ressentis et autres visions subjectives de la qualité logicielle
Apprendre à mieux se connaître les unes les autres
Prendre conscience des différences de points de vue, pour mieux travailler ensemble au quotidien
Eventuellement corriger des idées reçues, en bonne intelligence
Avertissement important : c’est un atelier qui est là avant tout pour que les membres d’une équipe se connaissent mieux professionnellement, pas pour juger dans l’absolu « qui a raison » !
Cet atelier n’est pas forcément recommandé aux équipes qui traversent de fortes tensions. Dans tous les cas, sa facilitation nécessite un soin particulier. Votre équipe en ressortira grandie.
Préparation de l’atelier
Pour mener à bien cet atelier en présentiel, il vous faudra :
3 personnes + 1 guide de jeu. S’il y a plus de 3 personnes, compter 3 équipes de N personnes + 1 guide de jeu.
Des cartes « Visions de la qualité », faites maison c’est mieux ! Le principe : chaque carte contient une phrase plus ou moins clivante sur le thème de la qualité logicielle.
Une salle avec une table centrale, pour y poser les cartes « Visions de la qualité »
La posture de guide de jeu
La personne qui endosse le rôle de guide de jeu se prépare à :
Faciliter les échanges en établissant un cadre d’ouverture et de respect
Faire en sorte que la parole soit équitablement répartie
Prendre des notes pendant l’atelier
Faire une synthèse de ce qui a été exprimé pendant l’atelier
Déroulement de l’atelier
Les cartes « Visions de la qualité » sont réparties en tas thématiques au milieu de la table, face cachée.
Lors de la première session, l’équipe 1 pioche une carte sur la pile de son choix et la lit à voix haute. L’équipe se concerte rapidement pour choisir de défendre ou contredire ce qui est écrit, puis se lance. En fonction du temps dont vous disposez, cette prise de parole peut être limitée, à 2 minutes par exemple.
A la fin de ce « plaidoyer », l’équipe 2 doit tenter de défendre l’avis contraire à l’équipe 1.
L’équipe 3 doit ensuite synthétiser le débat et attribuer le point à l’équipe qui, selon elle, a été la plus convaincante.
Pendant tout cet échange, la personne qui endosse le rôle de guide de jeu prend des notes. Elle pourra ensuite envoyer une synthèse des résultats de l’atelier.
Ensuite, ça tourne ! Ainsi, lors de la deuxième session, l’équipe 2 tire une carte et fait son plaidoyer, l’équipe 3 contredit et l’équipe 1 arbitre.
Autant de sessions que de cartes peuvent avoir lieu, mais en pratique les débats peuvent prendre un peu de temps et ce n’est pas forcément possible de tout parcourir en une fois. Pas grave : conservez les paquets de cartes et proposez un nouvel atelier quelques mois plus tard !
Exemples de cartes
Pour confectionner vos carte « Visions de la qualité », vous pouvez noter des phrases que vous avez entendues au fil du temps ; des phrases auxquelles vous adhérez mais aussi des phrases avec lesquelles vous n’êtes pas d’accord. Vous pouvez bien sûr créer d’autres catégories ou remanier celles présentes ci-dessous.
Gestion de projet
« Le test représente souvent un goulet d’étranglement dans un projet. »
« Pour un projet donné, on ira plus vite avec 5 personnes qui développent, plutôt que 4 qui développent et une qui teste. »
« Le test est à un projet ce qu’un complément alimentaire est à un corps humain : sympa, mais pas essentiel. »
« Le nombre de cas de test joués est un bon indicateur de performances. »
« La véritable mission des tests est de prévenir les bugs, plutôt que simplement les trouver. »
Pratiques de test
« Les tests d’une fonctionnalité commencent quand elle a été développée. »
« Il est important de suivre strictement les scénarios de test sans dévier. »
« Les tests sont déduits logiquement des spécifications fonctionnelles. »
« Vérifier et valider, c’est la même chose, ce sont des synonymes. »
« Le test ne peut avoir lieu que si les spécifications sont complètes. »
Rôles et responsabilités
« Comme les devs connaissent bien le produit, ce sont ces personnes qui sont les plus à même de trouver des tests pertinents à faire. »
« Dans un projet agile, c’est à l’équipe de test de rédiger les tests d’acceptation d’une User Story. »
« Dans un esprit d’agilité, c’est plutôt l’équipe de développement qui fait les tests. »
« Les tests fonctionnels sont du ressort du métier, et les tests techniques sont du ressort des profils techniques. »
« L’équipe de test est garante de la qualité logicielle. »
« Pour bien tester, il faut avoir accès à la base de données de l’appli. »
Tech
« Les tests à automatiser sont ceux qui couvrent les fonctionnalités les plus critiques. »
« L’automatisation des tests doit démarrer juste après la première mise en production d’une application donnée. »
« L’objectif premier des tests automatisés est de réduire la durée des campagnes de test. »
« C’est à la fin du projet qu’il est le plus pertinent de procéder à des tests de charge. »
« Les tests manuels deviennent peu à peu obsolètes à l’ère de l’automatisation. »
« Les tests de sécurité constituent un domaine à part et ne concernent pas les profils de test lambda. »
« Une bonne qualité de code suffit à éliminer la plupart des bugs. »
Bonne session de jeu ! Envoyez-nous votre feedback, et aussi si vous le souhaitez, les phrases que vous avez rajoutées !
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 »).
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.
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.
Vous testez un logiciel contenant un formulaire qui demande de saisir un RIB ? Voici quelques éléments pour vous aider !
Les différentes parties d’un RIB
Un RIB se compose de 23 caractères répartis en 4 éléments :
Le code banque (5 chiffres)
Le code guichet (5 chiffres)
Le numéro de compte (11 chiffres et/ou lettres)
La clé RIB (2 chiffres)
Peut-on « inventer » un RIB ?
Oui et non.
Non, parce qu’on ne peut pas « imaginer » un RIB de tête, parce que la clé RIB doit être le résultat d’un calcul que vous ne ferez pas facilement de tête !
Oui, parce qu’il n’y a pas besoin que le RIB existe « dans la vraie vie » pour valider le formulaire de saisie.
Tout est donc dans la clé RIB.
Quelques exemples de RIB et IBAN fictifs et bien formés
Ces RIB sont destinés à réaliser des tests passants de validation de RIB. N’effectuez pas de transactions en utilisant ces RIB et IBAN. Si vous devez effectuer des tests de virements réels, constituez votre propre jeu de données en bonne intelligence avec le reste de votre équipe.
Faux RIB avec le code banque de la BCI (Banque Calédonienne d’Investissement) : 17499 12345 12345678901 53
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
Un historique des défauts trouvés pendant les tests est maintenu : 73 % oui / 16 % parfois
Une personne est désignée en tant que responsable du processus de test : 65 % oui / 13 % parfois
Un plan de test décrivant les objectifs / l’approche est requis : 61 % oui / 29 % parfois
Le test est une activité systématique et organisée : 61 % oui / 30 % parfois
Des profils de test réalisent des tests système à temps plein : 62 % oui / 19 % parfois
Le test est séparé du développement : 60 % oui / 20 % parfois
Les tests doivent être rejoués lorsque le logiciel change : 51 % oui / 35 % parfois
Les tests sont conservés et maintenus en vue d’une utilisation ultérieure : 51 % oui / 28 % parfois
Les spécifications et la conception des tests est documentée : 48 % oui / 36 % parfois
La procédure de test est documentée dans le manuel des standards : 45 % oui / 15 % parfois
Un historique des tests joués est maintenu : 42 % oui / 35 % parfois
Le temps consacré aux test est suivi : 40 % oui / 30 % parfois
Les documents de test font l’objet d’une revue par les pairs formelle : 31 % oui / 29 % parfois
Des profils de test réalisent des tests d’intégration à temps plein : 24 % oui / 24 % parfois
Les coûts des tests sont mesurés et suivis : 24 % oui / 19 % parfois
Des formations en test sont fournies périodiquement : 22 % oui / 26 % parfois
Les résultats des tests font l’objet d’une revue par les pairs formelle : 20 % oui / 31 % parfois
Les utilisateurs et utilisatrices ont une forte implication dans les activités de test : 8 % oui / 39 % parfois
Les tests sont créés avant le développement : 8 % oui / 29 % parfois
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 ! 😃
Venir travailler en Nouvelle-Calédonie, quand on vit à l’autre bout du monde, ce n’est pas une petite décision.
Chez Hightest, la majorité d’entre nous vivait en France hexagonale avant d’intégrer l’équipe. Nous connaissons donc les différentes questions et dilemmes qui s’imposent quand on se projette dans cette nouvelle vie. Et c’est pour cette raison que nous créons des contenus pour aider à mieux appréhender le quotidien dans ce bel archipel !
Nous vous proposons un webinar tout neuf, daté de juillet 2023, qui vous permettra d’en savoir davantage sur notre quotidien de QA. Sous forme de questions/réponses avec Jean-François Fresi, cette intervention a permis également de répondre à des questions posées en live.
Merci à Werin Group qui nous a offert cette opportunité !
Webinar 2020
Un peu plus vintage, nous vous proposons également de visionner ce webinar plus généraliste que nous avons proposé en 2020 avec Laurent Marchois (Atlas Management) et Vincent Lavergne (Tealforge). Nous y évoquions en détails pas mal d’aspects de la vie calédonienne et du monde de l’IT calédonien. Certains passages ne sont plus d’actualité (nous parlions notamment du Covid !), mais la plupart des éléments restent valides.
Astuce : utiliser les timestamps (présents dans le premier commentaire) afin de naviguer vers les passages qui vous intéressent le plus !
Article de 2020
Nous vous proposons également de vous plonger dans cet article de 2020, où nous racontions notre quotidien de QA un peu plus en détail.
Bon visionnage, bonne lecture… et bonne réflexion ! 🙂🌴
Et si vous souhaitez obtenir davantage d’informations, nous vous invitons à laisser un commentaire ou à nous contacter directement sur LinkedIn.
___
Crédit image : Midjourney
On vous partage
notre expertise !
Abonnez-vous à notre newsletter pour suivre toute l’actualité du test !