第308回： 「ALTAのテキストをつくろう」61 （レビュー 後編）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、JSTQBのALTAシラバスの「5. レビュー」（pp. 61-65）の「5.1 イントロダクション」と「5.2 レビューでのチェックリストの使用」について書きました。
今回の導入部分であり、FLでのレビューが、概念と作法だったのに対して、ALTAでは、チェックリストに限定した話ではあるものの「レビューを成功に導く技術」に焦点が当てられているという話でした。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「5. レビュー」の「5.2.1 要件レビュー」、「5.2.2 ユーザーストーリーレビュー」、「5.2.3 チェックリストの調整」についてです。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢4の「特有の見解」が81%と最も多く、正解も4です。
最近易しすぎですか、そうですか。
今回は難しくするぞー。しないけど。（頭に残るといいなと思うことを問題にしているだけだから）
復習は以上として、今回のnoteのテーマに移ります。
≡ 要件レビュー
シラバスに良いことが書いてあったので、そこを引用します。
要件がテストできない場合、つまりテストアナリストがどうテストをするか決められないように要件定義をしている場合、その要件には欠陥があると認識することが重要である。例えば、「ソフトウェアは非常にユーザーフレンドリーであるべきだ」と記述されている要件はテストできない。どのようにしたら、テストアナリストは、ソフトウェアがユーザーフレンドリーであるか、または非常にユーザーフレンドリーなのかを判断できるだろうか？ 代わりに、要件が「ソフトウェアは、使用性の標準ドキュメント、バージョンxxxで規定されている使用性の標準に適合していなければならない」と記述されており、使用性の標準ドキュメントが存在する場合、これは、テストが可能な要件である。
これがチェックリストとどう関係するかというと、「各要件の試験性」です。試験性については以下を参照してください。（もっとも、以下の試験性は設計で作り込まれることが多いものですから要件のレビューリストには不適です）
復習のとおり、前回、「テストアナリストは、レビュープロセスに積極的に参加して特有の見解を提供しなければならない。」と学びました。そして、以下のオレオレ定義を書きました。
“特有の見解”とは、「テストすることを想像して、レビュー対象の記載を具体化したときの気づき」だと思っています。
この「特有の見解」のひとつに「どうテストをするか決められないように要件定義をしている場合、その要件には欠陥があると認識する」が求められます。
簡単に言えば、要件定義チェックリストに「その要件をテストするときの期待結果を書くことができる」と書いておくということです。
もっと簡単に「テスト可能か？」というチェックリストとしておくこともありです。チェックリストの各リストは、短い方が色々と広く考えてくれるというメリットがあります。「短すぎて意味がわからない」というデメリットと比較していい感じにします。
≡ ユーザーストーリーレビュー
「ユーザーストーリー」が何かは、この辺に詳しく書かれています。また、ISTQB用語集にも載っています。
私がまとめたスライドはこちらです。
「＜ユーザーの役割＞として、＜ゴール＞を達成したい。[それは、＜理由＞のためだ。]」というフォーマット（①）と、INVEST（②）と、アジャイル開発の時のAC（Acceptance Criteria）に「ユーザーストーリーを満たしたことの根拠（必要なテスト）を書いておく（③）」ことをいつでも思い出せれば良いと思います。
ユーザーストーリーで知っておくべきことを、整理すると以下の3つです。
① ユーザーストーリー（US）のフォーマット
② USの良しあしを評価するINVEST
③ ACにUSが満たされたことの根拠を書く
さて、ユーザーストーリーが分かったところで、そのチェックリストですが、シラバスには具体例として以下の記載があります。
● ストーリーは対象のイテレーション／スプリントにとって適切か？
● ストーリーは要求者の観点で記述されているか？
● 受け入れ基準は定義されており、テスト可能か？
● フィーチャーは明確に定義されており、他と区別できるか？
● ストーリーは他のいずれのストーリーから独立しているか？
● ストーリーに優先度が割り当てられているか？
● ストーリーは一般的に使用される形式に従っているか？
（<ユーザーの種類>として、<あるゴール>をしたい、なぜなら<ある理由>だから[Cohn04]）
箇条書きなので、ALTAの試験問題となりそうですが、ユーザーストーリーが何か分かっていたらどんな問題がでても答えられそうです。
≡ チェックリストの調整
突然このような実務的に有用な情報が書かれているので、JSTQBのシラバスを読むのは楽しいです。
チェックリストは、次の項目に基づいて調整できる。
● 組織（例：企業ポリシー、標準、慣習、および法的制約の考慮）
● プロジェクト／開発の取り組み（例：重点項目、技術的標準、リスク）
● レビュー対象の作業成果物の種類（例：コードレビューは特定のプログラム言語向けに調整することがある）
● レビュー対象の作業成果物のリスクレベル
● 使用するテスト技法
つまり、「ユーザーストーリーのチェックリスト」がどこかにあったときに、それをそのまま使ってレビューするのではなく、「今回のテスト対象のレビューに求められる要求事項（テスト分析で分析した内容）に合わせて調整してから使うように」ということです。
1行目の「チェックリストは、次の項目に基づいて調整できる。」の箇所は原文では、“A checklist can be tailored based on the following:”ですから「調整」に対応する単語は“tailored”です。
「チェックリストは、次の項目に基づいてテーラリングできる。」と訳してもよかったんじゃないかなあ？
ここに書いてあることをベースにして「テーラリングガイド」を作っておくと良いと思います。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
TA-5.2.1 （K3）シラバスが提供するチェックリストの情報に従って、要件仕様に存在する問題を識別する。
TA-5.2.2 （K3）シラバスが提供するチェックリストの情報に従って、ユーザーストーリーに存在する問題を識別する。
（K2：理解、K3：適用、K4：分析）
《問題》
チェックリスト（CL）を適用するときに推奨されないものを選びなさい。
1. 標準CLはテーラリングしてから使用する
2. CLは単独で使用する（組み合わせない）
3. ユーザーストーリーのレビューでは詳細なユーザーインターフェースCLも使用する
4. 要件の出どころをチェックする
答えは次回に書きます。
≡ おわりに
今回は、「5. レビュー」（pp. 61-65）の「5.2.1 要件レビュー」、「5.2.2 ユーザーストーリーレビュー」、「5.2.3 チェックリストの調整」がテーマでした。これで5章は終わりです。
短い章でしたが、実務で使えるテクニックや考え方がたくさん書いてあるので、この章はお気に入りです。
さて、次回は「6. テストツールおよび自動化」の「6.1 イントロダクション」と「6.2 キーワード駆動テスト」について書きます。