Je fais de l'AQ sur un grand code commercial, ce scénario irritant revient trop souvent. Habituellement, cela indique qu'il n'y a pas de procédures à toute épreuve pour la construction du binaire sur toutes les plates-formes que nous prenons en charge. Donc, si le développeur crée son propre code (qu'il doit faire pour déboguer et corriger), et ne suit pas la même procédure de construction à la lettre, il y a une chance que les bogues dépendants du système semblent disparaître comme par magie (ou apparaître) . Bien sûr, ces choses sont généralement fermées avec "fonctionne pour moi" dans la base de données de bogues, et si elles échouent la prochaine fois que ce problème est exécuté, le bogue peut être rouvert. Chaque fois que je soupçonne qu'un bogue peut dépendre du système, j'essaie de le tester sur diverses plates-formes et de signaler dans quelles conditions il se produit. Souvent, un problème de corruption de mémoire apparaît uniquement si les données corrompues sont suffisamment importantes pour provoquer un crash. Certaines plates-formes (combinaisons HW et OS) peuvent se bloquer plus près de la source réelle de la corruption, ce qui peut être très précieux pour le pauvre gars qui doit la déboguer.
Le testeur doit apporter une valeur ajoutée, au-delà du simple fait de signaler que son système présente une défaillance. Je passe beaucoup de temps à éliminer les faux positifs - peut-être que la plate-forme en question était surchargée ou que le réseau avait un problème. Et oui, parfois, vous pouvez obtenir quelque chose qui est vraiment affecté par des événements de synchronisation aléatoires, les bogues matériels peuvent souvent être comme un exemple de proto: si deux demandes de données reviennent exactement à la même période d'horloge et que la logique matérielle pour gérer le conflit potentiel est défectueuse, alors le bogue n'apparaîtra que par intermittence. De même avec le traitement parallèle, à moins que, par une conception soignée, vous n'ayez contraint la solution à être indépendante du processeur qui s'est avéré être le plus rapide, vous pouvez obtenir des bogues qui ne se produisent qu'une seule fois dans une lune bleue, et leur imporbabilité statistique fait du débogage un cauchemar.
De plus, notre code est mis à jour, généralement plusieurs fois par jour, le suivi d'un numéro de révision de code source exact pour quand il est allé vers le sud peut être des informations très utiles pour l'effort de débogage. Le testeur ne doit pas être dans une relation contradictoire avec les débogueurs et les développeurs, il est là au sein d'une équipe pour améliorer la qualité du produit.