Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WACATE 2010夏 ゆもつよ講演スライド

2,382 views

Published on

Published in: Engineering
  • Be the first to comment

WACATE 2010夏 ゆもつよ講演スライド

  1. 1. テストコンサルタントの 「見たい」「見せたい」 「伝えたい」 2010年6月13日 15:05~16:05 WACATE2010 夏 湯本 剛
  2. 2. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 1 自己紹介 湯本 剛 コンサルタント コンサルティング実績 ・大手SI企業、ユーザ企業、国内大手電機メーカ等にて、テスト設計標準策定、テスト計画策定、 テストチーム立 ち上げ、テストプロセス改善、キャプチャリプレイツール導入支援等のコンサルティング実績あり 経歴 ・製造メーカーにて原価管理システム、生産管理システム構築プロジェクトメンバー ・ソフトハウスにてテストエンジニア、テストチームリーダーとしてパッケージソフト、情報システム、 プリンタドライバなどのテスト経験 外部活動 ・日科技連 SQiPステアリング委員 ・ASTER理事 ・ソフトウェアテストシンポジウム(JaSST) 実行委員 ・JSTQB技術委員 ・ISO/IEC JT1 SC7 WG26 エキスパート ・「現場の仕事がバリバリ進むソフトウェアテスト手法」共著 ・「ソフトウエア・テストPress Vol.1,3,5」原稿執筆 ・「基礎から学ぶソフトウェアテスト(日経ITPro)」原稿執筆 ・「基本から学ぶソフトウエアテスト」共訳 など TestPress Vol.10 8月頃発売 【特集記事】 ・湯本のテスト分析・設計
  3. 3. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 2 今日の主な内容  テストに対する想い(いろんな人にいろんな想い)  目的と手段の階層構造  テストに関わる立場による想いの変化(湯本の例)  テストコンサルの想い(大事なことは、、)  「伝えたい」想いを持ち続けるためには  「見て」のコツ  成果物の連鎖  成果物の構造  テストのやり方  数字の使い方  「見せて」のコツ
  4. 4. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 3 テストはなんでやるんでしょう?
  5. 5. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 4 テストはなんでやるんでしょう? 品質を計測 し定量表示 するため 欠陥を摘出 するため 人は間違い を犯すため テスト結果が 納品物だから 欠陥を摘出 して直しても らうため プロダクトリ スクを軽減 するため プロジェクト の行く手を照 らすため 心配だから 仕事だから バグがあると命 に関わるから 市場バグがあると 上司に怒られる テストでバグを見 つけておけば会社 が損をしない リリース後にバ グが見つかると 手間だから 銀の弾丸 だから バグが出ると 楽しい バグがあると多く の人に迷惑がか かるから
  6. 6. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 5 いろんな人に いろんな想い
  7. 7. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 6 テストはなんでやるんでしょう?  テストの必要性  品質を計測し定量表示できる  摘出した欠陥を計測する  特性を計測する(応答時間、使用メモ リ量…)  契約や法律上の適格要件に対する証 拠の提示ができる  要件との合致を確認する  ソフトウェアの品質に確信を持つことが できる(もう出しても大丈夫)  プロダクトリスクは軽減している  見つかった欠陥を修正されていること で品質が確保できてる  将来開発するシステムの品質を改善 できる  他のプロジェクトで見つかった欠陥の 根本原因を理解する  プロセスを改善し、同じ原因の欠陥の 作りこみを防ぐ  テストの目的  欠陥を摘出する  対象ソフトウェアの品質レベルが十分 であることを確認し、その情報を示す  欠陥の作りこみを防ぐ ISTQBに 聞いてみた
  8. 8. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 7 「テストの必要性」を目的と手段に分けると 品質を計測、定量表示 契約、法律の証拠提示 品質に確信を持つ システム品質を改善 プロダクトリスク軽減 欠陥修正確認 欠陥原因分析 プロセス改善欠陥計測 特性計測 手段 目的 合致確認
  9. 9. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 8 「テストの目的」を追加…欠陥を摘出する 品質を計測、定量表示 契約、法律の証拠提示 品質に確信を持つ システム品質を改善 プロダクトリスク軽減 欠陥修正確認 欠陥原因分析 プロセス改善欠陥計測 特性計測 手段 目的 合致確認 欠陥を摘出する 表示の誤り は無いか 処理手順によって 出力が誤るか 境界値とか0とかNULLなど間違え そうな入力データで出力が誤るか サイズの大きいデータを高頻 度に与えるとエラーになるか ・・・ テストの目的 新規開発部分の機能 の不具合を見つける 影響範囲の機能 の不具合を見つける データ登録高負荷時 の不具合を見つける 影響範囲の機能 の不具合を見つける ・・・ その手段 具体的には.. 具体的には..
  10. 10. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 9 「テストの目的」を追加…品質情報を示す 品質を計測、定量表示 契約、法律の証拠提示 品質に確信を持つ システム品質を改善 プロダクトリスク軽減 欠陥修正確認 欠陥原因分析 プロセス改善欠陥計測 特性計測 手段 目的 合致確認 品質レベルが十分であることを確認し、その情報を示す ユーザが最も良く 使う機能の使い勝手 Windowsロゴの 取得 テスト労力に対する欠陥数 で信頼度を測定 システムを使った通常 処理機能の確認 ・・・ テストの目的 必要処理まで の操作数計測 ユーザプロファイルに基づ いたイレギュラー操作 MSから提示のあったチェッ クリストベースのテスト その手段 ・・・ 具体的には.. 具体的には..
  11. 11. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 10 「テストの目的」を追加…欠陥の作り込みを防ぐ 品質を計測、定量表示 契約、法律の証拠提示 品質に確信を持つ システム品質を改善 プロダクトリスク軽減 欠陥修正確認 欠陥原因分析 プロセス改善欠陥計測 特性計測 手段 目的 合致確認 欠陥の作りこみを防ぐ 仕様の抜け漏れ を指摘 非機能要件の実現 方法不備の指摘 構成管理不備 の指摘 欠陥を埋め込みそうな 構造の問題を指摘 ・・・ コーディング前 にテストベースレビュー バグの分析を行い 開発へフィードバック 静的解析 その手段 ・・・ テストの目的 具体的には.. 具体的には..
  12. 12. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 11 3つの例からわかること 品質を計測、定量表示 契約、法律の証拠提示 品質に確信を持つ システム品質を改善 プロダクトリスク軽減 欠陥修正確認 欠陥原因分析 プロセス改善欠陥計測 特性計測 手段 目的 合致確認 目的と手段の連鎖を単純 に1対1にせず工夫してい る…それが人間らしさ 繋がりが分かることで腑 に落ちて、何をすればよ いかが分かる…やる気の 源
  13. 13. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 12 それぞれの目的はなんで必要なんでしょう? 品質を計測、定量表示 契約、法律の証拠提示 品質に確信を持つ システム品質を改善 プロダクトリスク軽減 欠陥修正確認 欠陥原因分析 プロセス改善欠陥計測 特性計測 手段 目的 合致確認 利用する人たちにとって 価値のあるシステム/製品 /ソフトウェアを提供したい 世の中のルールに 沿ってビジネスを成立 させたい 開発に携わる人だけでな く、誰が見てもわかるよう に品質情報を提供したい 自分たちの開発をより 価値のある、やりがいの ある仕事にしていきたい 目的の先にある「想い」 欠陥を摘出する / 品質レベルが十分であることを確認し、その情報を示す / 欠陥の作りこみを防ぐ
  14. 14. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 13 それぞれの目的はなんで必要なんでしょう? 利用する人たちにとって 価値のあるシステム/製品 /ソフトウェアを提供したい 世の中のルールに 沿ってビジネスを成立 させたい 開発に携わる人だけでな く、誰が見てもわかるよう に品質情報を提供したい 自分たちの開発をより 価値のある、やりがいの ある仕事にしていきたい 目的の先にある「想い」にも関係がある
  15. 15. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 14 それぞれの目的はなんで必要なんでしょう? 利用する人たちにとって 価値のあるシステム/製品 /ソフトウェアを提供したい 世の中のルールに 沿ってビジネスを成立 させたい 開発に携わる人だけでな く、誰が見てもわかるよう に品質情報を提供したい 自分たちの開発をより 価値のある、やりがいの ある仕事にしていきたい 組織内の上長 組織内の経営層 利用者(メリットを得る人) 利用者(使う人) プロジェクトメンバ (他チーム) プロジェクトマネージャ プロジェクトメンバ (自チーム) 認証機関 組織内の監査部隊 目的の先にある「想い」は誰のため?
  16. 16. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 15 自分の立場によっても目的は変わる  目的と手段は階層構造  情報技術がなぜ世の 中に必要なのか?と考 えた場合の一例 究極の 目的 手段ビジネス 手段 IT活用 手段システム 開発 手段 品質 管理 手段 テスト 手段テスト 設計 手段 テストの目的 どこを立脚点にして世界を 捉えるかによって目的と手段は決まる 人の幸せ 「ビジネス」とは ・提供した価値に対して 相応しい対価を得ること
  17. 17. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 16 テスト担当者 の頃 ゆもつよ の場合
  18. 18. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 17 テストの仕事を始めた頃 テスト 手段 テストの目的 ・重大なバグを見つけると楽しい →「オレ、やったゼ」感 ・人より多くバグを見つけたい →自分をアピールしたい ・時間内で沢山テストケースを消化したい →沢山テストした方がバグが見つかる!&(早く帰れる or 人の分を手伝ってあげられる) テストでバグを 見つける テスト 実施 手段 とにかく与えられ た仕事をちゃんと やること以上の ことはよくわかっ ていない
  19. 19. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 18 テストケースを書くようになった頃 テスト 手段 テストの目的 テストでバグを見つける + 網羅的なテストをする テスト 実施 手段 何がバグになるかは わかってきたが、 それ以上は変わって いない ・重大なバグを見つけるテストケースを書きたい →データCRUDした後の他処理への反映 →共有リソースへの処理競合 →処理順序の入れ替え ・「これだけは最低見とかないと」と思えるテスト ケースを書いておきたい →「画面周り」「計算」「データCRUD」「大量データ」 … テスト 設計 手段 あまりに非現実的なものだと、細かいとか言 われるので、思いついた手順が現実的に想定 出来るかを考えるようになった。
  20. 20. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 19 テストリーダ の頃 ゆもつよ の場合
  21. 21. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 20 納期 手段 コスト 手段 テストリーダを始めた頃 テスト 手段 テストの目的 ・納期に間に合うようにテストをやり遂げたい →設計内容を早いうちに理解してポイントを押さえる →開発者にもっとテストしてもらう →開発者に何がダメかをちゃんとわかってもらう (次は同じ問題が出ないようにする) ・工数をちゃんと見積もりたい →見積もった工数を守らせる →守ることができる工数見積をする →やり方を工夫することで工数がかからないようにする…自動化 テスト 実施 手段 コストと納期を意識するが テストが品質管理の一部と まで考えられなかった… 「自分たちだけの最適化」 テスト 設計 手段 テスト 管理 手段 テストでバグを見つける + 網羅的なテストをする + 工数、納期を守る 自動テストツールの使い方を調べていてTEF の存在を知る(多分1999年か2000年)
  22. 22. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 21 システム 開発 手段品質 管理 手段 自組織 の売上 手段 案件の提案をするようになった頃 テストの目的 ・何故テストにコストがかかるかを人に説明する →テスト分析マトリクス…理解を共有するため ・案件毎にどこまでテストすべきかを決める →いろいろなドメインの案件 →人数の投入方法(1人~40人まで) ・自分たちの売りを作りたい →自動化…WinRunner →バグ分析…社内のBTS作成、報告書統一 納期 手段 コスト 手段 テスト 手段 テスト 実施 手段 テスト 設計 手段 テスト 管理 手段 テストでバグを見つける + 網羅的なテストをする + 工数、納期を勝ち取り、 QCDを達成する 二つの目的に対する 折り合いがつけなくっ てきていた このころまでに関わったソフトウェア 経理ソフト プリンタドライバ TWAIN プリンタ付属ソフト(カレンダー作成ソフト) 住宅見積もりシステム 資材管理システム、生産管理 システム、SCMシステム BTOサイト Windows認 証のテスト…など
  23. 23. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 22 テストコンサルに なってから ゆもつよ の場合
  24. 24. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 23 ビジネス 手段 顧客の IT活用 手段 開発組織 の成長 手段 視点を上げる事を学び、チャレンジしてきた コンサルの目的 ・テストのあるべき姿を伝えたい →テストプロセス、テスト設計の教育講師 ・どうやれば成長するかを伝えたい →アセスメント(どこに成長の余地があるかを調べ、伝える) ・自分で成長できるようになってもらいたい →テストプロセス改善…リスク分析、テスト戦略、テスト分析・設計、テスト実施に対するアドバイス &チャレンジする時に背中を押してあげる システム 開発 手段品質 管理 手段 納期 手段 コスト 手段 テスト 手段 テスト 実施 手段 テスト 設計 手段 テスト 管理 手段 「コンサルのお客様(開発組織)の成功」 と 「お客様のお客様(利用者)の成功」 をつなげることができて(connect) 自分のビジネスの成功につなげる テストの価値を上げる + テストがビジネスに 貢献する
  25. 25. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 24 大事なことは…視点をあげるということ  テストなら…テストをやり遂げるだけではなくテストの価値をあげる テストをやり遂げる テストをやり遂げる テストの価値向上 Quality 言われた通りのテスト をする バグを沢山見つける 適切なテスト内容、テスト量で テストする 出すべきバグを見つける Cost 計画したコスト以内でテ ストを終わらせる そのコストを掛けて得られるメ リットを見直す コストに見合う価値.. そこから 得られるものは?自己メリット があるのか? Delivery 納期にテストを間に合 わせる 適切な時期に適切なテストを 行う テストの 価値を 上げる ゴール ゴール
  26. 26. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 25 もうひとつの大事なことは…協奏 ビジネス 手段 ビジネス 手段 顧客の IT活用 手段 顧客の IT活用 手段 開発組織 の成長 手段 開発組織 の成長 手段 システム 開発 手段 システム 開発 手段品質 管理 手段 品質 管理 手段 納期 手段 納期 手段 コスト 手段 コスト 手段 テスト 手段 テスト 手段 テスト 実施 手段 テスト 実施 手段 テスト 設計 手段 テスト 設計 手段 テスト 管理 手段 テスト 管理 手段 ビジネス 手段 ビジネス 手段 顧客の IT活用 手段 顧客の IT活用 手段 開発組織 の成長 手段 開発組織 の成長 手段 システム 開発 手段 システム 開発 手段品質 管理 手段 品質 管理 手段 納期 手段 納期 手段 コスト 手段 コスト 手段 テスト 実施 手段 テスト 実施 手段 テスト 設計 手段 テスト 設計 手段 テスト 管理 手段 テスト 管理 手段 土台が無いと、 実現に無理がある…「妄想」 向かうべき場所がないとバラバラになる…「暴走」 目的と手段の両方が伴っている…「協奏」 物事を達成するための土台つくり 「勉強」「信頼関係」「経験」 視 点 上と下を 行ったり 来たりする
  27. 27. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 26 ここまでが 今日の 「伝えたい」
  28. 28. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 27 いったんまとめてみると  テストに対する想い(いろんな人にいろんな想い)  目的と手段の階層構造  →目的と手段を整理して理解しよう  テストに関わる立場による想いの変化  →目的はだんだん変わってくるよ(というより変えていいんだよ)  テストコンサルの想い(大事なことは、、)  →視点を上げてつながるようにすると納得して仕事が出来るよ  「伝えたい」想いを持ち続けるためには  「見て」のコツ  成果物の連鎖→プロセスを見て  成果物の構造→テスト設計を見て  テストのやり方→テスト戦略を見てる  数字の使い方→説明の「もっともらしさ」を確認するときに使う  「見せて」のコツ というのが 若い人達への メッセージです
  29. 29. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 28 「伝えたい」から 話した理由
  30. 30. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 29 見て、見せて、伝えるというより…  まずは伝えたい事がないと伝わらない  そこが出発点 見て 伝えたい事がある のが出発点 伝える 見せて (伝えたい事があるから)見て (確信を持って)伝える (伝わるように)見せて 「伝えたい」 を持ち続けて 欲しい
  31. 31. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 30 「伝えたい」想いを持ち続けるためには  「本来はこうなんじゃないか」という事を知る  あるべき姿を学ぶ…目的の先の「想い」  原理原則を学ぶ…抽象的な見方  「納得できるか」を大事にする  自分が納得できる  学びとチャレンジを繋げる  相手に納得してもらう  自分と相手を繋げる  押してもダメなら引いてみる  目的にふさわしい手段は一つじゃない 抽象的 具体的 connect the dots.
  32. 32. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 31 「見て」「見せて」 のコツ
  33. 33. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 32 以降はちょっとしたTips  「見て」「見せて」は「伝えたい想い」を実現する手段  なので、時と場合によりいくらでも変わるもの  今日は私がコンサルとして仕事するなかでやっているこ と/心がけていることをTipsとして紹介
  34. 34. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 33 「見る時」のコツ  コンサルは自分が知らないところへ行き短時間で状況把握をするのが仕事  まずは自分の感覚との意識合わせから始める  「テストプロセス改善」で言えば、以下3つのコンセプトを理解する  テストの成果物の連鎖  成果物の構造(各要素がどこにあるのか?)  テストの配置  理解した上でさらに現場の声を聞く  具体的なイメージが共有できることは数字を使って見ることで「短時間」で把握 する !その数字に対して共通理解が持てる単位でないと効果が低い  成果物の数  バグの件数  テストケースの件数  仕様書のページ数  時間  バグ一件あたりの時間  テストケース一件あたりの時間
  35. 35. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 34 テスト成果物の連鎖  テストプロセスの特徴を理解  調査対象となるドキュメントを決める  その後のドキュメントレビュー/インタビューにて理解内容を補正し、強み、弱みを評価 完了作業のプロセ スとして反省会実 施 各協力会社に 「提案」活動 を実施してもらっている Sbcが「提案」活動 を実施している ⇒キックオフ原案は 見積り前に提示している 試験設計のレ ビューが公式な ものとなっているバグ分析を行い テスト設計へ反 映している 完了作業のプロセ スとして反省会実 施 完了作業のプロセ スとして反省会実 施 各協力会社に 「提案」活動 を実施してもらっている Sbcが「提案」活動 を実施している ⇒キックオフ原案は 見積り前に提示している 各協力会社に 「提案」活動 を実施してもらっている 各協力会社に 「提案」活動 を実施してもらっている Sbcが「提案」活動 を実施している ⇒キックオフ原案は 見積り前に提示している Sbcが「提案」活動 を実施している ⇒キックオフ原案は 見積り前に提示している 試験設計のレ ビューが公式な ものとなっている 試験設計のレ ビューが公式な ものとなっているバグ分析を行い テスト設計へ反 映している バグ分析を行い テスト設計へ反 映している テストプロセスを図にしてアウトプットする
  36. 36. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 35 テスト成果物の構造  テスト成果物の(静的な)構造を調査  テスト設計書、テスト仕様書、手順書などへの要素の配置方法を調査し、テストの不足、重 複、複雑度合いなどを評価  テスト設計からテストケースのトレースを調査し、構造どおりになっているかを評価 成果物の構造を図にしてアウトプットする 昨日レビューしたテスト成果物の構造
  37. 37. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 36 テスト実施の進め方  テスト実施時の進め方(戦略を具現化したもの)を調査  テスト計画書で書かれているテスト実施の進め方を調査し、進め方どおりのテ ストが実施されているか、また進め方が「なるほどね」と思えるかを評価 2週 3週 4週 1週 2週 3週 4週 1週 2週 4月 5月 6月 4/23 5/21 6/44/16     ▲4/21 仕様項目レビュー ★ インストールテ スト 4/23 1h ★ インストールテ スト 5/21 1h ★ 実機動作確 認 ★ V1.2.0新機能動作確認 4/26~4/28  ゴールデン  ウイーク  4/29~5/5 ★ TOFTOF関連 5/10~5/14 ★ 回帰テスト 5/17~5/21 ★ ベースラインなど 5/24~5/28 ★ 回帰テスト 5/31~6/4 ★ V1.3.0新機能動作確認 5/24~5/25 ★ 性能テスト 5/26~5/28 ★ 探索的テスト 5/31~6/4 ★ シナリオテスト 6/3~6/4 2日 テスト分析・設計・実装     ▲ 5/7 テストシナリオ完成 ▲4/23 テスト設計方針完成 テスト対象項目は  ・PCがハングアップし たときのパターン  ・一連の基本動作 あとは技術Gで保証して いただく 新機能、変更内容に対 し  ・計算が絡むものは動 作確認  ・計算がからまないも のは仕様項目をベース にテスト実行する 5/20 コンサル予定 5月7日までに効率的に テスト実行が進むようテ ストシナリオまで準備す ること。(計算関係のテストは テストシナリオの有無が実行時 間に大きな影響を与えるので) 21日より前まで に、アクティビティ 図ベースで変更 範囲を設計に洗 い出してもらう ・TOFTOF自動測定 ・TOFTOFキャリブレーション .バグが出た時の再テストを考 慮すると、3日程度でテストが完 了するように準備した方が良い ・ベースライン補正、ピーク検出改善 ・キャリブレーション事後適用対応 .バグが出た時の再テストを考慮する と、3日程度でテストが完了するよう に準備した方が良い テスト実施の進め方を図にしてアウトプットする
  38. 38. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 37 数字を使った把握…その1  例  ある会社では、システムテストに協力会社を使ってテストを行って いる。沢山テストをしているのだが漏れがあると言う。直近のテスト でのテストケース数を確認すると、 37,671ケースであった。  コンセプトを理解しないとわからないこと  コンセプトを理解せずともわかること ・このテストケースの量は多いのか、少ないのか? ・充分なのか不十分なのか? ・37671が妥当な数字かを知るために、一人が1日何ケース実施しているかを確認する。 →33人日で実施していた場合… ・現状のテストケース数からを1テストケース辺りに掛かる時間を計算すると37671(総テ ストケース数)/33(人日) ≒ 1141(1人が1日に消化するテストケース数) となり、33日の間、全員が約29秒に1テスト項目を休み無く消化していることになる。
  39. 39. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 38 数字を使った把握…その2  例  あるプロジェクトでは、システムテスト開始の最初の週(5日間)の中 で、不具合の報告が80件あった。  コンセプトを理解しないとわからないこと  コンセプトを理解せずともわかること ・バグが出過ぎかどうかは分からない。 (テストの仕方、人の数、時間、バグの内容を見ないと分からな い。) ・80件が妥当な数字かを知るために、何人が何日で見つけたバグかを確認する →4人で20人日の可動工数だった場合 ・バグが出てからレポートにするまでの時間がどれくらいか? ・テストが進んでいるかどうかを調べる。 ・テスト始めて30分、バグレポート書いていて30分だと考えて、4件書いていたら約4時間 =何もテスト出来ていない。
  40. 40. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 39 「見せる時」のコツ  コンサルは自分が知らない相手に見てわかってもらうのが仕事  当然わかるだろうという思いを捨て去る(聞く人は初めて)  目的から理論だてる(テストプロセス改善の目的は…)  見せる相手に理解の枠組みを与える(今日の話の構成は…)  必要なものを取出し、不要なものを削る(モデル化して見せる)  伝えたいことを端的に見せてから 細かい話(根拠)に入る  結論は… → 理由は…  根拠は複数の視点で見せる  成果物の記載内容から見ると…  不具合の傾向から見ると…  現場の声は…  強み、弱み  全体、拡大、詳細 A駅 B駅 C駅 D駅 ***線 E駅 ***線 F駅 G駅 5 11 12 8 7 12 19 H駅 I駅 電車に乗って目的地に行きたいというとき、地図をそのまま見る よりも路線の乗り継ぎや、駅間の移動時間にフォーカスしたもの を見たほうが知りたいことがわかる モデル化の例
  41. 41. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 40 モデル化し、複数の視点で見せる  必要なものを取出し、不要なものを削る(モデル化)  根拠は複数の視点で見せる(全体、拡大、詳細) 拡大してみる 細かくしてみる 週毎傾向 この週が突然 上昇傾向 M T W T F SM T W T F S M T W T F S A B C M T W T F S A B C 日毎傾向 日毎傾向火曜日に欠陥 を大量に検出 欠陥が出ている のはモジュールC のみ 対象 観点 残存リスク収束率実績(平均) 0.0 10.0 20.0 30.0 40.0 50.0 60.0 70.0 80.0 90.0 100.0 09月01日 09月03日 09月05日 09月07日 09月09日 09月11日 09月13日 09月15日 09月17日 09月19日 09月21日 09月23日 09月25日 09月27日 09月29日 10月01日 10月03日 10月05日 10月07日 10月09日 10月11日 10月13日 10月15日 10月17日 10月19日 TC消化計画(平均) リスク収束計画 リスク収束実績 4週目欠陥分類パレート 6 6 3 2 2 1 30.0% 60.0% 75.0% 85.0% 95.0% 100.0% 0 5 10 15 20 25 30 35 40 システム統合 機能 インプリメント 要件・仕様 構造・データ システム構成 0.0% 10.0% 20.0% 30.0% 40.0% 50.0% 60.0% 70.0% 80.0% 90.0% 100.0% 件数 割合
  42. 42. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 41 残りをまとめてみると  テストに対する想い(いろんな人にいろんな想い)  目的と手段の階層構造  →目的と手段を整理して理解しよう  テストに関わる立場による想いの変化  →目的はだんだん変わってくるよ(というより変えていいんだよ)  テストコンサルの想い(視点を上げるということ)  →視点を上げてつながるようにすると納得して仕事が出来るよ  「伝えたい」想いを持ち続けるためには  →あるべき姿を描いて、納得して、押したり引いたりしてみよう  「見て」のコツ  成果物の連鎖→プロセスを見て  成果物の構造→テスト設計を見て  テストのやり方→テスト戦略を見てる  数字の使い方→説明の「もっともらしさ」を確認するときに使う  「見せて」のコツ→モデル化&複数の視点 抽象化すると 「見る」と一緒
  43. 43. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 42 ありがとうございました。 テストほど知的で創造的な仕事は無い! By 山浦恒央(東海大学)

×