バグを再現するためのハードウェアのセットアップが入手困難または不可能な場合に、新しいコードを効率的にトラブルシューティングまたはテストする方法は？

私は中規模の会社（従業員150人、エンジニアリングチーム10人まで）で働いており、私のプロジェクトのほとんどは、半自動化されたテストアプリケーションを目的として、実験装置（オシロスコープ、光スペクトラムアナライザーなど）とのインターフェイスを含んでいます。ハードウェアのセットアップが利用できなくなった、または利用できなかったために、新しいコードを効率的にトラブルシューティングまたはテストできないいくつかの異なるシナリオに遭遇しました。

例1：ベンチトップタイプのセンサーを使用して10〜20の「バーンイン」プロセスを個別に実行するセットアップ-テスト用にこのようなセンサーを1つ取得でき、ときどきインターフェイスのすべての面をシミュレートするために1つを盗むことができました複数のデバイス（検索、接続、ストリーミングなど）。

最終的にはバグが発生し（最終的にはデバイスファームウェアとドライバーに存在する）、1つのユニットだけで正確に再現するのは非常に困難でしたが、これらのデバイスを10〜20個同時に使用すると「ショーストッパー」レベルに近づきました。これはまだ解決されておらず、継続中です。

例2：コアコンポーネントとして高価な光スペクトルアナライザーを必要とするテスト。このデバイスはかなり古いものであり、大企業に買収されて基本的に解体されたメーカーによると、その唯一のドキュメントは翻訳が不十分であると思われる長巻の（そして情報価値のない）ドキュメントでした。最初の開発中、私はデバイスを自分の机に置いておくことができましたが、物理的にもスケジュールどおりにも、24時間年中無休の複数週間のテスト中に縛られました。

デバイスに関連する、または関連しないバグが表示される場合、アプリケーションの外部でコードをテストして適合させるか、コードを盲目的に書いて実行と実行の間にあるテスト時間で絞り込もうとする問題をしばしば経験する必要があります。プログラムロジックでは、OSAと残りのテストハードウェアが適切に配置されている必要があります。

私の質問は、これにどのようにアプローチする必要があるのでしょうか？デバイスシミュレーターの開発に時間を費やす可能性がありますが、それを開発の見積もりに組み込むと、ほとんどの人が期待する以上に膨れ上がります。すべての問題を正確に再現できるとは限りません。また、ここで同じ機器を2回使用することはほとんどありません。ユニットテストなどで上達することができます...私はまた、問題について大声で話し、一時的な遅延が必要であることを他の人に理解させることができます。これは、研究開発の頭痛だけでなく、通常は冗談として認識されます製造業に売り込まれたとき。

管理者は、テストハードウェアに完全にアクセスできない場合、ソフトウェアの開発と保守に時間がかかることを理解しています。見積もりを行う際には、これを考慮する必要があります。ソフトウェアを実稼働環境に置くための受け入れ基準の一部は、製造を停止することなく、ほとんどの状況でソフトウェアを維持する方法があることです。TDDを実践している場合、これはほとんど自然に起こるはずです。

私はかつて6,000万ドルの航空機用のソフトウェアを書いていました。明らかに、高度な信頼性が必要であり、すべての開発者に自分のデスクに1つを提供することに消極的です。基本的に5つのレベルのテスト環境があり、各レベルには実際のハードウェアがいっぱいで、完全な航空機までありました。私たちのソフトウェアの95％は、エミュレーターと単体テストでのみ開発およびデバッグできると推定しています。残りの機能の95％は、次のレベルで機能する可能性があります。

同様のレベルのテスト環境を自分で設定してみてください。実際のハードウェアへのアクセスが必要になることは期待できませんが、ハードウェアが利用できないとソフトウェアのGUIで作業できないようにセットアップすると、高価なリソースで貴重な時間を無駄にします（アーキテクチャとのカップリングの問題があることに言及してください）。他の開発者があなたと同じ問題を抱えている可能性が高いことを考慮してください。ハードウェアベンダーにエミュレータまたは他の利用可能なテストリソースがあるかどうかを尋ねます。

また、ハードウェアへのアクセスが制限されている場合は、考え方を多少変更する必要があります。通常のシリアル方式でアプリケーションをデバッグしようとするのではなく、できるだけ早く情報を収集するためのコードを記述する必要があります。

たとえば、おそらくバグがあり、10の原因が考えられます。オペレーターが休憩中に15分間しかマシンに乗れない場合は、バグをトリガーする短い、自己完結、正しい（コンパイル可能）の例を記述し、そのSSCCEを使用して理論をテストする10の自動テストを記述します大量のデータを記録します。その後、デスクに戻って、次の試行のためにデータを選別する必要がある限り、時間をかけることができます。アイデアは、ハードウェアで限られた時間のユーティリティを最大化することです。

あなたは解決すべき問題ではない問題を解決しようとしています。

管理者は、機器へのアクセスを優先する必要があります。それはあなたがより多くのアクセスを得られることを意味するかもしれませんが、あなたはより少ないアクセスで終わることを意味するかもしれません。

経営陣に客観的な形式で課題を提示し、指導を求めます。アクセスが必要な他のユーザーと共同作業を行うと、プレゼンテーションがより強力になるため、全員が同時にケースを提示できます。

そこから、会社（経営陣）は誰がいつアクセスするかを優先する必要があります。リソースの可用性（不足）がビジネス開発に影響を与えているため、彼らが行う必要があるのはビジネス上の決定です。

ブラインドを効果的にコーディングしています。

管理者がテストデバイスの費用を支払わない場合、バグが発生する可能性が高くなり、実際のデバイスを使用する場合よりも開発に時間がかかる可能性があります。

デバイスのコストを「開発」サイクルに完全に割り当てる必要はありません。たぶん、それらは本番用に、またはバックアップとしてローテーションできます。他の場所で中古品を転売することさえできますか？

バグ修正フェーズを時間とお金の両方で試してコストをかけ、チーム/会社に全体的なコストを示します。

いくつかの数字、または少なくともいくつかの長所と短所が手元にある場合、上司との議論ははるかに簡単なので、私の提案はコスト対利益分析をしようとしています。大まかなアイデアは次のようになります。

• デバイスシミュレータを作成するために、どのくらいの開発作業が期待されますか （特にハードウェアに予期しない癖がある場合、デバイスシミュレータは元のハードウェアを100％置き換えることができないことに注意してください）。

• そのようなツールなしでどれだけのテスト/デバッグ作業を期待しますか？テスト目的でハードウェアをブロックする必要があるため、ラボワーカーの費用を含めてください。また、バグのためにシステムを使用できず、根本原因を見つけるのに苦労する時間のコストも含めてください。

• テスト用の追加ハードウェアはいくらですか？

• テスト目的でハードウェアをブロックするのにどれくらいの時間がかかると予想していますか？

もちろん、現実はそれほど単純ではないかもしれず、この方程式には多くの未知の変数がありますが、いくつかの推定を行い、どこが不確かなのか、環境から他の人に尋ねてください。

結果を経営陣に提示し、代替案について話し合ってから決定させます。