SlideShare una empresa de Scribd logo
1 de 26
Descargar para leer sin conexión
品質本部 システム品質評価部 秋山 浩一
(NPO法人 ASTER)
■WACATE 2008 夏
ソフトウェアテストがおもしろい理由
2008年6月15日
2
目次
1. 自己紹介
2. テストの7つの原理
3. 現在の私のテーマ
3
自己紹介&関連イベント
1985年4月1日: 入社(Smalltalk, UNIX WS, Network)
1996年11月21日: ソフトウェアテスト技法&ツールを作る仕事に従事
2000年5月30日: TEF参加
2000年9月25日~9日: 2WCSQ:田口氏の発表の後に西さんの発表を聞く
2000年10月1日: TCS翻訳プロジェクト始動
~2001年11月26日: 『基本から学ぶソフトウェアテスト』出版
2002年5月8日: LLST翻訳プロジェクト始動
~2003年4月21日: 『ソフトウェアテスト293の鉄則』出版
2003年3月6日: JaSST’03(第一回)
2004年1月27日~28日: JaSST’04「HAYST法」発表
2005年1月5日: 『ソフトウェア・テストPRESS Vol. 2』出版
2005年12月12日: NPO法人 ASTER設立
2006年1月31日: JTCB(JSTQB)FLトライアル試験
2007年7月31日: 『ソフトウェアテストHAYST法入門』出版
2008年5月10日: 『ソフトウェアテスト入門』出版
現在: 『Foundations of Software Testing』共同翻訳中
SQiPテストWG、SEA: SS2008テストWG、SEC
4
おもしろく過ごすポイント:その1
話が来たら
断らない
他力本願とは、自分で何もせずに他人任せにするので
はなく、これも一つのご縁として「自分には無理」と
か思わずに積極的にチャレンジすること。なんとかな
ると思うから声をかけてきたと思おう。
5
温故知新: 世界初のテストシンポジウム
When: 1972年6月21日~22日
Where: ノースカロライナ大学(University of North Carolina)
Who: ヘッツェル(William C. Hetzel)@大学計算センタ
What: 計算機プログラム・テスト法のシンポジウム
(Computer Program Test Methods Symposium)
Why: テストの重要性に焦点を絞り、プログラム・テストに
おける現状技術の断面図を定めること
その結果は、Hetzelによって”PROGRAM TEST METHODS”という書籍にまとめら
れ、1973年に出版され、日本では、鳥居 宏次(奈良先端科学技術大学院大学特任教
授)によって、翻訳され1974年9月1日に『プログラム・テスト法』として出版され
た。
日本初の『ソフトウェアテスト本』!!
6
テストの7つの原理@『プログラム・テスト法』
1. セグメンテーション
2. 可テスト性を持つ設計
3. シミュレーション
4. サンプリング
5. 論理的簡約
6. 標準化
7. 自動化
7
テストの原理1. セグメンテーション
 複雑で大きな問題を数多くの小さな部分的な問題に分割し、それぞれ別
個に取り組むこと。テストを階層的に構造化しようというアイデア。
 Wilkesがサブルーチンを使用(1951)
 Dijkstraによるストラクチャード(構造化)プログラミング(1968)
 Parnasのモジュラー・プログラミング(1971)
 Millsのトップ・ダウン・プログラミングとセグメント(1971)
<現在の方法>
• 複雑の定義: 本質的複雑性、偶発的複雑性(環境に持ち込まれた複雑性)
• フェーズ: テストレベル(コンポーネント、統合、システム、受け入れ)
• 視点: テスト種別(構造視点、仕様視点、顧客視点、エラー視点)
• 技法: 同値分割、マインドマップ
8
設計による複雑さの軽減
システム全体(分割していない)
A
C
D
B
点の数:本質的複雑性、線の数:偶発的複雑性
9
テストの原理2. 可テスト性を持つ設計
 「テストを可能とする設計」というアイデア。
 全体の設計とコーディングの過程を通してテストは計画されなければ
ならないという認識が出てきた。
 テストが可能なように問題の仕様を決めることで、暗黙的に理解され
る仕様を排除し、仕様のあいまいさと誤解をなくす。
 スタブを用意して全ての開発が終わらなくてもテスト可能にする。
<現在の方法>
• テストプロセス: W字モデル(テスト技術を使いバグの総数を減らす)
• テスト駆動: テストファースト、xUnit
• 要件の検証: 要件を決める時に「テスト可能性」をレビュー
• FV表: 機能と検証をセットにしてアセスメント
10
要求
(RFP)
要件定義
仕様
詳細設計
基本設計
テストアクティビ
ティ開始
システムテスト
計画
コンポーネントテスト
計画
統合テスト
計画
コーディング
デバッグ
&変更
デバッグ
&変更
デバッグ
&変更
デバッグ
&変更
受け入れテスト
実施
システムテスト
実施
コンポーネントテスト
実施
統合テスト
実施
レビュー
レビュー
レビュー
レビュー
Wモデルを実現する上で大切なこと
は、まず下流のテストにおいてテス
トの質を高め、「テストを設計するこ
とだけでバグが発見できるという実
感を持つ」こと。その上で、上流工程
のレビューに参画していくことで上
流の質が高まる。
Wモデルありきでレビュー会を開い
ても成功しない。
にしさんのご講演内容より
ソフトウェア開発モデル(Wモデル)
11
テストの原理3. シミュレーション
 ソフトウェアの動作環境をソフトウェアでシミュレート。
 容易に特別な環境を用意できる。
 サブモジュールをテストするために主モジュールをシミュレートする。
⇒ スタブ的シミュレータ
<現在の方法>
• 自動化: 組込み系ソフトウェアの自動化に無くてはならない技術
• カバレッジ: 特殊なエラー条件をシミュレート
• ユースケース: ユーザシミュレーション(統計的テスト技法)
12
統計的テストは状態遷移図を遷移確率にしたがってランダムにパスを
選択し、選択されたパスが正しく処理されることを順次確認していく。
A
B
C
D
E
F70%
30%
100%
60%
40%
100%
10000件テストを自動生成した場合
A→B→F: 7000件
A→C→D→F: 1800件
A→C→E: 1200件
のテストケースがランダムに生成される
※ A~Fは状態を示す
初期
SCAN
To BOX
UI確認COPY
To PC
統計的テストの技法
13
テストの原理4. サンプリング
 品質を評価するときに、全体のプログラムを詳細に解析するのではなく、
サンプルした部分だけを分析して得られた結果に対して外挿を行う方法。
 エラーシーディングによる統計的テスト方法。
<現在の方法>
• 技法: 探針(区間推定)
• データ解析: パフォーマンステスト(区間推定、サンプル数の決め方)
• エラー埋め込み: テスターのモチベーション向上
14
探針(区間推定)の実際
http://hayst.com/qptest.aspx
15
テストの原理5. 論理的簡約
 プログラムを「論理的性質を温存しながら」単純化、簡約化。
⇒ フローチャートや有向グラフへの変換
 モデルを作る
<現在の方法>
• Black Box技法: モデルテスト(テスト観点の列挙、整理、検討: NGT)
状態遷移テスト(統計的テスト)
組合せを数個の因子で検査(直交表、All-pairs)
• White Box技法: モデル検査(SPIN)、形式手法
16
入力
信号因子
M {M1, M2, M3,…}
出力
y
(レスポンス)
ノイズ
誤差因子
z {z1, z2, z3 ・・・}
対
象
システムチャート
read write
内部変数の組合せ(=状態)
信号因子 m {m1, m2, m3 ,…}
17
テストの原理6. 標準化
 コーディング規約。
 インターフェースの標準化によるテストの問題の簡単化。
<現在の方法>
• 技法: 「MISRA-C」(元々は車載用ソフトウェアを対象とした規約)
• 静的解析: コーディング規約の遵守チェック
• テスト資産: インターフェースに対するテストの資産化
18
 テスト工程の改善と上流工程の改善を
対にして進める。
テスト分析
テスト設計
テスト項目作成
テスト実施
玉石混合
となってつ
き進む
テスト
技法導入
支援
ツール開発
テスト
教育
テスト
戦略
ツール
活用
標準化2
改善
改善
改善
標準化3
改善
テスト設計
重視
テスト分析
重視
上流への
取組み人海戦術
計画
実績
設計プロセス安定化
テ
ス
ト
コ
ス
ト
予実差解消
重点指向
本質的には
要件管理強化 設計品質重視
テスト分析
/設計の技術を
活かす
段階を踏んだ改善アプローチ(PDCA: A=標準化)
標準化1
標準化した瞬間から
増補改定が始まる!
19
テストの原理7. 自動化
 自動テスト。
 テストデータの自動生成。
 デシジョンテーブルを利用したテストケースの選択。
 カバレッジ測定の自動化。
<現在の方法>
• テスト分析: 三色ボールペン → Freemind → EXCEL(FV表)
• テスト設計: 組合せ関連テスト設計(実用化)、統計的テスト
• テスト実施: 負荷ツール、ユニットテストの自動化(回帰テスト)
操作の自動化
• テスト管理: TestLink、Bugzilla
20
仕様書のチェック……三色ボールペンを使って
仕様書のチェックは三色ボールペンを用いる。
赤…客観的に見て、最も重要な箇所
青…客観的に見て、まぁ重要な箇所
緑…主観的に見て、自分がおもしろいと感じたり、興味を抱いたりした箇所
テスト設計では、
緑…主観的に見て、おかしいと感じた箇所
1. 仕様書が汚れるのを気にせずにたくさん書き込む
2. 後になって説明があるかもと思わずに違和感を感じたらすぐに書き込む
3. 仕様書に書いていないこと(補集合)に注意しメモを残す
4. (自分用のメモと思って)気楽にやる
5. 眠くない時にやる(朝イチがベスト)
21
マインドマップによる整理
22
FV表
23
おもしろく過ごすポイント:その2
本は読もう
読んだら使おう
ソフトウェアテストは原理原則が長く使える領域の技
術です。それは、「専門技術」ではなく「汎用技術」
だからです。ゆえに様々な先人の知識が応用できます。
色々ためしてみましょう!
24
現在の私のテーマ1
 市場で起こっているソフトウェア問題を分析して対策をとる。
⇒ 一人では無理なのでSEAのソフトウェアシンポジウム2008で
古川先生、にしさん、大西さん、、、etcで検討・実施する予定
日付 タイトル
2008/4/24 後期高齢者医療制度:県内147人分の保険料、プログラムミスで天引きできず /愛媛
2008/4/25 住基ネット:システム故障、発給業務30分中断 プログラムのミス--池田市 / 大阪
2008/4/25 りそな銀などシステム障害 ATMで他行カード使えず
2008/4/26 京都信金:ATM、一時使用不能に システム障害 /京都
2008/4/26 都城市:都市計画税26件、課税額に誤り /宮崎
2008/4/26 富山市:国保納入通知書でミス1087通発送
2008/4/29 札幌市 1億5400万円過大受給 道から重度障害医療補助金で
2008/4/30 ドコモ、N902iL の「ソフトウェア更新」に不具合、配布を一時中断
2008/5/1 リコー、GR DIGITAL IIの不具合を修正
2008/5/2 三菱東京UFJ銀:世界最大のシステム完全統合作業に着手
2008/5/2 志賀原発:トラブル続き
2008/5/5 北京五輪入場券インターネット販売でシステム障害
2008/5/6 パーキングメーター誤作動、料金返還
2008/5/9 シグマ、「DP1」のファイルが消去
2008/5/9 電算システム障害で業務が一時停止/相模原市
2008/5/12 三菱UFJ システム統合初日に障害
2008/5/14 総務省、ソフトバンクモバイルに対して設備管理に関する指導
2008/5/14 竜巻情報:システム障害で伝達できず 名古屋と津気象台
2008/5/15 リコー、GR DIGITAL II シグマ製ストロボを認識しない不具合
2008/5/15 北銀ATMでシステム障害一時ストップ
2008/5/16 「ぴあ」チケット販売システムの不具合で大リストラ
2008/5/16 ヤマハ、最大120件の顧客情報が流出
2008/5/16 quanpでデータ消失
2008/5/18 Zoho Writerの検索機能にバグ--共有ドキュメントを意図しないユーザーに表示
2008/5/19 住友信託銀のシステム障害、原因はパラメータ設定ミス
2008/5/19 富士ゼロックスのDocuWorksでデータ消失を伴う不具合が発生
2008/5/19 住友信託銀:システム障害
2008/5/19 富山市教委:8幼稚園・小学校、給食費を過剰徴収
2008/5/20 福岡銀でシステム障害、ATMなどが1時間半にわたって全面ダウン
2008/5/21 住友信託銀2度目のシステム障害、原因は再びパラメータの設定ミス
2008/5/21 ムーディーズ、CPDOの格付け問題めぐり調査を開始
2008/5/21 後期高齢者「健康診査」受診券 5200人分あて名ミス 札幌市
誰でも出来ることです!
25
現在の私のテーマ2
 品質のコスト換算
 トム・デマルコ(『Controlling Software Projects』より)
 You can't control what you can't measure.
 測定することにより管理下に置く(正しい状態をキープ)ことができる
 多次元の品質を測定する方法(Qの定量化へのチャレンジ)
 区分原理(事実の収集=良い・悪いではなく数値で集める)
 たくさんの品質特性を漏れなくダブり無く分けてそれぞれを定量化
 多変量解析
 まずは仮説を立ててデータを当てはめて検証してみる
 最終的には数値解析(マハラノビスの距離を求めるなどしてパター
ン解析)
 テストで品質を予測できるようになる(目的)
 品質をテストによって守る(攻める)ためには予測ができるようになる
必要がある
 「果因(結果⇒原因)」の異常対応から、「因果関係」を理解し予測・
助言可能な世界へ
26
おもしろく過ごすポイント:その3
おもしろい
テーマを見つけよう
「好きこそ物の上手なれ」。「好き ⇒ できる」の順
番です。ソフトウェアテストの領域はとても広くまた
世の中から求められています。きっと「おもしろ
い!」と思えるテーマが見つかることと思います!

Más contenido relacionado

Destacado

Kpt×ナース(公開版)
Kpt×ナース(公開版)Kpt×ナース(公開版)
Kpt×ナース(公開版)
Noriyuki Nemoto
 
お絵描きコミュニケーション
お絵描きコミュニケーションお絵描きコミュニケーション
お絵描きコミュニケーション
Sayaka Nakano
 
WACATE 2010夏 ゆもつよ講演スライド
WACATE 2010夏 ゆもつよ講演スライドWACATE 2010夏 ゆもつよ講演スライド
WACATE 2010夏 ゆもつよ講演スライド
Tsuyoshi Yumoto
 

Destacado (12)

wacate2012w
wacate2012wwacate2012w
wacate2012w
 
正統なソフトウェア品質エンジニアであるためにSQiP研究会に入るべき7つの理由
正統なソフトウェア品質エンジニアであるためにSQiP研究会に入るべき7つの理由正統なソフトウェア品質エンジニアであるためにSQiP研究会に入るべき7つの理由
正統なソフトウェア品質エンジニアであるためにSQiP研究会に入るべき7つの理由
 
Jasst15 webjasst
Jasst15 webjasstJasst15 webjasst
Jasst15 webjasst
 
Kpt×ナース(公開版)
Kpt×ナース(公開版)Kpt×ナース(公開版)
Kpt×ナース(公開版)
 
異業種でのテスト自動化の実際
異業種でのテスト自動化の実際異業種でのテスト自動化の実際
異業種でのテスト自動化の実際
 
お絵描きコミュニケーション
お絵描きコミュニケーションお絵描きコミュニケーション
お絵描きコミュニケーション
 
一段深い心で人と関わろう
一段深い心で人と関わろう一段深い心で人と関わろう
一段深い心で人と関わろう
 
ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか(150918_jasst)
ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか(150918_jasst)ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか(150918_jasst)
ユーザビリティとユーザーエクスペリエンス、いかに向き合っていくか(150918_jasst)
 
Jasst14tokyo 公開資料_バグレポートの問題事例の調査と改善のためのアンチパターン集の作成
Jasst14tokyo 公開資料_バグレポートの問題事例の調査と改善のためのアンチパターン集の作成Jasst14tokyo 公開資料_バグレポートの問題事例の調査と改善のためのアンチパターン集の作成
Jasst14tokyo 公開資料_バグレポートの問題事例の調査と改善のためのアンチパターン集の作成
 
UX/ユーザビリティのためのテスト - ユーザーテスト見学会 at JaSST
UX/ユーザビリティのためのテスト - ユーザーテスト見学会 at JaSSTUX/ユーザビリティのためのテスト - ユーザーテスト見学会 at JaSST
UX/ユーザビリティのためのテスト - ユーザーテスト見学会 at JaSST
 
WACATE 2010夏 ゆもつよ講演スライド
WACATE 2010夏 ゆもつよ講演スライドWACATE 2010夏 ゆもつよ講演スライド
WACATE 2010夏 ゆもつよ講演スライド
 
テスト計画セッション
テスト計画セッションテスト計画セッション
テスト計画セッション
 

Más de Kouichi Akiyama

20150424 jasst新潟基調講演
20150424 jasst新潟基調講演20150424 jasst新潟基調講演
20150424 jasst新潟基調講演
Kouichi Akiyama
 

Más de Kouichi Akiyama (16)

業務状態遷移テストを語る夕べ
業務状態遷移テストを語る夕べ業務状態遷移テストを語る夕べ
業務状態遷移テストを語る夕べ
 
Ralph's Chart連結
Ralph's Chart連結Ralph's Chart連結
Ralph's Chart連結
 
20180421 Issueの書き方と伝えかた勉強会
20180421 Issueの書き方と伝えかた勉強会20180421 Issueの書き方と伝えかた勉強会
20180421 Issueの書き方と伝えかた勉強会
 
Oa mat
Oa matOa mat
Oa mat
 
20170203 test analysisdesign
20170203 test analysisdesign20170203 test analysisdesign
20170203 test analysisdesign
 
20160619 wacate 解答
20160619 wacate   解答20160619 wacate   解答
20160619 wacate 解答
 
20160619 wacate
20160619 wacate20160619 wacate
20160619 wacate
 
20160607 SS2016 FP
20160607 SS2016 FP20160607 SS2016 FP
20160607 SS2016 FP
 
SS2016 Workshop
SS2016 WorkshopSS2016 Workshop
SS2016 Workshop
 
よいアーキテクチャ、よいライブラリ、よいテスター
よいアーキテクチャ、よいライブラリ、よいテスターよいアーキテクチャ、よいライブラリ、よいテスター
よいアーキテクチャ、よいライブラリ、よいテスター
 
20150424 jasst新潟基調講演
20150424 jasst新潟基調講演20150424 jasst新潟基調講演
20150424 jasst新潟基調講演
 
20140610 秋山-ss2014
20140610 秋山-ss201420140610 秋山-ss2014
20140610 秋山-ss2014
 
Answer
AnswerAnswer
Answer
 
20081024 ja sst-sapporo
20081024 ja sst-sapporo20081024 ja sst-sapporo
20081024 ja sst-sapporo
 
N-Switchカバレッジテストの問題点と解決策
N-Switchカバレッジテストの問題点と解決策N-Switchカバレッジテストの問題点と解決策
N-Switchカバレッジテストの問題点と解決策
 
とてか2
とてか2とてか2
とてか2
 

20080615 wacate

Notas del editor

  1. <number>
  2. <number>