デバイスの複雑さが増すにつれて、製品を速やかに市場に投入しなければならないというテストチームへの時間的制約が強まっており、最適化されたテスト戦略がこれまで以上に重要になっています。テストエンジニアは、従来のテスタを維持しながら後続の製品のテスタを構築するという困難な作業に取り組んでいます。このホワイトペーパーでは、テストエンジニアが直面している重要な課題を探り、テストフレームワークがそうした課題にどのように応え、生産性の向上、リワークの削減、保守の削減をもたらすのかについて説明します。また、テストフレームワークを構築および維持するための市販ソリューションとしてNI TestStandを紹介し、さらにリスクの軽減、柔軟な開発、機能の実装というメリットをもたらすことを示します。
正常に動作する製品をエンドカスタマーに提供することは、テストエンジニアの優先課題の1つです。しかし、製品の複雑さが増すにつれて、そのテストも複雑になっています。たとえば、照明について考えてみましょう。スマート照明にはWi-FiやBluetoothの機能が組み込まれていて、スピーカーを搭載したものもあります。つまり、ここ数年の間に、テストチームにはパワーエレクトロニクス、ワイヤレス接続、音響のテストが追加されたことになります。
図1: 製品機能の高度化によって、開発にかかる期間が長くなり、テスト開発に割くことのできる時間が短くなっています。
図1は、各段階で計画される時間と実際に費やされる時間との違いを示しています。納期は変わらないため、初期の段階での遅れはテスト開発時間の切り詰めにつながり、テストエンジニアは、より短い時間でより多くの機能をテストするよう求められます。テスト開発段階の時間が切り詰められると、テストエンジニアは先を見越した対応ではなく受け身の対応を強いられます。こうした事態に効率的に対応するためのアプローチを検討する時間は、彼らにはありません。
より短時間でより多くのテストを行うという傾向は何年も前から見られますが、こうした受け身の開発で生じるコストはすぐには明らかにならないために見過ごされがちです。受け身の開発で生じる大きなデメリットの1つは、柔軟性の欠如につながることです。テストエンジニアは、肥大化した厳格なテスタに機能を追加する方法を見つけるのに時間を奪われ、そのことが生産性の低下につながるおそれがあります。ある時点に達すると、同じテスタで構築を続けることが非効率になり、エンジニアは構築を最初からやり直さざるをえなくなって、以前と同じ機能を再構築する時間を無駄に費やすことになります。
その結果、大量のリワークが生じるだけでなく、保守を必要とするテスタの数も増加します。保守段階においては、特にテスタの構築を担当したエンジニアが適切なドキュメント化を行わずに会社を辞めた場合に、保守にありがちな一連の課題が生じます。彼らの離脱はシステム全体の再構築を招くおそれもあります。
このような受け身の悪循環から脱却する方法の1つが、テストフレームワークの構築です。テストフレームワークとは、自動化されたテストシーケンスでの開発、実行、デプロイ、レポート作成に使用する高レベルのソフトウェアアプリケーションのことです。
図2: NIのお客様が組織へのTestStandの導入で節減した時間の割合。
詳細については、構築か購入かを決める際のガイドを参照してください。
組織でこうしたフレームワークを活用すれば、開発時間を最大75%、保守に費やされる時間を67%、減らすことができます。
テスタをいくつか眺めてみると、共通の要素と独自の要素があることがわかります。これらの共通の要素がわかれば、テスト組織にとって再利用モデルの基盤となります。たとえば、ほとんどのテスタにはユーザインタフェースが必要ですが、ユーザの好みや能力に応じたインタフェースを用意する必要があります。
共通の要素:
テスト管理ソフトウェア
独自の要素:
テスト開発ソフトウェア
リスト1テスタにおける共通の要素と独自の要素の具体例
テストシステムの再構築から脱却するためには、すべての共通の要素を特定してそれらをフレームワークに組み込み、すべてのテスタで再利用できるようにする必要があります。フレームワークは共通の要素のサポートに不可欠ですが、それだけではなく、現在と将来にわたって独自の要素をサポートできるほどの十分な柔軟性を備えている必要もあります。
すべてのテストチームが1つのテストフレームワークで標準化されれば、チーム間でのコードの共有がより簡単にできるようになります。共有は、共通の要素について有効なだけでなく、独自の要素についても有効です。
図3: ボードの3種類のバリエーション。大きな違いとして、2つ目のボードにBluetooth機能が追加され、3つ目のボードにWi-Fi機能が追加されています。
たとえば、図3では3種類のボードのバリエーションを示しています。2つ目と3つ目のボードの追加機能は数年後に追加される可能性がありますが、ボードの基本的なテスト方法は変わりません。テスト組織が受け身であると、同じ基本的なテストシステムの開発を3回行う可能性があります。そのようなアプローチでは、初期投資のテスタのコストが増大し、長期的には保守コストにも影響します。
エンジニアが自分の職能に最もふさわしい作業に時間を費やしているとき、生産性は最大になります。しかし多くの場合、エンジニアはユーザインタフェースの構築やレポートの生成といった他の作業にかなりの時間を費やすことを強いられています。すべてのテスタで共通のフレームワークを構築すれば、新規のテスタの開発スピードがずっと速まります。標準のコンポーネントのすべてがすでに組み込まれているため、テストエンジニアはデバイスのテストに必要な機能の構築に専念でき、その結果、新製品を市場に投入するまでの時間を短縮できます。
保守段階は、テスタの存続期間の中で最も長い時間を占めます。保守では、新規テストの追加、ソフトウェアやOSをアップグレードする際の互換性の維持、見つかったバグの修正などを行います。テストエグゼクティブソリューションの保守はドキュメントの領域にまで及びます。テスタの開発段階でどのような決定を下すかによって、保守段階でどれだけの時間がかかり、どれだけの負担が生じるかが決まります。
テストフレームワークの構築では、構築に必要な時間と職能を有する人を確保することが障害の1つとなっています。そうした問題を解決するために開発されたのがNIのTestStandであり、市販のカスタマイズ可能なテストエグゼクティブとして、あらゆるテストオペレーションに対応します。TestStandは、すべてのテスタで共通のフレームワークを提供し、将来のテスタ開発を合理化します。標準のコンポーネントのすべてがすでに組み込まれているため、テストエンジニアは独自のテスト機能の開発に専念できます。その結果、頻繁な変更が減少し、製品の市場投入が迅速化されます。
テストエンジニアはさまざまな言語に精通しており、自分が望む言語でテストの実施手順の構築に集中できるようになることが非常に重要です。TestStandは言語に依存しないため、テスト組織はPython、C/C++、.NETなどのさまざまな言語でプログラミングを行い、すべてを同じフレームワークに組み込んで連携させることが可能です。
テスト管理ソリューションの開発は作業の始まりにすぎません。ソフトウェアは一時的なコストではなく、継続的な取り組みです。ソフトウェアは以下の目標が達成されるように維持する必要があります。
多くの場合、こうした保守作業はかなりの量になり、数か月の開発期間が費やされます。一方で、すぐに利用できるNI TestStandなどのテストエグゼクティブパッケージは、NIによって定期的に更新され、競争力と実現可能性が保たれます。こうしたポリシーにより、最新のテクノロジの利用 (加えてバグの修正プログラムや新機能の入手) がわずかなコストで可能になります。詳細については、「Test Executive Software - Build or Buy?」ガイドを参照してください。
カスタムのテストエグゼクティブの構築に伴って生じる最も明らかなコストは、テストエグゼクティブのすべての機能の実装に必要となる初期開発コストです。以下のチャートは、テストフレームワークに関連するいくつかの機能を示しています。このチャートでは、それぞれの機能をゼロから実装するのに必要な推定時間を示し、NI TestStandを使用して同じ機能を実装するのに要する時間と比較しています。
図4: NIはテストの専門家と協力することにより、TestStandで標準の機能を簡単に実装できるようにしました。
詳細については、構築か購入かを決める際のガイドを参照してください。
すべての機能が常にすべての組織にとって関連性があるわけではありませんが、将来も関連性がないとは限りません。
ここでは、並列実行、レポート生成、データベース接続、ユーザインタフェース、デバッグ/デプロイメントツールなど、TestStandで簡単に追加できるいくつかの重要な機能について説明します。
図5: この図に示されているTestStandの機能では、シーケンスをパイプライン化してリソースを自動スケジューリングすることで、複数のUUT (テスト対象ユニット) を一度にテストすることができます。
テストスループットを向上させる方法の1つは、複数の異なるデバイス間で同時にテストを実行することです。並列実行が可能なソフトウェアの開発に要する時間を考慮すると、どうしても必要という場合でない限り、なぜテスト組織がそうした機能の開発を避けるのかは明らかです。問題なのは、並列実行の開発にはかなりの労力を要するため、並列実行の必要性に気付いたときにはすでに実装の機会を逃してしまっていることが多い、ということです。TestStandを採用すれば、並列システムの開発がはるかに容易になるため、そうした労力のほとんどが不要になり、並列システムの費用対効果が非常に高くなります。
テストシステムの構築にあたっては、テスト結果の処理方法を検討することが不可欠です。そこでTestStandには、データベース接続とレポート生成を簡素化する機能が組み込まれています。TestStandでのレポートのカスタマイズは一般的なタスクであり、TestStandはレポートのコンテンツ、機能、およびスタイルをカスタマイズするための多くの機能を備えています。
テストレポートは、テスト実行の合格不合格を示すスナップショットを提供するという点では優れていますが、1つまたは複数のテストステーションから過去のテスト結果を抽出したいという場合には便利ではありません。対してNI TestStandでは、Oracle、SQL Server、MySQLといったほとんどすべてのオープンデータベース接続 (ODBC) システムにテスト結果をすばやく記録して、すぐに利用することができます。
TestStandの組込機能を利用すれば、テストコードのデバッグに費やす時間を短縮できます。ツールを活用してシーケンス全体でテスト値を監視できるほか、ブレークポイントを利用して実行を一時停止し、テストコードの一部分を詳しく調べることができます。
図6: デプロイメントでは、必要となるすべてのテストシステムコンポーネントを、目的のテストステーションに配布する前に、デプロイメント用のツールやサーバを使用してパッケージ化します。
また、インストーラやディストリビューションの構築を自動化するユーティリティを使用して、テストコードを本番稼働マシンにデプロイする作業を簡素化することもできます。
オペレータインタフェースとは、オペレータがテストシステムを操作する際に利用する表示インタフェースのことです。カスタムのオペレータインタフェースの開発は、特に使いやすさや一貫性を考慮した場合に、かなりの時間を要する可能性があります。TestStandは、デプロイされたシステムでテストを構成および実行するためのシンプルなオペレータインタフェースを備えています。また、複数のプログラミング環境でカスタムのユーザインタフェースを開発して、オペレータがテストシステムを操作する方法をより詳細に制御することもできます。
共通の要素: テスト管理ソフトウェア
| 独自の要素: テスト開発ソフトウェア
|