Tous les articles
REX: Quand un QA crée son propre copilote – Nicolas Trzcinski
Je tiens tout d’abord à remercier chaleureusement Marc Hage Chahine pour le temps qu’il m’a accordé afin que je lui présente QAlityOS, ainsi que pour l’opportunité de m’exprimer sur la Taverne du Testeur. C’est un véritable honneur. Je suis consultant QA, actuellement en mission dans un grand groupe audiovisuel français. Sur mon temps libre, j’ai voulu créer l’outil qui me manquait au quotidien : un couteau suisse pour le QA qui travaille avec Jira et Xray. Une situation que vous connaissez sûrement Vendredi soir. La release est prête. Le plan de test est monté, les exécutions sont créées, les cas de
Partitions d’équivalence VS tables de décisions VS transition d’état
Dans l’ISTQB on parle de partitions d’équivalence, tables de décisions et transition d’état comme techniques pour définir un périmètre de test. Certains testeurs utilisent une de ces techniques, d’autres plusieurs ou aucune. Qui a raison, quel est la meilleure technique ? Partitions d’équivalence Une partition d’équivalence est définie pour toutes les valeurs d’une donnée qui engendrent le même résultat attendu. En dessous de 18 ans on ne peut pas souscrire, au-dessus on peut, il y a donc deux partitions d’équivalence et donc 2 tests à faire (hors tests aux limites, qui sont une sous partie des partitions). Cette technique de test est
L’IA peut générer des tests, mais peut-elle garantir leur fiabilité ? – Audrey Moulins
L’organisation Product & Tech du Boncoin repose sur des Feature Teams mixtes, chacune dédiée à des domaines fonctionnels précis. Au sein de la Feature Team Homepage & Reco, nous gérons l’intégralité de la chaîne, du front-end au Machine Learning, pour proposer des recommandations pertinentes. Ces modules suggèrent des contenus ou des annonces aux utilisateurs à des moments clés : sur la page d’accueil, lors de la consultation d’une annonce ou via la recherche par image. C’est sur ce périmètre que nous avons voulu construire une première base de tests de non-régression sur des parcours web critiques. L’objectif était de sécuriser certains
Accessibilité/RGAA : Tester le contraste, ou ne pas croire (que) ce que l’on voit
Pour tester l’accessibilité, on se base sur des référentiels comme les WCAG (Web Content Accessibility Guidelines) du W3C ou le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) applicable en France (voir à ce sujet l’article de Marc Hage Chahine). Parmi les vérifications, ils prescrivent entre autres de vérifier le contraste entre le premier plan (le texte, les objets graphiques et les éléments UI) et l’arrière-plan (le fond sur lequel ils s’affichent), pour garantir leur visibilité par tous, même dans des conditions dégradées. Ces tests, les sites n’affichant que des éléments noirs sur fond blanc (ou l’inverse) les passent haut la main. Cependant,
Présentation du RGAA
Introduction Vous avez sûrement déjà entendu parler d’accessibilité numérique. Cela peut être à travers des articles de la taverne, ce webinaire de 2023 ou toute autre source comme des conférences ou des articles de médias. Au delà d’une importance de principe pour garantir un accès au plus grand nombre (dans un contexte aussi large que possible) au service numérique, le monde de l’accessibilité est structuré. La principale référence est le WCAG qui propose des règles priorisées. Le WCAG est un référentiel reconnu internationalement… qui n’est évidemment pas contraignant. Ce n’est pas le cas du RGAA pour Référentiel Général d’Amélioration de l’Accessibilité