Comment dépanner ou tester efficacement un nouveau code lorsque la configuration matérielle pour reproduire les bogues est difficile ou impossible à obtenir?

Je travaille dans une entreprise de taille moyenne (150 employés, environ 10 ingénieurs) et la plupart de mes projets consistent à interfacer avec des équipements de laboratoire (oscilloscopes, analyseurs de spectre optique, etc.) à des fins d'applications de test semi-automatisées. J'ai rencontré plusieurs scénarios différents où je ne suis pas en mesure de dépanner ou de tester efficacement le nouveau code car je n'ai plus ou jamais la configuration matérielle à ma disposition.

Exemple 1: une configuration dans laquelle 10 à 20 processus de «rodage» sont exécutés indépendamment à l'aide d'un capteur de type de paillasse - j'ai pu obtenir un tel capteur pour les tests et je pouvais parfois en voler une seconde pour simuler toutes les facettes de l'interface avec plusieurs appareils (recherche, connexion, streaming, etc.).

Finalement, un bug est apparu (et s'est finalement retrouvé dans le firmware et les pilotes du périphérique) qui était très difficile à reproduire avec précision avec une seule unité, mais a atteint des niveaux proches de "show stopper" lorsque 10-20 de ces périphériques étaient utilisés simultanément. Ceci n'est toujours pas résolu et est en cours.

Exemple 2: Un test nécessitant un analyseur de spectre optique coûteux comme composant central. L'appareil est assez ancien, hérité selon le fabricant qui a été acquis par une grande entreprise et essentiellement dissous, et sa seule documentation était un document de longue haleine (et non informatif) qui semble mal traduit. Au cours du développement initial, j'ai pu garder l'appareil à mon bureau, mais maintenant il est immobilisé, à la fois physiquement et dans les délais lors de ses tests de 24 semaines sur 7.

Lorsque des bogues apparaissent liés ou non à l'appareil, je dois souvent passer par la difficulté de tester le code externe à l'application et de l'adapter, ou d'écrire du code à l'aveugle et d'essayer de réduire le temps de test entre les exécutions, autant de la logique du programme nécessite que l'OSA et le reste du matériel de test soient en place.

Je suppose que ma question est de savoir comment dois-je aborder cela? Je pourrais potentiellement passer du temps à développer des simulateurs de périphériques, mais comprendre que dans l'estimation du développement le montera en ballon plus que la plupart ne l'apprécieraient probablement. Il peut ne pas reproduire tous les problèmes avec précision non plus, et il est assez rare de voir le même équipement utilisé deux fois ici. Je pourrais m'améliorer dans les tests unitaires ... etc ... Je pourrais aussi être bruyant sur le problème et faire comprendre aux autres que des retards temporaires seront nécessaires, pas beaucoup plus qu'un mal de tête pour la recherche et le développement mais généralement perçu comme une blague lorsqu'il est présenté à la fabrication.

La direction comprend que le développement et la maintenance de logiciels prendront plus de temps lorsque vous n’avez pas un accès complet au matériel de test. Vous devez en tenir compte lors de vos estimations. Une partie des critères d'acceptation pour la mise en production de votre logiciel doit être que vous avez un moyen de maintenir le logiciel dans la plupart des circonstances sans arrêter la fabrication. Si vous pratiquez le TDD, cela devrait se produire assez naturellement.

J'avais l'habitude d'écrire des logiciels pour des avions de 60 millions de dollars. De toute évidence, un degré élevé de fiabilité est requis et ils hésitent à donner à chaque développeur un pour leur bureau. Nous avions essentiellement 5 niveaux d'environnements de test, avec plus de matériel réel à chaque niveau, jusqu'à un avion complet. J'estime que 95% de nos logiciels pourraient être développés et débogués uniquement avec des émulateurs et des tests unitaires. 95% des fonctionnalités restantes pourraient être travaillées au niveau supérieur suivant, et ainsi de suite.

Essayez de configurer vous-même des niveaux d'environnements de test similaires. Vous ne pouvez pas vous attendre à ne jamais avoir besoin d'accéder au vrai matériel, mais si vous l'avez configuré pour ne pas pouvoir travailler sur l'interface graphique de votre logiciel sans le matériel disponible, vous perdez un temps précieux sur une ressource coûteuse (pas pour mentionner que vous avez des problèmes de couplage avec votre architecture). Considérez que d'autres développeurs ont probablement les mêmes problèmes que vous. Je demanderais au fournisseur de matériel s'il a déjà des émulateurs ou d'autres ressources de test disponibles.

Vous devez également changer quelque peu votre état d'esprit si vous n'avez qu'un accès limité au matériel. Plutôt que d'essayer de déboguer votre application de la manière série normale, vous devez souvent écrire du code spécifiquement dans le but de recueillir des informations le plus rapidement possible.

Par exemple, vous avez peut-être un bug et vous pouvez penser à 10 causes possibles. Si le seul temps que vous pouvez obtenir sur une machine est les 15 minutes pendant que l'opérateur est en pause, écrivez un court, autonome, correct (compilable), exemple qui déclenche le bogue et écrivez 10 tests automatisés en utilisant ce SSCCE pour tester vos théories et enregistrez un tas de données. De retour à votre bureau, vous pouvez prendre le temps nécessaire pour parcourir les données pour votre prochaine tentative. L'idée est de maximiser l'utilité de votre temps limité avec le matériel.

Vous essayez de résoudre un problème qui n'est pas le vôtre.

La direction doit prioriser l'accès à l'équipement. Cela peut signifier que vous vous retrouvez avec un meilleur accès, mais cela peut également signifier que vous vous retrouvez avec moins.

Présentez les défis que vous avez dans un format objectif à votre équipe de direction et demandez-leur des conseils. Votre présentation serait beaucoup plus forte si vous collaboriez avec les autres personnes qui ont également besoin d'un accès, afin que vous puissiez tous présenter votre cas en même temps.

À partir de là, l'entreprise (la direction) doit prioriser qui a accès et quand. C'est une décision commerciale qu'ils doivent prendre car le (manque) de disponibilité des ressources a un impact sur le développement des affaires.

Vous codez effectivement en aveugle.

Si la direction ne paie pas pour les appareils de test, il y a une forte probabilité de bugs, ou même le développement prend plus de temps que si vous aviez de vrais appareils à utiliser.

Le coût des appareils n'a pas besoin d'être entièrement alloué au cycle de "développement". Peut-être qu'ils pourraient être tournés vers une utilisation en production, ou comme sauvegarde. Pourraient-ils même être revendus ailleurs?

Essayez et chiffrez les phases de correction de bogues, en temps et en argent, et montrez le coût global à votre équipe / entreprise.

Se disputer avec vos patrons est beaucoup plus facile lorsque vous avez des chiffres, ou au moins quelques avantages et inconvénients à portée de main, donc ma suggestion essaie de faire une analyse des coûts par rapport aux avantages. L'idée approximative se présente comme suit:

• combien d'efforts de développement attendez-vous pour écrire un simulateur de périphérique? (Notez qu'un simulateur de périphérique ne peut pas remplacer le matériel d'origine à 100%, en particulier lorsque le matériel présente des bizarreries inattendues).

• combien de tests / débogage attendez-vous sans un tel outil? Incluez les coûts pour vos employés de laboratoire, car vous devez bloquer le matériel à des fins de test. Incluez également les coûts pour le temps pendant lequel le système ne peut pas être utilisé en raison de bogues et vous avez du mal à trouver la cause première.

• combien coûtera du matériel supplémentaire pour les tests?

• combien de temps pensez-vous avoir besoin de bloquer le matériel à des fins de test?

Bien sûr, la réalité n'est peut-être pas aussi simple, et il y a beaucoup de variables inconnues dans cette équation, mais essayez de faire des estimations et si vous n'êtes pas sûr, demandez à d'autres personnes de votre environnement.

Présentez les résultats à votre direction, discutez des alternatives et laissez-les décider.