ISTQB Advanced Level Test Analystに学ぶテストケース粒度
はじめに
みなさんこんにちは。
2022年にASTQB Certified Tester Advanced Level Test Analyst(CTAL-TA) & Test Manager(CTAL-TM) 試験に合格しました、QAの相澤です。
※1 ASTQBはISTQBのアメリカ合衆国支部に相当します。ソフトウェア技術者のテスト技術向上を目的とした資格認定制度です。
今回はISTQB Certified Tester Advanced Level Test Analyst試験(+一部Test Manager試験)にスポットライトを当て、以下を目論んでの本記事とします。
日々のプロジェクトにも活用できる内容の共有
エッセンスのご紹介
ソフトウェアテストの認知&水準向上
Test Analyst試験は言ってみればテスト設計に関わる方のための試験です。 それではみなさん、これを機にぜひテストケースにも向き合ってみましょう。
おもなメッセージ
結論から言います。
盲目的に粒度が細かめなテストケースを採用するべきではありません。 まずは粗めのテストケースから作成し、プロジェクト特性に応じて細かめなテストケースの要否・作成タイミングを判断しましょう。
こちらのメッセージに対して更に理解を深めたい方は以降の内容もぜひ。
テストケース粒度の話
※JSTQB Test Analyst試験のシラバスでは粒度の粗めなテストケース=「論理的テストケース」、粒度の細かめなテストケース=「具体的テストケース」 と表現されています。本記事ではより日常的な用語と考えられる前者の表現を採用いたしました。
現場でこんな悩み、ありませんか？
実際に声が上がるかどうかはともかく、テストケース粒度に関しては以下のような嘆きが起こりえます。今回は代表的にテスト設計者視点 & テスト実行者視点での嘆きをご紹介いたします。なかなか難しいところですが、誰かが声を上げて言わなくとも、メンバーの雰囲気からも潜在的ニーズを感じ取れると尚良いでしょう。
テスト設計者視点
「こんなに細かく設計するなんてめんどくせえなあ。それぐらいテスト実行時に判断してくれよ～」
テストケース粒度を粗くすべきサインなのかもしれません。
テスト実行者視点
「テストケースでもっと詰めてくれないと、具体的に何をしたら良いのか分からないよ～」
テストケース粒度を細かくすべきサインなのかもしれません。
テストケース粒度の実態
これまでQAやテストエンジニアとして開発プロジェクトに関わってきました限り、どのプロジェクトでも粒度が細かめのテストケースが採用されてきました。どのぐらい細かめのテスト粒度かと言いますと、各機能 & 各画面内の各項目内にまで、テスト内容が事細かく記載されていることが当たり前でした。また、テストデータとして使用する具体的な値についても決まっていることが多かったと思います。ここまで事細かくテストデータがテストケース内で定められていたのは体感的に75%ぐらいで、残りの場合はテストデータの値が満たすべき条件のレベルまで記載されていたと記憶しています。
例）(最大値＋1)、(最小値-1) など
ISTQB/JSTQBのシラバスに沿って考えますと、この粒度は 「最も細かい粒度」、あるいは「かなり細かめの粒度」 に相当します。
テストケース粒度が粗め & 細かめの場合の特徴整理
ISTQB Advanced Level Test AnalystやTest Managerのシラバスや参考書によりますと、粒度が細かめのテストケース、粒度が粗めのテストケースどちらにもメリットやデメリットがあります。両者の特徴を以下の図にまとめてみました。
「粒度」と言ってイメージが湧きにくい方のために、シューマイを例にとってご説明いたします。
粗い粒度の例
「シューマイを電子レンジで良い感じに温めてください」
細かい粒度の例
「シューマイに濡れた布きんをかけ、600Wで1分間温めてください」
粒度が細かめなテストケースのメリット
粒度が細かめなテストケースのメリットは以下の5つだと考えられます。 適宜先ほどのシューマイの例を思い浮かべて照らし合わせていただけると分かりやすいかもしれません。
1. テスト実行内容に関して属人化が生じにくい
テストケースを細かい内容までカッチリと定めることは、人によってテスト内容がバラつく余地をなくします。言い換えるとテスト内容がテスターのスキルに左右されにくく、テスト実施結果の再現性が増すことを意味します。あまり良くない表現をしてしまうと、未熟なテスターでもテスト実行がしやすくなるとも言えるでしょう。
2. 仕様の妥当性が吟味しやすくなる
シューマイだと説明が難しいため、空想上のECサイトを例にとってみます。 「支払いが完了すると、顧客アカウントのステータスが変わること」 という仕様があったとします。この粒度が粗い状態のまま妥当性を吟味しようとすると、「ああ、そりゃあ支払いが終わったことをシステムは認識しないといけないよな」で議論が終わってしまいます。
しかし、以下を詰めていくとすればどうでしょう。
何を以て「支払いが完了」したとみなす？
→支払い額が請求額と一致したとき？上回った場合はどうする？
→そもそも、どんな方法で支払うことができるのだろう？その方法に応じて、支払い額が請求額を上回る場合は出てくる？
顧客アカウントのステータスはどんな風になれば良い？
→そもそも支払いができる顧客とは、どんな顧客だろう？
→購入内容が決まった顧客？購入内容が決まっていなくても、プリペイド方式もいけたりする？
→逆に、支払いができない顧客とは、どんな方だろう？
→たとえば本人確認は必要？ブラックリスト入りの顧客でも支払える？
考え始めればキリはありませんが、内容を細かく詰めていけばいくほど、仕様に関して議論の余地が生まれます。このことによって仕様の妥当性を吟味する余地が生まれていくものと理解しております。
3.仕様について、開発 & テスト担当者間で認識を合わせやすくなる
先ほどの②を例にとりますと、テストケース粒度を細かくすることで以下のようなことを開発者の方に確認できるようになります。
『本人確認の状態には「未実施」・「審査中」・「完了」の3つ、ブラックリストへの登録状況には「未登録」・「登録済」の2つがある認識です。これらを組み合わせた場合、3×2=6(通り)の状態が考えられます。顧客の6つの状態に応じた支払いの可否についてご教示いただけないでしょうか。』
まあ、そもそもECサイトは本人確認なんてないかもしれませんが、たとえばの話として捉えていただけますと幸いです。
4. テスト自動化が容易になる
AIが著しい進化を遂げてきた昨今ですが、特定のプログラムが状況に応じて柔軟に判断を下すのは困難なこともありえます。このことから、円滑なテスト自動化のためには判断の分かれ目のないテストケース、つまり粒度の細かめのテストケースが必要になると考えられます。
5. 監査がしやすい
粗いテストケースを採用しており、テスターに応じてテスト内容がバラつく場合を考えてみましょう。ガイドライン上、何か達成しないといけない要件があったとします。その要件に沿っているかどうかを人によってバラつく内容に沿って照らし合わせるのは心許ないですよね。そう考えると、「ガイドライン上の要件よりも粒度が粗いテストケースだと、遵守状況の照合が困難」 なことが伺えます。つまり、テストケース粒度が細かいほうがガイドライン遵守状況を追跡しやすくなることが言えると思います。
色々と述べているうちに、粒度が細かめのテストケースのメリッﾄがもうひとつ思い浮かびました。それは「テスト実施工数の厳密な管理がしやすいこと」です。これは粒度が細かめの場合、脱線が許容されにくいため、テスト工数にも状況によるバラつきが生じにくくなるためです。
粒度が粗めなテストケースのメリット
粒度が粗めなテストケースに馴染みのない方は沢山いらっしゃることと思います。けれど、粗めのテストケースに決してメリットがない訳ではありません。以下の5つが粒度が粗めなテストケースのメリットだと考えられます。
1. 仕様の詳細が定まっていなくてもテストケース作成ができる
いつぞやのシューマイの例に戻ってみましょう。 細かめの粒度を採用すると 「電子レンジが何ワットなのか分からないから、テストケースが作れない」となることでしょう。粗めの粒度だと、「どんな電子レンジが来るか分からないけれど、とにかくシューマイが良い感じに温められることが確認できれば良い」となるため、テストケース作成がブロックされてしまう局面を減らすことができます。
2. テストケースのメンテナンスが楽
これもシューマイの例を用いてご説明いたします。 たとえば採用する電子レンジのワット数が600Wから500Wに変わったとします。 細かめの粒度を採用している場合、ワット数の変更をいちいち反映させなければなりません。粗めの粒度の場合、こういった変更に対し、都度反映させる必要がなくなるため、メンテナンスが楽になるのです。（もっとも、反映の要否は変更の内容にもよる訳ですが。。。）
3. トレーサビリティの追跡が楽
テストケースの粒度を細かくするということは、多くの場合それだけテストケース数が増えることを意味します。テストケースが増えるということは、それだけ照合対象ケース数が増えることになります。トレーサビリティについて本記事で語ると長くなってしまうため、詳細にご興味おありの方は別記事『ISTQB Advanced Test Managerに学ぶプロジェクト毎のテストマネジメント』もぜひご覧くださいませ。
4. テスト実行者の視野を広げることができる
シューマイの例を用いてご説明いたします。 テストケースが「シューマイに濡れた布きんをかけ、600Wで1分間温めてください」となっていた場合、こちらの場合を一度確認してしまえば、それで終わりでしょう。
では、テストケース粒度が粗めで 「シューマイを電子レンジで良い感じに温めてください」 となっていた場合はどうでしょうか。「まずは1分半で試してみよう」、「ちょっと熱すぎたな。今度は45秒にしてみたらどうだろう？」といった具合に脱線の余地が生まれてきます。この脱線がテスト実行者の方の視野を広げることに一役買ってくれることもあります。
5. 別プロジェクトでのテストケース流用がしやすくなる
これは粒度が粗めのテストケースが多少の仕様差異の許容度が増すためだと考えられます。
プロジェクト特性によるテストケース粒度の判断例
これまで粗め & 細かめなテストケース粒度のメリットを色々と述べてきましたが、次のような疑問が思い浮かぶ方もいらっしゃるかもしれません。「結局、うちの案件ではテストケース粒度、どうしたらええのん？」こればかりはISTQB/JSTQBのシラバスにもなかなか載っていなかったりするため、一概に述べるのは難しいところがあるのが本音です。あくまで私の見解であることを断っておいた上で、このポイントに踏み込んでみたいと思います。
前提として、粒度粗めのテストケースはプロジェクトを問わず必須なので今更議論の必要はないでしょう。プロジェクトによって分かれてくるのは粒度の細かめのテストケースの要否です。よって先に粒度が粗めのテストケースを作成し、徐々にテストケース粒度を細かくしていくべきかどうか判断していくアプローチがベストだと考えられます。
1. テスト活動のOfficialさ
こちらは概ね、「監査がしやすい」 で述べた通りです
2. エンドユーザーによる操作
エンドユーザーによる操作が想定されない場合、基本的には 「企業の中の人」 がシステムを操作することになるでしょう。このため、エンドユーザーが操作するシステムと比較すると、比較的ワークアラウンドが許容されやすいことが言えると思います。 （あくまで比較の問題ですので、ステークホルダーとの合意をお忘れなく。）
3. テスト工数の潤沢さ
粒度が細かめなテストケース作成のためにはもちろん、粗めな場合よりも多くの時間を要します。テスト工数に応じて適切な粒度のテストケース作成が求められます。
4. テスト実行者のスキル
こちらは概ね、「テスト実行内容に関して属人化が生じにくい」 で述べた通りです。 他にもテスト設計者とテスト実行者が同一人物となることが想定されている場合、テストケース粒度を粗くすることを検討する価値が出てくるでしょう。テストケース内容のテスト実行者への引き継ぎが不要になるためです。
※テスト設計者とテスト実行者を別人物にすることでテストケースのクロスチェック効果が生まれるため、テスト実行者をテスト設計者と同一人物にするかどうかは慎重に検討しましょう。
5. スピードor正確さ重視？
こちらは上記の 「1.テスト活動のOfficialさ」と「3. テスト工数の潤沢さ」を組み合わせたものと考えていただければ良いと思います。テスト活動が公式なものとなればなるほど正確さも要求されますし、テスト工数が潤沢なものとなればなるほど、スピードよりも正確さを優先すべきです。
プロジェクト内で判明しているファクターを並べていき、これまで述べてきました粒度が粗め & 細かめのテストケースのメリット & デメリットを比較しつつ判断されることをおすすめいたします。
あとがき
私が本ブログを書いた頃はネット上でJSTQB Advanced Levelに関して無料で参照できる有力な情報が著しく乏しい状況でした。このため、日本人の方でJSTQB Advanced Levelに合格するためには以下のいずれかの行動が必要となっており、英語が超得意な方でもない限りハードルの高い状況となってしまっていました。
社内研修や有料セミナーを通じ、企業の占有しているナレッジにアクセスすること
ISTQB Advanced Levelの英語の参考書や過去問を読み解いていくこと
ISTQB Advanced Level学習時に得た知見をネット上に開放し、少しでもJSTQB Advanced Level諸試験の勉強を進めるためのハードルを下げるとともに、我が国のソフトウェアテスト水準向上に貢献したい（ちょっと大袈裟？笑）。そのような想いから、今回の3ブログ投稿に至りました。皆さんが本記事を読まれる頃には、このようなナレッジがネット上でも当たり前のものとなっていることを願ってやみません。
他にもISTQB/JSTQB関連で以下のブログを書いてみました。 もしご興味おありの方がいらっしゃいましたら、併せてぜひご覧くださいませ。
参考文献
1. ISTQB Certified Tester Advanced Level Test Analyst (CTAL-TA) Syllabus
『Low-level and High-level Test Cases』章
下記ページ右部の「Download Materials」> 「Syllabus」よりダウンロードできます。
https://www.istqb.org/certifications/test-manager
※2023年7月7日時点
2. テスト技術者資格制度 Advanced Level シラバス日本語版 テストアナリスト
『具体的テストケースと論理的テストケース』章
下記ページのシラバス（学習事項）> Advanced Level> 「- テストアナリスト（ALTA）・テクニカルテストアナリスト（ALTTA）」>「テストアナリスト シラバス」よりダウンロードできます。
https://jstqb.jp/syllabus.html
※2023年7月7日時点
3. ISTQB Advanced Level Syllabus Test Manager Syllabus
下記ページ右部の「Download Materials」> 「Syllabus」よりダウンロードできます。
https://www.istqb.org/certifications/test-manager
※2023年7月7日時点
4. テスト技術者資格制度 Advanced Level シラバス日本語版 テストマネージャ
下記ページのシラバス（学習事項）> Advanced Level> 「- テストマネージャ（ALTM）」よりダウンロードできます。
https://jstqb.jp/syllabus.html
5. Rex Black氏著、『Advanced Software Testing Vol.1』(RockyNook Computing社)
「1.5 Test Design」章
6. C.Newbould氏著、『Software Testing Advanced Test Analyst-Complete Guide for ISTQB Exam』(AiFlex Publishing社)
執筆者プロフィール：相澤 恒自
幼少期のうち計8年間をワルシャワ（ポーランド）、モスクワ（ロシア）のインターナショナルスクールで過ごす。慶應義塾大学法学部政治学科卒業後、2017年4月に某ソフトウェアテスト専門会社に新卒入社。初年度にJSTQB Foundation Level(CTFL)を取得。約2年半テスト設計やテスト実行に従事し、2020年12月に株式会社SHIFTに転職。2022年1月にASTQB Certified Tester, Advanced Level Test Analyst(CTAL-TA)、同年5月にASTQB Certified Tester, Advanced Level Test Manager(CTAL-TM)を取得。以後、テスト設計やテスト実行をリードする業務、プロジェクト管理ツールのJIRAにより試験報告の仕組みを構築する業務、試験統括の支援業務などを担当。2019年以降は複数の通信キャリアのプロジェクトを行き来しつつ、BSS:Business Support System（業務支援システム）の開発を対象とするグローバルなマルチベンダープロジェクトにて奮闘中。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/