1. WACATE2019 夏
テスト計画の立て方

2. *Goalテスト計画の理解を深め、重要性を知り、
作成するセンスを身につけ、その可能性
を感じつつ、苦手意識を持つことなく、新
しい武器としてテスト計画を扱うための感
覚を持っている状態

3. エンタープライズシステムの開発者、プロジェクトマネージャなどを経験後、テスト技術者へ転
向。 ネット証券のシステム開発部門のテストチームのリーダーを経験後、現在のLIFULLでソ
フトウェアテスト技術の展開に従事。
共著に「ソフトウェアテスト教科書 JSTQB Foundation 第3版」。
NPO法人ソフトウェアテスト技術振興協会（ASTER)理事/JSTQB技術委員/JaSST'19
Tokyo 共同実行委員長など。
*自己紹介
中野 直樹
株式会社LIFULL
LIFULL技術開発部 品質改善推進ユニット QAグループ長 兼 ユーザーファースト推進ユニット長
3

4. *本日お伝えしたい 3つのこと
What is a Test Plan Technique ７RULES
テスト計画とは何か
テスト計画に関わるテストの用
語と概念の説明
テスト計画を早く作るための
テクニックと考え方
テスト計画の技術をどう役立てるのか
私の7つのルール
8cN
20cN
11cN
18cN 21cN
18cN
4

5. ü ソフトウェアテストとは道である。華道や書道のように、テストの道には終わりはない
ü テスト計画の作成方法に、明確な正解はない
ü 同じプロジェクトは2つとないので、結果としてテスト計画の良し悪しを検証するのは難しい
ü テスト計画のスキルがほしい場合、まずは型を身につける。守破離の守として、テスト計画を立てるため
の感覚を持てるようにする
*先に知っておいてほしいこと
5

6. テスト計画とは何か
テスト計画に関わるテストの用語と概念の説明
What is Test Plan
01

7. ü テスト計画では、テストの目的と、状況により課せられる制約内でテストの目的を達成するためのアプ ローチを定義する（例
えば、適切なテスト技法とタスクを指定し、納期に間に合うようにテストスケジ ュールを作成する）。テスト計画書は、モニタリ
ングとコントロールの活動からのフィードバックに応じて更新をする。(*1)
ü 計画されたテスト活動の狙い、アプローチ、リソース、スケジュールを記述す るドキュメント。テストアイテム、テストすべきフィー
チャ、タスク、各タスク担当者、テスト担当者の独立の度合、テスト環境、用いるテスト設計技法と開始・終了基準、それら
の選択の理論的根拠、それに代替 計画を必要とするあらゆるリスクを識別する。これはテスト計画プロセスの記録である。
[AEer IEEE 829] (*2)
ü 各テストレベルにおいて、テスト計画作業はそのレベルのテストプロセスの開始時に始まり、そのレベルの終了作業が完了す
るまで、プロジェクト全体を通じて継続する。そこでは、テスト戦略で特定された使命や目的を達成するために必要な、活
動とリソースの特定を行う。また、テスト計画作業では、プロジェクトのガイド、計画順守の判断、および目的の達成の評価
に使用されるメトリクスを収集し追跡する方法も特定する。計画作業段階で有用なメトリクスを決定することにより、ツール
の選択、トレーニングのスケジュール、および文書化ガイドラインの作成が可能となる。 (*3)
*テスト計画とは
テストの目的や狙いを明確にし、アプローチを定義する。また、テスト設計や開始終了基準を定める。
計画はテストプロセスの開始時に始まり、完了するまで継続する。
つまり、テスト計画書には、テストプロジェクトのグランドデザインが記載されるべきである。
7
*1: ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストマネージャ Version2012.J03 作成：International Software
*2: ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J02
*3:ソフトウェアテスト標準用語集 日本語版 Version 2.3.J02
ソフトウェアテスト資格のデファクトスタンダードであるJSTQBから学ぶ

8. ü テスト戦略
ü テスト分析
ü テスト条件
ü テスト設計
ü テスト実装
ü テストベース
ü テストウェア
ü テストアイテム
ü プロダクトリスク
ü プロジェクトリスク
ü テストレベル
ü テストタイプ
ü テストサイクル
ü 品質特性
etc..
*テスト計画を理解するために
8
テストに関する用語も必要最低限理解しましょう

9. *先人に学ぶ
彼らが残した言葉にも目を向けてみる

10. *テスト計画を先人に学ぶ
Professor of Software Engineering at Florida Institute of Technology, and the Director of Florida Tech's
Center for Software Testing Education & Research (CSTER) since 2004.
“
Cem Kaner
Florida InsXtute of Technology
J.D., Ph.D.
Cem Kaner先生、高橋寿一さんの先生ですね
https://en.wikipedia.org/wiki/Cem_Kaner
10

11. ü 「テスト計画の作成を考えた場合，テスト計画は非常に異なった二つの目的を持っている。その一つは製品であり，もう一つ
はテストするための道具である。」
ü 「テスト計画は，テストプロジェクトを管理し，バグを見付け出すのに役立つという意味において価値の
ある道具である。その範囲を逸脱したものは資源の無駄になる」
ü 「テスト計画を作成することによって，たくさんある利点の全てを享受している組織はほんの一握りにす
ぎない。」
*Testing Computer Software
基本から学ぶソフトウェアテスト〜テストの「プロ」を目指す人のために〜より引用*1
*1:https://www.nikkeibp.co.jp/atclpubmkt/book/01/P81130/
Cem Kaner, Jack Falk, Hung Quoc Nguyen 著、テスト技術者交流会 訳
11

12. Rex is the most prolific author in the field of soEware tes^ng. His fourteen popular books
have sold over 100,000 copies around the world and have been translated into over a
dozen languages.
*テスト計画を先人に学ぶ
Rex is the past President of the ISTQB and of the ASTQB. He leads the Agile Working Group, is a lead
author for the Advanced Test Manager syllabus, and participates in a number of other syllabus teams as
well.
“
Rex Black
Rex Black Consulting Services, Inc. (RBCS)
President
日本のテストマネジメントの父が佐々木さんなら、世界のテストマネジメントの父はRexさんかもしれない。
https://rbcs-us.com/about/our-team/
12

13. ü 「今までに経験したほとんどのプロジェクトでは、テスト計画のもっとも重要なポイントは文書そのもの
を作成することよりも、それを媒介にした合意、期待、コミットメントをいかに形成するかというプロセ
スにあった。」
ü 「計画を策定して文書化する意義は、テストサブプロジェクトに関わる利害関係者全員にテストチームの
意図を知らせることと、主要メンバー全員に各自の役割と責務を知らせることにあり、計画書作成はそれ
を確実にするステップなのである。」
*Critical Testing Processes
ソフトウェアテスト12の必勝プロセス テストの計画・準備・実行・改善を究めるために より引用*1
*1 hcps://shop.nikkeibp.co.jp/front/commodity/0000/P82120/
13

14. テスト計画に関係する規格や標準からも
必要な知識を学びましょう
*規格・標準

15. ü 概要（Overview）
ü 文章を特定する情報（Document specific information）
ü 文書ID（Unique identification of document）
ü 発行組織（Issuing organization）
ü 承認権限（Approval authority）
ü 変更履歴Change history）
ü はじめに（Introduction）
ü スコープ（Scope）
ü リファレンス（References）
ü 用語（glossary）
ü テストのコンテキスト（Context of the testing）
ü プロジェクト / テストのサブプロセス（Project(s) / test sub-process(es)）
ü テストアイテム（Test item(s)）
ü テストスコープ（Test scope）
ü 想定と制約（Assumptions and constraints）
ü ステークホルダー（ Stakeholders）
ü テストのコミュニケーション（Testing communication）
ü リスク台帳（Risk register）
ü プロダクトリスク（Product risks）
ü プロジェクトリスク（Project risks）
*Test Plan Items
標準的なテスト計画の項目をISO20119に学ぶ
実際に作成するテスト計画では、すべての項目は採用しないかもしれないが、知っておいて損はない
15
ü テスト戦略（Test strategy）
ü テストのサブプロジェクト（Test sub-processes）
ü テストの成果物（Test deliverables）
ü テスト技法（テストのアプローチ）（Test design techniques）
ü テスト完了基準（Test comple^on criteria）
ü 収集するメトリクス（Metrics to be collected）
ü テストデータ要件（Test data requirements）
ü テスト環境要件（Test environment requirements）
ü 再テストと回帰テスト（Retes^ng and regression tes^ng）
ü 中断と再開基準（Suspension and resump^on criteria）
ü 組織のテスト戦略からの逸脱（Devia^ons from the Organiza^onal Test
Strategy）
ü テスト活動と見積り（Tes^ng ac^vi^es and es^mates）
ü 体制（Staffing）
ü 役割、活動、および 責任（Roles, ac^vi^es, and responsibili^es）
ü 雇用ニーズ（Hiring needs）
ü トレーニングニーズ（Training needs）
ü スケジュール（Schedule）

16. *品質モデルをどう捉えるか
JIS X 25010:2013 システム/ソフトウェア 製品品質
https://www.ipa.go.jp/files/000045962.pdf
16

17. テスト計画を早く作るために
高速に作るためのテクニックと考え方
Technique
01

18. *料理のレシピで考える
レシピが伝えてくれることには、足りない要素が沢山ある
同じレシピでも、料理する作り手によって味は異なる
https://www.kikkoman.co.jp/homecook/search/recipe/00006531/index.html
18

19. 探索的テストの書籍などでも
有名なJames Whittaker
ネットには様々な講演のログが残っている
彼から、テスト計画を高速に作成するという
プラクティスを学びたい
*作成する速度

20. *テスト計画を先人に学ぶ
James’ first stint at Microsoft was in Trustworthy Computing and Visual Studio. He then joined Google as
an engineering director and led teams working on Chrome, Maps and Google+. In 2012 James rejoined
Microsoft.
“
James Whittaker
Microsoft
Distinguished Engineer and Technical Evangelist
Google や Microsoft でテストをリードした テスト界のトップランナー
https://www.crunchbase.com/person/james-whittaker#section-overview
20

21. ü 私はテスト計画のタスクを数時間から数日の間に確立することにしています。そのように生み出された計画書に価値がある
かどうかについては、まったく別の話です。
ü 私のチームが書いた何十種類ものテスト計画を見るたびに、役に立たないテスト計画がみられます。計画が細か過ぎるある
いは少なすぎる場合にもテスト計画は放棄されます。
ü 私はチームのために簡単なタスクを考え出しました。それは、「テスト計画を10分で作成する」です。 考え方は単純です。テ
スト計画に何か価値がある場合、できるだけ早くその価値に到達するというものです。
ü 私は彼らに10分を与え、1時間分の成果を望みました。 彼らは30分で作業の80％を完了しました。 80％で十分ではあり
ませんか？ 私たちはすべてをテストするつもりはないことを十分に知っています。
*The10MinuteTestPlan
EuroSTAR Software Testing Video: Ten Minute Test Plan with James Whittaker
hcps://www.youtube.com/watch?v=QEu3wmgTLqo
hcps://tes^ng.googleblog.com/2011/09/10-minute-test-plan.html
21

22. 世界的なソフトウェアテストのコンサルタントで
あるレックスからは、テスト計画の重要性や、
テスト戦略やリスクについて学んでいきたい
*テスト戦略

23. ü 分析的戦略
テストチームはテストベースを分析して、カバーするテスト条 件を識別する
ü モデルベースド戦略
テストチームは(実際の状況または予想される状況に基 づいて)、システムが存在する環境、システムに対する入力と
条件、および本来のシステムの動作方法 の各モデルを作成する
ü 方法論的戦略
テストチームは品質標準(たとえば ISO 9126 [ISO9126]から改訂中の ISO 25000 [ISO25000]など)の事前に決定した
一連のテスト条件、チェック リスト、あるいは特定のドメイン、アプリケーション、またはテストのタイプ(たとえばセキュリティ
テストな ど)に関連する汎用的かつ論理的な一連のテスト条件を使用する
ü プロセス準拠または規格準拠戦略
テスト チームは規格委員会または他の専門家達が定義した一連のプロセスに従う。このプロセスでは、文書 化、テス
トベースとテストオラクルの適切な識別と使用、およびテストチームの編成を行う
ü 対処的戦略
テストチームはソフトウェアを受け取るまでテスト の設計と実装を待ち、テスト対象の実際のシステムで対処する
ü コンサルテーションベースの戦略
テストチームは一人以上の主なステーク ホルダの入力に依存して、カバーするテスト条件を決定する
ü 回帰的テスト戦略
テストチームは回帰のリスクをマネジメントするさまざまな技 法(特に 1 つ以上のレベルにおける機能/非機能回帰テス
トの自動化)を使用する
*テスト戦略
狭義のテスト戦略では、テストの設計方針を決定する
（詳しくは JSTQB Advanced Level Test Manager*1 に定義がある）
*1 http://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TM_Version2012.J03.pdf
23

24. ü テスト戦略（Test strategy）
ü テストのサブプロジェクト（Test sub-processes）
ü テストの成果物（Test deliverables）
ü テスト技法（テストのアプローチ）（Test design techniques）
ü テスト完了基準（Test completion criteria）
ü 収集するメトリクス（Metrics to be collected）
ü テストデータ要件（Test data requirements）
ü テスト環境要件（Test environment requirements）
ü 再テストと回帰テスト（Retesting and regression testing）
ü 中断と再開基準（Suspension and resumption criteria）
ü 組織のテスト戦略からの逸脱（Deviations from the Organizational Test Strategy）
*テスト戦略
テスト戦略には、テスト設計の方針を示す側面だけでなく、
テストプロジェクトを効率的に進めるという側面が存在する
そして、組織としてのテスト戦略を持つことにもできる
24
テスト戦略とは何か、テストプロジェクトにおいて、どのように機能するものなのか
ISO29119の項目をもとにテスト戦略の可能性について考えていきたい

25. 実際の計画を策定、立案する際に、
どのような流れで計画をまとめていくのか
具体的な例を紹介したい
*テスト計画

26. *テスト計画検討フローテスト計画を作り始める当初、どの項目から書いていって良いのか分からなくなることがある
検討する順序を意識することで効率よく作成することができる
26
1.テストする目的
2.リファレンス
3.テストする対象と範囲
4.テストの戦略・アプローチ
5.テストタイプ・テストレベル
6.各テストレベルの開始基準
7.プロダクトリスク
8.テストの成果物
9.テスト環境の要件
10.体制と役割
11.雇用ニーズ
12.コミュニケーション
13.タスク
14.スケジュール
15.中断と再開基準
16.その他
17.発行組織

27. *テストのアプローチ検討の流れ
テスト計画の策定で一番時間がかかるのはテストのアプローチを検討する流れ
検討する流れを感覚的につかむことができれば作成は飛躍的に早くなる
27
1.仕様ベース、構造ベースの機能テスト（網羅的にテストすべき機能やテスト条件への）アプローチ
2.経験ベース（網羅的に考えるべきでない機能やテスト条件への）アプローチ
3.移植性、互換性のテスト（１、２の中で特定の環境でのみ発生するエラーへの）アプローチ
4.性能効率性（パフォーマンスの劣化が懸念される機能やテスト条件への）アプローチ
5.セキュリティや脆弱性の懸念がある機能へのテストアプローチ
6.ユーザービリティの低さに懸念がある機能へのテストアプローチ
7.回帰テストで考慮すべきリスクが高い、でグレードが起こりやすい機能へテストアプローチ
8.上記のテストでケアできないプロダクトリスクに対するテストやレビューなどのアプローチ

28. *テスト計画で語られないコト
テスト計画の策定で一番時間がかかるのは、テストのアプローチを検討する流れ
検討する流れを感覚的につかむことができれば作成は飛躍的に早くなる
28
1.インサイト（洞察と気づき）
2.バックキャスト（ゴールから巻き戻しても予定通りにこなせるのか）
3.見積もりの基準をもつ（全体に対して何割が妥当なのか）
4.苦しくなったらリスクをみる

29. テスト計画の技術をどう役立てるのか
わたしの7つのルール
７RULES
01

30. RULE
テスト計画の可能性を疑わない
30
1

31. RULE
みんなのために計画を作る
31
2

32. RULE
最速で作り共有する
32
3

33. RULE
戦略やアプローチにこだわる
33
4

34. RULE
包み隠さず全部書き出す
34
5

35. RULE
無理だとわかったらなおす
35
6

36. RULE
誰よりもコミットメントを持つ
36
7

37. これからも*
学び続けることで
楽しいQA Life を