ISTQB Advanced Level Test Managerに学ぶテストマネジメントのカスタマイズ
はじめに & 事前のお断り
みなさんこんにちは。
2022年にASTQB Certified Tester Advanced Level Test Analyst(CTAL-TA) & Test Manager(CTAL-TM) 試験に合格しました、QAの相澤です。
※1 ASTQBはISTQBのアメリカ合衆国支部に相当します。ソフトウェア技術者のテスト技術向上を目的とした資格認定制度です。
今回はISTQB Certified Tester Advanced Level Test Manager試験(+一部 Expert Level Test Manager参考書)にスポットライトを当て、以下を目論んでの本記事とします。
日々のプロジェクトにも活用できる内容の共有
エッセンスのご紹介
ソフトウェアテストの認知&水準向上
Test Manager試験はテストチームのマネジメントを志す方向けの試験です。 本記事は「マネジメントの中でもテストに特化した部分に自信がない」、そんな方を想定した内容となっています。特に今回は紙面の都合上皆様の取るべき具体的アクションに結びつく内容を網羅的に触れるのが困難となり、詳細は割愛されている傾向にあります。「ちょうどこんなことをクリアにしていきたい」、そう思われた方はぜひ最後にご紹介する参考文献をもとに学習を進めていきましょう！
また、あくまでISTQBで学習した内容をご紹介しているため、私相澤は皆様のプロジェクトの結果に対して一切の責任を取りかねます。無論、皆様の成功を願っておりますが、どうかご理解いただけますと幸いです。
おもなメッセージ
結論から言います。
「あるべきテスト像」は一定なものではありません。プロジェクト毎に変わってきます
全てご自身で対応されるかどうかはともかく、以下の段取りも考慮に入れてプロジェクト内のテスト活動の詳細を落とし込んでいきましょう
テスト活動の目的・方針の策定
テストのアプローチの策定
活動の目的・方針・アプローチを元に、収集したい情報の取り決め。テストケースや不具合チケットと紐づける項目等の策定による情報収集の仕組み構築
これらのメッセージに対して更に理解を深めたい方は以降の内容もぜひ。 今回は特にテスト特有と思われる、上記#3を中心に取り扱います。
プロジェクト毎に変動するテスト像
そもそも何のためのテスト？
なぜテストに関わる組織は開発組織との有機的な連動を必要とするのでしょうか。 決して簡単な問いではありませんが、ここではイメージを掴んでいただければと思います。
そもそも、一体何のためにテストをするのでしょうか？ 究極的には「お客様のニーズを満たすため」 なのかもしれません。 ですが、各プロジェクトにおいて、「お客様のニーズを満たすこと」とは一体どういうことなのでしょうか？ テストにあたっての優先事項は何でしょうか？ 何を満たせばテスト活動は成功したと言えるのでしょうか？
さしずめ以下などがテストの目的例として考えられるのではないでしょうか。
品質基準系
致命的な不具合を発見するため
細やかな不具合を発見しておくため
プロダクト品質に対して自信を得るため
リスク管理系
プロダクトにまつわるリスクを管理するため
運用系
ソフトウェア品質にまつわるリスクに事前対処するため
他のステークホルダーと対象のソフトウェア品質に関する認識を揃えるため
→リリース前にひととおりの不具合を洗い出し、事前にワークアラウンド時の運用を決めておく等
上記の全てを実現できれば何て素晴らしいことでしょう。 けれど、応えていく要求を増やすと費用もかさんでしまうのが世の常です。 中でも譲れないポイントは何なのか、ここが決まってくることに応じてあるべきテスト像も変わってくることをイメージとして掴んでいただけていることを願います。
あるべきテスト像を左右する要素
さて、めでたく第一歩「テストの目的」が定まったとします。 これであるべきテスト像も定まるものでしょうか？ もちろん他にも考慮すべき要素があります。 以下に挙げる要素はテストプロジェクトが始まった後、所与のものになっていることもあり得ます。しかし、テストの目的にも応じて以下を最適化できることも望ましいでしょう。
ソフトウェア開発ライフサイクル：ウォーターフォール、アジャイル、インクリメンタル開発、スパイラル開発等
要件、仕様書等のドキュメントの充実度
テスト活動のために活用できる成果物
プロジェクトのスケジュール、人的リソースと納期との兼ね合い
実装変更のサイクル：実装変更が頻繁に行われれば行われるほど、デグレのリスクは増加するものと考えられる
遵守すべき規制やガイドラインの有無
上記を強引に関数に置き換えてみた場合、以下のようになります。 あるべきテスト像=f(あるべきテスト像を左右する要素) つまり、関数で言うところのインプットに相当します。
いくつか具体例も挙げてみます。
ソフトウェア開発ライフサイクルを例にとります。 ウォーターフォール開発で要件や仕様のドキュメントが充実している場合、アジャイル開発でドキュメントが不足している場合よりも開発者への仕様質問や認識合わせは少なくて済むでしょう。
次に、実装変更のサイクルを例にとります。 もしインフラ面を固定した場合、デグレが生じ得るのは基本的に実装に変更を加えた際です。このため、実装変更が頻繁に入れば入るほど、デグレのリスクが増します。実装変更が入るたび、デグレの有無を確認するリグレッションテストを毎度人手で賄っていては費用もかかりますし、毎度同じ内容を人がテストするのは退屈だったりもします。でも言い換えると、リグレッションテストは新規機能に対するテストよりもテスト内容を変える頻度は少なくて済みます。このため、テストケースのメンテナンスが少なくて済むことから、テスト自動化との相性も良いようです。
テストのあり方の中で左右される要素
先ほどはあるべきテスト像を導くためのインプットたちをご紹介いたしました。 それでは関数のアウトプットに相当するものにはどのようなものがあるのでしょうか。 以下を例として挙げさせていただきます。
テストのアプローチ
分析的、モデルベース、規制・ガイドライン、実操作ベース、相談ベース、リグレッション予防的
成果物
テスト粒度
テスト結果の共有/報告方法
→既存バグの内容やworkaroundの共有も含む計測対象
テストの開始/終了基準
テストツール
テスト環境
テストのフェーズ
テストのアプローチは説明すると長くなりますので、詳細はISTQB/JSTQBのシラバスやテキストに委ねたいと思います。 計測対象について後に関連する内容をご紹介いたしますので補足します。 たとえばテストの目的として「致命的な不具合発見」を優先する場合、不具合チケットやテストケースに最低限不具合の優先度や緊急度に関する情報を紐付ける必要が出てくるでしょう。一方、「リスクへの事前対処」を優先する場合、不具合チケットやテストケースにリスク項目を紐付ける必要が出てきます。つまり、テストの目的に応じて優先して計測すべき情報が変わってくるのです。
テスト粒度について本記事で述べると長くなってしまうため、詳しくは以下の記事でご説明しております。ご興味おありの方はぜひ。
『ISTQB Advanced Test Analystに学ぶテストケース粒度』
トレーサビリティと計測
導入
唐突ですが、Test Manager試験の勉強中に遭遇した格言をご紹介したいと思います。
What gets measured gets done. What does not get measured does not get done.
訳するなれば、 「計測されることは遂行され、 計測されないことは遂行されない。」 あるいは 「計測なくして遂行なし」 といった具合でしょうか。 一人ならともかく、大人数になればなるほど計測を徹底することの重要性が増していくことが伺えますね。
トレーサビリティとは
いきなり「トレーサビリティ」と聞いてピンと来る方はなかなか居ないのではないかと思います。一言で言いますと、「紐づき」ぐらいの理解で良いと思います。念のため、ISTQB用語集からの説明を載せておきます。
トレーサビリティ（traceability）
互いに関連する成果物や項目間の関係性が明示できること
検索元は以下のISTQB公式の用語ページです↓
https://glossary.istqb.org/jp/search/
なぜトレーサビリティが重要なのか
トレーサビリティが重要な理由をいくつか挙げてみます。
トレーサビリティ対象に万一漏れがあった際に、別項目起点で不足を洗い出すことができる
要件/仕様変更時の影響範囲の把握のため
テスト内容を監査できるようにするため
規制/ガイドラインへの対応
各ステークホルダーの関心に応じた報告のため
→前提:報告相手によって関心事は異なる
次に、トレーサビリティ対象になり得る項目と、トレーサビリティの具体例を見ていきましょう。
トレーサビリティ対象項目
トレーサビリティの付与対象には以下の項目などが考えられます。
ソフトウェア品質特性
ビジネス/システム要件上の項目
仕様書上の項目
コンポーネント
機能名
テスト条件
テスト観点
High-levelテストケース（粒度が粗めのテストケース)
Low-Levelテストケース（粒度が細かめのテストケース）
リスク分析時のリスク項目
規制/ガイドライン上の項目
でも、これらを羅列しただけだと何だか分かりにくいですよね。 次にいよいよ、トレーサビリティの具体例をご紹介いたします。
トレーサビリティの具体例
たとえば、とあるテストチームがアプローチとして要件ベースのテストを採用していたとします。そうしますと、トレーサビリティの例としては以下などが考えられます。
ビジネス要件⇔システム要件⇔コンポーネント⇔機能⇔テストケースといったように成果物/項目間をたどっていくことができ、それぞれ紐づきが生じていることが見て取れるかと思います。これがトレーサビリティです。ここで、先ほどのトレーサビリティ対象項目たちを思い浮かべていただきたいのです。
ソフトウェア品質特性を例にとってみましょう。 「ざっくりと、機能面と非機能面のプロダクト品質を把握できるようにしたいなあ」。もしこのように思われた場合、テストケースや不具合チケット上で機能or非機能を識別できるようにすれば良いのです。 「いや、うちのプロジェクトではもっと細かく、機能性・効率性・保守性など、ソフトウェア品質特性毎にプロダクト品質を把握できないといけない」。もしこのように思われた場合、もっと細かく各品質特性をテストケースや不具合チケット上に紐づけていけば良いのです。もちろん紐づけ粒度が細かくなればなるほど労力もかかりますので、その点は要注意ですね。
「うちのプロジェクトだとお客様内での監査を通過しないとリリースできないんだよなあ。」 そんな場合、予め監査対象項目を入手しておき、テストケースと監査対象項目を紐づければ、後々容易に監査対象項目毎のテストケースPASS率を割り出すことができるようになるでしょう。
また、成果物間の関係性は大別すると以下に分類でき、網羅性などの把握に一役買うものです。 ですが詳細に関しては今回は割愛いたします。
1対1
1対n
n対1
n対n
これらはあくまで代表的な例に過ぎません。プロジェクト毎のテスト目的に応じて最適なトレーサビリティを考え、テストケースや不具合チケットと必要な情報を紐づけることで必要な情報を収集できる仕組みを構築していきましょう。
あとがき
私が本ブログを書いた頃はネット上でJSTQB Advanced Levelに関して無料で参照できる有力な情報が著しく乏しい状況でした。このため、日本人の方でJSTQB Advanced Levelに合格するためには以下のいずれかの行動が必要となっており、英語が超得意な方でもない限りハードルの高い状況となってしまっていました。
社内研修や有料セミナーを通じ、企業の占有しているナレッジにアクセスすること
ISTQB Advanced Levelの英語の参考書や過去問を読み解いていくこと
ISTQB Advanced Level学習時に得た知見をネット上に開放し、少しでもJSTQB Advanced Level諸試験の勉強を進めるためのハードルを下げるとともに、我が国のソフトウェアテスト水準向上に貢献したい（ちょっと大袈裟？笑）。そのような想いから、今回の3ブログ投稿に至りました。皆さんが本記事を読まれる頃には、このようなナレッジがネット上でも当たり前のものとなっていることを願ってやみません。
他にもISTQB/JSTQB関連で以下のブログを書いてみました。 もしご興味おありの方がいらっしゃいましたら、併せてぜひご覧くださいませ。
2023年7月7日、相澤 恒自
参考文献
1. ISTQB 『Certified Tester Advanced Level Syllabus Test Manager』
下記ページ右部の「Download Materials」> 「Syllabus」よりダウンロードできます。
https://www.istqb.org/certifications/test-manager
※2023年7月7日時点
2. テスト技術者資格制度 Advanced Level シラバス日本語版 テストアナリスト
『1.5.1 具体的テストケースと論理的テストケース』章
下記ページのシラバス（学習事項）> Advanced Level> 「- テストマネージャ（ALTM）」よりダウンロードできます。
https://jstqb.jp/syllabus.html
※2023年7月7日時点
3. Rex Black氏著、『Advanced Software Testing Vol.2』(RockyNook Computing社)
4. Rex Black氏・Leo van der Aalst氏・James L.Rommens氏著、『The Expert Test Manager』(RockyNook Computing社)
執筆者プロフィール：相澤 恒自
幼少期のうち計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/