第307回： 「ALTAのテキストをつくろう」60 （レビュー 前編）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、JSTQBのALTAシラバスの「4. ソフトウェア品質特性のテスト」の「4.2 ビジネスドメインテストの品質特性」の「4.2.6 移植性テスト」について書きました。
「移植性テスト」の要点は以下の3行に集約できます。
適応性： 製品を固定して環境の変化に適応できる
置換性： 環境を固定して製品を置換できる
設置性： インストール／アンインストールが容易で期待通り
言われてみれば当たり前の適応性、置換性、設置性ですが、ゼロから移植性のテストを作るときの良い参考になります。
もっとも、○○規格にしたがっても100点の仕事ができるとは限りません。しかしながら、及第点の結果は残せることでしょう。
○○は、ISO/IEC 25000シリーズやISO/IEC/IEEE 29119など。
ところで、規格が実務に適用するには重すぎるときに、どこをテーラリングして省略するかは結構難しいものです。
一般的には、
・ shall/must（必須事項（義務/要求）・しなければならない）
・ should（推奨事項・することが望ましい）
までを取り入れます。
・ may/optional（許容事項・してもよい・できる・することもある）
については気が向いたら取り入れます。
なお、「すべきである」と「すべきでない」という言い回しは、最近の規格書では出てこないと思いますが、昔の書籍などに残っていたら、shall（必須）なのかshould（推奨）なのかを確認したほうがいいです。
ただし、一般書籍では著者の感覚でこれらの助動詞を書き分けていることが多いので、その場合は、上記のように機械的に考ることはできません。
ところで「ゼロから移植性のテストを作るときの良い参考」と書いたのは、ISO 25010の製品品質特性を使うときには、必ず自分のテスト対象を思い浮かべながら読み替える必要があるためです。
例えば適応性であれば、環境適応性テストのために、自分のテスト対象が対応すべき環境について、「設置される可能性がある既存の環境」と「将来の環境変化の予測」を実施し、【テスト環境】を計画し、構築し、テストします。
このときに、「どうして、その環境に設置される可能性があると思ったのか？」という質問が来たときに、TAなら「なんとなく必要と思った」ではなく「○○の根拠からこのテスト環境で移植性のテストをする必要があると考えました」と回答できることが求められます。
※ HAYST法では、3W（When/Where/Who）の組み合わせでキワの環境を見つけます。
このときの「根拠」とは「テスト対象が設置される環境に対する要求の背景」のことです。
「根拠」は、標準的なものは使いまわせますし、前バージョンの「根拠」は踏襲すべきものが多いです。しかしながら基本的には、テスト分析プロセスの中で毎回考える必要があります。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「5. レビュー」（pp. 61-65）の「5.1 イントロダクション」と「5.2 レビューでのチェックリストの使用」の総論までとします。「5.2.1 要件レビュー」以降については次回書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢２の「適応性」が78.3%と最も多く、正解も3です。
「何回、品質特性の定義を確認するんだよ」といわれそうです。
ですが、暗記することまではもとめませんが、理解してそれをもとにテストをつくれることはテストエンジニアの必須のスキルです。
「つながる世界の ソフトウェア品質ガイド」という最高の教科書が無料で手に入るのですし、実際に高品質ソフトウェアの開発に役立つものですので、使いこなしましょう。
復習は以上として、今回のnoteのテーマに移ります。
≡ （レビュー：イントロダクション）
こちらシラバスの全文を引用します。
テストアナリストは、レビュープロセスに積極的に参加して特有の見解を提供しなければならない。適切に行われれば、全体的な納品時の品質に最大限寄与する最も費用対効果の高い手段となることができる。
このシラバスで勉強している人は「“特有の見解”ってなんだろう？」って思うんじゃないかなあ、、、というか思ってほしいです。
原文を引用します。
Test Analysts must be active participants in the review process, providing their unique views. When done properly, reviews can be the single biggest, and most cost-effective, contributor to overall delivered quality.
“特有の見解”は、原文の”unique views”に対応します。”their unique views”のtheirはTest Analystsを指していますので、「テストアナリストならではの観点」でしょうか。短くしたら「テスト観点」、、、。
えっ？、そういうこと？？
“特有の見解”が「テストアナリストとしての見解」であることはよいとして、今度は、「TAとしての見解」ってなんだ？という話になります。
この連載の第一回目で、「テストアナリストとは、テストプロセスなどのテストの全般技術と、ブラックボックステストの高度なレベルの技術を有する」という定義を紹介しました。
そこで、「TAとしての見解」は、「テストの全般技術と、ブラックボックステストの高度なレベルの技術を持つエンジニアとしての見解」ということになります。
しかし、文が長くなっただけで、正解に近づいている気配がありません。
ということで、書いていないのだから、オレオレ解釈となります。
結論から言うと、“特有の見解”とは、「テストすることを想像して、レビュー対象の記載を具体化したときの気づき」だと思っています。
レビュー対象には、「要件リスト」、「ユーザーストーリー」、「設計仕様書」等があります。
このとき、上流工程に行けば行くほど、その記載は曖昧になります。これは、「顧客は自分が欲しいものの詳細を説明できない」ことと、「多くの開発者は実装してみないと何ができるか その詳細はわからない」ことの2つが原因です。
『顧客が本当に必要だったもの』という風刺画があります。以下のような絵です。（様々なバージョンがあります）
出典：University of London Computer Center Newsletter No.53
要は、顧客は何が欲しいかなんて正確に伝えられませんし（多くの場合、完成品を使ってみてあれこれほしいというだけです）、世の中にあるシステムはその結果として生まれたヘンテコなものばかりということです。
これが、「顧客は自分が欲しいものの詳細を説明できない」という意味です。
もう一つの、「多くの開発者は実装してみないと何ができるか その詳細はわからない」というのは、残念ながら多くのソフトウェア開発者は実装してみないと詳細についてはわからないレベルの技術者ということです。
顧客から要求を引き出すスキルもないし、引き出した要求から機能や品質要求を理解して仕様書にまとめるスキルも無い人が多いということです。
だからTAが「テストすることを想像して、レビュー対象の記載を具体化したときの気づき」（＝特有の見解）をレビューで提供する価値があるのです。
TAは、ソフトウェアエンジニアとして「①何がソフトウェアで簡単に実現でき、何がソフトウェアで実現困難なのか」を判断できる技術を持っています。
また、テストをつくることに慣れています。「テストをつくる」とは、「②具体的な動作条件とその期待結果をつくる」ことです。
以上の2点のスキルをレビューで発揮する事をTAは期待されています。これが“特有の見解”の正体です。
※ 実際のところ、ISTQBのシラバスを作成した委員の人が何を考えてたかは分かりません。
さて、今度は後半を理解するために、もう一度レビューのイントロダクションについて、シラバスの全文を引用します。
テストアナリストは、レビュープロセスに積極的に参加して特有の見解を提供しなければならない。適切に行われれば、全体的な納品時の品質に最大限寄与する最も費用対効果の高い手段となることができる。
「適切に行われれば、全体的な納品時の品質に最大限寄与する最も費用対効果の高い手段となる」というのは本当のことです。テストも品質向上に大いに貢献しますが、レビューはテスト以上に貢献します。
「（TAが特有の見解を提供できたらそれは）最も費用対効果の高い手段」となります。
≡ レビューでのチェックリストの使用
ALTAのレビューの章は「5.1 イントロダクション」、「5.2 レビューでのチェックリストの使用」しかありません。学習時間もわずか2時間です。
以下は目次です。
「チェックリスト」がレビューで如何に大切かということが中心に書かれています。
今、「大切」と書きましたが、全てのレビュー技法の「基本（土台）」と言うほうが適切かもしれません。
FLでのレビューの説明は、「テストは故障を見つけ、レビューは欠陥を見つける」であるとか、「レビュープロセスとレビューに関わる人の役割」といった概念や作法といったものでした。
ALTAでは、チェックリストに限定した話ではあるものの「レビューを成功に導く技術」に焦点が当てられています。
ところが私が知っている日本の現場では「チェックリストを作成し（あるいは汎用的なチェックリストを用意して）、それを使用してレビューを実施している」組織はほとんどありません。
多くの組織では、「要求仕様書ができたからメールレビューをお願いします。」とか「基本設計書のインスペクションを〇月〇日に実施しますのでご参集ください」といった形で、それぞれが要求仕様書や基本設計書を読んで気が付いたことをレビュー記録表にまとめるだけです。
30年前の方がチェックシートを真面目に作っていたように思います。日本では、それが役に立たなかったから無くなったのですが、役にたつチェックシートに進化させる道もあったということです。
さて、そんなチェックリストですが、ALTAシラバスでは「要件」と「ユーザーストーリー」に対する具体的なチェックリストの例を示すことで、チェックリストの重要性と実用性を伝えています。（こちらは次回のテーマです）
具体的なチェックリストの例を示す前段として、ALTAシラバスには、チェックリストベースドレビューの話が載っているのですが、あまり核心をついた記載ではありません。しいて言えば、以下は箇条書きなので、ALTAの試験にでるかもしれません。単なる例なのでたぶん出ない。
チェックリストは、次のような特定の側面を対象にすることもある。
● プログラマー／アーキテクトのスキルセットまたはテスト担当者のスキルセット -テストアナリストの場合、テスト担当者のスキルセットに対するチェックリストが最も適している
● 特定のリスクレベル（セーフティクリティカルシステムの場合など） - チェックリストはそのリスクレベルで必要な固有の情報を含むことが多い
● 特定のテスト技法 - チェックリストは特定の技法で必要な情報に重点を置く（デシジョンテーブルで提示される規則など）
● 特定の仕様アイテム（要件、ユースケース、ユーザーストーリーなど） - これらについては、以下の節で説明する。コードまたはアーキテクチャーのレビュー向けにテクニカルテストアナリストが使用するものとは、異なる側面に重点を置くことが多い。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
TA-5.2.1 （K3）シラバスが提供するチェックリストの情報に従って、要件仕様に存在する問題を識別する。
TA-5.2.2 （K3）シラバスが提供するチェックリストの情報に従って、ユーザーストーリーに存在する問題を識別する。
他と同様に、章のイントロダクション（5.1）に対する学習の目的はありません。
TA-5.2.1とTA-5.2.2は「5.2 レビューでのチェックリストの使用」に対するものです。試験対策としては次回の範囲に的を絞るほうが良いでしょう。
（K2：理解、K3：適用、K4：分析）
《問題》
ALTAシラバスにはレビューに関して以下の記載がある。○○に当てはまるものを選びなさい。
－
テストアナリストは、レビュープロセスに積極的に参加して○○を提供しなければならない。
－
1. ハイレベルテストケース
2. テスト見積り
3. モデレータの役割
4. 特有の見解
答えは次回に書きます。
≡ おわりに
今回は、「5. レビュー」（pp. 61-65）の「5.1 イントロダクション」と「5.2 レビューでのチェックリストの使用」の総論がテーマでした。
チェックリストで見つかるような欠陥のレビューはAIに置き換わっていくんじゃないかなと思います。それは良いことです。
さて、次回は「5. レビュー」（pp. 61-65）の「5.2 レビューでのチェックリストの使用」の「5.2.1 要件レビュー」と「5.2.2 ユーザーストーリーレビュー」と「5.2.3 チェックリストの調整」について書きます。
