Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 20170704Wモデル導入の基礎-公開.pdf
Similar to 20170704Wモデル導入の基礎-公開.pdf (20)
More from Tsuyoshi Yumoto
More from Tsuyoshi Yumoto (9)
Recently uploaded
Recently uploaded (16)
20170704Wモデル導入の基礎-公開.pdf
- 1. Wモデル導⼊の基礎 7th Jul. 2016 湯本剛 © Copyright 2017 Tsuyoshi Yumoto
- 2. 2 ⾃⼰紹介 湯本剛 q経歴 1991年 ⼯作機器メーカーにて⽣産管理システムの構築メンバー 1995年 メーカー系列ソフトハウスにてテストリーダとして数多くのアプリケーションの開発に従事 – 財務会計のパッケージソフト、プリンタ、スキャナ、製造業受託開発（在庫管理、⽣産管理など）、顧客向けプロダクト販売Webサイト構築な ど 2003年 ソフトウェアテストコンサルタントとなりテストプロセス改善コンサル、テストツール導⼊⽀援、テスト 教育に従事 2010年 ⽇本ヒューレット・パッカード ソフトウェア部⾨にて、ALM製品のプリセールスに従事 q現在（2017年4⽉） 2013年より、ITサービス部⾨へ移動し、⼤型案件のテストマネジメント、QA組織⽴ち上げのコンサルティング • 2017年1⽉よりITサービス部⾨はヒューレット・パッカードから分離し、⽇本エンタープライズサービスとなり ました NPO法⼈ ASTER︓ソフトウェアテスト技術振興協会 理事／JSTQB︓認定ソフトウェアテスト技術者資格制度 技術委員 ⽇科技連 SQiP（ソフトウェア品質研究委員会）ステアリング委員 ISO/IEC JTC1/SC7 WG26 （ISO29119︓テストプロセス標準の策定）エキスパート 著書 § 書籍（6冊）︓ ビジネス主導のテストプロセス改善、現場の仕事がバリバリ進むテスト⼿法、ソフトウェア テストの基礎、JSTQBソフトウェアテスト教科書、基本から学ぶソフトウェアテスト、ソフトウェアテスト 293の鉄則 § 学術論⽂︓ 「データ共有タスク間の順序組合せテストケース抽出⼿法」電気学会 論⽂誌C Vol. 137 No. 7 § 国際学会︓ A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge など § 雑誌、ネット記事︓ ⽇経ITProなど多数 講演（毎年２~３回程度） • 昨年度実績︓ソフトウェアテストシンポジウム九州（基調講演）、ソフトウェア品質シンポジウム（チュート リアル） © Copyright 2017 Tsuyoshi Yumoto
- 3. 3 アジェンダ ・はじめに ・Wモデルとは何か ・Wモデルに類似したコンセプト ・Wモデル導⼊の阻害要因／事例 ・テストプロセス改善モデルを使った現状把握とロードマップ策定 ・演習︓セルフアセスメント ・総合質疑 © Copyright 2017 Tsuyoshi Yumoto 本テキストで使⽤する⽤語は、基本的に国際資格であるISTQBが発⾏している⽤語集 （⽇本語訳はJSTQB）に従います http://jstqb.jp/syllabus.html#glossary_download
- 4. 4 ⽬的と到達ゴール はじめに ⽬的 • Wモデルを現場で適⽤し、効果を出す この講義の到達ゴール • オリジナルのWモデルの定義を知る • Wモデルのような開発モデル適⽤時の阻害要因を知る • Wモデルを現場に適⽤していくために、改善モデルを適⽤する⽅法を知る © Copyright 2017 Tsuyoshi Yumoto 正しく適⽤すると効果が出ることは確実︕ ＜事例＞ ・テスト実⾏期間が前倒しで終わるようになった ・詳細設計のレビューでテスト技法を使ったテストケース を作るようにして、レビューでの⽋陥検出が向上した ・仕様の問題を仕様書レビューでテスト担当者が⾒つ けるため、仕様上の⽋陥がテストで出なくなった
- 5. 5 本講義の流れ はじめに © Copyright 2017 Tsuyoshi Yumoto ① 本来のWモデルの定義を知る ② Wモデルと似たものを知る ③ Wモデル導⼊の課題を知る ④ テストプロセス改善モデルを使って新しいことを推進する⽅法を知る ⑤ テストプロセス改善の⼀番最初の部分である現状把握をしてみる
- 6. Wモデルとは何か 開発とテストの間の結びつきを強化させた開発モデル © Copyright 2017 Tsuyoshi Yumoto
- 7. 7 Wモデルについて WモデルをSQuBOKで確認すると… • 1993年にイギリスのHerzlichが発表したのが最初だと⾔われている • 2002年にドイツのAndreas Spillner博⼠により発表されたWモデルの論⽂がある – ⽇本では15年前のこの論⽂が広まりWモデルの適⽤が話題になるようになった ⽇本では、15年前の論⽂からいろいろな定義に変化している • JaSST2012東京 「Ｗモデルとは何か」 鈴⽊三紀夫 P12 – テストのアクティビティを前倒しで実⾏すること – テスト仕様書を設計書とほぼ同時に作成すること – テスト技術者を上流⼯程から参画させること – テストチームまたは第三者検証会社を上流⼯程から参画させること – テスト技術を上流⼯程に適⽤すること – 要件定義や設計時にデータバリエーションを作ること – テストの知⾒を早い段階から開発にフィードバック させること © Copyright 2017 Tsuyoshi Yumoto
- 8. 8 Wモデルとは、をオリジナルの論⽂から理解する Andreas Spillner博⼠の提唱するWモデル Vモデルに基づき、テストのタスクが開発のタスクとどのように関係す るかを⽰した開発モデル • 開発アクティビティとテストアクティビティの依存関係をさらに明確にする • テストの重要性を⽰し、個々のテスト活動の順序を明確に⽰す（計画->実⾏） • テストとデバッグが同じものではないことを明らかにする © Copyright 2017 Tsuyoshi Yumoto
- 9. 9 Wモデルが克服する課題／克服できない課題 Andreas Spillner博⼠の提唱するWモデル 過去の開発モデルの課題 • これまでの開発モデルでは、テストプロセスに対する説明が⽋けている – コーディングの後に⾏う「魅⼒に⽋けるタスク」として現れていて、本来の開始時期が明確でない – テストレベルとテストベースの関係が明確ではない – テスト実⾏時のテストタスク、デバッグタスク、変更タスク間の密接なリンクが明確でない • テストに本当に必要な時間／⼯数を誤ってしまい、省略されてしまう Wモデルが克服する課題 • Vモデルに⽰す、開発の右と左といった分割ではなく、開発とテストは常に綿密な協⼒関係が 必要であることを⽰した • プロジェクトの初めから、テスト担当者（Tester）と開発者（Developer）は常にタスクをもち、 平等な権利をもつパートナーとして仕事をすることを⽰した – Wモデルは、テストコストが40％以上与えられると、実践に近づく – テストはテストケースの構築、実⾏、評価だけではない(レビューもある︕)という事実を明確にした • 開発の品質改善に向けたさらなるステップとなる Wモデルでは克服できない課題 • モデルが単純であるため開発プロセスの様々な部分での関係を表現できていない • テストの活動に割り当てるリソースを明確にしていない • アプリケーションによってリソースの割当のバランスがコトンあることを⽰していない © Copyright 2017 Tsuyoshi Yumoto
- 10. 10 各アクティビティの説明 Andreas Spillner博⼠の提唱するWモデル テストアクティビティの開始 • 成熟した開発プロセスでは、レビューとインスペクションをプロセス全体通して実⾏する • 要件⽂書のレビューでは、次のような質問に回答し、開発中に問題が発⽣する前に、問題を⾒ 直し、修正する – すべての顧客要件が満たされていますか︖ – 要件は完全で⼀貫していますか︖ 等々 • しかし、次のような質問に対する答えを期待することが重要である – 要件はテスト可能ですか︖ – この要件は正当化できる⽀出でテスト可能か︖ • 答えが「いいえ」の場合、これらの要件を実装するには問題がある • いくつかの要件をテストする⽅法がわからない場合は、これらの要件を実装する⽅法がわから ない可能性がある • 開発プロセスのこの段階では、受け⼊れテストに関するすべての知識が利⽤可能であり、⼊⼿ できる。受⼊れテストのためのすべての計画と準備を⾏うのに最適な段階である。 たとえば、 以下のことができる – 重要度に応じてテストの優先順位を設定する – （機能的および⾮機能的）テストケースを仕様化する – 必要なインフラストラクチャを指定し、可能であれば提供する – ... • この段階で、受け⼊れテスト準備はすべて完了し、達成することができる © Copyright 2017 Tsuyoshi Yumoto
- 11. 11 各アクティビティの説明 Andreas Spillner博⼠の提唱するWモデル システムテストの準備 • 仕様書のレビュー会議では、次のような質問をするとよい – 仕様はテスト可能ですか︖ – その仕様は正当化できる⽀出でテスト可能か︖ • 回答に応えられる仕様のみが現実的に実装され、開発プロセスの次のステップに使⽤さ れることができる • 質問に対する回答が「いいえ」の場合は、仕様の再作成が必要となる • この段階で、システムテストに必要な情報はすべて⼿元にあり、システムテストの計画 と準備には次のタスクがおこなえる – 重要度に応じてテストの優先順位を設定する – （機能/⾮機能）システムテストケースの仕様化 – 必要なインフラストラクチャの定義と確⽴ – ... • 受け⼊れテスト準備と同様に、システムテスト準備はすべてこの初期の開発段階で終了 する © Copyright 2017 Tsuyoshi Yumoto
- 12. 12 各アクティビティの説明 Andreas Spillner博⼠の提唱するWモデル 統合テスト、ユニットテストの準備 • アーキテクチャ設計の⾒直し中、次のような質問をすることができる – デザインのテスト容易性はどうか︖ – コンポーネントとそれらのインタフェースはテスト可能か︖ – その設計は正当化できる⽀出でテスト可能か︖ • コンポーネントのテストにコストがかかりすぎてできない場合は、開発プロセスを進め る前に、アーキテクチャ設計の再実施を⾏い完了させる • また、この段階では、統合テストのためのすべての情報が利⽤可能であり、制御フロー とデータフローの統合テストケースを抽出するといったすべての準備を⾏うことができ る • したがって、アーキテクチャ設計のレビューと統合テストのすべてのアクティビティは、 ユニットテストのレベルまでに終わらせられる © Copyright 2017 Tsuyoshi Yumoto
- 13. 13 各アクティビティの説明 Andreas Spillner博⼠の提唱するWモデル テスト実⾏ • コーディングが完了したら、⽤意されたテストの実⾏をユニットテストから開始するこ とができる • テスト結果を確認するには、エラーが⾒つかったかどうかを判断する必要があり、 エ ラーの報告後、デバッグが始まる。エラーの原因を特定し、⽋陥の場所を特定し、問題 を修正するかどうか/修正する⽅法を決定する • この仕事はテストの⼀部ではないため、テスト担当者ではなく、開発者が⾏う必要があ る – しかし、両⽅のグループの緊密な協⼒が必要がある • 変更後、再テストにて、テスト担当者は、エラーが修正され、新しい問題が発⽣してい ないことを確認する必要がある • これは通常、テスト-デバッグ - 変更 - 回帰 - 再テストのサイクルとなる • テストの実⾏、デバッグ、変更、再テストのアクティビティは、単体テストから受⼊テ ストまでのすべての段階で⾏われる © Copyright 2017 Tsuyoshi Yumoto
- 14. 14 ここまでのまとめ Wモデルとは何か • Wモデルは今から15年前に提唱された考え⽅である – 既出の開発モデルはテストについて⼗分に表現できていないため、省略されてしまうことが問題 – 開発で本来必要なことを表現し、省略しないことが⽬的 Wモデルに類似したコンセプト Wモデル導⼊の阻害要因／事例 テストプロセス改善モデルを使った現状把握とロードマップ策定 © Copyright 2017 Tsuyoshi Yumoto テストの活動をごちゃまぜにしない︕ テストとデバッグは別の活動だよ︕
- 15. Wモデルに類似した コンセプト 他の「開発とテストの間の結びつきを強化させた開発モデル」の紹介 © Copyright 2017 Tsuyoshi Yumoto
- 16. 16 「体系的ソフトウェアテスト⼊⾨（2002）」で紹介されている⽅法論 STEP テストとは、テスト対象のソフトウェアの品質を測定し、改善するため に、テストウェアをエンジニアリングし、使⽤し、保守する、並⾏的な ライフサイクルプロセス • プロダクトリスク分析（何をテストするのかを明確にする） • テストウェアのエンジニアリング（開発と並⾏に⾏う） • 予防テスト（ソフトウェア、テストウェア双⽅のプロダクトの相互レビュー） ソフトウェアエンジニアリングプロセス 要件定義 設計 コーディング テストウェアエンジニアリングプロセス 分析 テスト戦略 テスト 設計 テスト 分析 テストスクリプト、 テストデータ実装 © Copyright 2017 Tsuyoshi Yumoto
- 17. 17 HP Quality Model（2005） HPQM 効果①︓開発期間の短縮 • テストと開発の並列作業により開発期間が短縮 効果②︓テストコストの削減 • テストコストの削減が開発コスト削減に最も寄与する 効果③︓プロダクト品質の早期可視化 • テストが品質向上に寄与する仕掛け 開発 開発 計画 ビジネス 要件 設計 アプリケーション 配備 テスト 時間 従来開発ライフサイクル 要件の 検証 アプリケーション 配備 ビジネスの成功を最適化する HPQM(HP Quality Model)にそった開発ライフサイクル 計画 ビジネス 要件 設計 テスト の実⾏ テスト の準備 © Copyright 2017 Tsuyoshi Yumoto 要件ツリーの末端がテスト要件 になっているかを検証 リスク分析 を⾏う
- 18. 18 テストを出来る限り早く開始する SHIFT-LEFT testing 昨今、欧⽶では最もトレンドなコンセプト • さまざまな考え⽅が出てきている – Wモデルもシフトレフトの1つとされている • 反復型開発、アジャイル開発に⾔及している – シフトレフトを適⽤するためのテストとして Paul Gerrardが A new model for software testing を提唱 A New model for software testing（2014） • アジャイル／継続的デリバリに対応したテスト ・V字全てが1反復（毎回、統合してテスト） （http://druby.hatenablog.com/entry/2017/06/15 /090724） © Copyright 2017 Tsuyoshi Yumoto ・テストモデル（簡単に⾔うとテスト設計成果物）もプロダクトと同様に成⻑させていく
- 19. 19 「TPINEXT (2009) 」のキーエリアのひとつ 関与の度合い テストプロセス改善モデルであるTPINextで扱う改善すべき領域の1つ • テスト作業がプロジェクトに深く関与すると、開始当初からプロダクト品質が向上しやすく なり、テスト活動がプロジェクトのクリティカルパスに残ることを避けられる – テスト実⾏以外の作業（テスト全体の60％以上をしめる）を開発と並⾏して⾏う – 「体系的な準備を早期に開始」→「深く関与し品質向上に寄与」→「プロジェクト活動全体に寄与」 © Copyright 2017 Tsuyoshi Yumoto TPINEXTの説明にて 詳しく解説します 改善すべき領域（キーエリア）
- 20. 20 ここまでのまとめ Wモデルとは何か Wモデルに類似したコンセプト • Wモデルの提唱と同時期から現在にかけて様々な考えが提唱されている – STEP、HPQMなどの⽅法論はテストによる予防について強く打ち出している – TPINEXTでは、「テストによる予防」に達するまでの道のりを⽰している Wモデル導⼊の阻害要因／事例 テストプロセス改善モデルを使った現状把握とロードマップ策定 © Copyright 2017 Tsuyoshi Yumoto 「テストによる予防」に達するまでに は順番がある︕
- 21. Wモデル導⼊の阻害要因 Wモデル導⼊時のよくある問題／事例紹介 © Copyright 2017 Tsuyoshi Yumoto
- 22. 22 Wモデル導⼊時のゴール設定と活動の定義 Wモデル導⼊のゴール設定に合わせた活動の定義 得たい効果に対して、その効果を得るための活動を公式に追加していない • 効果を出す活動をスケジュールに具体的なタスクとして⼊れていないので効果が出ない – テストケース数の最適化のために、リスク分析で公式にテストの優先度を合意していない 本来やるべき活 動を省略しない テストをクリ ティカルパスに しない テスト実⾏期間 を短縮する テストコストを 削減する 早期品質確保 に寄与する 品質の可視化を する Wモデル導⼊におけるさまざまなゴール設定 テストケース数 を最適化する © Copyright 2017 Tsuyoshi Yumoto リスク分析の⼀連の活動は スケジューリングされて いるか︖
- 23. 23 Wモデル導⼊時のゴール設定と活動の定義 Wモデルに本来必要な定義 （そもそも）Vモデルの定義があいまいで実際の現場に適⽤できていない • 前提の活動（つまり、Vモデル）ができていないので上⼿く出来ない • 例︓テストレベルの定義をしていない（テストレベルは⽇程ではない︕） ユニットテスト 統合テスト システムテスト なんのために︖（⽬的） メソッドレベルの仕様充⾜の 確認と⽋陥の摘出 統合したレベルで実現でき る機能の仕様充⾜確認と⽋ 陥の摘出 完成したレベルで実現でき る機能の要件充⾜確認と⽋ 陥の摘出 どこで︖（テスト環境） 開発⽤パソコン 開発⽤テスト環境（３⾯） 疑似本番環境（2⾯） 何を︖（テストアイテム ／テストベース） メソッド，クラス メソッド定義書 コンポーネント コンポーネント仕様書 全コンポーネント 機能仕様書 着眼点は︖ （テストタイプ） ・ビジネスロジックのテスト ・構造テスト ・画⾯UIからの機能テスト ・データベース接続テスト ・順序組合せテスト ・利⽤シナリオのテスト ・負荷テスト 誰が︖ ※R＆R 計画、設計 プログラマ テストチーム テストチーム 環境構築 プログラマ 開発チームテスト担当 開発チームテスト担当 テスト実⾏ プログラマ 開発チームテスト担当 テストチーム ⽋陥管理 プログラマ テストチーム テストチーム ⽋陥修正 プログラマ 設計者、プログラマ 開発チーム全体 © Copyright 2017 Tsuyoshi Yumoto プロジェクト計画で⾏うVモデルの定義
- 24. 24 テストプロセスの改善 テストプロセス（テスト計画、テスト分析、テスト設計など）の定義 （そもそも）テストプロセスの活動が定義されていない • ちゃんとやっていないテストプロセスを早い段階から始めても効果は期待できない • （経験のない）新しいやり⽅を現場に押し付けると現場は⼤混乱して逆効果となる 新しいやり⽅になれるまでの「駆け込み寺」がない テスト 分析 テスト ベース テスト 条件 テスト 設計 テストケース テスト 実装 テスト 手順 テストの 目的 テスト 計画 テストポリ シー ⽋陥 追跡 基準 評価 報告 進捗 管理 テストウェ ア管理 リリース 管理 コミュニ ケーショ ン マネジメント系の アウトプット テスト⽤ リリース 操作 確認 ⽋陥報告 終了 判定 終わるまで 繰り返し 準備 実⾏ マネジメント © Copyright 2017 Tsuyoshi Yumoto
- 25. 25 テストプロセスの改善 テストプロセス（テスト計画、テスト分析、テスト設計など）の定義 （そもそも）テストプロセスの活動が定義されていない • ちゃんとやっていないテストプロセスを早い段階から始めても効果は期待できない • （経験のない）新しいやり⽅を現場に押し付けると現場は⼤混乱して逆効果となる 新しいやり⽅になれるまでの「駆け込み寺」がない テスト 分析 テスト ベース テスト 条件 テスト 設計 テストケース テスト 実装 テスト 手順 テストの 目的 テスト 計画 テストポリ シー ⽋陥 追跡 基準 評価 報告 進捗 管理 テストウェ ア管理 リリース 管理 コミュニ ケーショ ン マネジメント系の アウトプット テスト⽤ リリース 操作/ 確認 ⽋陥報告 終了 判定 終わるまで 繰り返し © Copyright 2017 Tsuyoshi Yumoto 本来のテストプロセスでやること
- 26. 26 テスト分析／テスト設計スキルの習得 テスト分析のスキル習得 テストケース設計と⾔って仕様書を右から左にコピーペーストしている • テストケースにする前の段階の成果物が明確でなくいきなりテストケースを書く – 変更負荷が⼤きい（Wモデルはテスト成果物の更新を前提にしているので変更量が致命的になる） • （コピーなので）怪しいところ、もやっとするところなどの指摘が出来ない – テスト対象の知識が必要なため、コピーだと頭を使わないため予防効果がでない ゆもつよメソッドの例 © Copyright 2017 Tsuyoshi Yumoto 目的 手段 対象を分析して ⽬的を明らかに する 明らかしたもの を技術を使って 網羅する
- 27. 27 テスト分析／テスト設計スキルの習得 テスト設計のスキル習得 テストケース設計と⾔って仕様書を右から左にコピーペーストしている • テスト設計で何をするのかを知らない – 分析結果を網羅する適切なモデルを作る • テスト設計技法そのものを知らない – モデル作りのベストプラクティス – ドメインに合わせたカスタマイズ も必要 ⼊⼒領域 出⼒に影響を与える ⼊⼒や状態の組合せ 動的な振る舞い ・ ・ ■ テスト条件を網羅するためのテ ストケース設計モデルを選択 ■テスト条件とした仕様項⽬ ＜仕様項⽬の構成要素＞ ・機能を使ってもらうためのI/F ・機能のために他へ要求するI/F ・事前状態 ・外部イベント ・機能に影響を与える内部動作 ・出⼒ ・事後状態 テスト パラメータ アクション 期待結果 ■ テストケース にしたてる © Copyright 2017 Tsuyoshi Yumoto
- 28. 28 テスト分析／テスト設計スキルの習得 なぜテスト分析/テスト設計スキルが重要なのか︖ 関係者（テスト設計する本⼈含む）が納得できるテストケースを⽤意するため • 説明可能（Accountable）︓ – ⽬的→⼿段の構造を作ることで、何を網羅するかが論理的に説明可能になる https://www.slideshare.net/NoriyukiMizuno/jasst17-kansai • 役に⽴つ情報提供︓ – テストは「情報サービス」であるため、必要な情報を提供することが重要（必要な情報=⽬的） • コストに⾒合う合理的な労⼒︓ – やみくもに全部テストするといつまでやっても終わらない チームの成⻑、テストケースを作る実⼒の向上につながるため • テストケースのレビューが容易になり、チームのナレッジ共有が促進する • 構造化しているのでどこに⽋陥から得た知識をフィードバックすべきかが分かる • 再利⽤ができる（変更管理、構成管理ツールとセットで実現） © Copyright 2017 Tsuyoshi Yumoto
- 29. 29 テスト成果物の変更管理／構成管理 テスト成果物の変更管理／構成管理の仕組み構築と機械化 • テストケースを構造的に管理して変更点に対処しやすいようにしていない – データベースでテストケースを管理していない（そのため、データ設計もされていない） – テストケースのバージョン管理をしていない – その為、Wモデルをやるとテストケースの変更が何度も⼊るため、変更⼯数が激増する • テストケースを資産だと認識して、将来に渡って何度も使いまわすという認識がない – 何故か︖が理解できないので仕⽅なくやっている（失敗して当然だと思うので上⼿くできない） © Copyright 2017 Tsuyoshi Yumoto
- 30. 30 関係者との合意 お客様との合意 • 上流⼯程の⾦額が⾼くなることを理解してもらえていない – 特に要件定義⼯程は準委任の場合が多く⾦額に跳ね返る プロジェクトマネージャとの合意 • 上流⼯程でテスト⼯数が増えることを（頭では理解してても）実⾏に移せない – テスト実⾏⼯数を適正化させるように 上流に⼯数が積み上がる計画ができない – Wモデルの活動が感情論と不安感に ひっくり返されてしまう。 JaSST2012東京 「Ｗモデルとは何か」 鈴⽊三紀夫 P10 © Copyright 2017 Tsuyoshi Yumoto
- 31. 31 阻害要因を乗り越えるために⼤事なこと 実現させるモチベーションのために必要な5つのこと ⽬的の共有と合意形成 • お先真っ暗にしないため「この光に向かうんだ︕」 パトロール • 放置しないため「無視されていない︕」 駆け込み寺 • 途⽅に暮れないため「なるほど︕」 ダッシュボード • みんなが同じものを⾒て仕事するため「9回裏2アウト満塁︕」 – 計測とか、報告とか、⼀⾒つまらない仕事は、ダッシュボードのためにある 機械化（ツールを使った効率化） • つまらない仕事を減らすため「刺し⾝たんぽぽはやだ︕」 – 標準化とは、つまりは機械化するための中間過程である © Copyright 2017 Tsuyoshi Yumoto
- 32. 32 ここまでのまとめ Wモデルとは何か Wモデルに類似したコンセプト Wモデル導⼊の阻害要因／事例 • 5つの阻害要因 – Wモデル導⼊時のゴール設定と活動の定義 – テストプロセスの改善 – テスト分析／テスト設計スキルの習得 – テスト成果物の変更管理／構成管理の仕組み構築と機械化 – 関係者との合意（お客様、ブロジェクトマネージャ） • この阻害要因を乗り越えればうまくいくということ テストプロセス改善モデルを使った現状把握とロードマップ策定 © Copyright 2017 Tsuyoshi Yumoto 実現のモチベーションを⾼めよう コミュニケーションも⼤事だよ︕
- 33. Wモデル導⼊のための改善 テストプロセス改善モデルを使った現状把握とロードマップ策定 © Copyright 2017 Tsuyoshi Yumoto
- 34. 34 テストプロセス改善／モデルの必要性 はじめに テストプロセスの段階的な改善を⽀援するモデルの必要性 テストプロセスは開発プロセスの多くの部分を占めている テストを良くするためには技法、⼿法だけで対応できない – 多くの依存関係、想定外の対応を余儀なくされる CMMIやSPICEなどは開発プロセス全体を対象にした改善モデルは、テス トの具体的な改善をガイド・制御しない 開発プロセス全体の中の単⼀のステップで扱われている – CMMIでは、レベル３以上になって初めてテストが取り上げられる – レベル3で登場するプロセス領域(PA)は「検証（VER）」と「妥当性確認（VAL）」の2つだけ テストプロセスが⼗分に分解されていない – PA「検証」の例 • 検証の準備をする • ピアレビューを実施する • 検証を実施する © Copyright 2017 Tsuyoshi Yumoto
- 35. 35 世の中に公開されているテストプロセス改善モデル はじめに 段階的モデル TMMi（テスト成熟度モデル統合...CMMIを基にしたテストプロセス改善モデル） ISO/IEC/IEEE33063 Process assessment model for software testing 連続的モデル TPI NEXT（TPIの後継版として2009年に開発された） CTP（クリティカルテスティングプロセス..RexBlackが提唱） STEP(体系的テストと評価プロセス...RickCriagが提唱) ※段階的モデル、連続的モデルの分類はISTQBテスト技術者資格制度 Advanced Level シラバス ⽇本語版 テストマネージャ Version2012.J03より引⽤ © Copyright 2017 Tsuyoshi Yumoto
- 36. 36 テストプロセス改善に特化した成熟度モデル TPI NEXTとは “⾃⼰評価”とそれに基づく”⾃⼰改善” アセッサにより“認定”したり,”認定”されたりしない 評価軸(通常横軸)はプロセスではない 独⾃に選定した16個のキーエリア ビジネス主導 ［BD（ビジネス主導）のTPI］ TPINextでいう「ビジネス」とは 「テスト業務が実現すべきこと」を指している • 適切な市場投⼊タイミング順守 • コスト削減 • テスト対象の有効性の向上、など 達成度の因果関係を⽰すクラスタ • ビジネス要因を加味したクラスタのカスタマイズ ⽇本語版 – 時期:2015年出版 – 出版社:トリフオリオ – 訳者: 薮⽥和夫、湯本剛、皆川義孝 英語版 – 時期:2013年出版 – 出版社:UTN Publishers – 著者:Alexander van Ewijk, 他6名 © Copyright 2017 Tsuyoshi Yumoto
- 37. 37 TPI NEXTの基本構成要素 TPI NEXTとは © Copyright 2017 Tsuyoshi Yumoto
- 38. 38 16のキーエリアと3つのグループ TPI NEXTとは 利害関係者との関係 テスト管理 テスト業務の専⾨性 利害関係者のコミットメント 関与の度合い テスト戦略 テスト組織 コミュニケーション 報告 テストプロセス管理 ⾒積りと計画 メトリクス ⽋陥管理 テストウェア管理 ⼿法の実践 テスト担当者のプロ意識 テストケース設計 テストツール テスト環境 © Copyright 2017 Tsuyoshi Yumoto
- 39. 39 初期レベル コントロール レベル 効率化レベル 最適化レベル ４段階の成熟度レベル TPI NEXTとは n 初期レベル︓必要なリソースや計画された活動が⼤まかに⾒積もられてる n コントロールレベル︓各活動に対して必要なリソース量が予測できている n 効率レベル︓正式な技法により⾒積や計画を信頼性のあるものにしている n 最適レベル︓⾒積は組織の経験データに基づいて⾏われている アドホック 適切なことを ⾏う 適切な⽅法で ⾏う 刻々と変わる状 況に絶えず対応 する KA［見積もりと計画］の 成熟度レベル定義 © Copyright 2017 Tsuyoshi Yumoto
- 40. 40 成熟度レベルとチェックポイント TPI NEXTとは KA［見積もりと計画］の チェックポイント ※ マトリックスの1~4がチェックポイント 初期レベル（1）︓テスト作業の⾒積もりには⽐率のような単純 な技法が⽤いられている ［YES／NO］ © Copyright 2017 Tsuyoshi Yumoto
- 41. 41 成熟度レベルとチェックポイント TPI NEXTとは チェックリストに全部答えると何が分かるか︖ 1.利害関係者のコミットメント 2.関与の度合い 3.テスト戦略 4.テスト組織 5.コミュニケーション 6.報告 7.テストプロセス管理 8.見積もりと計画 9.メトリックス 10.欠陥管理 11.テストウェア管理 12.手法の実践 13.テスト担当者のプロ意識 14.テストケース設計 15.テストツール 16.テスト環境 初期レベル コントロールレベル 効率化レベル 最適化レベル ※マトリックス中の１～４はチェックポイント © Copyright 2017 Tsuyoshi Yumoto
- 42. 42 成熟度レベルとチェックポイント TPI NEXTとは 何から⼿をつけるか︖ （基本クラスタセット） 1.利害関係者のコミットメント 2.関与の度合い 3.テスト戦略 4.テスト組織 5.コミュニケーション 6.報告 7.テストプロセス管理 8.見積もりと計画 9.メトリックス 10.欠陥管理 11.テストウェア管理 12.手法の実践 13.テスト担当者のプロ意識 14.テストケース設計 15.テストツール 16.テスト環境 初期レベル コントロールレベル 効率化レベル 最適化レベル ※マトリックス中のA～Mはクラスタ © Copyright 2017 Tsuyoshi Yumoto
- 43. 43 成熟度レベルとチェックポイント TPI NEXTとは さっきの例なら、何から、どの順番で改善するか︖ 1.利害関係者のコミットメント 2.関与の度合い 3.テスト戦略 4.テスト組織 5.コミュニケーション 6.報告 7.テストプロセス管理 8.見積もりと計画 9.メトリックス 10.欠陥管理 11.テストウェア管理 12.手法の実践 13.テスト担当者のプロ意識 14.テストケース設計 15.テストツール 16.テスト環境 初期レベル コントロールレベル 効率化レベル 最適化レベル ※薄い茶は、達成している 灰⾊は、最初に改善すべきポイント。A, B, Cレベルで未達 ⾚は、コントロールレベルに達成するために必要な改善 © Copyright 2017 Tsuyoshi Yumoto
- 44. 44 改善の進め⽅ TPI NEXT の改善ステップ 1． 気付きを与える（意識付け） • なぜテストプロセスを改善すべきかを理解 2． ゴール、スコープ、取り組み⽅を決定する • To-Be像と開始ポイントを決定 3． 現状をアセスメントする • As-IS把握（SWOT分析） 4． 改善を定義する • ゴール達成に向けたロードマップ作成 5． ⾏動計画を⽴案する • ⼈員のアサイン、 タイムフレーム 6． ⾏動計画を実施する • 新しい⼿順やテンプレートの適⽤ 7． 評価して再⽅向付けを⾏う • ゴール達成を評価し、評価結果から次のアクションを決定 © Copyright 2017 Tsuyoshi Yumoto
- 45. 45 ゴール達成に向けたロードマップ TPI NEXT の改善ステップ ロードマップの作成⽅法（基本編） 基本クラスタセット • TPINextにて定義した標準的な改善のロードマップ – 筆者たちのこれまでの経験ベース ＜組織がテスト設計技法を使いこなしている状態に改善する例＞ キーエリア「テストケース設 計」テスト技法活⽤がゴール アセスメン結果でOKになっ ていないクラスタBのキーエ リア「テストウェア管理」か ら改善を始める クラスタIがゴール アセスメント結果、クラスタA すべてOKでクラスタBはテスト ウェア管理以外はOKの場合 クラスタBからスタート コントロールレベル 効率化レベル 最適化レベル A ︓テストケースを論理レベルで記述し ている F︓チームの他の⼈が⾒て理解出来て、保 守できる K︓次フェーズで発⽣した⽋陥を分析し、 テストケースの正確性、有効性の向上に 勤めている A︓テストケースには「事前条件」「操 作」「期待結果」がある I︓達成できるテストベースのカバレッジ レベルがわかる K︓テストケースの妥当性と保守性を評価 している E︓テストベースのどこがテスト対象に なっているかがわかる I︓テスト設計技法を⽤いている M︓再利⽤できるようにテストケースの⾒ 直しをしている J︓動的テストができないものでもチェッ クリストを⽤いて確認している OK © Copyright 2017 Tsuyoshi Yumoto
- 46. 46 基本クラスタセット 組織がテスト設計技法を使いこなしている状態に改善 クラスタIがゴール テストウェア管理が未達なた め、クラスタBからスタートして テストケース設計Eを目指す 道程を⾃分たちで 考えるのが 改善の醍醐味 適切なことを⾏う 適切な⽅法で⾏う © Copyright 2017 Tsuyoshi Yumoto
- 47. 47 ⾃組織に合わせたロードマップの作成例 テストケース設計 その他４つのKA 5つのKA 6つのKA I ・テスト設計技法を⽤いている ・達成できるテストベースのカバ レッジレベルがわかる H G F ・チームの他の⼈が⾒て理解出来 て、保守できる E ・テストベースのどこがテスト対 象になっているかがわかる D C B A ・「事前条件」「操作」「期待結 果」が書かれている ・テストケースを論理レベルで記 述している 利害関係者との関係 テスト管理 テスト業務の専⾨性 ＜テストウェア管理＞ だれもがすぐにテスト ウェアにアクセスできる ＜テストウェア管理＞ テストケースにバージョンが ついており、テストベースが どれかわかる。 ＜⼿法の実践＞ プロセスがテスト ⼿法にそっている ＜プロ意識＞ テストに特化したトレーニ ング・体系的なテストの現 場経験がある ＜⼿法の実践＞ 開発スタイルに合 わせてテスト⼿法 を⾒直している ＜コミュニケーション＞ 関連する情報を、関係者 から収集している。 ＜コミットメント＞ コミットしたリソー スを実際に⼿配して いる。 要は、推進するためにやること ・リソース（⼈、道具）確保 ・道具の調達、作成（テンプレート、ツール） ・作業環境の整備 ・他部署へ周知、調整（会議体） ・技術者教育（勉強会、セミナー、⾃⼰学習） 「適切な⽅法」で⾏うその前に、「適切なこと」を⾏う OK © Copyright 2017 Tsuyoshi Yumoto
- 48. 48 ここまでのまとめ Wモデルとは何か Wモデルに類似したコンセプト Wモデル導⼊の阻害要因／事例 テストプロセス改善モデルを使った現状把握とロードマップ策定 • 出来るようにするには順番がある – 「適切なことをする」→「適切な⽅法でやる」→「状況の変化に対応できる」 • 改善したい領域以外の領域の改善も必要になる © Copyright 2017 Tsuyoshi Yumoto ロードマップを作るのを楽しもう︕ どこまで進んだか⾒るために継続的な セルフアセスメントも楽しいよ︕
- 49. 演習 キーエリア「関与の度合い」のセルフアセスメント © Copyright 2017 Tsuyoshi Yumoto
- 50. 50 演習の進め⽅ 「関与の度合い」チェックポイントの解説 セルフアセスメント • 解説を聞きながら チェックしてください グループディスカッション • ３つのテーマで話し合って下さい 結果発表 © Copyright 2017 Tsuyoshi Yumoto
- 53. 53 グループディスカッションメモ 1. グループで話し合った結果、どのレベルでしたか︖ • グループで⼀つの回答でも良いですし、それぞれが別の回答でも良いです （プロジェクトが違うので⼀緒にしないほうが良い場合もあります） 2. メンバーで結果に「違い」がでたチェックポイントはどれですか︖ • 「違い」が出た理由も話し合ってみましょう 3. 何から着⼿していけば良いと思いますか︖ • 道程を⾃分たちで考えるのが改善の醍醐味です︕ © Copyright 2017 Tsuyoshi Yumoto １５︓１５まで 10分休憩 発表 6分
- 54. 54 コントロールレベル クラスタA 「関与の度合い」のチェックポイント解説 1. 最初のテスト活動として、テストの任務、スコープ、取り組み⽅につ いて、早い段階で利害関係責任者と交渉している 以下のことに関して利害関係責任者に最適な⽅法を提案し、認識の齟齬が無い ようにすること ※利害関係責任者＝テストが果たすべき責務に責任をもち、テストのために必要な事前条件を整える 責任を持つ⼈ • テストの任務（テストをする⼈たちに与えられた役⽬、役割） – 1件でも多く機能の⽋陥を⾒つける。Or ユーザが安⼼して使えるかを確認する など – テストレベル毎に決めるのが現実的 • スコープ – 全体的なスコープ、テストレベル毎のスコープ（テストは「積み上げ」て⼗分を保証する） – 機能、環境（H/W、データ）、スケジュール（⽇次、⽉次、年次） など • 取り組み⽅（アプローチ） – テストケースの設計⽅法、テスト実⾏の⽅法、道具（ツール）の利⽤⽅法 など YES NO © Copyright 2017 Tsuyoshi Yumoto
- 55. 55 コントロールレベル クラスタB 「関与の度合い」のチェックポイント解説 2．テスト活動をプロジェクトのクリティカルパスにしないよう、テス ト実⾏よりも前の早い時期に開始している。 テスト実⾏以外の活動がプロジェクト全体のクリティカルパスにならないよう なスケジュール／リソースアサインを利害関係責任者と合意すること（そのた めの交渉をすること） – 書籍では、⼀般的にテスト全体の60％以上がここに該当するとしている ＜例＞ • 各テストレベルの開始基準に「テストの準備完了」がある – 準備には「変更への対処」が含まれる（つまり、バージョン管理、やトレース管理ができること） • 他の開始基準より完了が遅くなるようなスケジュールにしない（開始を早める） YES NO © Copyright 2017 Tsuyoshi Yumoto
- 56. 56 コントロールレベル クラスタC 「関与の度合い」のチェックポイント解説 3．プロジェクト計画において、テストプロセスとその他のプロセスの 依存関係を考慮できるように、テスト担当者が計画に関与している。 プロジェクト計画時に、テストを早期にすることで必要となる活動の開始時期 を開発のスケジュールと調整していること ＜例＞ • テストベースレビューの開始時期は仕様書／設計書作成⽇程から決めている • レビュー結果の対応完了のマイルストーンは再確認のタスクまで考慮して決めている • 要件、設計の変更に伴うテスト成果物の修正作業⼯数を確保している • 双⽅のコミュニケーション基盤となるツールのセットアップ完了マイルストーンを決め ている YES NO © Copyright 2017 Tsuyoshi Yumoto
- 57. 57 コントロールレベル クラスタE 「関与の度合い」のチェックポイント 4．テスト担当者は、プロジェクト全体のプロジェクトリスクの分析と 軽減策の⽴案に関与している。 ※ プロジェクトリスク＝⽇程、コストが計画どおりにならない可能性 以下の内容がプロジェクト全体で管理しているリスク⼀覧にあり、周知されて いること • テストの活動のプロジェクトリスクとその軽減策 • テスト以外の活動のリスクが現実化した場合の、テストの活動に及ぶ影響 • テスト以外の活動のリスク軽減策で対処すべきテストの活動 YES NO © Copyright 2017 Tsuyoshi Yumoto
- 58. 58 効率化レベル クラスタH 「関与の度合い」のチェックポイント解説 5．テスト担当者は、変更要求やテストベースの変更による影響分析お よび（プロダクト）リスク分析に積極的に取り組んでいる。 ※ プロダクトリスク＝開発したプロダクトがリリース後に問題を起こす可能性 変更要求がテストベースにどう反映しているかを調べること • そのために、該当のテストレベルのテストベースだけでなく要求レベルのテストベース からレビューをすること • 変更を調べやすいツールを駆使すること – ドキュメント⽐較ツールや構成管理ツール システムに詳しい⼈員をこの役割に配置すること • これらの活動を通じて計画的に育成する／他の部署から連れてくる 変更要求やブロダクトリスク分析が公式に管理されていること • 管理ツールの利⽤ • 問題点を⾒つけたときの修正までの追跡ルール適⽤ YES NO © Copyright 2017 Tsuyoshi Yumoto
- 59. 59 効率化レベル クラスタH 「関与の度合い」のチェックポイント解説 6．テスト担当者は、⽋陥の影響分析に積極的に取り組んでいる。 ⽋陥がテスト対象にどこまで影響するかを調べること • ⽋陥によってブロックされるテストケース • ⽋陥の修正によって影響を受ける箇所 • 上記の情報から判断できる重要度の設定 システムに詳しい⼈員をこの役割に配置すること • これらの活動を通じて計画的に育成する／他の部署から連れてくる ⽋陥が公式に管理されていること • ⽋陥管理ツールの利⽤ • ⽋陥の分析結果の記録、影響先へのトレース YES NO © Copyright 2017 Tsuyoshi Yumoto
- 60. 60 効率化レベル クラスタJ 「関与の度合い」のチェックポイント解説 7．テスト担当者は、テスト対象が記述されているテストベースのテス ト容易性をレビューするだけでなく、そのテストベースの最適化に積極 的に関与している。 ※ テスト容易性=網羅基準の達成しやすさ/テストで⽋陥を発⾒しやすい の２つの側⾯がある テストベースのテスト容易性に関する課題をテストの視点から伝えること ※あくまでテストの視点ということがポイントであり、⾏き過ぎた⼲渉はNG ＜例＞ • 期待結果の記載（テスト条件記載の推進） • 代替処理、例外処理の記載（デシジョンテーブル利⽤の推進） • 上位レベル⽂書、同レベルの⽂書との⼀環性の確保（チェックツール利⽤の推進） YES NO © Copyright 2017 Tsuyoshi Yumoto TPINEXTではこの「テスト容易性レ ビュー」が予防を実現する活動︕
- 61. 61 最適化レベル クラスタL 「関与の度合い」のチェックポイント解説 8．テストチームがプロジェクトの評価に関与している。テストプロセ スから学んだ教訓を貴重なものだと評価して、その後のプロジェクト （の準備）に利⽤している。 ※ここからは、1プロジェクト内の話にとどまらず、組織としての話になる これからWモデルのようなプロセスを適⽤して予防できた⽋陥、予防できな かった⽋陥を整理して、改善策を決めて他のプロジェクトに横展開すること • ナレッジを有効活⽤できるデータベースがあり、活⽤できている YES NO © Copyright 2017 Tsuyoshi Yumoto
- 62. 62 最適化レベル クラスタL 「関与の度合い」のチェックポイント解説 9．該当するすべての開発活動で、テストチームが重要な位置付けであ ると認め、⾼く評価している。 開発の全てのフェーズでテストに関する知⾒が役にたつことをテスト担当者が 提案し、実証すること • テストチームに⼊るテスト担当者のスキルとして、要求分析、アーキテクチャ設計が ⼊ってくる • プロジェクトの企画段階（プロジェクトにいくらお⾦をかけるか決める段階）から、テ スト担当者が⼊る ここまでテストが関与することが、開発にとって意義があることを関係者が理 解していること • テストウェアはプロダクトの⼀部であり、Go-liveしてから使うものである • テストはコストではなく上記プロダクトのための投資である YES NO © Copyright 2017 Tsuyoshi Yumoto
- 63. 総合質疑 キーエリア「関与の度合い」のセルフアセスメント © Copyright 2017 Tsuyoshi Yumoto
- 64. 64 事前に頂いた質問のまとめ 開発規模 • ⼤規模はマネジメントが難しいが、しっかりテストをするためのコスト捻出は容易。 • 中⼩はスキルをもったメンバアサインで実現可能であるが、コスト捻出が困難。 →Wモデルが運⽤にのり、使えるテストメンバを0.5⼈⽉レビューにあてるといったアサ インができるとよい。 開発対象の種類 • アプリケーションのパラメータ設定とテストやマイグレーションはテストの⽐率が⾼い でWモデルを適⽤し、クリティカルパスにならないようにするとよい。 開発プロセス • どの開発プロセスでも適⽤可能 – 開発期間が短いほどWモデルをしたほうがテストがクリティカルパスにならない。 テスト戦略 • テスト（戦略）が本当に現新⽐較のみであれば、Wモデルはいらない。ただし、本当に そうか︖が必要。 Wモデルに必要なこと • テスト技術者の育成（テスト設計、テストマネジメント） • 体系的なテストプロセスの適⽤ • テスト成果物の構成管理／変更管理の実施
- 66. 66 まとめ Wモデルとは何か • Wモデルは今から15年前に提唱された考え⽅である – 既出の開発モデルはテストについて⼗分に表現できていないため、省略されてしまうことが問題 – 開発で本来必要なことを表現し、省略しないことが⽬的 Wモデルに類似したコンセプト • Wモデルの提唱と同時期から現在にかけて様々な考えが提唱されている – STEP、HPQMなどの⽅法論はテストによる予防について強く打ち出している – TPINEXTでは、「テストによる予防」に達するまでの道のりを⽰している Wモデル導⼊の阻害要因／事例 • 5つの阻害要因 – Wモデル導⼊時のゴール設定と活動の定義 – テストプロセスの改善 – テスト分析／テスト設計スキルの習得 – テスト成果物の変更管理／構成管理の仕組み構築と機械化 – 関係者との合意（お客様、ブロジェクトマネージャ） • この阻害要因を乗り越えればうまくいくということ テストプロセス改善モデルを使った現状把握とロードマップ策定 • 出来るようにするには順番がある – 「適切なことをする」→「適切な⽅法でやる」→「状況の変化に対応できる」 • 改善したい領域以外の領域の改善も必要になる © Copyright 2017 Tsuyoshi Yumoto
- 67. ありがとうございました © Copyright 2017 Tsuyoshi Yumoto