第306回： 「ALTAのテキストをつくろう」59 （移植性テスト）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、JSTQBのALTAシラバスの「4. ソフトウェア品質特性のテスト」の「4.2 ビジネスドメインテストの品質特性」の「4.2.5 使用性評価」の「4.2.5.2 使用性評価手法」について書きました。
使用性は本当に深いテーマだと思います。新しいデザインの流行についても知らないといけませんし、一方で子供から大人まで、どんな国の人でも使いやすいデザインってなんだろう？という底知れない技術と経験が必要となります。
例えば、スマホのハンバーガーメニューがはやり出したとき、私は「ただの飾り」だと思っていました。
なので「○○ってどうやるのー？」って大騒ぎした後に後輩に教えてもらって、「そんなところにメニューが隠れていたのかー」と驚くやら自分に腹が立つやらでした（笑）。
また、昔使っていたAndroidスマホ（Galaxy）でスクリーンショットを取るには、「手のひらキャプチャ」（下図参照）という方法だったのですが、「わかるかっ！」って思いました。
「手のひらキャプチャ」は片手での操作が難しいですし、手を動かす速度にも微妙なコツが必要でした。その後、別のスマホで聞いたことがないので使用性が悪かったんだろうなと思います。
不公平があるといけないのでiPhoneの使用性についても書いておけば、基本操作のひとつである文字の選択について「出来たり出来なかったりするし、急に画面がスクロールしちゃうことがある」のはなぜってよく思います。
もし、このnoteを読んでいる人のなかに関係者がいたらごめんなさいだけれど、Kindleアプリ、使いにくいじゃないですか。
だいぶ良くなってはきたけれども、先日、『にしさんの教え』の移植性テストのために、Windows版のKindleアプリを使ったら頭がおかしくなりそうになりました。（笑）
ということで、使用性のテストは、ユーザビリティのプロを育成するか、プロに頼むのが良いと思います。（大学の研究室との共同研究がお勧めです）
なお、使用性の問題はテストで指摘できるけど、開発初期に一生懸命考えてつくるほうがいいです（アジャイル開発の時には顧客をどれほど巻き込めるかが鍵かな）。
あと、良い使用性を持つものにたくさん触れることも大事です。
良いものに触れていないと、使いにくくても、「こういうものかも？」ってなってしまいがちです。（テストをはじめて間もない方は特に遠慮しがちです）
骨董商の目利きに似ています。彼らは日々、美術館や博物館を巡り、良いものをインプットし続けることで贋作を見破ることが出来るようになるとのことです。
仕様書通りの動きをしているときに、使いにくいことに気が付いても、その感覚のみを信じてNO!と言える人は少ないものです。
自分の経験で言えば、入社した1985年にJStarという、当時、技術的に10年先を走っていたワークステーションを自分専用で使えたことがラッキーでした。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「4. ソフトウェア品質特性のテスト」の「4.2 ビジネスドメインテストの品質特性」の「4.2.6 移植性テスト」について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢3の「環境適応性テスト」が84%と最も多く、正解も3です。
「環境適応性テスト」は、今回の「移植性のテスト」の例の一つです。「環境適応性テスト」では、保証する環境下において、機能するかどうかまでをテストします。（“適応性”は移植性の副特性であり、使用性について焦点を当てたテストではありません）
復習は以上として、今回のnoteのテーマに移ります。
≡ 移植性テスト
まずは、「移植性」という用語の定義について、JIS X 25010:2013を確認します。
用語の定義の確認はJIS・ISO・IEEEなどの規格書や○○BOKが便利です。テストの専門用語でしたらISTQBの用語集がおすすめですが、一般的な用語の場合は、ちょっと不安です。あと、「〇〇辞書」は情報が古いことがあるので気をつけましょう。
移植性（portability）
一つのハードウェア，ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に，システム，製品又は構成要素を移すことができる有効性及び効率性の度合い。
注記1 ISO/IEC 24765を変更した。
注記2 移植性は，移植活動を容易にするための製品若しくはシステムの固有の能力，又は製品若しくはシステムを移植する目標を経験した利用時の品質のいずれかとして解釈できる。
移植性については、1991年に発行されたISO/IEC 9126の6つの品質特性（機能性、信頼性、使用性、効率性、保守性、移植性）にも定義されているように、昔からソフトウェアの特徴をあらわす大きな切り口の一つとされてきました。
ところが昔から【「保守性」と「移植性」は誰のため？】という議論がありました。
機能、性能、互換性、使用性、信頼性、セキュリティはストレートにユーザーに対して価値を与えますが、「保守性」と「移植性」はユーザーから要求として上がってくるのかというと疑問があるというのです。機能（＝ユーザーが求めるシステムの働き）との結びつきが弱いからです。
ということでJIS X 25010の製品品質モデルを確認してみます。
よく見ると、左からユーザーが求める特性で並んでいます。（機能適合性、性能効率性、互換性、、、（略）、、、保守性、移植性の順）
移植性の副特性は「適応性」、「設置性」、「置換性」の3つです。
移植性と言っても「製品品質モデル」ですので、「COBOL言語で書かれているソースコードをJavaに書き直す」といった開発者向けの品質特性ではなく「インストール」といったユーザーに直結するほうの移植性と捉えることができます。
これは「製品品質モデル」なので当たり前の話かもしれません。
でもだいぶ前に非機能要求をUSDMで書く方法について、清水吉男さんからお話を伺ったときに違う説明をされていて「あれ？」っと思ったのでした……。
ちょっと話題がそれますが、USDMで非機能要件を取り扱うときには、
① 保守性と移植性は、まずそれを要求するステークホルダー（notエンドユーザー）から要求を聴き出す
② ISOの品質特性の定義を開発する製品にあてはめて解釈し直す
③ 設計に織り込む品質要求を確定する
④ 評価尺度を決定する
⑤ 対応知識・技術を明らかにする
の順番で行います。……USDMについてどこかにまとめておきたいなあ。我流の人が多すぎるしー。（かといって、例の本を読んだら分かるかというと、たぶん分からないですし、非機能については書いていないですし。）
そういえば、清水さんは、2017/11/22にお亡くなりになったので、7年経つのですね。逢いたいですね。
さて、ALTAシラバスでは、移植性の3つの副特性、つまり、「適応性」、「設置性」、「置換性」のそれぞれに対して、「4.2.6.2 環境適応性テスト」、「4.2.6.1 設置性テスト」、「4.2.6.3 置換性テスト」として説明があります。以下、シラバスの順で説明します。
■ 設置性テスト
インストール（＋アンインストール）のテストです。
● インストール時のパラメータについてペアワイズ技法を使用する
● 手順どおりにインストールできることをテストする（機能正確性）
● インストールが成功したことをテストする（機能適合性）
● 手順やメッセージの分かりやすさをテストする（使用性）
シラバスには5個目の「●」がありますが、文はありません。ISTQBのほうも4つしかないのでJSTQBシラバスの編集ミスと思われます。
■ 環境適応性テスト
シラバスを確認します。
環境適応性テストでは、意図したすべての対象となる環境（ハードウェア、ソフトウェア、ミドルウェア、オペレーティングシステム、クラウドなど）で所定のアプリケーションが正しく機能するように、効果的、かつ効率的に適応ができているかどうかを確認する。
とあります。今回の“はじめに”に
先日、『にしさんの教え』の移植性テストのために、Windows版のKindleアプリを使ったら頭がおかしくなりそうになりました。
と書きましたが、これは「環境適応性テスト」をしたということです。
■ 置換性テスト
こちらは何かと置換するテストです。一つ前の「環境適応性テスト」と似ています。もとの規格を並べて確認しておきましょう。
適応性（adaptability）
異なる又は進化していくハードウェア，ソフトウェア又は他の運用環境若しくは利用環境に，製品又はシステムが適応できる有効性及び効率性の度合い。
置換性（replaceability）
同じ環境において，製品が同じ目的の別の明示された製品と置き換えることができる度合い。
適応性では、「環境が多様であったり、変化していったりするときにそれに追随できるか」を問題としているのに対して、置換性の方はバージョンアップや類似製品などへの置換、すなわち、「同じ環境で同じ目的を持つ別のシステムに置き換えることができるか」に着目をしています。
要点を整理すると、「適応性： 製品を固定して環境の変化に適応できる」、「置換性： 環境を固定して製品を置換できる」です。
ちなみに「設置性： インストール／アンインストールが容易で期待通りか」です。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
TA-4.2.6 （K2）移植性テストでのテストアナリストの役割について、対象となる欠陥を識別する役割を含めて説明する。
TA-4.2.7 （K4）一連の指定された要件について、機能そして/または非機能の品質特性を検証するために必要なテスト条件を、テストアナリストの役割の範疇内で決定する。
移植性のテストは、TA-4.2.6の方だけなのですが、「TA-4.2.7 （K4）」に対応する本文がシラバスに無いので、ここに書いておきました。
K4なのに……。どこまで試験で確認するのか、本文に書いてよ、シラバス。
（K2：理解、K3：適用、K4：分析）
《問題》
移植性のなかで、「設置環境の多様性や変化へ追随できる度合い」を測る副特性はどれですか？
1. 設置性
2. 適応性
3. 置換性
4. 多様性
答えは次回に書きます。
≡ おわりに
今回は、「4.2 ビジネスドメインテストの品質特性」のうち、「4.2.6 移植性のテスト」がテーマでした。
「設置性テスト」、「環境適応性テスト」、「置換性テスト」の違いはバッチリでしょうか。👌
インストール／アンインストールときたら「設置性」、変化への追随は適応性と置換性、環境の変化への追随が「環境適応性」、テスト対象自体の置き換えは「置換性」。
ALTAの試験に向けて、定義の違いをあれこれ書いていますが、実務ではゆっくりとシラバスを見ながらテストをつくっていけばよいです。
つまり、移植性には3つの観点があることだけ覚えておけば良いと思います。
さて、次回は新しい章に移って、「5. レビュー」です。実質3ページしかないのですが、K3なので2回に分けるかなー。
