第302回： 「ALTAのテキストをつくろう」56 （相互運用性テスト）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、JSTQBのALTAシラバスの「4. ソフトウェア品質特性のテスト」の「4.2 ビジネスドメインテストの品質特性」の「4.2.1 機能正確性テスト」、「4.2.2 機能適切性テスト」、「4.2.3 機能完全性テスト」について書きました。機能適合性の副特性をテストする３兄弟でした。
ALTA連載の前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「4. ソフトウェア品質特性のテスト」の「4.2 ビジネスドメインテストの品質特性」の「4.2.4 相互運用性テスト」について書きます。
相互運用性テストでは、まず、
【相互運用】＝【データ交換】
というポイントを押さえてください。そうしないと共存性と混同してしまいます。
おそらく、このポイントを押さえておくだけで試験問題はほぼ解けるはずです。
キャッチイメージと結びつけて記憶して！
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢3の「平均点について小数点以下1桁まで正しい値を出力する」が42.3%と最も多く、正解も3です。
選択肢3は、「機能適切性」ではなく「機能正確性」の例です。
機能適切性とは「出力が得られれば良い（＝機能がある）というだけではなく、開発成果物がニーズの実現を促進しているかの度合い」です。
機能適合性には、あと一つ機能完全性があり、こちらは要求をどれだけ機能が実現しているかです。機能完全性は、例えば、
機能完全性 ＝ （機能により実現した要求数÷全要求数）×100
によって求めます。
復習は以上として、今回のnoteのテーマに移ります。
≡ 相互運用性テスト
「相互運用性テスト」は、ISO 25010(JIS X 25010)の製品品質モデルの相互運用性のテストです。
それでは、JIS X 25010の「製品の品質モデル」から今回の「相互運用性」を読んでみましょう。
相互運用性（interoperability）
二つ以上のシステム，製品又は構成要素が情報を交換し，既に交換された情報を使用することができる度合い。
データをやり取りして動くかどうかです。たまに英語の「インターオペラビリティ（interoperability）」という人もいます。同じ意味です。
なお、複数のシステムがデータを介して協調動作をしてひとつのシステムのように振る舞うものを「システムオブシステムズ（System of Systems： SoS）」といいます。「システムオブシステムズ」はALTAのシラバスにもでてきますので、用語集を確認しておきましょう。
試験では、「相互運用性テストは、システムオブシステムズに基づくアプリケーション対して特に重要なことが多い」といったことを確認されると思います。
■ 相互運用性テストの実施タイミング
コンポーネント統合テスト時およびシステム統合テスト時に実施します。
【統合】は、独立したものを一緒に使うと言うことです。一緒に使うためにはデータの受け渡しが必要ですので、相互運用性の出番となります。
※ 組織によっては「システム統合テスト」というテストレベルを持たずに「システムテスト」でシステムを統合したときの相互運用性についてテストをしているかもしれません。
独立した個々のカタマリをテストしてからそれらを組み合わせたテストをする方が良いと主張される方が増えているのは確かだと思います。
このような「テスト全体の組み立てをどうするか」の検討は、いわゆるテストアーキテクチャの話になります。
■ 相互運用性テストにTAが期待されること
「テストアナリストはデータ交換を動かすために必要なデータとトランザクションを作成できなければならない」とされています。つまりXMLを作ったり、エンドツーエンドでデータ交換をするテストケース（1回の（邪魔が入らない）やり取り＝トランザクション）を作ることができることが期待されます。シラバスに以下の注意点が載っています。
すべての相互作用が要件ドキュメントで明確に記述されているとは限らないことを覚えておくことが重要である。むしろ、これらの相互作用の多くは、システムアーキテクチャーおよび設計ドキュメントでのみ定義している。テストアナリストはそれらのドキュメントを調査して、システム間およびシステムとその環境との間の情報交換をしている箇所を特定し、すべてのテストを確実に行うことができるように準備しなければならない。
■ 相互運用性テストで使用するテスト技法
テスト用のデータを作るときには、同値分割法、境界値分析、デシジョンテーブル、状態遷移図、ユースケース、およびペアワイズテストなどの技法を駆使します。
個々の技法は覚えていて、FLやALTAで出てくる問題をスラスラ解けるレベルに上達していても、テスト技法を相互運用性テストで有効的に使うことは簡単ではありません。
本当は「簡単だ」と書きたいのですが、プログラマーにスーパープログラマーがいるように、テスターにもスーパーテスターがいます。だから一回や二回やって、バグを見逃して、凹んで、「自分にはテスト技法は向いていない」とへこたれることはありません。
見逃してしまったバグから学び、次からは同じようなバグを見逃さなければよいのです。バグのパターンは有限ですからひとつずつ丁寧に学び続けていけば数年でスーパーテスターになれるはずです。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
TA-4.2.5 （K2）相互運用性テストでのテストアナリストの役割について、対象となる欠陥を識別する役割を含めて説明する。
章番号が4.2.4で学習の目的が4.2.5なので、注意しましょう。
（K2：理解、K3：適用、K4：分析）
《問題》
相互運用性ではないものはどれですか？
1. 2つ以上のシステムが情報を交換/使用すること
2. 2つ以上のコンポーネントが情報を交換/使用すること
3. システムとその環境との間の情報を交換/使用すること
4. 他の製品と環境や資源を共有しているときに機能を効率的に実行すること
答えは次回に書きます。
≡ おわりに
今回は、「4.2 ビジネスドメインテストの品質特性」のうち、「4.2.4 相互運用性テスト」がテーマでした。
1991年に生まれたISO 9126において、相互運用性は、機能性の副特性でした。
その20年後、2011に生まれたISO 25010では、9126の品質特性になかった「互換性」が追加され、相互運用性は互換性の副特性に移動しました。
ソフトウェアが生活に浸透するにつれて、「互換性」という品質特性の位置づけが重要になったということの表れの一つです。
ちなみに、9126と25010の比較について（主）特性でいえば、「セキュリティ」が増え、「効率性」が「性能効率性」に変わりました。
今日では、セキュリティの特性も重要です。
※ 品質特性の規格の変化から市場の変化を認識できそうです。
次回は、「4.2.5 使用性評価」です。「使用性」だけ「使用性テスト」ではなく「使用性評価」なんですよね。正解を用意できないから？
