私は中規模の会社(従業員数150人、10人程度のエンジニアリングチーム)で働いており、ほとんどのプロジェクトは半自動テストアプリケーションのためにラボ機器(オシロスコープ、光スペクトラムアナライザーなど)とのインターフェースを含みます。ハードウェアセットアップを利用できなくなった、または利用できなかったために、新しいコードを効率的にトラブルシューティングまたはテストできないいくつかの異なるシナリオに遭遇しました。
例1:ベンチトップタイプのセンサーを使用して10〜20の「バーンイン」プロセスが独立して実行される設定-テスト用にそのようなセンサーを1つ取得でき、シミュレーション用に1秒盗むこともありました複数のデバイスとのインターフェース(検索、接続、ストリーミングなど)のすべての側面。
最終的に1つのユニットだけでは正確に再現することが非常に困難でしたが、最終的にデバイスのファームウェアとドライバーにバグが現れましたが、これらのデバイスが10〜20個同時に使用されていると、「ショーストッパー」レベルに近づきました。これはまだ解決されておらず、進行中です。
例2:コアコンポーネントとして高価な光スペクトルアナライザを必要とするテスト。このデバイスはかなり古いものであり、大企業に買収されて基本的に解散したというメーカーの遺産であり、その唯一の文書は翻訳が不十分であるように思われる長い(そして有益ではない)文書でした。最初の開発中はデバイスを机に置いておくことができましたが、現在は24時間年中無休の数週間のテスト中に、物理的にもスケジュールどおりに縛られています。
バグがデバイスに関連するかどうかに関係なく表示される場合、アプリケーションの外部でコードをテストしてそれを組み込む問題、またはコードを盲目的に記述し、実行と実行の間のあるテスト時間で絞ろうとする問題を経験する必要があります。プログラムロジックでは、OSAと残りのテストハードウェアを配置する必要があります。
私の質問はこれにどのように取り組むべきかと思いますか?デバイスシミュレータの開発に潜在的に時間を費やす可能性がありますが、開発見積もりに理解すると、それ以上に膨らみますほとんどはおそらく感謝します。また、すべての問題を正確に再現することはできません。また、ここで同じ機器が2回使用されているのを見るのは非常にまれです。単体テストの方が上手くなります...など...問題について大声で話し、一時的な遅延が必要になることを他の人に理解させることもできます。研究開発の頭痛の種だけではなく、通常は冗談として認識されます製造業に売り込むとき。
管理者は、テストハードウェアに完全にアクセスできない場合、ソフトウェアの開発と保守に時間がかかることを理解しています。見積もりを行うときは、これを考慮する必要があります。ソフトウェアを量産するための受け入れ基準の一部は、製造を停止せずにほとんどの状況でソフトウェアを維持する方法があることです。 TDDを実践している場合、これは自然に起こるはずです。
私はかつて6000万ドルの航空機用のソフトウェアを作成していました。明らかに、必要な高度の信頼性があり、彼らはすべての開発者に自分のデスクのために与えることには消極的です。基本的に5つのレベルのテスト環境があり、実際のハードウェアは各レベルで、航空機全体までありました。私のソフトウェアの95%は、エミュレーターと単体テストでのみ開発およびデバッグできたと思います。残りの機能の95%は、次のレベルで作業できます。
同様のレベルのテスト環境を自分でセットアップしてみてください。実際のハードウェアにアクセスする必要がないと期待することはできませんが、ハードウェアを使用せずにソフトウェアのGUIで作業できないように設定した場合、高価なリソースに貴重な時間を費やしています(あなたのアーキテクチャといくつかのカップリングの問題があることに言及してください)。他の開発者があなたと同じ問題を抱えている可能性が高いと考えてください。ハードウェアベンダーに、すでにエミュレーターやその他のテストリソースが利用可能かどうか尋ねます。
また、ハードウェアへのアクセスが制限されている場合は、考え方を多少変える必要があります。通常のシリアル方式でアプリケーションをデバッグしようとするのではなく、できるだけ迅速に情報を収集することを目的として、特にコードを記述する必要があることがよくあります。
たとえば、おそらくバグがあり、10の考えられる原因を考えることができます。オペレーターが休憩中にマシンに乗れる唯一の時間が15分である場合、バグをトリガーして10個の自動テストを作成する Short、Self Contained、Correct(Compilable)、Example と記述します。そのSSCCEを使用して理論をテストし、大量のデータを記録します。その後、デスクに戻って、次の試行のためにデータをふるいにかける必要がある限り、時間がかかることがあります。アイデアは、ハードウェアで限られた時間のユーティリティを最大化することです。
あなたが解決すべき問題ではない問題を解決しようとしています。
管理者は、機器へのアクセスを優先する必要があります。それはあなたがより多くのアクセスで終わることを意味するかもしれませんが、それはあなたがより少なくなることを意味するかもしれません。
直面している課題を客観的な形式で経営陣に提示し、指導を求めます。あなたもアクセスを必要とする他の人たちとコラボレーションした場合、あなたのプレゼンテーションはより強力になるでしょう。そのため、あなたの全員が同時にあなたのケースを提示することができます。
そこから、会社(経営陣)は誰がいつアクセスできるかを優先する必要があります。リソースの可用性(の欠如)がビジネス開発に影響を与えているため、彼らはビジネス上の決定を下す必要があります。
あなたは効果的にブラインドをコーディングしています。
管理者がテストデバイスの代金を払わない場合、バグの可能性が高いか、実際のデバイスを使用する場合よりも開発に時間がかかる可能性があります。
デバイスのコストを「開発」サイクルに完全に割り当てる必要はありません。たぶん、それらは本番用にローテーションしたり、バックアップとして使用したりできます。彼らは別の場所で中古品を転売することさえできますか?
時間とお金の両方でバグ修正フェーズを試してコストをかけ、チーム/会社に全体的なコストを示します。
いくつかの数値、または少なくともいくつかの長所と短所が手元にある場合、上司との議論ははるかに簡単です。そのため、私の提案は、費用対利益分析を行うことです。大まかなアイデアは次のようになります。
デバイスシミュレータを作成するためにどのくらいの開発努力を期待しますか? (特に、ハードウェアに予期しない癖がある場合、デバイスシミュレータは元のハードウェアを100%置き換えることができないことに注意してください)。
そのようなツールがなければ、どのくらいのテスト/デバッグ作業を期待できますか?テスト目的でハードウェアをブロックする必要があるため、ラボワーカーのコストを含めます。バグのためにシステムを使用できず、根本的な原因を見つけるのに苦労したときのコストも含めます。
テストのための追加のハードウェアはいくらですか?
テスト目的でハードウェアをブロックする必要があると予想される時間はどれくらいですか。
もちろん、現実はそれほど単純ではない可能性があり、この方程式には未知の変数がたくさんありますが、いくつかの推定を行って、どこがわからないかを確認し、環境内の他の人に尋ねてください。
結果を経営陣に提示し、代替案について話し合い、決定を任せます。