テスト計画の立て方 WACATE2019 夏
•
9 likes•5,398 views
WACATE 2019 夏 (2019/06/15-16) の「テスト計画の立て方」のセッションスライドです。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to テスト計画の立て方 WACATE2019 夏
Similar to テスト計画の立て方 WACATE2019 夏 (20)
テスト計画の立て方 WACATE2019 夏
- 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 テストに関する用語も必要最低限理解しましょう
- 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
- 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
- 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
- 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の項目をもとにテスト戦略の可能性について考えていきたい