テストを育てる。テストを支える(Ultimate Agilist Tokyo)

6,678 views

Published on

0 Comments
17 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,678
On SlideShare
0
From Embeds
0
Number of Embeds
3,065
Actions
Shares
0
Downloads
46
Comments
0
Likes
17
Embeds 0
No embeds

No notes for slide

テストを育てる。テストを支える(Ultimate Agilist Tokyo)

  1. 1. テストを育てる。テストを支える。 Ul#mate  Agilist  Tokyo  -­‐  集え、日本の活動家たちよ   2012/11/17  @オラクル   井芹 洋輝
  2. 2. 自己紹介 •  井芹 洋輝   –  組み込みソフトウェアの開発とテストに従事   –  アジャイルやっていません。アジャイルのプラクティスが好き   –  活動   •  WACATE実行委員/TDD研究会/TDDBC 等   •  TDDやテスト設計、バグ管理などのコーチングを行う   –  講演   •  「実践!組み合わせテスト設計」(WACATE2012夏)   •  「ユニットテストの保守性を作りこむ」(XP祭り関西)   •  「テストで支える開発効率化」(Androidテスト祭り)等   –  執筆   •  ソフトウェアテストPRESS総集編等    
  3. 3. Ul#mate  Agile  Storyでは •  組み込みTDDの記事を執筆させて 頂きました   –  組み込みがマイナーなため講演テー マとして断念..   別の人により翻訳進行中 •  書いたこと   –  TDDは組み込み開発を大きく効率化さ せます!   –  組み込みプログラマはTDDをしよう!
  4. 4. このセッションについて •  変化を許容しつつ、開発ライフサイクル全体 でテストを積極活用する開発において   テストの力を引き出す考え方や知見を紹介し ます。  
  5. 5. ソフトウェアテストの課題
  6. 6. Vモデル開発 システム  要求定義 テスト 基本設計 結合テスト 詳細設計 単体テスト 実装
  7. 7. Vモデル開発 システム   要求定義 テスト 基本設計 結合テスト 詳細設計 単体テスト 実装 ●インプット資料 ●インプットに対しきちんとテスト分 析・設計を行うこと  をきちんと作ること ●早期からテストを考慮すること
  8. 8. Vモデル開発 システム   要求定義 テスト 基本設計 結合テスト 詳細設計 単体テスト 実装 ●インプット資料 ●インプットに対しきちんとテスト分 析・設計を行うこと   これだけではうまくいかない をきちんと作ること ●早期からテストを考慮すること
  9. 9. アジャイル開発などでの   ソフトウェアテストへの要求 •  変更や曖昧さに対応する  •  反復開発、中間リリース 中間リリース 中間リリース プロトタイピング 仕様変更 仕様追加 最終リリース 中間リリース プロトタイプ
  10. 10. アジャイル開発などでの   ソフトウェアテストへの要求 •  色々な目的で色々なテストが実施される   中間リリース CIでのデグレード監視 網羅的なバグ出し プロトタイピング 仕様変更 仕様追加 最終リリース 中間リリース 中間リリースの   プロトタイプ TDDでの  ための品質保証 プログラミング 品質証保の  
  11. 11. 取り組まなければならない課題
  12. 12. 課題:変更による生産性低下 •  変更の度に・・   –  テスト設計のやりなおし   –  インターフェースの変更への対応   –  既存テストの再評価   –  回帰テストの追加  •  テストの変更性が劣悪だと、「Cut  &  Run」や非 効率化を促す  
  13. 13. 課題:テストへの要求の見逃し •  テストの要求を見逃したり阻害したりする   TDDのテスト これでテストは大丈夫だ 品質保証のため   のテスト CIのテスト 中間リリース   のテスト
  14. 14. 課題:テストへの要求の見逃し •  テストの要求を見逃したり阻害したりする   リリース判定の   バグを見逃さない網羅的な ためのテスト テストを作るように TDDのテスト CIのテスト 中間リリース   のテスト
  15. 15. 課題:全体整合のないテスト •  バラバラにテスト設計やテスト実装を行う   •  設計や保守で無駄なコストが発生する   •  全体としてテストの穴や冗長性が見えにくくなる   CIでのデグレード監視 網羅的なバグ出し テストファースト  中間リリースの   での設計 品質証保の  ための品質保証 ためのテスト
  16. 16. ソフトウェアテストを  効果的に運用するには   どうすればよいか?
  17. 17. ソフトウェアテストを効果的に運用するには   どうすればよいか? •  テストを育てる。テストを支える。  •  テストを育てる視点   –  全体の方針を立てた上で、変化に対応しつつ全 体最適が得られるようにテストを作っていく  •  テストを支える視点   –  テストの課題やリスクに対応する
  18. 18. テストを育てる
  19. 19. テストを育てる 開発開始 終了
  20. 20. テストを育てる テストの活動
  21. 21. テストを育てる基本フロー 1.  テストへの要求を分析する  2.  全体の方針や構造を明らかにする 3.  段取りを明らかにする 4.  テストを育てていく
  22. 22. テストを育てる基本フロー 1.  テストへの要求を分析する  2.  全体の方針や構造を明らかにする 3.  段取りを明らかにする 4.  テストを育てていく 開発ライフサイクル 開発プロセスと並行   開発ライフサクルを通して要求を監視する
  23. 23. 1.  テストへの要求を分析する
  24. 24. テストへの要求を分析する •  開発ライフサイクルでどのようなテストが要求 されているのか明らかにする  •  テストへの要求   –  テスト対象   –  テストの計画   –  テストの運用   –  テスト目的  
  25. 25. テストへの要求を分析する •  テストへの要求   – テスト対象   “何に対してテストするか”   – テストの計画   “いつどのような流れでテストするか”   “どのような形でテストするか”   – テストの運用   “どこまでテストするか”   – テスト目的  
  26. 26. テストへの要求を分析する ●機能構成  •  テストへの要求   ・再生機能   ・通話機能   –  テスト対象   …     •  対象の構造   ●ユニット構成   •  開発のフローやスケジュール   ・コンポーネント1   ・コンポーネント2   –  テストの計画   …   –  テストの運用   –  テスト目的   リリース状況   第一イテ 第二イテ 第三イテ … レーション レーション レーション フィーチャ1 ○ ○ ○ フィーチャ2 ○ ○ …. ○
  27. 27. テスト対象の分析 •  システムテスト設計のための機能分析   階層一覧で整理 外部仕様   レベル カテゴリ 中項目 小項目 機能 機能 ビープ メインビープ エラービープ アーキテクチャ   通常ビープ レベル … … 機能 日時通知 時刻表示 日時表示 コンポーネント   … レベル 機能のレイヤ設計
  28. 28. テスト対象の分析 •  システムテスト設計のための機能分析   インターフェース 機   階層一覧で整理 能 外部仕様   レベル カテゴリ 中項目 小項目 機能 機能 ビープ メインビープ エラービープ 通常ビープ アーキテクチャ   状態やインターフェース   レベル … … との関連付けで整理 機能 日時通知 時刻表示 日時表示 コンポーネント   … 状態やトリガ   レベル 機   能 機能のレイヤ設計
  29. 29. テストへの要求を分析する •  テストへの要求   –  テスト対象   –  テストの計画   テストどの段階で実行するか   •  テストのフローやスケジュール   –  テストの運用   •  環境   •  実行や管理上の要求   –  テスト目的   「1秒以内での軽快な実行を行う」   「夜間に自動実行する」   「納入先と同等の環境でテストする」  
  30. 30. テストへの要求を分析する •  テストへの要求   –  テスト対象   –  テストの計画   –  テストの運用   –  テスト目的   •  着目する品質特性   どのような品質を見るのか   •  品質基準   どのような品質を保証するのか  
  31. 31. テスト目的の分析 品質特性 ●  ISO  9126   ●テストタイプ   機能性   単機能テスト  合目的性    正確性   ✕✕機能組み合わせテスト  相互運用性    ….   状態遷移テスト 信頼性   使用性   マニュアルテスト 効率性   …   ●テストタイプ   対象の形態 構造テスト ●対象の形態    ユニット    アーキテクチャ    システム 静的解析による構文チェック 品質モデルや品質指標 品質のテスト手段
  32. 32. テスト目的の分析 判定基準値   境界値テスト に対するテスト プッシュボ タン 押下時間に   同値分割 対するテスト ボタン 有効領域に   タッチパネ 対するテスト ルボタン 操作方法   に対するテスト 文字の視認性   に対するテスト モニタ表示 テストカテゴリ   ちらつき、   ノイズのテスト テストカテ テスト条件 テスト設計 ゴリ 方針 モニタ表示 文字視認 同値クラス 性 網羅
  33. 33. テスト目的の分析 判定基準値   境界値テスト に対するテスト 参考にしますが、テスト対象とは切り離して考えます。   プッシュボ タン 押下時間に   同値分割 抽象的に考えることで、テスト対象から独立して分析できるように 対するテスト なるほか、テスト設計漏れを防止します ボタン 有効領域に   タッチパネ 対するテスト ルボタン 操作方法   に対するテスト 文字の視認性   に対するテスト モニタ表示 テストカテゴリ   ちらつき、   ノイズのテスト テストカテ テスト条件 テスト設計 ゴリ 方針 モニタ表示 文字視認 同値クラス 性 網羅
  34. 34. 参考文献 Vol.10 「今こそ聞きたいテストの上流設計」
  35. 35. 2.  全体の方針や構造を   明らかにする
  36. 36. 全体の方針や構造を明らかにする •  要求に基づいてテスト活動を誘導する全体の 方針や構造を明らかにする
  37. 37. 全体の方針や構造を明らかにする •  テスト対象とテスト目的の関連付け テストタイプやテストカテゴリ テスト対象 機能性テスト ユーザビリティテスト … 中項目 小項目 単機 状態 組み 異常 仮想   ユー … … 能 遷移 合わ 系 ユー ザ せ ザ 日時表示 時間表示 A C   年月日表示 A B C テスト対象 ストップ 再生・停止 A B C ウォッチ リセット A C … … テスト分析マトリクス 必要なテストを見つけ出す   「●ユーザビリティテストC   プロダクオーナにより時間関連処理のユーザビリティを評価する」  
  38. 38. 全体の方針や構造を明らかにする •  テストの運用や計画の方針を決める テスト対象 機能性テスト ユーザビリティテスト … 中項目 小項目 単機 状態 組み 異常 仮想   ユー … … 能 遷移 合わ 系 ユー ザ せ ザ 日時表示 時間表示 A C   年月日表示 A B C ストップ 再生・停止 A B C ウォッチ リセット A C … … ●ユーザビリティテストC   対象:時間関連処理   テスト目的:主要ユーザが滞りなく操作できること   運用、計画:プロダクトオーナが実機を使って評価    中間リリースでアドホックに評価  
  39. 39. 全体の方針や構造を明らかにする –  各フェーズでのテストの「対象」「目的」「運用」を 明らかにする テストの種類 フェーズ 開発中 内部リリース プロトタイプ   βリリースA リリース ユニットテスト 開発者   内部リリース テスト 向けユニット テスト 自動構成テスト …. システム試験 … ●開発したソースコードを対象   ●システム全体が対象  ●事情がない限りコードカバレッジ100%推奨   ●コードレビューを行い、テストが基準以上●デイリーでフル実行 の網羅性を持っていることを確認  
  40. 40. 段取りを明らかにする
  41. 41. 段取りを明らかにする •  どう育てていくかを考える  •  開発全体での整合性を確保する  •  全体最適を意識する   組み合 単機能   わせ   単機能   テスト テスト テスト リリース前の   結合テスト システム試験 単機能  テスト 単機能   単機能   テスト テスト 開発初期 中間リリース 最終リリース
  42. 42. 段取りの例:   VOTDD(検証指向TDD) •  高品質なプログラミングを行うTDD  •  「バグを網羅的に検出するユニットテストの構 築」+「TDD」を効率的に進める  
  43. 43. 段取りの例:   VOTDD (検証指向TDD) •  1 パッケージや上位コンポーネントレベルで テストの方針や構造を明らかにする  テスト設計の方針 対応   対応   テスト テスト ●構造の方針   フィーチャ1 フィーチャ2 Testcase  Class  per  Class  Testcase  Class  per  Fixture  Testcase  Class  per  Feature    ●テスト設計の方針  カバレッジC2網羅率   下位   下位   下位  同値クラス網羅率   機能 機能 機能 コードレビュールール 対応   対応   対応   テスト テスト テスト
  44. 44. 段取りの例:   VOTDD (検証指向TDD) •  2  ユニットレベルで、テストリストをテスト設計 技法にて整理する   4で割り切れる N Y Y Y 100で割り切れる N N Y Y ●テストリスト   400で割り切れるならば…   400で割り切れる N N N Y 100で割り切れるならば…   ….   うるうどし N Y N Y仕様   デシジョンテーブル     0   6   12       -­‐1     ありえない 0   5   無料 6   12   半額 13   定額 同値分割・境界値分析
  45. 45. 段取りの例:   VOTDD (検証指向TDD) •  3  テスト設計、テスト実装を作りこみながら TDDを進める   テストファースト リファクタリング による追加・変更 (REFACTOR) (RED→GREEN) Green 通常のTDD
  46. 46. 段取りの例:   VOTDD (検証指向TDD) •  3  テスト設計、テスト実装を作りこみながら TDDを進める   テストファースト テストコードの による追加・変更 設計改善 (RED→GREEN) (REFACTOR[TEST]) Green リファクタリング テスト設計の洗練 (REFATCOR (VERIFY&DEBUG) [PRODUCT])
  47. 47. 段取りの例:   VOTDD (検証指向TDD) •  4  テストを綺麗にする   –  安定したテストコードから巡回的にレビューし、テ スト設計の補強や再構築を行う   –  最終的に適切なテスト設計に基づいた網羅的な ユニットテストを得る 開発工程(TDD) テスト作成 TDD+網羅的なテスト作成 VOTDDで 工数 ・総工数7%削減 ・テスト設計経験者なら 20%削減 VOTDD+網羅的なテスト作成 開発工程(VOTDD) テスト作成 ※単体テスト工程:網羅的なユニットテスト構築 工数
  48. 48. 段取りを考える:   テストプロセスの活用 •  ゆもつよメソッド   Vol.10 「今こそ聞きたい   テストの上流設計」
  49. 49. 段取りを考える:変更対応に   優れたテスト方法論(ゆもつよメソッド) テスト   スケーラビリティに優れた方法論 対象   の分析 テスト分析マトリクスな どによる   テスト   テスト テストの上流設計 設計 ケース テスト   目的   の分析 開発プロセス 上流   イテレー イテレー …   テスト   工程   ション   ション  
  50. 50. 段取りを考える:変更対応に   優れたテスト方法論(ゆもつよメソッド) テスト   スケーラビリティに優れた方法論 対象   の分析 テスト分析マトリクスな どによる   テスト   テスト テストの上流設計 設計 ケース テスト   目的   の分析 変更対応に優れたプロセスやフレー ムワークを採用することで、変化や問開発プロセス 題に対し、整合性を崩さず規律を持っ 上流   工程   て対応できる イテレー ション   イテレー ション   …   テスト  
  51. 51. 段取りを考える:変更対応に   優れたテスト方法論(ゆもつよメソッド) テスト対象から離れてテスト設計を行うことができる テスト対象 機能性テスト ユーザビリティテスト … 中項目 小項目 単機 状態 組み 異常 仮想   ユー … … 能 遷移 合わ 系 ユー ザ せ ザ 日時表示 時間表示 A C   年月日表示 A B C ストップ 再生・停止 A B C ウォッチ リセット A C … … 変更が発生した際、  変更がテスト全体に対しどこに波及しているか検討しやすい  
  52. 52. テストを育てる •  変更対応に優れたテストの方法論にもとづ いてテストを育てる   1.  テストへの要求を分析する   2.  全体の方針や構造を明らかにする 3.  段取りを明らかにする 4.  それぞれでテストを育てる •  キーワード   –  「4つの要求の分析」「VOTDD」「ゆもつよメソッド」
  53. 53. テストを支える
  54. 54. テストを支える •  育てる方針はわかってもうまくいかない   –  ソフトウェアテストは宿命として様々な問題に直 面する。それらはルールやプロセスを吹き飛ばす  
  55. 55. テストが抱えがちな問題 要求分析 設計 実装 テスト ふつうのWF リリース テストエンジニアは   後工程を主担当 (とちぎテストの会議2レシピ発表より)  
  56. 56. テストが抱えがちな問題 バグは出すな   リリースは   BOSS 遅らせるな 要求分析 設計 実装 テスト ふつうのWF リリース テストエンジニアは   後工程を主担当 (とちぎテストの会議2レシピ発表より)  
  57. 57. テストが抱えがちな問題 バグは出すな   遅延 リリースは   BOSS 遅らせるな 要求分析 設計 実装 テスト ふつうのWF リリース (とちぎテストの会議2レシピ発表より)  
  58. 58. テストが抱えがちな問題 バグは出すな   遅延 リリースは   BOSS 遅らせるな 要求分析 設計 実装 テスト ふつうのWF リリース バグ混入 要求定義   のミス テスタビリ ティの悪さ 仕様バグ 粉飾 見積りミス 隠れた   仕様変更 (とちぎテストの会議2レシピ発表より)  
  59. 59. テストが抱えがちな問題 仕様やプ 遅延や  問題対応   契約やプ ロトタイピ 設計や先 残業や増 スピリチュ ロセス、計 行テストでの選択肢 画で対策 ングで対 対策   員で対策   アル系で   策   対策 要求分析 設計 実装 テスト ふつうのWF リリース 対策が遅れるほど   問題対応の選択肢が少なくなる (とちぎテストの会議2レシピ発表より)  
  60. 60. テストを支える •  テストを支える   –  テストプロジェクトのリスクや問題を識別し、対策 を打つ   –  テストの活動をより効率的にする  
  61. 61. テストを支えるプロセス 1.  テストプロセス –  トップダウンで必要な支援策を抽出する。 2.  プロジェクトリスクのリスクマネジメント –  問題や課題を抽出し、ダメージの予防・軽減・回 避・移行を行う  •  最後に説明
  62. 62. テストを支える道具 •  2つのプロセスに基づいて対策をうつ   –  良い方に誘導する   –  選択肢を広げる   –  堅牢な構造を確保する   –  テストを維持する   –  自動化する   –  粒度を調整する
  63. 63. 誘導する:ウォーキングスケルトンに よるダブルループ •  最初にアーキテクチャのスケルトンを開発  •  End  To  Endの自動テスト環境を構築   End  To  Endの自動テストを肉付けしながら細 部の自動テストを記述していく  •  アーキテクチャの瓦解を防ぎ、自動テストの 保守コストを削減する
  64. 64. 誘導する:ウォーキングスケルトンに よるダブルループ 外部   システム コンポーネ ント コンポーネFake ント Mock 仮実装 ウォーキング・スケルトン   (動くアーキテクチャのスライス)
  65. 65. 誘導する:ウォーキングスケルトンに よるダブルループ 外部   外部   システム システム コンポーネ コンポーネ 開発の進展に応じてアーキテクチャに肉付けしていく ント ント コンポーネ コンポーネFake ント DB ント Mock 仮実装 コンポーネ コンポーネ ント ント ウォーキング・スケルトン   アーキテクチャ (動くアーキテクチャのスライス)
  66. 66. 誘導する:ウォーキングスケルトンに よるテストのダブルループ TDD ユニットテストを書く EndToEndテスト   ウォーキ CIや  担当者 ングスケ ルトン 製品コードを書く ウォーキングスケルトン   に対して自動テストを書く コミット   End  To  Endの自動テストの   ユニット テストファースト   ユニットテスト  
  67. 67. 選択肢を広げる:   デュアルターゲット・テスト •  クロス開発(特に組み込み開発)において、自 動テストをホスト環境、ターゲット環境両方で 同時実行する  •  ホスト側の柔軟なテスト環境を活用しつつ、   ホスト環境とターゲット環境の差違に起因す る問題を軽減できる
  68. 68. 選択肢を広げる:   デュアルターゲット・テスト ホスト環境  (テストフレームワーク) ターゲット環境 ターゲット環境に対し   ビルド・実行 ホスト環境に対し   ビルド・実行 ターゲット 依存コード ユニットテスト ビルド設定で   共通ロジック 切り替える ホスト依存 コード
  69. 69. 選択肢を広げる:   デュアルターゲット・テスト ユニットテスト   ターゲット環境 【メリット】     実行 本番環境でビルド・実行   CI   【デメリット】  サーバ 時間がかかる   環境に制約   コミット ホスト環境   【メリット】   ユニットテスト   (テストフレームワーク) 軽快に実行   実行 柔軟な環境やツール   【デメリット】   ターゲット向けでない環境で   ビルド・実行    
  70. 70. 選択肢を広げる:   マルチコンフィグレーションテスト •  複数の構成設定を自動テストで同時検証  •  ありふれたテクニックとなっている   構成設定1 構成設定2 構成設定3 開発者環境 自動テスト CI   サーバ 任意の構成設定
  71. 71. 堅牢な構造を得る:   データ駆動テスト •  テストのデータとロジックを分離  •  ロジックを共通化し、データを柔軟に変更・拡 張できるようにする  •  インターフェースが堅牢ならテストの堅牢性が 向上する
  72. 72. 堅牢な構造を得る:   データ駆動テスト テストデータ 入力値 期待値 ソースコード AAA BBB DB CCC DDD … … ファイル テストスクリプト …   TEST_F(Hoge,  Fuga)   {          …          ActualValue  =  Fuga(InputValue);   ロジックとデータを分離し、        EXPECT_EQ(expectedValue,  ActualValue);   データの変更・管理を容易        …   にする }
  73. 73. 堅牢な構造を得る:   テストユーティリティメソッド •  重複するテストコードを共通化する   –  フィクスチャのセット   –  オブジェクトの生成   –  Asser#on   –  等々  
  74. 74. テストを維持する:   CI •  テストの保守や自動テストの基盤   –  テストをCIで実行することが、テストのCIとなる  “(中略)Jenkinsを使用した継続的インテグレーション(中略)などをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。”
  75. 75. 自動化する:   実行の自動化 •  すでに色々なツールや手法が出ている  
  76. 76. 自動化する:   テスト設計の自動化 •  モデルベースドテスト   –  設計モデルからテストを自動生成する   –  テスト分析・設計の手間を削減する   –  テスト実行まで自動化できる場合もある
  77. 77. 自動化する:   テスト設計の自動化 •  モデルベースドテスト   テストケース生成   (astah、EA、ZIPC等) …   ソースコード   状態遷移モデル … 実装  
  78. 78. 自動化する:   テスト設計の自動化 •  モデルベースドテスト テストケース テスケース自動生成   (CEGTest) …   原因結果グラフ 実装   ソースコード   …
  79. 79. 自動化する:   テスト設計の自動化 •  テスト設計ツール。すでに色々存在する   •  テスト設計の手間を削減する  因子と水準 【因子】  麺:やわめ、ふつう、かため、バリカタ  スープ:味噌、とんこつ、しょうゆ  具:コーン、チャーシュー、ネギ、ノリ  【禁則】  ・具:コーンはスープ:味噌のみと組み合わせ可 All-­‐Pair法ツール   (PICT、PICTMaster等) テストケース 麺 スープ 具 テストケース1 やわめ 味噌 コーン テストケース2 やわめ とんこつ コーン … … … …
  80. 80. 自動化する:   テスト設計の自動化 •  参考書籍  
  81. 81. 堅牢な構造を得る:   インターフェースの抽象化 •  インターフェースを抽象化し、インターフェース の変更からテストを保護する  •  テストの変更・追加を容易にする   システム
  82. 82. 堅牢な構造を得る:   インターフェースの抽象化 •  UIとAPIの分離  •  UIの抽象化   自動テスト API ボタン   ID1 GUI システム システム テキストボックス   ID2
  83. 83. 堅牢な構造を得る:   インターフェースの抽象化 •  キーワード駆動テスト。ドメイン駆動のテスト  •  非開発者でもテストの保守が可能 自動テスト キーワード「ボタン」「押す」「異常系エラー」   DDTL「異常系エラーを発生させてボタンをおす」   KDTや DDDの   システム フレーム ワーク  
  84. 84. 堅牢な構造を得る:   テストインフラの確保 •  観察点の確保   –  有用な内部エラーや内部リスクに対して設置  •  制御点の確保   –  実現の難しい異常や特殊処理に設置   –  入力を柔軟に操作可能にする  •  接合部の確保   –  テストの障害となるコンポーネントの   インターフェースに設置  
  85. 85. 堅牢な構造を得る:   モジュラリティの確保 •  一般的な設計原則に従う  •  SOLID   –  単一責任の原則   –  オープン・クローズドの原則   –  リスコフの置換原則   –  インターフェース分離の原則   –  依存関係逆転の原則  •  コンポーネントの結合度は低く、凝集度は高く  •  時間的、構造的に影響範囲を限定する
  86. 86. 堅牢なテストを得る:   テストインフラの確保 •  FIRST   –  Fast:軽快に実行可能   –  Independent:テストは個別に独立している   –  Repeatable:テストは再現可能   –  Self-­‐Valida#on:実行から判定まですべてこなす   –  Timely:すぐに書ける
  87. 87. 機能テストを育てる:   探索的テストの活用 テスト設計   テスト設計   テスト設計  … N Y Y Y … N Y Y Y … N Y Y Y… N N Y Y … N N Y Y … N N Y Y… N N N Y … N N N Y … N N N Y…. N Y N Y …. N Y N Y …. N Y N Y 探索 テスト  テスト   探索的   テスト   的   実装 実装 テスト 実装 テスト 探索的   テスト 開発の進展
  88. 88. ベースとなるプロセス •  テストプロセス –  トップダウンで必要な支援策を抽出する。 •  プロジェクトリスクのマネジメント –  問題や課題を抽出し、ダメージの予防・軽減・回 避・移行を行う
  89. 89. テストプロセス •  テストの構造や段取りを適切な手法で明らか にすることで、必要な対策や補助を明らかに する  •  施策に適したインプットを確保する  
  90. 90. プロジェクトリスクのリスクマネジメント –  リスクや問題を補足し、対策する  リスクマネジメントプロセス リスク   リスク   対応   対策   フォロー の識別   の分析   検討   実施   アップ  開発プロセス 要求   計画   …   …   テスト   分析  
  91. 91. プロジェクトリスクのリスクマネジメント –  リスクや問題を補足し、対策する   リスク 対応手段 リスク要因 リスク内容 移行基準 リスク   対応手段 軽減後の   重大度 重大度 開発工程でのバ 手戻り工数が増大 2回以上の A ・スモークテストを作成。それに合 B グ見逃しが常態 し、リリース遅延を 手戻り発生 格してからテスト工程に移行する  化 発生させる ・実装工程中、前倒しで単機能テ ストを実施する
  92. 92. プロジェクトリスクのリスクマネジメント
  93. 93. ご清聴ありがとうございました •  テストを育てる。テストを支える。   –  育てる   •  変更対応に優れた方法論に基づく   1.  テストへの要求を分析する   2.  全体の方針や構造を明らかにする 3.  段取りを明らかにする 4.  それぞれでテストを育てる –  支える   •  テストプロセスやリスクマネジメントで課題を抽出し、問 題対策や効率化対策をサポートする  

×