SlideShare a Scribd company logo

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

1 of 43
テストコンサルタントの
「見たい」「見せたい」
「伝えたい」
2010年6月13日 15:05~16:05
WACATE2010 夏
湯本 剛
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月頃発売
【特集記事】
・湯本のテスト分析・設計
2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 2
今日の主な内容
 テストに対する想い(いろんな人にいろんな想い)
 目的と手段の階層構造
 テストに関わる立場による想いの変化(湯本の例)
 テストコンサルの想い(大事なことは、、)
 「伝えたい」想いを持ち続けるためには
 「見て」のコツ
 成果物の連鎖
 成果物の構造
 テストのやり方
 数字の使い方
 「見せて」のコツ
2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 3
テストはなんでやるんでしょう?
2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 4
テストはなんでやるんでしょう?
品質を計測
し定量表示
するため
欠陥を摘出
するため
人は間違い
を犯すため
テスト結果が
納品物だから
欠陥を摘出
して直しても
らうため
プロダクトリ
スクを軽減
するため
プロジェクト
の行く手を照
らすため
心配だから
仕事だから
バグがあると命
に関わるから
市場バグがあると
上司に怒られる
テストでバグを見
つけておけば会社
が損をしない
リリース後にバ
グが見つかると
手間だから
銀の弾丸
だから
バグが出ると
楽しい
バグがあると多く
の人に迷惑がか
かるから
2010/6/13 WACATE2010夏 Tsuyoshi YUMOTO 5
いろんな人に
いろんな想い

Recommended

テスト分析入門 -「ゆもつよメソッド」を例に- #wacate
テスト分析入門 -「ゆもつよメソッド」を例に- #wacateテスト分析入門 -「ゆもつよメソッド」を例に- #wacate
テスト分析入門 -「ゆもつよメソッド」を例に- #wacateKinji Akemine
 
WACATE2019冬 ソフトウェアテスト業界でのステップアップを考えよう #wacate
WACATE2019冬 ソフトウェアテスト業界でのステップアップを考えよう #wacateWACATE2019冬 ソフトウェアテスト業界でのステップアップを考えよう #wacate
WACATE2019冬 ソフトウェアテスト業界でのステップアップを考えよう #wacateKinji Akemine
 
テスト分析とは何か
テスト分析とは何かテスト分析とは何か
テスト分析とは何かkauji0522
 
モデル検査入門 #wacate
モデル検査入門 #wacateモデル検査入門 #wacate
モデル検査入門 #wacateKinji Akemine
 
REBOKを社内展開する際の障壁
REBOKを社内展開する際の障壁REBOKを社内展開する際の障壁
REBOKを社内展開する際の障壁mkoszk
 
ゆもつよ博士論文説明資料公開
ゆもつよ博士論文説明資料公開ゆもつよ博士論文説明資料公開
ゆもつよ博士論文説明資料公開Tsuyoshi Yumoto
 
TABOK Skill Category2解説
TABOK Skill Category2解説TABOK Skill Category2解説
TABOK Skill Category2解説Kinji Akemine
 

More Related Content

What's hot

テストを分類してみよう!
テストを分類してみよう!テストを分類してみよう!
テストを分類してみよう!Kenji Okumura
 
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacateKinji Akemine
 
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年verソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年verKosuke Fujisawa
 
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しようテスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しようAkira Ikeda
 
GUI自動テストの保守性を高めるには
GUI自動テストの保守性を高めるにはGUI自動テストの保守性を高めるには
GUI自動テストの保守性を高めるにはNozomi Ito
 
テストプロセスについて
テストプロセスについてテストプロセスについて
テストプロセスについてKosuke Fujisawa
 
EMTEを使って自動化の費用対効果をわかりやすく表現する
EMTEを使って自動化の費用対効果をわかりやすく表現するEMTEを使って自動化の費用対効果をわかりやすく表現する
EMTEを使って自動化の費用対効果をわかりやすく表現するJYERUEY
 
アジャイル×テスト開発を考える
アジャイル×テスト開発を考えるアジャイル×テスト開発を考える
アジャイル×テスト開発を考えるyasuohosotani
 
「マインドマップから始めるソフトウェアテスト」まとめ
「マインドマップから始めるソフトウェアテスト」まとめ「マインドマップから始めるソフトウェアテスト」まとめ
「マインドマップから始めるソフトウェアテスト」まとめKosuke Fujisawa
 
テストアプローチにデータ分析を使おう
テストアプローチにデータ分析を使おうテストアプローチにデータ分析を使おう
テストアプローチにデータ分析を使おうSayaka Nakano
 
システムテスト自動化標準ガイド 読書会 第8章
システムテスト自動化標準ガイド 読書会 第8章システムテスト自動化標準ガイド 読書会 第8章
システムテスト自動化標準ガイド 読書会 第8章mirer
 
システムテスト自動化標準ガイド 5章発表資料
システムテスト自動化標準ガイド 5章発表資料システムテスト自動化標準ガイド 5章発表資料
システムテスト自動化標準ガイド 5章発表資料Masatoshi Itoh
 
テスト自動化のこれまでとこれから
テスト自動化のこれまでとこれからテスト自動化のこれまでとこれから
テスト自動化のこれまでとこれからKeizo Tatsumi
 
Agileツール適合化分科会(テスト自動化ツール)
Agileツール適合化分科会(テスト自動化ツール)Agileツール適合化分科会(テスト自動化ツール)
Agileツール適合化分科会(テスト自動化ツール)masanori kataoka
 
テストの極みを目指して ~さあ、理想に近づくための一歩を踏み出そう!~
テストの極みを目指して ~さあ、理想に近づくための一歩を踏み出そう!~テストの極みを目指して ~さあ、理想に近づくための一歩を踏み出そう!~
テストの極みを目指して ~さあ、理想に近づくための一歩を踏み出そう!~崇 山﨑
 
アジャイルテストを、壮絶に、考える。
アジャイルテストを、壮絶に、考える。アジャイルテストを、壮絶に、考える。
アジャイルテストを、壮絶に、考える。Dai FUJIHARA
 
アジャイル開発におけるシステムテストの自動化
アジャイル開発におけるシステムテストの自動化アジャイル開発におけるシステムテストの自動化
アジャイル開発におけるシステムテストの自動化Toru Koido
 

What's hot (17)

テストを分類してみよう!
テストを分類してみよう!テストを分類してみよう!
テストを分類してみよう!
 
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
 
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年verソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年ver
 
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しようテスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
テスト分析・設計を体感しよう ~マインドマップを活用してテスト観点を発想しよう
 
GUI自動テストの保守性を高めるには
GUI自動テストの保守性を高めるにはGUI自動テストの保守性を高めるには
GUI自動テストの保守性を高めるには
 
テストプロセスについて
テストプロセスについてテストプロセスについて
テストプロセスについて
 
EMTEを使って自動化の費用対効果をわかりやすく表現する
EMTEを使って自動化の費用対効果をわかりやすく表現するEMTEを使って自動化の費用対効果をわかりやすく表現する
EMTEを使って自動化の費用対効果をわかりやすく表現する
 
アジャイル×テスト開発を考える
アジャイル×テスト開発を考えるアジャイル×テスト開発を考える
アジャイル×テスト開発を考える
 
「マインドマップから始めるソフトウェアテスト」まとめ
「マインドマップから始めるソフトウェアテスト」まとめ「マインドマップから始めるソフトウェアテスト」まとめ
「マインドマップから始めるソフトウェアテスト」まとめ
 
テストアプローチにデータ分析を使おう
テストアプローチにデータ分析を使おうテストアプローチにデータ分析を使おう
テストアプローチにデータ分析を使おう
 
システムテスト自動化標準ガイド 読書会 第8章
システムテスト自動化標準ガイド 読書会 第8章システムテスト自動化標準ガイド 読書会 第8章
システムテスト自動化標準ガイド 読書会 第8章
 
システムテスト自動化標準ガイド 5章発表資料
システムテスト自動化標準ガイド 5章発表資料システムテスト自動化標準ガイド 5章発表資料
システムテスト自動化標準ガイド 5章発表資料
 
テスト自動化のこれまでとこれから
テスト自動化のこれまでとこれからテスト自動化のこれまでとこれから
テスト自動化のこれまでとこれから
 
Agileツール適合化分科会(テスト自動化ツール)
Agileツール適合化分科会(テスト自動化ツール)Agileツール適合化分科会(テスト自動化ツール)
Agileツール適合化分科会(テスト自動化ツール)
 
テストの極みを目指して ~さあ、理想に近づくための一歩を踏み出そう!~
テストの極みを目指して ~さあ、理想に近づくための一歩を踏み出そう!~テストの極みを目指して ~さあ、理想に近づくための一歩を踏み出そう!~
テストの極みを目指して ~さあ、理想に近づくための一歩を踏み出そう!~
 
アジャイルテストを、壮絶に、考える。
アジャイルテストを、壮絶に、考える。アジャイルテストを、壮絶に、考える。
アジャイルテストを、壮絶に、考える。
 
アジャイル開発におけるシステムテストの自動化
アジャイル開発におけるシステムテストの自動化アジャイル開発におけるシステムテストの自動化
アジャイル開発におけるシステムテストの自動化
 

Viewers also liked

テスト分析についての説明資料公開用
テスト分析についての説明資料公開用テスト分析についての説明資料公開用
テスト分析についての説明資料公開用Tsuyoshi Yumoto
 
20170203 test analysisdesign
20170203 test analysisdesign20170203 test analysisdesign
20170203 test analysisdesignKouichi Akiyama
 
テスト分析・設計について、釈然としないところ
テスト分析・設計について、釈然としないところテスト分析・設計について、釈然としないところ
テスト分析・設計について、釈然としないところKosuke Fujisawa
 
A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.
A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.
A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.Tsuyoshi Yumoto
 
A study on the efficiency of a test analysis method utilizing test-categories...
A study on the efficiency of a test analysis method utilizing test-categories...A study on the efficiency of a test analysis method utilizing test-categories...
A study on the efficiency of a test analysis method utilizing test-categories...Tsuyoshi Yumoto
 
とてか03「「いかす!」のために大事だと思う4つのこと」
とてか03「「いかす!」のために大事だと思う4つのこと」とてか03「「いかす!」のために大事だと思う4つのこと」
とてか03「「いかす!」のために大事だと思う4つのこと」Tsuyoshi Yumoto
 
テスト計画セッション
テスト計画セッションテスト計画セッション
テスト計画セッションTomoaki Fukura
 
20150424 jasst新潟基調講演
20150424 jasst新潟基調講演20150424 jasst新潟基調講演
20150424 jasst新潟基調講演Kouichi Akiyama
 
N-Switchカバレッジテストの問題点と解決策
N-Switchカバレッジテストの問題点と解決策N-Switchカバレッジテストの問題点と解決策
N-Switchカバレッジテストの問題点と解決策Kouichi Akiyama
 
JSTQB AL テストアナリスト 概要資料
JSTQB AL テストアナリスト 概要資料JSTQB AL テストアナリスト 概要資料
JSTQB AL テストアナリスト 概要資料Akira Ikeda
 
【JaSST'11 Tokyo】 テスト イノベーション
【JaSST'11 Tokyo】 テスト イノベーション【JaSST'11 Tokyo】 テスト イノベーション
【JaSST'11 Tokyo】 テスト イノベーション智治 長沢
 
JaSST'15 Tokyo クロージングパネル概要
JaSST'15 Tokyo クロージングパネル概要JaSST'15 Tokyo クロージングパネル概要
JaSST'15 Tokyo クロージングパネル概要Makoto Nonaka
 
Myweekdays and testing
Myweekdays and testingMyweekdays and testing
Myweekdays and testingryuji koyama
 
JaSST'12 Niigata LT-koyaman
JaSST'12 Niigata LT-koyamanJaSST'12 Niigata LT-koyaman
JaSST'12 Niigata LT-koyamanryuji koyama
 
はじめてのテスト技法
はじめてのテスト技法はじめてのテスト技法
はじめてのテスト技法Tatsuya Saito
 
詳解!自動結合テスト #jasst
詳解!自動結合テスト #jasst詳解!自動結合テスト #jasst
詳解!自動結合テスト #jasstkyon mm
 

Viewers also liked (20)

テスト分析についての説明資料公開用
テスト分析についての説明資料公開用テスト分析についての説明資料公開用
テスト分析についての説明資料公開用
 
20170203 test analysisdesign
20170203 test analysisdesign20170203 test analysisdesign
20170203 test analysisdesign
 
20160619 wacate 解答
20160619 wacate   解答20160619 wacate   解答
20160619 wacate 解答
 
テスト分析・設計について、釈然としないところ
テスト分析・設計について、釈然としないところテスト分析・設計について、釈然としないところ
テスト分析・設計について、釈然としないところ
 
A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.
A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.
A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.
 
A study on the efficiency of a test analysis method utilizing test-categories...
A study on the efficiency of a test analysis method utilizing test-categories...A study on the efficiency of a test analysis method utilizing test-categories...
A study on the efficiency of a test analysis method utilizing test-categories...
 
とてか03「「いかす!」のために大事だと思う4つのこと」
とてか03「「いかす!」のために大事だと思う4つのこと」とてか03「「いかす!」のために大事だと思う4つのこと」
とてか03「「いかす!」のために大事だと思う4つのこと」
 
テスト計画セッション
テスト計画セッションテスト計画セッション
テスト計画セッション
 
20150424 jasst新潟基調講演
20150424 jasst新潟基調講演20150424 jasst新潟基調講演
20150424 jasst新潟基調講演
 
20160607 SS2016 FP
20160607 SS2016 FP20160607 SS2016 FP
20160607 SS2016 FP
 
N-Switchカバレッジテストの問題点と解決策
N-Switchカバレッジテストの問題点と解決策N-Switchカバレッジテストの問題点と解決策
N-Switchカバレッジテストの問題点と解決策
 
JSTQB AL テストアナリスト 概要資料
JSTQB AL テストアナリスト 概要資料JSTQB AL テストアナリスト 概要資料
JSTQB AL テストアナリスト 概要資料
 
20080615 wacate
20080615 wacate20080615 wacate
20080615 wacate
 
【JaSST'11 Tokyo】 テスト イノベーション
【JaSST'11 Tokyo】 テスト イノベーション【JaSST'11 Tokyo】 テスト イノベーション
【JaSST'11 Tokyo】 テスト イノベーション
 
JaSST'15 Tokyo クロージングパネル概要
JaSST'15 Tokyo クロージングパネル概要JaSST'15 Tokyo クロージングパネル概要
JaSST'15 Tokyo クロージングパネル概要
 
Myweekdays and testing
Myweekdays and testingMyweekdays and testing
Myweekdays and testing
 
JaSST'12 Niigata LT-koyaman
JaSST'12 Niigata LT-koyamanJaSST'12 Niigata LT-koyaman
JaSST'12 Niigata LT-koyaman
 
20160619 wacate
20160619 wacate20160619 wacate
20160619 wacate
 
はじめてのテスト技法
はじめてのテスト技法はじめてのテスト技法
はじめてのテスト技法
 
詳解!自動結合テスト #jasst
詳解!自動結合テスト #jasst詳解!自動結合テスト #jasst
詳解!自動結合テスト #jasst
 

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

ありえるえりあ勉強会@五反田~テスト編~ Part2
ありえるえりあ勉強会@五反田~テスト編~ Part2ありえるえりあ勉強会@五反田~テスト編~ Part2
ありえるえりあ勉強会@五反田~テスト編~ Part2Tomoyuki Sato
 
LINE Developer Meetup in Tokyo #39 Presentation (modified)
LINE Developer Meetup in Tokyo #39 Presentation (modified)LINE Developer Meetup in Tokyo #39 Presentation (modified)
LINE Developer Meetup in Tokyo #39 Presentation (modified)Yasuharu Nishi
 
九州ソフトウェアテスト勉強会紹介LT:Developers Summit 2016 FUKUOKA懇親会
九州ソフトウェアテスト勉強会紹介LT:Developers Summit 2016 FUKUOKA懇親会九州ソフトウェアテスト勉強会紹介LT:Developers Summit 2016 FUKUOKA懇親会
九州ソフトウェアテスト勉強会紹介LT:Developers Summit 2016 FUKUOKA懇親会Rina Fukuda
 
アジャイル入門
アジャイル入門アジャイル入門
アジャイル入門Kenji Morita
 
Ricoh UCS for iPad でみる エンタープライズ アジャイル開発
Ricoh UCS for iPad でみる エンタープライズ アジャイル開発Ricoh UCS for iPad でみる エンタープライズ アジャイル開発
Ricoh UCS for iPad でみる エンタープライズ アジャイル開発Naoki Umehara
 
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門陽一 滝川
 
20180730 ds womens
20180730 ds womens20180730 ds womens
20180730 ds womensRio Kurihara
 
アジャイルの今とこれから-Agile conference2012参加報告-技術動向編
アジャイルの今とこれから-Agile conference2012参加報告-技術動向編アジャイルの今とこれから-Agile conference2012参加報告-技術動向編
アジャイルの今とこれから-Agile conference2012参加報告-技術動向編Hiroyuki Ito
 
アジャイル開発へのイテレーション・ゼロ
アジャイル開発へのイテレーション・ゼロアジャイル開発へのイテレーション・ゼロ
アジャイル開発へのイテレーション・ゼロTaisuke Shiratori
 
テスト計画の立て方 WACATE2019 夏
テスト計画の立て方 WACATE2019 夏テスト計画の立て方 WACATE2019 夏
テスト計画の立て方 WACATE2019 夏Naoki Nakano
 
カスタマーサクセスのためのデータ整備人の活動記録
カスタマーサクセスのためのデータ整備人の活動記録カスタマーサクセスのためのデータ整備人の活動記録
カスタマーサクセスのためのデータ整備人の活動記録syou6162
 
モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013
モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013
モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013Kinji Akemine
 
アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱Koichi ITO
 
JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-
JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-
JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-崇 山﨑
 
0181013 warai CI(継続的インテグレーション)と実例紹介_公開用
0181013 warai CI(継続的インテグレーション)と実例紹介_公開用0181013 warai CI(継続的インテグレーション)と実例紹介_公開用
0181013 warai CI(継続的インテグレーション)と実例紹介_公開用tomohiro odan
 
第3回ソフトウェアテストセミナー
第3回ソフトウェアテストセミナー第3回ソフトウェアテストセミナー
第3回ソフトウェアテストセミナーTomoyuki Sato
 
異業種でのテスト自動化の実際
異業種でのテスト自動化の実際異業種でのテスト自動化の実際
異業種でのテスト自動化の実際Satsuki Urayama
 
Windowsアプリ開発の実務で使うUnitTest
Windowsアプリ開発の実務で使うUnitTestWindowsアプリ開発の実務で使うUnitTest
Windowsアプリ開発の実務で使うUnitTestkeitasudo1
 

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

ありえるえりあ勉強会@五反田~テスト編~ Part2
ありえるえりあ勉強会@五反田~テスト編~ Part2ありえるえりあ勉強会@五反田~テスト編~ Part2
ありえるえりあ勉強会@五反田~テスト編~ Part2
 
LINE Developer Meetup in Tokyo #39 Presentation (modified)
LINE Developer Meetup in Tokyo #39 Presentation (modified)LINE Developer Meetup in Tokyo #39 Presentation (modified)
LINE Developer Meetup in Tokyo #39 Presentation (modified)
 
九州ソフトウェアテスト勉強会紹介LT:Developers Summit 2016 FUKUOKA懇親会
九州ソフトウェアテスト勉強会紹介LT:Developers Summit 2016 FUKUOKA懇親会九州ソフトウェアテスト勉強会紹介LT:Developers Summit 2016 FUKUOKA懇親会
九州ソフトウェアテスト勉強会紹介LT:Developers Summit 2016 FUKUOKA懇親会
 
アジャイル入門
アジャイル入門アジャイル入門
アジャイル入門
 
Ricoh UCS for iPad でみる エンタープライズ アジャイル開発
Ricoh UCS for iPad でみる エンタープライズ アジャイル開発Ricoh UCS for iPad でみる エンタープライズ アジャイル開発
Ricoh UCS for iPad でみる エンタープライズ アジャイル開発
 
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門とりあえず30分でひととおり分かった気にはなれるアジャイル入門
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
 
View Monitoring Tips
View Monitoring TipsView Monitoring Tips
View Monitoring Tips
 
20180730 ds womens
20180730 ds womens20180730 ds womens
20180730 ds womens
 
GxPユニットテスト研修
GxPユニットテスト研修GxPユニットテスト研修
GxPユニットテスト研修
 
アジャイルの今とこれから-Agile conference2012参加報告-技術動向編
アジャイルの今とこれから-Agile conference2012参加報告-技術動向編アジャイルの今とこれから-Agile conference2012参加報告-技術動向編
アジャイルの今とこれから-Agile conference2012参加報告-技術動向編
 
アジャイル開発へのイテレーション・ゼロ
アジャイル開発へのイテレーション・ゼロアジャイル開発へのイテレーション・ゼロ
アジャイル開発へのイテレーション・ゼロ
 
テスト計画の立て方 WACATE2019 夏
テスト計画の立て方 WACATE2019 夏テスト計画の立て方 WACATE2019 夏
テスト計画の立て方 WACATE2019 夏
 
カスタマーサクセスのためのデータ整備人の活動記録
カスタマーサクセスのためのデータ整備人の活動記録カスタマーサクセスのためのデータ整備人の活動記録
カスタマーサクセスのためのデータ整備人の活動記録
 
モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013
モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013
モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013
 
アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱
 
JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-
JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-
JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-
 
0181013 warai CI(継続的インテグレーション)と実例紹介_公開用
0181013 warai CI(継続的インテグレーション)と実例紹介_公開用0181013 warai CI(継続的インテグレーション)と実例紹介_公開用
0181013 warai CI(継続的インテグレーション)と実例紹介_公開用
 
第3回ソフトウェアテストセミナー
第3回ソフトウェアテストセミナー第3回ソフトウェアテストセミナー
第3回ソフトウェアテストセミナー
 
異業種でのテスト自動化の実際
異業種でのテスト自動化の実際異業種でのテスト自動化の実際
異業種でのテスト自動化の実際
 
Windowsアプリ開発の実務で使うUnitTest
Windowsアプリ開発の実務で使うUnitTestWindowsアプリ開発の実務で使うUnitTest
Windowsアプリ開発の実務で使うUnitTest
 

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

  • 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 「テストの目的」を追加…欠陥を摘出する 品質を計測、定量表示 契約、法律の証拠提示 品質に確信を持つ システム品質を改善 プロダクトリスク軽減 欠陥修正確認 欠陥原因分析 プロセス改善欠陥計測 特性計測 手段 目的 合致確認 欠陥を摘出する 表示の誤り は無いか 処理手順によって 出力が誤るか 境界値とか0とか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 3つの例からわかること 品質を計測、定量表示 契約、法律の証拠提示 品質に確信を持つ システム品質を改善 プロダクトリスク軽減 欠陥修正確認 欠陥原因分析 プロセス改善欠陥計測 特性計測 手段 目的 合致確認 目的と手段の連鎖を単純 に1対1にせず工夫してい る…それが人間らしさ 繋がりが分かることで腑 に落ちて、何をすればよ いかが分かる…やる気の 源
  • 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 「見る時」のコツ  コンサルは自分が知らないところへ行き短時間で状況把握をするのが仕事  まずは自分の感覚との意識合わせから始める  「テストプロセス改善」で言えば、以下3つのコンセプトを理解する  テストの成果物の連鎖  成果物の構造(各要素がどこにあるのか?)  テストの配置  理解した上でさらに現場の声を聞く  具体的なイメージが共有できることは数字を使って見ることで「短時間」で把握 する !その数字に対して共通理解が持てる単位でないと効果が低い  成果物の数  バグの件数  テストケースの件数  仕様書のページ数  時間  バグ一件あたりの時間  テストケース一件あたりの時間
  • 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 山浦恒央(東海大学)

Editor's Notes

  1. 中途入社でもあるため、周りに早く溶け込みたい、存在価値を認めてもらいたいと思っていた
  2. 使う人に「ありがとう」と言ってもらいたいが、これでは駄目だと思ってもダメだとは言わなかった。そこまで真剣に納得して仕事をしていたとは思えない。
  3. いろいろなことがつながるとやる気が出る
  4. コーワにいたとき上司に言われたこと  ・上手くやるためのコツを知っているか?   →決めたとおりにやることだ     ↓   「決める」つまり計画する   そのとおりにやる、つまり計画がずれるのではなく、自分が計画にずれないように考えて仕事しろと言うこと   例えば、守れない、、のではなく、守っていないのである。ただし、ありえない計画を立てたら守れない。。ということで現場感覚が必要。  ・おまえは鳥の巣のヒナみたいだ。   →例えば、仕様書がなければテストケースは書けないといって仕様書がくるまで口を開けて待っているみたい   もともとは親会社の仕事を請け負っていた。そこには紛いなりにもちゃんとしたルールがあり、仕様書もあるし、親会社の窓口の方が仕切ってくれた。   その後、自分たちの会社の開発請負案件のQAをやることになった。QAと言っても最初はテストしか知らないのでテストしていた。周りからも其れを望まれていた。   そこでは、RADという開発手法を取っていて、DBの設計図とVBで作ったプロトタイプの画面、細かいルールはQ&Aだけで作ってしまう。圧倒的な開発のスピード   感が売りということをやっていたので仕様書を作るつもりがもともとない。   ・VBのオブジェクトプロパティから画面入力箇所とそのレングスをリストするツールを作った。正しくは作らせた。   ・QA全員でER図を使った開発手法の勉強をして、読めるようになり、テストのポイントはER図を見ながら洗い出すようにした。   ・自動テストツール、Winriunnerを購入して使うようになった。
  5. <わからないこと> <わかること> 37671が妥当な数字かを知るために、一人が1日何ケース実施しているかを確認する。 また、現状のテストケース数からを1テストケース辺りに掛かる時間を計算すると   37671(総テストケース数)/33(人日) ≒ 1141(1人が1日に消化するテストケース数) となり、33日の間、全員が約29秒に1テスト項目を休み無く消化していることになる。
  6. <わからないこと> バグが出すぎかどうかが分からない。 テストの仕方、人の数、時間、バグの内容を見ないと分からない。 <わかること> 80件が妥当な数字かを知るために、何人が何日で見つけたバグかを確認する バグが出てからレポートにするまでの時間がどれくらいか? テストが進んでいるかどうかを調べる。 テスト始めて30分、バグレポート書いていて30分だと考えて、6件書いていたら約6時間=何もテスト出来ていない。 バグ出た日にちの分布をみる。