少し前に、何度か偶然「
コンポーネント指向開発」が話題となることがあり、”
コンポーネントテスト”と”
コンポーネントのテスト”が気になっていた。
コンポーネントテストは
ユニットテストと呼ばれるもので、ソフトウェアモジュールを分離してテストするもの。後者は一般用語にはなっていないが、ここでのイメージは、開発の際の市販を含めた外部のモジュールをテストするものである。
で、ここでの”
コンポーネントのテスト”って、一般的な用語では”受け入れテスト”に近い。開発の最初の頃に、テストフェーズでの終盤のテストと同じような事を実施することになる。反面”受け入れテスト”と多少異なるのは、利用する部分のテストでも十分であることや不具合発見が開発全体に影響することが多いことだろう。（開発の中間や終わりに、中心的なモジュールが利用できないと発覚したら、システム設計自体の見直しにもなりかねない。）
ただその観点で、「受け入れテスト」（ただし
コンポーネントのテスト）のテスト技法とかの議論を、あまり見かけないように思えてきた。特にテスト効率などの議論。その辺りが気になった。
で、調べてみたら、
JSTQB(ISTQB)のFL
シラバスでは、2.2.4. 「受け入れテスト」でいくつかのテストを述べている。FL:Foundation Level AL:Advanced Level
・ユーザ受け入れテスト
・運用受け入れテスト
・契約、および規程による受け入れテスト
・アルファ、ベータ(あるいはフィールド)テスト
また、「市販ソフトウェアプロダクト(COTS)は、インストールや統合時点で受け入れテストを実施する。」、「
コンポーネントのユーザピリティの受け入れテストは、
コンポーネントテストで実施する。」との記載もある。なので、ここで書いた”
コンポーネントのテスト”は、受け入れテストと呼んでも良さそうに思う。ただし
JSTQB(ISTQB)では、”受け入れテスト”はテストレベルでの1つとしており、テストレベルはテストフェーズの意味でもあるので、用語の概念としてすっきりしない。
ちなみに、
JSTQB(ISTQB)のAL
シラバスの方では、受け入れテスト自体の細部に関してはFLほどには言及していない。
用語をすっきりさせるには、組織体で○○
コンポーネント受け入れテストとか○○モジュール受け入れテストと呼んだり、多少一般化するのなら”
コンポーネント受け入れテスト”という用語などを使った方が良さそうに個人的には思えた。
なお、懇親会の類では、特に海外製のモジュールに重大バグがあったり窓口対応が悪かったりで、開発スケジュールに大きな影響が出たなどの話は少なくない。そして、同じ社内のモジュールとか装置開発の遅れ起因がある。割合的には後者は少ない気がするが、起きて
システムプロジェクト側が責任を負わされたり犠牲になることも。同じ社内なので、責任追及しにくかったり、元々駄目チームと分かってても利用しないと行けない事情があるのだろう。
ちなみに
コンポーネント受け入れテストで話題になるのは、以下辺りが多い。
・テスト効率
・負荷テスト
・非機能要件
・外部を含めたバグ管理
・スタブ作成チーム、テスト作業チーム形成
・テスト環境保存 （自動化でスクリプトを作成したらその保存なども）
最近は外部機器でもネット接続可能なものが増えたり、市販
コンポーネントでもサンプルプログラムが付いたものも少なくない。パソコンを利用して、それらの機器や
コンポーネントをテストすることは増えている。さらには、
GUIやネット系の自動テストツールや画面操作再生ツールなどを利用すると、結構効率良いテスト環境を構築できる。組込み
ソフトウェア産業実態調査報告書などで自作テストツールの割合が多いが、今後は市販ツールの利用が増えていくと思われる。
用語がすっきりするのは良いことだが、結局この類のテストの重要性を感じているところは以前も含めて実施しており、何らかの呼称を行っているだろう。また、テスト自動化の議論と多少似てて、実施しているところはさらなる効率化を目指していて、一般的な議論は進みにくいようにも思えてきた。
補足：通常の受け入れテストが発注者側が主体であるのに対して、ここでの”
コンポーネントのテスト”や”
コンポーネント受け入れテスト”は機器やシステムの開発側／受注者側が主体となる。発注者、開発者／受注者の各々の目線でテストのフェーズを考えることが多いので、それも少し違和感が発生するのかもしれない。開発者／受注者目線で考えるなら、テストのフェーズとしては受け入れテストという言葉よりも、出荷テストとかカットオーバーテストの方が良いように思える。
