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

1. テストコンサルタントの「見たい」「見せたい」「伝えたい」 2010年6月13日 15:05～16:05 WACATE2010 夏湯本剛

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. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 2 今日の主な内容  テストに対する想い（いろんな人にいろんな想い）  目的と手段の階層構造  テストに関わる立場による想いの変化（湯本の例）  テストコンサルの想い（大事なことは、、）  「伝えたい」想いを持ち続けるためには  「見て」のコツ  成果物の連鎖  成果物の構造  テストのやり方  数字の使い方  「見せて」のコツ

4. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 3 テストはなんでやるんでしょう？

5. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 4 テストはなんでやるんでしょう？品質を計測し定量表示するため欠陥を摘出するため人は間違いを犯すためテスト結果が納品物だから欠陥を摘出して直してもらうためプロダクトリスクを軽減するためプロジェクトの行く手を照らすため心配だから仕事だからバグがあると命に関わるから市場バグがあると上司に怒られるテストでバグを見つけておけば会社が損をしないリリース後にバグが見つかると手間だから銀の弾丸だからバグが出ると楽しいバグがあると多くの人に迷惑がかかるから

6. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 5 いろんな人にいろんな想い

7. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 6 テストはなんでやるんでしょう？  テストの必要性  品質を計測し定量表示できる  摘出した欠陥を計測する  特性を計測する（応答時間、使用メモリ量…)  契約や法律上の適格要件に対する証拠の提示ができる  要件との合致を確認する  ソフトウェアの品質に確信を持つことができる（もう出しても大丈夫）  プロダクトリスクは軽減している  見つかった欠陥を修正されていることで品質が確保できてる  将来開発するシステムの品質を改善できる  他のプロジェクトで見つかった欠陥の根本原因を理解する  プロセスを改善し、同じ原因の欠陥の作りこみを防ぐ  テストの目的  欠陥を摘出する  対象ソフトウェアの品質レベルが十分であることを確認し、その情報を示す  欠陥の作りこみを防ぐ ISTQBに聞いてみた

8. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 7 「テストの必要性」を目的と手段に分けると品質を計測、定量表示契約、法律の証拠提示品質に確信を持つシステム品質を改善プロダクトリスク軽減欠陥修正確認欠陥原因分析プロセス改善欠陥計測特性計測手段目的合致確認

9. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 8 「テストの目的」を追加…欠陥を摘出する品質を計測、定量表示契約、法律の証拠提示品質に確信を持つシステム品質を改善プロダクトリスク軽減欠陥修正確認欠陥原因分析プロセス改善欠陥計測特性計測手段目的合致確認欠陥を摘出する表示の誤りは無いか処理手順によって出力が誤るか境界値とか０とかNULLなど間違えそうな入力データで出力が誤るかサイズの大きいデータを高頻度に与えるとエラーになるか・・・テストの目的新規開発部分の機能の不具合を見つける影響範囲の機能の不具合を見つけるデータ登録高負荷時の不具合を見つける影響範囲の機能の不具合を見つける・・・その手段具体的には.. 具体的には..

10. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 9 「テストの目的」を追加…品質情報を示す品質を計測、定量表示契約、法律の証拠提示品質に確信を持つシステム品質を改善プロダクトリスク軽減欠陥修正確認欠陥原因分析プロセス改善欠陥計測特性計測手段目的合致確認品質レベルが十分であることを確認し、その情報を示すユーザが最も良く使う機能の使い勝手 Windowsロゴの取得テスト労力に対する欠陥数で信頼度を測定システムを使った通常処理機能の確認・・・テストの目的必要処理までの操作数計測ユーザプロファイルに基づいたイレギュラー操作 MSから提示のあったチェックリストベースのテストその手段・・・具体的には.. 具体的には..

11. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 10 「テストの目的」を追加…欠陥の作り込みを防ぐ品質を計測、定量表示契約、法律の証拠提示品質に確信を持つシステム品質を改善プロダクトリスク軽減欠陥修正確認欠陥原因分析プロセス改善欠陥計測特性計測手段目的合致確認欠陥の作りこみを防ぐ仕様の抜け漏れを指摘非機能要件の実現方法不備の指摘構成管理不備の指摘欠陥を埋め込みそうな構造の問題を指摘・・・コーディング前にテストベースレビューバグの分析を行い開発へフィードバック静的解析その手段・・・テストの目的具体的には.. 具体的には..

12. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 11 ３つの例からわかること品質を計測、定量表示契約、法律の証拠提示品質に確信を持つシステム品質を改善プロダクトリスク軽減欠陥修正確認欠陥原因分析プロセス改善欠陥計測特性計測手段目的合致確認目的と手段の連鎖を単純に１対１にせず工夫している…それが人間らしさ繋がりが分かることで腑に落ちて、何をすればよいかが分かる…やる気の源

13. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 12 それぞれの目的はなんで必要なんでしょう？品質を計測、定量表示契約、法律の証拠提示品質に確信を持つシステム品質を改善プロダクトリスク軽減欠陥修正確認欠陥原因分析プロセス改善欠陥計測特性計測手段目的合致確認利用する人たちにとって価値のあるシステム/製品 /ソフトウェアを提供したい世の中のルールに沿ってビジネスを成立させたい開発に携わる人だけでなく、誰が見てもわかるように品質情報を提供したい自分たちの開発をより価値のある、やりがいのある仕事にしていきたい目的の先にある「想い」欠陥を摘出する / 品質レベルが十分であることを確認し、その情報を示す / 欠陥の作りこみを防ぐ

14. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 13 それぞれの目的はなんで必要なんでしょう？利用する人たちにとって価値のあるシステム/製品 /ソフトウェアを提供したい世の中のルールに沿ってビジネスを成立させたい開発に携わる人だけでなく、誰が見てもわかるように品質情報を提供したい自分たちの開発をより価値のある、やりがいのある仕事にしていきたい目的の先にある「想い」にも関係がある

15. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 14 それぞれの目的はなんで必要なんでしょう？利用する人たちにとって価値のあるシステム/製品 /ソフトウェアを提供したい世の中のルールに沿ってビジネスを成立させたい開発に携わる人だけでなく、誰が見てもわかるように品質情報を提供したい自分たちの開発をより価値のある、やりがいのある仕事にしていきたい組織内の上長組織内の経営層利用者（メリットを得る人）利用者（使う人）プロジェクトメンバ（他チーム）プロジェクトマネージャプロジェクトメンバ（自チーム）認証機関組織内の監査部隊目的の先にある「想い」は誰のため？

16. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 15 自分の立場によっても目的は変わる  目的と手段は階層構造  情報技術がなぜ世の中に必要なのか？と考えた場合の一例究極の目的手段ビジネス手段 IT活用手段システム開発手段品質管理手段テスト手段テスト設計手段テストの目的どこを立脚点にして世界を捉えるかによって目的と手段は決まる人の幸せ「ビジネス」とは・提供した価値に対して相応しい対価を得ること

17. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 16 テスト担当者の頃ゆもつよの場合

18. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 17 テストの仕事を始めた頃テスト手段テストの目的・重大なバグを見つけると楽しい →「オレ、やったゼ」感・人より多くバグを見つけたい →自分をアピールしたい・時間内で沢山テストケースを消化したい →沢山テストした方がバグが見つかる！&（早く帰れる or 人の分を手伝ってあげられる）テストでバグを見つけるテスト実施手段とにかく与えられた仕事をちゃんとやること以上のことはよくわかっていない

19. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 18 テストケースを書くようになった頃テスト手段テストの目的テストでバグを見つける＋網羅的なテストをするテスト実施手段何がバグになるかはわかってきたが、それ以上は変わっていない・重大なバグを見つけるテストケースを書きたい →データCRUDした後の他処理への反映 →共有リソースへの処理競合 →処理順序の入れ替え・「これだけは最低見とかないと」と思えるテストケースを書いておきたい →「画面周り」「計算」「データCRUD」「大量データ」 … テスト設計手段あまりに非現実的なものだと、細かいとか言われるので、思いついた手順が現実的に想定出来るかを考えるようになった。

20. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 19 テストリーダの頃ゆもつよの場合

21. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 20 納期手段コスト手段テストリーダを始めた頃テスト手段テストの目的・納期に間に合うようにテストをやり遂げたい →設計内容を早いうちに理解してポイントを押さえる →開発者にもっとテストしてもらう →開発者に何がダメかをちゃんとわかってもらう（次は同じ問題が出ないようにする）・工数をちゃんと見積もりたい →見積もった工数を守らせる →守ることができる工数見積をする →やり方を工夫することで工数がかからないようにする…自動化テスト実施手段コストと納期を意識するがテストが品質管理の一部とまで考えられなかった… 「自分たちだけの最適化」テスト設計手段テスト管理手段テストでバグを見つける＋網羅的なテストをする＋工数、納期を守る自動テストツールの使い方を調べていてTEF の存在を知る（多分1999年か2000年）

22. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 21 システム開発手段品質管理手段自組織の売上手段案件の提案をするようになった頃テストの目的・何故テストにコストがかかるかを人に説明する →テスト分析マトリクス…理解を共有するため・案件毎にどこまでテストすべきかを決める →いろいろなドメインの案件 →人数の投入方法（1人~40人まで）・自分たちの売りを作りたい →自動化…WinRunner →バグ分析…社内のBTS作成、報告書統一納期手段コスト手段テスト手段テスト実施手段テスト設計手段テスト管理手段テストでバグを見つける＋網羅的なテストをする＋工数、納期を勝ち取り、 QCDを達成する二つの目的に対する折り合いがつけなくってきていたこのころまでに関わったソフトウェア経理ソフトプリンタドライバ TWAIN プリンタ付属ソフト（カレンダー作成ソフト）住宅見積もりシステム資材管理システム、生産管理システム、SCMシステム BTOサイト Windows認証のテスト…など

23. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 22 テストコンサルになってからゆもつよの場合

24. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 23 ビジネス手段顧客の IT活用手段開発組織の成長手段視点を上げる事を学び、チャレンジしてきたコンサルの目的・テストのあるべき姿を伝えたい →テストプロセス、テスト設計の教育講師・どうやれば成長するかを伝えたい →アセスメント（どこに成長の余地があるかを調べ、伝える）・自分で成長できるようになってもらいたい →テストプロセス改善…リスク分析、テスト戦略、テスト分析・設計、テスト実施に対するアドバイス &チャレンジする時に背中を押してあげるシステム開発手段品質管理手段納期手段コスト手段テスト手段テスト実施手段テスト設計手段テスト管理手段「コンサルのお客様（開発組織）の成功」と「お客様のお客様（利用者）の成功」をつなげることができて（connect）自分のビジネスの成功につなげるテストの価値を上げる＋テストがビジネスに貢献する

25. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 24 大事なことは…視点をあげるということ  テストなら…テストをやり遂げるだけではなくテストの価値をあげるテストをやり遂げるテストをやり遂げるテストの価値向上 Quality 言われた通りのテストをするバグを沢山見つける適切なテスト内容、テスト量でテストする出すべきバグを見つける Cost 計画したコスト以内でテストを終わらせるそのコストを掛けて得られるメリットを見直すコストに見合う価値.. そこから得られるものは？自己メリットがあるのか？ Delivery 納期にテストを間に合わせる適切な時期に適切なテストを行うテストの価値を上げるゴールゴール

26. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 25 もうひとつの大事なことは…協奏ビジネス手段ビジネス手段顧客の IT活用手段顧客の IT活用手段開発組織の成長手段開発組織の成長手段システム開発手段システム開発手段品質管理手段品質管理手段納期手段納期手段コスト手段コスト手段テスト手段テスト手段テスト実施手段テスト実施手段テスト設計手段テスト設計手段テスト管理手段テスト管理手段ビジネス手段ビジネス手段顧客の IT活用手段顧客の IT活用手段開発組織の成長手段開発組織の成長手段システム開発手段システム開発手段品質管理手段品質管理手段納期手段納期手段コスト手段コスト手段テスト実施手段テスト実施手段テスト設計手段テスト設計手段テスト管理手段テスト管理手段土台が無いと、実現に無理がある…「妄想」向かうべき場所がないとバラバラになる…「暴走」目的と手段の両方が伴っている…「協奏」物事を達成するための土台つくり「勉強」「信頼関係」「経験」視点上と下を行ったり来たりする

27. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 26 ここまでが今日の「伝えたい」

28. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 27 いったんまとめてみると  テストに対する想い（いろんな人にいろんな想い）  目的と手段の階層構造  →目的と手段を整理して理解しよう  テストに関わる立場による想いの変化  →目的はだんだん変わってくるよ（というより変えていいんだよ）  テストコンサルの想い（大事なことは、、）  →視点を上げてつながるようにすると納得して仕事が出来るよ  「伝えたい」想いを持ち続けるためには  「見て」のコツ  成果物の連鎖→プロセスを見て  成果物の構造→テスト設計を見て  テストのやり方→テスト戦略を見てる  数字の使い方→説明の「もっともらしさ」を確認するときに使う  「見せて」のコツというのが若い人達へのメッセージです

29. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 28 「伝えたい」から話した理由

30. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 29 見て、見せて、伝えるというより…  まずは伝えたい事がないと伝わらない  そこが出発点見て伝えたい事があるのが出発点伝える見せて（伝えたい事があるから）見て（確信を持って）伝える（伝わるように）見せて「伝えたい」を持ち続けて欲しい

31. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 30 「伝えたい」想いを持ち続けるためには  「本来はこうなんじゃないか」という事を知る  あるべき姿を学ぶ…目的の先の「想い」  原理原則を学ぶ…抽象的な見方  「納得できるか」を大事にする  自分が納得できる  学びとチャレンジを繋げる  相手に納得してもらう  自分と相手を繋げる  押してもダメなら引いてみる  目的にふさわしい手段は一つじゃない抽象的具体的 connect the dots.

32. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 31 「見て」「見せて」のコツ

33. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 32 以降はちょっとしたTips  「見て」「見せて」は「伝えたい想い」を実現する手段  なので、時と場合によりいくらでも変わるもの  今日は私がコンサルとして仕事するなかでやっていること/心がけていることをTipsとして紹介

34. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 33 「見る時」のコツ  コンサルは自分が知らないところへ行き短時間で状況把握をするのが仕事  まずは自分の感覚との意識合わせから始める  「テストプロセス改善」で言えば、以下３つのコンセプトを理解する  テストの成果物の連鎖  成果物の構造（各要素がどこにあるのか？）  テストの配置  理解した上でさらに現場の声を聞く  具体的なイメージが共有できることは数字を使って見ることで「短時間」で把握する！その数字に対して共通理解が持てる単位でないと効果が低い  成果物の数  バグの件数  テストケースの件数  仕様書のページ数  時間  バグ一件あたりの時間  テストケース一件あたりの時間

35. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 34 テスト成果物の連鎖  テストプロセスの特徴を理解  調査対象となるドキュメントを決める  その後のドキュメントレビュー／インタビューにて理解内容を補正し、強み、弱みを評価完了作業のプロセスとして反省会実施各協力会社に「提案」活動を実施してもらっている Sbcが「提案」活動を実施している ⇒キックオフ原案は見積り前に提示している試験設計のレビューが公式なものとなっているバグ分析を行いテスト設計へ反映している完了作業のプロセスとして反省会実施完了作業のプロセスとして反省会実施各協力会社に「提案」活動を実施してもらっている Sbcが「提案」活動を実施している ⇒キックオフ原案は見積り前に提示している各協力会社に「提案」活動を実施してもらっている各協力会社に「提案」活動を実施してもらっている Sbcが「提案」活動を実施している ⇒キックオフ原案は見積り前に提示している Sbcが「提案」活動を実施している ⇒キックオフ原案は見積り前に提示している試験設計のレビューが公式なものとなっている試験設計のレビューが公式なものとなっているバグ分析を行いテスト設計へ反映しているバグ分析を行いテスト設計へ反映しているテストプロセスを図にしてアウトプットする

36. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 35 テスト成果物の構造  テスト成果物の（静的な）構造を調査  テスト設計書、テスト仕様書、手順書などへの要素の配置方法を調査し、テストの不足、重複、複雑度合いなどを評価  テスト設計からテストケースのトレースを調査し、構造どおりになっているかを評価成果物の構造を図にしてアウトプットする昨日レビューしたテスト成果物の構造

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. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 37 数字を使った把握…その1  例  ある会社では、システムテストに協力会社を使ってテストを行っている。沢山テストをしているのだが漏れがあると言う。直近のテストでのテストケース数を確認すると、 37,671ケースであった。  コンセプトを理解しないとわからないこと  コンセプトを理解せずともわかること・このテストケースの量は多いのか、少ないのか？・充分なのか不十分なのか？・37671が妥当な数字かを知るために、一人が1日何ケース実施しているかを確認する。 →33人日で実施していた場合… ・現状のテストケース数からを1テストケース辺りに掛かる時間を計算すると37671（総テストケース数）/33(人日) ≒ 1141(1人が1日に消化するテストケース数) となり、33日の間、全員が約29秒に1テスト項目を休み無く消化していることになる。

39. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 38 数字を使った把握…その2  例  あるプロジェクトでは、システムテスト開始の最初の週（5日間）の中で、不具合の報告が80件あった。  コンセプトを理解しないとわからないこと  コンセプトを理解せずともわかること・バグが出過ぎかどうかは分からない。（テストの仕方、人の数、時間、バグの内容を見ないと分からない。）・80件が妥当な数字かを知るために、何人が何日で見つけたバグかを確認する →4人で20人日の可動工数だった場合・バグが出てからレポートにするまでの時間がどれくらいか？・テストが進んでいるかどうかを調べる。・テスト始めて30分、バグレポート書いていて30分だと考えて、4件書いていたら約4時間＝何もテスト出来ていない。

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. 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. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 41 残りをまとめてみると  テストに対する想い（いろんな人にいろんな想い）  目的と手段の階層構造  →目的と手段を整理して理解しよう  テストに関わる立場による想いの変化  →目的はだんだん変わってくるよ（というより変えていいんだよ）  テストコンサルの想い（視点を上げるということ）  →視点を上げてつながるようにすると納得して仕事が出来るよ  「伝えたい」想いを持ち続けるためには  →あるべき姿を描いて、納得して、押したり引いたりしてみよう  「見て」のコツ  成果物の連鎖→プロセスを見て  成果物の構造→テスト設計を見て  テストのやり方→テスト戦略を見てる  数字の使い方→説明の「もっともらしさ」を確認するときに使う  「見せて」のコツ→モデル化＆複数の視点抽象化すると「見る」と一緒

43. 2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 42 ありがとうございました。テストほど知的で創造的な仕事は無い！ By 山浦恒央（東海大学）

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

You are reading a preview.

Check these out next

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

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Similar to WACATE　2010夏　ゆもつよ講演スライド (20)

Recently uploaded (20)