SlideShare a Scribd company logo
1 of 49
Download to read offline
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 20101
ソフトウェアテスト・ヒストリーの学び方
辰巳 敬三
2010年12月19日
~ タメにならなければ学ばない。
面白くなければ学ぶ資格がない。
WACATE 2010冬
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 20102
自己紹介 : マイ ヒストリー1975
1990
2000
1980
1985
2010
1995
2005
1976-富士通入社、ソフトウェア事業部検査部
1990-ソフトウェア品質管理ガイドブック(共著)
2007-ソフトウェア品質知識体系ガイド(SQuBOK)(共著)
2009-ソフトウェアテスト・ヒストリー(テストPress Vol.8)
2009-続ソフトウェアテスト・ヒストリー日本編(テストPress Vol.9)
1976-メインフレームOSの製品検査 1990-UNIX/PCソフトウェア製品検査
1999-製品適用サービス
2006-知財/特許
2009-高度情報通信人材育成支援センター
1989-富士通におけるソフトウェア品質保証の実際(共著)
1990-ソフトウェア品質管理事例集(共著)
1987-Conceptual Support for Test Case Design
1987-Test Case Design Support System
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 20103
内容
 ソフトウェアテスト前史
 コンピュータとソフトウェア技術の歴史
 テストの考え方の進化
 テスト技法の歴史
 日本の品質・テスト技術の歴史
 世界のテスト技術の研究最前線
 まとめ
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 20104
ソフトウェアテスト前史
 コンピュータの原型
(1/2)
 Charles Babbage(英国)の「解析機関」
• 1837年に設計を開始 (完成には至らず)
• 入力(プログラムとデータ)はパンチカード
• 出力はプリンター、曲線プロッター、ベル
 最初のプログラマー
 Ada Byron, Lady Lovelace
• 解析機関のプログラムを作成(1843年)
– Babbageの講演記録の翻訳の注釈の中に記述
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 20105
ソフトウェアテスト前史
 最初のテスターは ?
(2/2)
Ada Loverace女史はプログラマの第1号として、19世紀、
Charles Babbageの壮大にして未完成に終わったコン
ピュータのプログラム作成にたずさわったが、「あと1週間
あれば大丈夫です、バベッジ博士。それですべて終わり
ます」と何度も言っていたにちがいない。幸いにもハード
ウェアが完成しなかったため、Loverace女史は机上デ
バッグに巻き込まれずにすんだ。
(ボーリス・バイザー,「ソフトウェアテスト技法」,1994,日経BP)
 Boris Beizerによると・・・
• 『テストやデバッグの最初の議論はAdaのメモに遡る』
• Software System Testing and Quality Assurance
[Beizer,1984] では
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 20106
内容
 ソフトウェアテスト前史
コンピュータとソフトウェア技術の歴史
 テストの考え方の進化
 テスト技法の歴史
 日本の品質・テスト技術の歴史
 世界のテスト技術の研究最前線
 まとめ
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 20107
コンピュータとソフトウェア技術の歴史
 別紙の歴史年表参照
2010.11.18 辰巳
▲ ▲ ▲ ▲
EDSAC(最初のノイマン型コンピュータ) IBM System/360 IBM System/370 Cray-1(スパコン)
▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲
UNIVAC1(世界初の商用コンピュータ) DEC PDP-1 DEC PDP-8 Apple PC IBM PC ▲ Apple Macintosh iPhone iPad
▲ ▲ ▲ Sun-1 ▲ ▲
IBM 701 IBM 704 Intel 4004MPU Sun SPARC Intel Pentium Pro
(科学演算用) ● ●
(Apple社設立) (Sun Microsystems社設立)
▲ ▲ ▲ ▲ ▲ ▲ ▲
OS/360 UNIX CP/M MS-DOS UNIX System V Linux Windows NT
(4004MPU用OS) Netware ▲ ▲ ▲
▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ Windows 3.1 ▲ J2EE .NET ▲
SpeedCode FORTRAN FORTRAN COBOL LISP PL/I C言語 ▲ C++ ▲ Java ▲ Ajax
開発開始 ▲ ALGOL Smalltalk-72 Smalltalk-80 Eiffel ▲ ▲Internet Explorer Ruby on Rails
FLOW-MATIC ▲ Netscape ▲ ▲
● ● HTML/HTTP/WWW XML ● SOAP ●
(Microsoft社設立) (Free Software Foundation) (Apache Software Foundation) (Eclipse Foundation)
▲SAGE(防空管制システム) ▲ ● ● ▲ ▲
▲SABRE(航空座席予約システム) CompuServe America Online Amazon.com Amazon Web Services Amazon EC2
▲マーキュリー計画 (商用オンラインサービス) ● ● Google Docs & Spreadsheets
▲ジェミニ計画 Yahoo! Google ☆
▲アポロ計画発表 ▲アポロ11号 有人月面着陸 ● ● クラウド・コンピューティング
eBay Salesforce.com
▲ ▲ ▲ ▲ ▲ ▲ ▲
ETL Mark I<電気試験所> FUJIC<富士写真フイルム> NEAC2200<日本電気> DIPS-1<電電公社> PC-8001 PC-9001 UNIXサーバ
(日本初のディジタル式自動計算機) (日本初の電子計算機)[真空管式] FACOM230<富士通> ▲ ▲ <日本電気> <日本電気> <日立,日本電気,富士通,三菱,沖>
[リレー式] ▲ HITAC8000<日立> 国産メーカ・3グループ化 計算機完成 ▲ ▲
▲ ETL MarkⅢ<電気試験所>[トランジスタ式] Mシリーズ<富士通・日立> FM-8<富士通> PCサーバ
FACOM100 ▲MUSASINO-1<電電公社>(日本初のパラメトロン計算機) ACOSシリーズ<日本電気・東芝> <三菱,富士通,日立> ▲
[リレー式] ▲HIPAC MK-1[パラメトロン式] COSMOシリーズ<三菱・沖電気> ▲ Express5800<日本電気>
▲NEAC-1101[パラメトロン式] 日本語ワープロJW-1<東芝> (WinNT3.5搭載PCサーバ)
▲ ▲ ▲
NEAC-1101用ローダなど NEAC2200用の最初のOS DIPS-103-10OS
HIPAC-101用記号入力ルーチン HITAC-5020用モニタ (タイムシェアリングシステム用OS)
▲ ▲ ▲
自動プログラム(FORTRAN)など(HIPAC 103用) FACOM 230-20/30用モニタ MCPII OSIV<富士通>、OS<日立>
▲ (マルチプログラミング処理) ACOS<日本電気・東芝>
FORTRAN/アセンブラ/IOCS/SORT(FACOM 222A) UTS<三菱電機>
▲ ▲ ▲ ▲ ▲ ▲ ▲
日本最初の商用コンピュータ稼働 国鉄座席予約システム 国鉄オンライン座席予約システムMARS101 JUNET PC-VAN Yahoo! JAPAN アマゾン・ジャパン
UNIVAC120(真空管式) ▲ MARS1 JAL国内線座席予約システム ▲ ▲ ▲
東京証券取引所、野村證券 気象庁予報部 東京オリンピック・リアルタイム記録管理システム NIFTY 楽天市場 iモード
▲ ▲ ▲ ▲
三和銀行 三井銀行オンラインバンキング 全銀システム ▲ ▲ ジャパンネット銀行
(初の銀行への導入) 第一次金融オンラインシステム 第二次金融オンラインシステム 第三次金融オンラインシステム (日本初のネット銀行)
▲ ▲ ▲ ▲1st NCSE(ICSE)
NATO Software Engineering Conference Symposium on Computer Software Reliability
▲ ▲ ▲ ▲ ▲ ▲
構造化定理 段階的詳細化 構造化設計 CASE Booch法 UML UML 2.0
▲ ▲ ▲ (Computer aided ▲ ▲ ▲
構造化プログラミング トップダウンプログラミング▲ データフロー図 software engineering) オブジェクトモデル化技法 デザインパターン アスペクト指向プログラミング
▲ 抽象データ型 ▲ ▲ ▲
▲ 抽象モジュール ▲ オブジェクト指向ソフトウェア工学 Software Architecture テスト駆動開発(TDD)
形式手法 ERモデル ▲
▲ ▲ 契約による設計 ▲
ワーニエ法 ジャクソン法 アジャイル宣言(Agile Manifesto)
▲ ▲ ▲ ▲ ▲
Waterfall Model(Royce) DoD-2167 DoD-2167A MIL-498 XP
▲ ▲ ▲
Spiral Model(Boehm) ISO/IEC 12207 ISO/IEC 15288
▲ ▲ (ソフトウェアライフサイクルプロセス) ▲ (システムライフサイクルプロセス)
ISO 9000 CMM CMMI
▲ ▲ ▲ △ ▲ ▲ ▲
プログラム品質特性(Ruben) 品質特性(Boehm) 品質モデル(McCall) ▲ ISO9126標準化開始 ISO/IEC 9126 ISO/IEC 14598 ISO/IEC 15939
1965 19701950 1955 1960 20102000 20051975 1980 1985 1990 1995
ハードウェア
ソフトウェア
開発技法/開発方法論
マネジメント/プロセス
コンピュータの歴史とソフトウェアテスト・品質技術の歴史
コンピュータ時代の幕開け
「計算機」パラダイムの時代
「日の丸コンピュータ」
の開発促進期
分散処理ネットワーク
の普及期
IBMを中心とする
市場開拓期
ミニコンと汎用機ソフト
市場の成長期
パソコン, ワークステーション
の誕生・普及期
オープンシステムへの
転換期
「情報処理」パラダイムの時代
インターネットの
急成長期
社会インフラとしての
IT浸透期
「ネットワーク」パラダイムの時代
ソフトウェア
ハードウェア
世界
(米国)
日本
稼働システム
稼働システム
ITパラダイム
の変遷 (*1)
コ
ン
ピ
ュ
ー
タ
の
歴
史
ソ
フ
ト
ウ
ェ
ア
技
術
の
歴
史
品質モデル、品質測定
会議・シンポジウム
品質特性・品質モデル
クラウド・コンピューティン
グの時代?
ソフトウェア・マネジメントの観点(*2)
ソフトウェア・エンジニアリングの進化(*3)
品質の時代機能の時代 スケジュールの時代 コストの時代
<反> 並行プロセス 対 順次プロセス<反> ソフトウェア工芸(Crafting) <合と反> 形式化とウォータフォールプロセス <合> 生産性と拡張性<正> ハードウェア工学的なソフトウェア工学 <反、部分的に合> 俊敏性と価値
世界
(米国)
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 20108
[出典] Basili, Musa, “The Future Engineering of Software: A Management Perspective,“ 1991
 1960年代: 機能の時代
 ITが社会に入り始めた
 社会的ニーズに応えられる機能の開発が主要課題
 1970年代: スケジュールの時代
 ソフトウェア危機(NATO会議,1968年)
 計画期間内にソフトウェア開発を完了させることが主要課題
 工程を明確化したライフサイクルモデルが紹介され始めた
ex. Royce waterfall model、品質モデル
1950 1980 19901960 1970 2000 2010
スケジュールの時代 コストの時代 品質の時代機能の時代
ソフトウェア・マネジメントの観点 (1/2)
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 20109
 1980年代: コストの時代
 ハードウェアコストの継続的低減、パソコンの出現
 ソフトウェアの価格の高さに目が向き始め、コスト/生産性が
主要課題
 各種のコストモデルが提案され、適用され始めた
ex. Function Point、Putnamモデル、COCOMO
 1990年代: 品質の時代
 ソフトウェアに対する社会の依存度の増大
 マスマーケットでの利用者が増え、ソフトウェアの故障や使
いにくさが深刻な事態を招くことが広く認識されはじめる
1950 1980 19901960 1970 2000 2010
スケジュールの時代 コストの時代 品質の時代機能の時代
ソフトウェア・マネジメントの観点 (2/2)
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201010
ソフトウェア工学の進化
 Boehmのヘーゲル的進化ビュー
 ソフトウェア工学の歴史を弁証法で捉える
テーゼ(正) 対 アンチテーゼ(反) → ジンテーゼ(合)
自律;
バイオ・
コンピュー
ティング
1990年代 2010年代2000年代1970年代 1980年代1960年代1950年代
COTS
工芸品
としての
ソフトウェア
テーゼ
(正)
ジン
テーゼ
(合)
アンチ
テーゼ
(反)
形式化;
ウォータ
フォール
生産性;
再利用;
オブジェクト;
ピープルウェア
計画駆動の
ソフトウェア
成熟度
モデル
アジャイル
メソッド
ハードウェア
のような
ソフトウェア
の扱い
リスクベース・
アジャイルと
計画駆動の
ハイブリッド;
モデル駆動開発
ソフトウェア
工学と
システム工学
の統合
バリューベース法;
コラボレーション;
グローバル開発;
エンタープライズ・
アーキテクチャ
ソフトウェアと
ハードウェアの違い,
技術者の不足
多くの欠陥
スケーラビリティ,
リスクマネジメント
プロトタイピング
Time to Market,
迅速な変化
スケーラビリティ
ドメイン工学
リスクマネジメント
準拠
プロセス・オーバヘッド
ソフトウェアの
付加価値
ソフトウェア-
システム工学
グローバルな
Systems
of
Systems
[出典] B. Boehm, A View of 20th and 21st Century Software Engineering, 2006のプレゼンテーションスライドから引用
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201011
内容
 ソフトウェアテスト前史
 ソフトウェア技術の発展過程
テストの考え方の進化
 テスト技法の歴史
 日本の品質・テスト技術の歴史
 世界のテスト技術の研究最前線
 まとめ
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201012
テストの考え方の進化
 D. Gelperin and W. Hetzel,
“The Growth of Software Testing,” 1988
• テストの歴史的成長過程を5段階に区分
• 区切りは各段階開始のマイルストーンとなった文献
 1. デバッグ指向の時代 ( ~1956年)
 2. 論証指向の時代 (1957年~1978年)
 3. 破壊指向の時代 (1979年~1982年)
 4. 評価指向の時代 (1983年~1987年)
 5. 予防指向の時代 (1988年~ )
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201013
1. デバッグ指向の時代 (~1956年)
 デバッグとテストが区別されていなかった時代
 ソフトウェアはハードウェアの信頼性の一部
 『難しいのは間違いを検出することではなく、
異常原因の究明である』
(Gill <EDSAC開発メンバー>, 1951)
 プログラムを書いたらチェックする(check it out)程度の認識
checkout, debugging, testingの定義はまだ不明確
 McCracken, "Digital Computer Programming,“
1957 (最も初期のプログラミング教科書)
• ”Program Checkout”の章でデバッグやテストを説明
評価
指向
論証指向
破壊
指向デバッグ指向 予防指向
1950 1980 19901960 1970 2000 2010
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201014
2. 論証指向の時代 (1957年~1978年)
 テストはプログラムが仕様を満足していることを示す
ためのもの
 Baker, "Digital Computer Programming"の書評, 1957
• 『デバッグとテストという二つのフェーズを区別すべき』
– デバッグ : コーダの目論見どおりにプログラムが動くことを確認
– テスト : 解決しようとした問題が解決されていることを確認
 大規模プロジェクト(1950年後半~1960年代)
• 軍や航空・宇宙関係のシステム開発
– SAGE(防空管制システム), SABRE(航空座席予約システム),
宇宙(マーキュリー計画,ジェミニ計画,アポロ計画)
• コンピュータメーカでの基本ソフトウェア開発
– IBM OS/360 (参考) Brooksの「人月の神話」
 ソフトウェア工学の歴史の幕開け(1968, 1969)
• NATO Software Engineering 会議
「テストではバグの存在は示せるがバグがないことは示せない」(Dijkstra,1969)
(1/2)
論証指向デバッグ指向
評価
指向
破壊
指向
予防指向
1950 1980 19901960 1970 2000 2010
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201015
2. 論証指向の時代 (1957年~1978年)
 テストのコミュニティの開始
• Debugging Techniques in Large Systems シンポジウム(1970年)
• 最初のテストのシンポジウムの開催(1972年6月)
The Computer Program Test Methods Symposium
• 最初のテストの書籍
Hetzel(Ed.), "Program Test Methods," 1973
 テスト技術の研究の拡大
• 最初のテストケース設計の理論付け
Goodenough, Gerhart, "Toward a Theory of Test Data Selection," 1975
• テスト・ワークショップの開始 (現在のISSTAの源流)
Software Testing and Test Documentation Workshop, 1978
<参考>1973年, Wulfの品質属性の定義, Boehmらの品質モデル
(2/2)
論証指向デバッグ指向
評価
指向
破壊
指向
予防指向
1950 1980 19901960 1970 2000 2010
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201016
3. 破壊指向の時代 (1979年~1982年)
 テストとは、エラーをみつけるつもりでプログラムを実
行する過程(テストの成功とはエラーを見つけること)
 Myers, "The Art of Software Testing," 1979
テストでは、経済学的・心理学的な観点が大切
• 投資対効果の最大化を目的とすべき
(限られたテストで検出できるエラー数を最大に)
• 『完全なテストは不可能であるから、いかなるプログ
ラムのテストも不完全にならざるを得ない。だから、
作戦としては、この不完全さをできる限り減らすこと
であることが明らかである。』
⇒ これが、きちんとテスト設計することの意味であり、
テスト設計技法の目的
1950 1980 19901960 1970 2000 2010
論証指向デバッグ指向
評価
指向
破壊
指向
予防指向
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201017
4. 評価指向の時代 (1983年~1987年)
 ソフトウェアのライフサイクルを通じた評価活動の中
にテストが位置付けられた時代
 FIPS 101 (米国標準局(NBS)規格), 1983
"Guideline for Lifecycle Validation, Verification, and
Testing of Computer Software"
• ライフサイクルの中で、解析、レビュー、テストの活動
を統合する方法論、各フェーズのVV&T技法
⇒ ソフトウェアの品質は単一の技法で保証できる
ものではない。個々のプロジェクトで吟味して
選んだ技法群を使うことにより品質のよい
ソフトウェアの開発が可能になる
1950 1980 19901960 1970 2000 2010
論証指向デバッグ指向
評価
指向
破壊
指向
予防指向
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201018
5. 予防指向の時代 (1988年~)
 ソフトウェアライフサイクルと並行して進められる予防
指向のテストプロセス
 テスト方法論STEP (Systematic Test and Evaluation Process)
Hetzel, "The Complete Guide to Software Testing 2nd Ed.," 1988
• ソフトウェアライフサイクルと並行してテスト活動を実施
• テスト計画の立案、テストの設計、テストのメトリクスの収集方法、
リスク分析法などから構成
現在の“Wモデル”につながる考え方
<補足> Hetzelは既に1973年の"Program Test Methods"で
「テストは設計とコーディングの全プロセスにおいて
計画されなければならない」
と書いている。
1950 1980 19901960 1970 2000 2010
論証指向デバッグ指向
評価
指向
破壊
指向
予防指向
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201019
Beizerのテスト道
 テスト担当者の精神面による区分
• フェーズ0 : テストとデバグには何の差もない。デバグ以外
にはテストには特別な目的はない。
• フェーズ1 : テストの目的は、ソフトウェアが動くことを示す
ことである。
• フェーズ2 : テストの目的は、ソフトウェアが動かないという
ことを示すことにある。
• フェーズ3 : テストの目的は、何かを証明することではなく、
プログラムが動かないことによって発生する
危険性をある許容範囲にまで減らすことである。
• フェーズ4 : テストは行動ではない。テストをしないで品質の
高いソフトウェアを作るための精神的な訓練である。
[出典] B. Beizer, "Software Testing Techniques,2nd Ed.," 1990
(電通大・西先生の命名)
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201020
内容
 ソフトウェアテスト前史
 ソフトウェア技術の発展過程
 テストの考え方の進化
テスト技法の歴史
 日本の品質・テスト技術の歴史
 世界のテスト技術の研究最前線
 まとめ
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201021
テスト技法の歴史 : 胎動期
テスト技法の多くが確立する1970年以前の状況
 1960年代前半はテストに関する論文は少ない
 テスト文献数(累積)
1969年-57件、1973年-200件、1977年-400件以上
 内容的にもテストの手順やテストの自動化に関するもので、
テスト技法に関する内容は見受けられない。
 1960年代後半
 IBMのOS/360の開発プロジェクト (Brooksの「人月の神話」)
• 1966年リリース、1967年に本格的マルチタスクOSのMVTをリリース
かなりのテスト作業が行われ、テストプロセス、テスト技法、
テストマネジメントに関するノウハウが蓄積された筈
(1/2)
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201022
テスト技法の歴史 : 胎動期
 IBM社のElmendorfのテスト制御プロセス
 Elmendorf, "Controlling the functional testing
of an operating system," 1969
• Elmendorfは1965年からOS/360の
ソフトウェアテストを担当
• この論文から、きちんとしたテストプロセス
が実践されていたことが伺える。
• このプロセスによりテストを自由放任から
統率へ、芸術から科学的なアプローチに
変えていくことができると言っている。
予防指向プロセス, Wモデルの先駆け
(2/2)
設計
仕様化
実装
テスト
プログラム目標
テスト目標
プログラム仕様書
調査
識別
評価
レビュー
監視
機能バリエーション
テスト計画
テスト仕様書
テスト資材
プログラム
テスト結果
【開発工程】 【テストプロセス】
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201023
同値分割、限界値分析
 入力データを「同じ出力結果が得られるグループ」に
分割して各グループ(同値クラス)の代表値、および
同値クラスの端に着目してテストケースを作成
<歴史>
 同値分割、限界値分析という名称でテスト技法として確立
したのは、1979年のIBMのMyersの"ソフトウェア・テストの
技法"
 Myers以前からテストデータ選定の考え方はあった
• 1967年のElmendorfの論文には、ソフトウェアの機能のバリエー
ションを変数とその状態で定義し、状態として正常値、最大値、最
小値、それらを越える値を含める考え方が書かれている
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201024
原因結果グラフ
 外部仕様を、原因(入力条件)と結果(出力や状態)の
論理関係、および原因間の関係(制約条件)を示すグ
ラフで表現し、それにもとづいてテストケースを作成
<歴史>
 Myersの"ソフトウェア・テストの技法"(1979年)で紹介され
たことにより広く知られるようになった
 技法を考案したのはElmendorf(1970年頃)
• スイッチング回路の故障点の発見のための手法を元に、制約条件
の考え方を追加してソフトウェアの機能を記述できるようにした
• 原因結果グラフからテストケースを作成するツールTELDAP(TEst
Library Design Automation Program)を開発。ハードウェアの論
理回路のテストパターン作成ツールを元に作成
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201025
デシジョンテーブルテスト
 プログラムの仕様を条件部とアクション部からなるデ
シジョンテーブルに整理してテストケースを作成
<歴史>
 1958年:システム設計の道具としてGeneral Electric(GE)
社やSutherland社でデシジョンテーブルを考案
 1960年:GE社はデシジョンテーブルから直接ソースコード
を生成するプログラム言語TABSOLを開発
 1965年:RCA社のScheffがテスト設計にデシジョンテーブ
ルを用いた論文を発表
• 条件部にテストカテゴリとパラメタを、アクション部に結果とテストア
クションを整理
• 縦の列(ルール)をテストケースとして自動テストツールへ入力
 1975年:Goodenough&Gerhartはテスト理論の論文でプロ
グラム構造に基づくテストをデシジョンテーブルで設計する
方法(Condition table method <条件表法>)を提案
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201026
直交表/Pairwiseテスト
 任意の二つの因子間で組み合わせが網羅されるよ
うにテストケースを作成
(直交表やpair生成ツールを使用)
<歴史>
 実験計画法は1920年代に英国のFisherが農業実験の合
理化のために開発した手法。これをもとに田口玄一博士が
品質工学(タグチメソッド)を開発
 テストへの直交表の適用は、1983年に富士通で開始、同
時期に米国でもMandlがAdaコンパイラのテストに適用
 米国で活用されるようになったのは、AT&T社(Bell Labs,
Bellcore)の成果が発表された1990年代半ばから。
• 1992年に直交表によるテスト設計ツールOATSを開発
• 1994年に制約条件を考慮した組み合わせ表ツールCATSを開発
• 1994年に逐次的な手法によるPairwise生成ツールAETG を商用化
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201027
組み合わせテスト
(1957: Decision table)
~1967: Equivalence partitioning,
Boundary value analysis
1970: Cause Effect Graph
[Elmendorf]
(1983~)1985: Orthogonal Latin Squares
[R. Mandl]
(1983~)1984: 直交表/組合せ表
[佐藤,下川(富士通)]
1987: ATAF
[辰巳(富士通)]
(198x~)1992: OATS
[Brownlie, Prowse, Phadke]
(1990~)1994: CATS
[Sherwood]
(1992~)1994: AETG
[Cohen, et. al]
1998: IPO
[Lei, Tai]
2000: Covering arrays
[Williams]
2000: CTE XL
[Daimler Chrystler]
(2000~)2004: PICT
[Microsoft]
2007: FireEye 2009:ACTS
(IPOG)[Lei, Kuhn]
AT&T社, Bellcore社
で開発
1988: Category-partition method
[Ostrand, Balcer]
1993: Classification-tree method
[Grochtmann, Grimm]
(1976: テスト要因分析)
[富士通]
(199x~)2004: 直交表(HAYST法)
[富士ゼロックス]
1980 1990 2000 20101950 1960 1970 ‘85 ‘95 ‘05
組み合わせ手法
入力条件分析手法
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201028
制御フローテスト (1/2)
 プログラムの制御の流れをフローグラフで表現し,基
準に従ってグラフを網羅するテストケースを作成
<歴史>
 グラフ理論の適用
• 1960年にソフトウェア開発(コンパイラ)へグラフ理論を適用(Karp)
• 1963年にテスト設計へ適用。フローチャートをグラフ化し、ブール
行列に変換後、分岐点に着目してテストを設計(MillerとMaloney)
• 1976年にMaCabeがグラフ理論を元にプログラムの複雑度を表す
サイクロマチック複雑度、基礎パステスト法を提案
 カバレッジの計測
• 1960年代前半には意図したルートが通過したかどうかの計測開始
• IBM社のPoughkeepsie地区でコードカバレッジ・ツールを開発
– [Warner,1964] : COBOLとFORTRANソースプログラムを対象にした
ハードウェアの命令語モニタについてのいちばん最初の解説書
– [Hirsh,1967] : ソフトウェアのステートメントカバレージとブランチカバ
レージアナライザについての初期の論文
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201029
制御フローテスト (2/2)
<歴史> (つづき)
 動的解析システム(カバレッジ計測ツール)
• 1970年代初めに各社で本格的な動的解析システムを開発
– TRW社のPACE(Product Assurance Confidence Evaluator) [Brown,1972]
– McDonnell Douglas社のPET(Program Evaluater and Tester) [Stucki,1972]
– General Research社のRXVP [Miller,1974] など
 カバレッジ基準
• TER(Test Effectiveness Ratio:テスト有効度) [Brown,1972]
– TERとして命令網羅、分岐網羅を定義
• C0, C1, C2, ・・・ [Miller,1975]
– 1975年時点では、
C0 : プログラマの直感、C1 : 命令網羅、C2 : 判定条件網羅、・・・
– 1977年頃に、
C0 : 命令網羅、C1 : 判定条件網羅、C1p : 判定条件/条件網羅、
C2 : C1基準+ループ網羅、・・・
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201030
データフローテスト
 プログラムの制御フローを元に、変数の定義、変数
の使用の関係に着目してパスを選択することにより
テストケースを作成
<歴史>
 1960年後半、コンパイラ分野でプログラム最適化技術とし
てデータフロー解析の研究が進められた(IBM社のAllenら)
 1974年の米国コロラド大学のOsterweilとFosdickのデータ
フローテストの論文がテスト技術としては最初と思われる
 その後、データフローテスト基準の提案や制御フローテスト
も含めた構造テストの基準間の包含関係の研究が進めら
れている(RappsとWeyuker,1982 など)
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201031
状態遷移テスト
 プログラムの仕様を状態遷移図や状態遷移表を使っ
て整理し、それにもとづいてテストケースを作成
<歴史>
 状態遷移図や状態遷移表は、元来は有限オートマトン(有
限状態機械:FSM)の仕様を記述するためのもの
• デジタル回路の設計ソフトウェア、コンパイラのための字句解析(言
語理論)、通信プロトコルのような有限状態をとるシステムのチェッ
クをするソフトウェアなどの分野に用いられている計算モデル
 1956年のMooreの論文"Gedanken-experiments on
sequential machines"(順序機械の思考実験)がFSMベー
スのテスト生成の研究の先駆け
 1978年にChowが状態遷移テストにおけるカバレッジ基準
"n-switch cover"を提案
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201032
内容
 ソフトウェアテスト前史
 ソフトウェア技術の発展過程
 テストの考え方の進化
 テスト技法の歴史
日本の品質・テスト技術の歴史
 世界のテスト技術の研究最前線
 まとめ
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201033
日本の品質・テスト技術の歴史 (1/3)
 1958年 テストに関する初期の文献
 藤原, "大型電子計算機 IBM 704をプログラムテストして," 1958
• 気象庁の数値予報のプログラムのテストをしたときの状況の報告
 1964年 プログラムの検査に関する議論
 情報処理学会, 「情報処理」ソフトウェア特集, 1964
• 仕様を決める段階からその検査をやる組織というものが加わって、最終製品につい
てつくった側とは独立に、いろいろなテスト・プログラムをかけて検査するというよう
なことをやっていかなければいけないんじゃないかと思います。
• 検査部門というのは工程の状況を把握するための情報をとる感覚器官。それを工
程に正しくフィードバックして初めて工程をよい状態に維持できるし、ときには改善も
可能になるんだというような解釈が、近代的品質管理における検査の職能である。
 1969年 日立製作所でソフトウェア工場を開設
 工場制度におけるソフトウェアの検査機能を確立
 1971年、富士通も出荷前のソフトウェア製品検査を制度化
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201034
日本の品質・テスト技術の歴史 (2/3)
 1972年 ソフトウェアの検査の考え方
 菅野, “ソフトウェア検査の考え方,” 1972
• われわれは、過去数年間ソフトウェア検査の確立に努力
してきた。当初ソフトウェアにおいては、検査という語は
存在していなかった。単に言葉がなかったばかりではな
く、検査という行為もそれまではなかったといってよかろ
う。このような周辺事情のなかで、ソフトウェアは製品で
あるという認識のもとに、近代的ソフトウェア・エンジニア
リング確立の一つとして、現在まで検査技術の設定に努
力し、一応軌道に乗った様相で、ソフトウェア検査業務を
遂行している現状である。
 1974年 検査技術の開発
 坂田, "ソフトウェアの生産管理における予測技
法の定式化," 電子通信学会, 1974
• 静的な予測および故障率推移モデル
成長曲線やゴンペルツ曲線などを使った品質予測手法
• 動的な予測:先取評価手法
先取り評価手法(QP:Quaity Prove)(探針と呼ばれている)
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201035
日本の品質・テスト技術の歴史 (3/3)
 1980年~ テスト技法の研究開発
 1980年 AGENT(Automated GENeration system for Test cases)、日立
• 原因結果グラフからテストケースを生成するツールAGENTの開発
 1984年 AGENT機能図式、日立
• 機能仕様の動的部分を状態遷移で、静的部分をデシジョンテーブルや原因結果グ
ラフで表現し、これらを組み合わせてテストケースを生成する機能仕様表現形式
 1984年 ソフトウェアテストへの直交表の適用、富士通
• 直交表を応用してテストケースを生成する方法とツールの開発
 1988年 CFD(Case Flow Diagram)、NEC ※現在はCause Flow Diagramと呼んでいる
• 原因流れ図で仕様を整理し、デシジョンテーブルを作成する技法
 1991年 Japan's Software Factories
 日本のソフトウェア開発が米国の驚異の的に
• Cusumano, "Japan's Software Factories: A Challenge to U.S. Management",
1991 (日本のソフトウェア戦略-アメリカ式経営への挑戦, 三田出版会, 1993)
• MITのCusumano教授の日立、東芝、NEC、富士通の調査報告
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201036
内容
 ソフトウェアテスト前史
 ソフトウェア技術の発展過程
 テストの考え方の進化
 テスト技法の歴史
 日本の品質・テスト技術の歴史
世界のテスト技術の研究最前線
 まとめ
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201037
世界のテスト技術の研究最前線
 A. Bertolino, "Software Testing Research:
Achievements, Challenges, Dreams," 2007
• 2007年 ソフトウェア工学国際会議(29th ICSE) Future
of Software Engineering trackの論文
• Bertolinoはソフトウェアエンジニアリング基礎知識体系
(SWEBOK)の5章 Testingの執筆者
 Achievements : 達成できたテーマ
 Dreams : 4つの夢
 Challenges : 夢の実現に向けた研究課題
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201038
テスト技術の6つの側面
 テストは
 実行サンプルの観測と結果の判定
 テスト技術を特徴づける6つの側面
 WHY : テストの目的
バグの検出、製品の出荷判断、
UIのユーザビリティ評価、・・・
 HOW : テストの選択方法
アドホック、ランダム、系統的な
方法
 HOW MUCH : テストの量
テスト充分性、網羅度合い、
信頼性尺度
 WHAT : テスト対象
ユニット、コンポーネント/サブ
システム、システム(全体)
 WHERE : 観測場所
社内(in house)、疑似環境、
実環境
 WHEN : 実施時期
ライフサイクルのどこで
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010
ソフトウェアテストの研究ロードマップ
Software testing research roadmap
テストベースド・
モデリング
100% 自動テスト
有効性最大化
テスト工学
普遍的テスト理論
テスト
プロセス
信頼性
テスト
WHY How How much What Where When
プロトコル
テスト
テスト基準
テスト基準の比較
コ
ン
ポ
ー
ネ
ン
ト
ベ
ー
ス
ド
・テ
ス
ト
オ
ブ
ジ
ェ
ク
ト
指
向
テ
ス
ト
テスター教育
テストパターン
進化の制御
ユーザ人口や資源の活用テストのコストの理解
テスト入力の生成
オンライン・テスト
テスト
結果判定
モデルベースド・テスト
アンチ・モデルベースド・テスト
テストの仮説
の明示
テスト有効性
実証体系化
合成テスト
ドメイン固有
テストアプローチ
Achievements Challenges Dreams
テストの目的 テストの選択方法 テストの量 テスト対象 観測場所 実施時期
[出典] A. Bertolino, “Software Testing Research: Achievements, Challenges, Dreams,” FOSE’07, p.85-103, 2007, Figure 1
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201040
達成テーマ (1/2)
 テストプロセス (Testing process)
 テスト技術やツールの開発プロセスへの組み込み
 Vモデルなどのプロセス、新モデル(Agile/TDD)
 テスト基準 (Test criteria)
 テスト基準を利用した系統的なテストケース選択
 テスト基準の比較 (Comparison among test criteria)
 テスト技法の評価、テスト基準の階層化
 オブジェクト指向テスト (Object-oriented testing)
 OO開発に伴う新しいリスクや問題への対応
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201041
達成テーマ (2/2)
 コンポーネントベースド・テスト (Component-based testing)
 コンポーネントを使って組み立てたシステムのテスト
 テストしやすくするために、適切な情報、あるいはテスト
ケース自体(Built-in Testing)をコンポーネントへパッケージ
 独立にテストされたコンポーネントのテスト結果から、組み
立てたシステムの特性を推定(継続課題)
 プロトコル・テスト (Protocol testing)
 プロトコルの仕様と実装の適合性検証
 信頼性テスト (Reliability testing)
 運用プロファイルによるテストで頻度の多い障害を除去
 信頼性モデルに基づくテスト
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201042
夢
(1) 普遍的テスト理論 (Universal test theory)
 テスト技術の支援と育成に役立つ包括的な理論
 各々のテスト技法の強み弱みが理解でき、適切な技法が選択できる指
針のフレームワーク
(2) テストベースド・モデリング (Test-based modeling)
 モデルからテストを設計するのではなく効果的にテストできるモデルを
開発者が考慮(テスト容易化設計のように)
(3) 100%自動テスト (100% automatic testing)
 テスト入力の生成手法、テストプロセス自動化手順
 ソフトウェアの組み込み、テスト環境構築、テストケース生成・実行・レ
ポートを自動的に行う統合テスト環境
(4) 有効性最大化テスト工学 (Efficacy-maximized test engineering)
 高品質ソフトウェアの開発のための実践的テスト手法、ツール、プロセ
スに関する費用対効果の高い工学技術
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201043
夢: (1)普遍的テスト理論
 テスト技術の支援と育成に役立つ包括的な理論
 各々のテスト技法の強み弱みが理解でき、適切な技法が
選択できる指針のフレームワーク
<研究課題>
 テストの仮説の明確化 (Explicit test hypotheses)
• 各テスト技法が前提とする仮定(ex. こういうプログラムのときに、こうい
うバグを検出)を明らかにすることにより、テストの目的を明確化
 テスト有効性 (Test effectiveness)
• 各種テスト基準の有効性を評価し、テスト技法の組み合わせを支援
 合成テスト (Compositional testing)
• 個々のテスト結果の再利用、コンポーネントベースの信頼性理論
 実証体系化 (Empirical body of evidence)
• テスト理論の構築と進化の基礎となる実証データの体系
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201044
夢: (2)テストベースド・モデリング
 モデルからテストを設計するのではなく効果的にテストでき
るモデルを開発者が考慮(テスト容易化設計のように)
<研究課題>
 モデルベースド・テスト (Model-based testing)
• 異なるモデル(遷移、事前・事後条件、シナリオベース)の組み合わせ
• ソフトウェア・プロセスへのMBTプラクティスの統合(実行可能なテスト
の生成、要件からテストへのトレーサビリティの維持)
 アンチ・モデルベースド・テスト (Anti-model-based testing)
• モデルがない、あるいはアクセスできない場合(商用ソフト-COTS-、レ
ガシーコンポなど)はプログラムの実行結果から帰納的にモデル化
 テスト結果判定 (Test oracles)
• まだ人の目に頼るところが多く、複雑度や重要性が増大している今日
では不十分。テスト自動化の障壁
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201045
夢: (3)100%自動テスト
 ソフトウェアの量、複雑性の増加に対して品質を維持する
手段として自動化が重要
 テスト入力の生成手法、テストプロセス自動化手順
 ソフトウェアの組み込み、テスト環境構築、テストケース生
成・実行・レポートを自動的に行う統合テスト環境
<研究課題>
 テスト入力の生成 (Test input generation)
• モデルベースドテスト生成、ランダムテスト生成、search-based test
generation(メタヒューリスティックな探索手法-遺伝アルゴリズムなど)
 ドメイン固有テストアプローチ (Domain-specific test approaches)
• 特定ドメイン(DB、GUI、Webアプリ、航空、通信)のテスト技法は研究さ
れているが、ドメイン知識を利用する方法論の研究は少ない
 オンライン・テスト (On-line testing)
• 動的解析や自己テスト手法を用いて、実運用でのシステムの振る舞い
をモニターしてテストする技術
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201046
夢: (4)有効性最大化テスト工学
 高品質ソフトウェアの開発のための実践的テスト手法、
ツール、プロセスに関する費用対効果の高い工学技術
 主要な障壁はシステムの複雑度の増大
<研究課題>
 進化の制御 (Controlling evolution)
• 稼働後も動的に進化するソフトウェアの品質の維持。進化の中での回
帰テストの意義の理解、および回帰テスト選択手法の修正と拡張
 利用人口・資源の活用 (Leveraging user population and resources)
• 動的にフィールドから収集したデータを使って社内の品質保証活動を
拡大(ex. 多数のユーザのコンフィグレーション情報をテストに活用)
 テストパターン (Testing patterns)
 テストのコストの理解 (Understanding the costs of testing)
• テストの予算の効果的な使用、各テスト技法の費用対効果の見積もり
 テスター教育 (Education of software testers)
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010(C) K. Tatsumi 201047
夢: 横断的な課題
<研究課題>
 最新開発パラダイムにおけるテスト手法
(Testing within the emerging development paradigm)
• サービス指向コンピューティングにおけるサービス指向アプリケーショ
ンのテスト
• サービスのテストではオンライン・テストが特に重要(アプリケーションの
振る舞いを観察する唯一の方法は稼働中のモニタリング)
 機能特性と非機能特性の整合性テスト
(Coherent testing of functional and extra-functional properties)
• 従来の機能テストには時 (いつ、時間) や、リソース使用量やワークロードの考
慮がない
• モデルベースのアプローチの研究が進んでいるが、非機能特性の制約を考慮
できるモデルへの拡張が必要
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010
まとめ : あらためて『温故知新』
[出典] 論語百選 http://shamada.net/weblog/rongo/ から引用
 温故而知新
• 故(ふる)きを温(たず)ねて新しきを知る、以(もつ)て師と為るべし。
• 「古典や歴史を学んで、そこから現代に通用する新しい意義を見出すことがで
きれば、立派な指導者になれるだろう」
 學而時習之
• 学びて時にこれを習う、亦た説(よろこ)ばしからずや。朋遠方より来たる有り、
亦楽しからずや。人知らずして慍(うら)みず、亦君子ならずや。
• 「学んでは適当な時期におさらいをする、いかにも心嬉しいことだ。友が遠い所
からからも尋ねて来る、いかにも楽しいことだ。他人が理解してくれなくても気
することはない、凡人にはできないことだから」
 學而不思則罔
• 学びて思わざれば則(すなわ)ち罔(くら)く、思いて学ばざれば則ち殆(あやう)し。
• 「学ぶだけで、じっくりと自分の頭で思索してみなければ、真に活きた学問とは
ならない。逆に、自分の頭で思い巡らすだけで、博く学ぶことをしなければ、危
なっかしくて頼りにならない」
 誨女知之乎
• 女(なんじ)に之(これ)を知るを誨(おし)えんか。之を知るを之を知ると為(な)し、
知らざるを知らずと為す。是れ知るなり。
• 「お前に知るとはどういうことか教えようか。知っていることは知っているとし、
知らないことは知らないとはっきりさせる。これが本当に知るということだ」
HISTORYOFSOFTWARETESTING
HISTORYOFSOFTWARETESTING
(C) K. Tatsumi 2010
の力で歴史をつくろう
ご清聴ありがとうございました

More Related Content

What's hot

パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へパターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へHironori Washizaki
 
長田武徳, アジャイル開発と品質 ~ アジャイル品質パターンの利用事例
長田武徳, アジャイル開発と品質 ~ アジャイル品質パターンの利用事例長田武徳, アジャイル開発と品質 ~ アジャイル品質パターンの利用事例
長田武徳, アジャイル開発と品質 ~ アジャイル品質パターンの利用事例Hironori Washizaki
 
エムスリーのQAチームが目指すもの
エムスリーのQAチームが目指すものエムスリーのQAチームが目指すもの
エムスリーのQAチームが目指すものYuki Shiromoto
 
What should you shift left
What should you shift leftWhat should you shift left
What should you shift leftYasuharu Nishi
 
5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版Fumihiko Kinoshita
 
modern software qa - draft 1
modern software qa - draft 1modern software qa - draft 1
modern software qa - draft 1Yasuharu Nishi
 
ソフトウェアテストの歴史と近年の動向
ソフトウェアテストの歴史と近年の動向ソフトウェアテストの歴史と近年の動向
ソフトウェアテストの歴史と近年の動向Keizo Tatsumi
 
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証Yasuharu Nishi
 
DeNA QA night #2 presentation
DeNA QA night #2 presentationDeNA QA night #2 presentation
DeNA QA night #2 presentationYasuharu Nishi
 
Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~Mineo Matsuya
 
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)Hironori Washizaki
 
アジャイル開発と品質保証の密なる関係 #quesqa
アジャイル開発と品質保証の密なる関係 #quesqaアジャイル開発と品質保証の密なる関係 #quesqa
アジャイル開発と品質保証の密なる関係 #quesqaques_staff
 
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)Yasuharu Nishi
 
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎Hironori Washizaki
 
SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査
SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査
SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査Hironori Washizaki
 
How to let them in house of quality
How to let them in house of qualityHow to let them in house of quality
How to let them in house of qualityTakahiro Toku
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用ESM SEC
 
REBOKを社内展開する際の障壁
REBOKを社内展開する際の障壁REBOKを社内展開する際の障壁
REBOKを社内展開する際の障壁mkoszk
 
テスト観点に関する取り組み事例
テスト観点に関する取り組み事例テスト観点に関する取り組み事例
テスト観点に関する取り組み事例NaokiKashiwagura
 
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugItsuki Kuroda
 

What's hot (20)

パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へパターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
 
長田武徳, アジャイル開発と品質 ~ アジャイル品質パターンの利用事例
長田武徳, アジャイル開発と品質 ~ アジャイル品質パターンの利用事例長田武徳, アジャイル開発と品質 ~ アジャイル品質パターンの利用事例
長田武徳, アジャイル開発と品質 ~ アジャイル品質パターンの利用事例
 
エムスリーのQAチームが目指すもの
エムスリーのQAチームが目指すものエムスリーのQAチームが目指すもの
エムスリーのQAチームが目指すもの
 
What should you shift left
What should you shift leftWhat should you shift left
What should you shift left
 
5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版
 
modern software qa - draft 1
modern software qa - draft 1modern software qa - draft 1
modern software qa - draft 1
 
ソフトウェアテストの歴史と近年の動向
ソフトウェアテストの歴史と近年の動向ソフトウェアテストの歴史と近年の動向
ソフトウェアテストの歴史と近年の動向
 
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
 
DeNA QA night #2 presentation
DeNA QA night #2 presentationDeNA QA night #2 presentation
DeNA QA night #2 presentation
 
Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~Agile開発でのテストのやり方~私の場合~
Agile開発でのテストのやり方~私の場合~
 
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
メトリクスを用いたソフトウェア品質定量評価・改善 (GQM, Metrics, ET2013)
 
アジャイル開発と品質保証の密なる関係 #quesqa
アジャイル開発と品質保証の密なる関係 #quesqaアジャイル開発と品質保証の密なる関係 #quesqa
アジャイル開発と品質保証の密なる関係 #quesqa
 
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
 
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
鷲崎 メトリクスの基礎とGQM法によるゴール指向の測定 2014年12月18日 日本科学技術連名SQiP研究会 演習コースI ソフトウェア工学の基礎
 
SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査
SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査
SQuaRE に基づくソフトウェア品質評価枠組みと品質実態調査
 
How to let them in house of quality
How to let them in house of qualityHow to let them in house of quality
How to let them in house of quality
 
リーン開発の本質 公開用
リーン開発の本質 公開用リーン開発の本質 公開用
リーン開発の本質 公開用
 
REBOKを社内展開する際の障壁
REBOKを社内展開する際の障壁REBOKを社内展開する際の障壁
REBOKを社内展開する際の障壁
 
テスト観点に関する取り組み事例
テスト観点に関する取り組み事例テスト観点に関する取り組み事例
テスト観点に関する取り組み事例
 
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
 

Viewers also liked

ボクらのプロセスにきづこう #wacate
ボクらのプロセスにきづこう #wacateボクらのプロセスにきづこう #wacate
ボクらのプロセスにきづこう #wacateToshiyuki Kawanishi
 
Rsj2013 02 nakabo
Rsj2013 02 nakaboRsj2013 02 nakabo
Rsj2013 02 nakaborobotcare
 
Pythonで二段階認証
Pythonで二段階認証Pythonで二段階認証
Pythonで二段階認証aoshiman
 
クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門H Iseri
 
ソフトウェアメトリクス概要 20160514
ソフトウェアメトリクス概要 20160514ソフトウェアメトリクス概要 20160514
ソフトウェアメトリクス概要 20160514Yutaka Ohwada
 
Iso 12207 diapositivas
Iso 12207 diapositivasIso 12207 diapositivas
Iso 12207 diapositivasskrass19
 
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacateKinji Akemine
 
わりとディープ?同値分割↔境界値分析
わりとディープ?同値分割↔境界値分析わりとディープ?同値分割↔境界値分析
わりとディープ?同値分割↔境界値分析scarletplover
 
質問されない資料にするための4ステップ
質問されない資料にするための4ステップ質問されない資料にするための4ステップ
質問されない資料にするための4ステップAsuka (飛鳥) Kamijo (上條)
 
C#でもメタプログラミングがしたい!!
C#でもメタプログラミングがしたい!!C#でもメタプログラミングがしたい!!
C#でもメタプログラミングがしたい!!TATSUYA HAYAMIZU
 
プロジェクトマネジメントと開発手法の概要 Web
プロジェクトマネジメントと開発手法の概要 Webプロジェクトマネジメントと開発手法の概要 Web
プロジェクトマネジメントと開発手法の概要 Webminamo
 
Java Web Application Security with Java EE, Spring Security and Apache Shiro ...
Java Web Application Security with Java EE, Spring Security and Apache Shiro ...Java Web Application Security with Java EE, Spring Security and Apache Shiro ...
Java Web Application Security with Java EE, Spring Security and Apache Shiro ...Matt Raible
 

Viewers also liked (15)

Agile meets BABOK
Agile meets BABOKAgile meets BABOK
Agile meets BABOK
 
ボクらのプロセスにきづこう #wacate
ボクらのプロセスにきづこう #wacateボクらのプロセスにきづこう #wacate
ボクらのプロセスにきづこう #wacate
 
Rsj2013 02 nakabo
Rsj2013 02 nakaboRsj2013 02 nakabo
Rsj2013 02 nakabo
 
Pythonで二段階認証
Pythonで二段階認証Pythonで二段階認証
Pythonで二段階認証
 
SQiP2016 SIG8
SQiP2016 SIG8SQiP2016 SIG8
SQiP2016 SIG8
 
クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門クラシフィケーション・ツリー法入門
クラシフィケーション・ツリー法入門
 
ソフトウェアメトリクス概要 20160514
ソフトウェアメトリクス概要 20160514ソフトウェアメトリクス概要 20160514
ソフトウェアメトリクス概要 20160514
 
Iso 12207 diapositivas
Iso 12207 diapositivasIso 12207 diapositivas
Iso 12207 diapositivas
 
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
 
わりとディープ?同値分割↔境界値分析
わりとディープ?同値分割↔境界値分析わりとディープ?同値分割↔境界値分析
わりとディープ?同値分割↔境界値分析
 
質問されない資料にするための4ステップ
質問されない資料にするための4ステップ質問されない資料にするための4ステップ
質問されない資料にするための4ステップ
 
C#でもメタプログラミングがしたい!!
C#でもメタプログラミングがしたい!!C#でもメタプログラミングがしたい!!
C#でもメタプログラミングがしたい!!
 
Iso 12207
Iso 12207Iso 12207
Iso 12207
 
プロジェクトマネジメントと開発手法の概要 Web
プロジェクトマネジメントと開発手法の概要 Webプロジェクトマネジメントと開発手法の概要 Web
プロジェクトマネジメントと開発手法の概要 Web
 
Java Web Application Security with Java EE, Spring Security and Apache Shiro ...
Java Web Application Security with Java EE, Spring Security and Apache Shiro ...Java Web Application Security with Java EE, Spring Security and Apache Shiro ...
Java Web Application Security with Java EE, Spring Security and Apache Shiro ...
 

Similar to ソフトウェアテスト・ヒストリーの学び方 (WACATE 2010冬 クロージングセッション) 20101219

ソフトウェアテストの最新動向の学び方
ソフトウェアテストの最新動向の学び方ソフトウェアテストの最新動向の学び方
ソフトウェアテストの最新動向の学び方Keizo Tatsumi
 
SQuBOKの変遷 (SQuBOK V3発行記念イベント)
SQuBOKの変遷 (SQuBOK V3発行記念イベント)SQuBOKの変遷 (SQuBOK V3発行記念イベント)
SQuBOKの変遷 (SQuBOK V3発行記念イベント)Keizo Tatsumi
 
ソフトウェア品質技術の歴史を振り返る - ソフトウェア品質測定を中心に -
ソフトウェア品質技術の歴史を振り返る - ソフトウェア品質測定を中心に -ソフトウェア品質技術の歴史を振り返る - ソフトウェア品質測定を中心に -
ソフトウェア品質技術の歴史を振り返る - ソフトウェア品質測定を中心に -Keizo Tatsumi
 
ソフトウェアテストの変遷と最近の品質管理の方向性
ソフトウェアテストの変遷と最近の品質管理の方向性ソフトウェアテストの変遷と最近の品質管理の方向性
ソフトウェアテストの変遷と最近の品質管理の方向性Keizo Tatsumi
 
ソフトウェアテスト年表-WACATE2015冬
ソフトウェアテスト年表-WACATE2015冬ソフトウェアテスト年表-WACATE2015冬
ソフトウェアテスト年表-WACATE2015冬Keizo Tatsumi
 
SQiP2016発表資料_プロセス改善の黒歴史(slideshare共有版)
SQiP2016発表資料_プロセス改善の黒歴史(slideshare共有版)SQiP2016発表資料_プロセス改善の黒歴史(slideshare共有版)
SQiP2016発表資料_プロセス改善の黒歴史(slideshare共有版)Adachi Kenji
 
ニューノーマル時代のテストエンジニアへの"food for thought" (JaSST'18 Kansai)
ニューノーマル時代のテストエンジニアへの"food for thought" (JaSST'18 Kansai)ニューノーマル時代のテストエンジニアへの"food for thought" (JaSST'18 Kansai)
ニューノーマル時代のテストエンジニアへの"food for thought" (JaSST'18 Kansai)Keizo Tatsumi
 
世界に目を向けよう - ASTER国際連携活動事例(JaSST'15 tokyo)
世界に目を向けよう - ASTER国際連携活動事例(JaSST'15 tokyo)世界に目を向けよう - ASTER国際連携活動事例(JaSST'15 tokyo)
世界に目を向けよう - ASTER国際連携活動事例(JaSST'15 tokyo)Keizo Tatsumi
 
ICST 2017の歩き方 -歴史、開催概要、聴きどころ、Who's Who ・・ -
ICST 2017の歩き方 -歴史、開催概要、聴きどころ、Who's Who ・・ -ICST 2017の歩き方 -歴史、開催概要、聴きどころ、Who's Who ・・ -
ICST 2017の歩き方 -歴史、開催概要、聴きどころ、Who's Who ・・ -Keizo Tatsumi
 
テスト自動化クロニクル (JaSST 東海 2016)
テスト自動化クロニクル (JaSST 東海 2016)テスト自動化クロニクル (JaSST 東海 2016)
テスト自動化クロニクル (JaSST 東海 2016)Keizo Tatsumi
 
TERAS Conference
TERAS ConferenceTERAS Conference
TERAS ConferenceKeiju Anada
 
テスト自動化のこれまでとこれから
テスト自動化のこれまでとこれからテスト自動化のこれまでとこれから
テスト自動化のこれまでとこれからKeizo Tatsumi
 
Language presentations at WOCS and after.
Language presentations at WOCS and after.Language presentations at WOCS and after.
Language presentations at WOCS and after.Kiyoshi Ogawa
 
運用に自動化を求めるのは間違っているだろうか
運用に自動化を求めるのは間違っているだろうか運用に自動化を求めるのは間違っているだろうか
運用に自動化を求めるのは間違っているだろうかMasahito Zembutsu
 
カバーフローで見る5分間ソフトウェアテスト・ヒストリー
カバーフローで見る5分間ソフトウェアテスト・ヒストリーカバーフローで見る5分間ソフトウェアテスト・ヒストリー
カバーフローで見る5分間ソフトウェアテスト・ヒストリーKeizo Tatsumi
 
AJ2010_20100409_maegawasensei
AJ2010_20100409_maegawasenseiAJ2010_20100409_maegawasensei
AJ2010_20100409_maegawasenseiAkiko Kosaka
 
ソフトウェアテスト年表 - テストのニューノーマルへの流れ
ソフトウェアテスト年表 - テストのニューノーマルへの流れソフトウェアテスト年表 - テストのニューノーマルへの流れ
ソフトウェアテスト年表 - テストのニューノーマルへの流れKeizo Tatsumi
 
ビルドプロセスとCI #STAC2014
ビルドプロセスとCI #STAC2014ビルドプロセスとCI #STAC2014
ビルドプロセスとCI #STAC2014Koji Hasegawa
 
SeasarCon 2009 White TDD
SeasarCon 2009 White TDDSeasarCon 2009 White TDD
SeasarCon 2009 White TDDTakuto Wada
 

Similar to ソフトウェアテスト・ヒストリーの学び方 (WACATE 2010冬 クロージングセッション) 20101219 (20)

ソフトウェアテストの最新動向の学び方
ソフトウェアテストの最新動向の学び方ソフトウェアテストの最新動向の学び方
ソフトウェアテストの最新動向の学び方
 
SQuBOKの変遷 (SQuBOK V3発行記念イベント)
SQuBOKの変遷 (SQuBOK V3発行記念イベント)SQuBOKの変遷 (SQuBOK V3発行記念イベント)
SQuBOKの変遷 (SQuBOK V3発行記念イベント)
 
ソフトウェア品質技術の歴史を振り返る - ソフトウェア品質測定を中心に -
ソフトウェア品質技術の歴史を振り返る - ソフトウェア品質測定を中心に -ソフトウェア品質技術の歴史を振り返る - ソフトウェア品質測定を中心に -
ソフトウェア品質技術の歴史を振り返る - ソフトウェア品質測定を中心に -
 
ソフトウェアテストの変遷と最近の品質管理の方向性
ソフトウェアテストの変遷と最近の品質管理の方向性ソフトウェアテストの変遷と最近の品質管理の方向性
ソフトウェアテストの変遷と最近の品質管理の方向性
 
ソフトウェアテスト年表-WACATE2015冬
ソフトウェアテスト年表-WACATE2015冬ソフトウェアテスト年表-WACATE2015冬
ソフトウェアテスト年表-WACATE2015冬
 
SQiP2016発表資料_プロセス改善の黒歴史(slideshare共有版)
SQiP2016発表資料_プロセス改善の黒歴史(slideshare共有版)SQiP2016発表資料_プロセス改善の黒歴史(slideshare共有版)
SQiP2016発表資料_プロセス改善の黒歴史(slideshare共有版)
 
ニューノーマル時代のテストエンジニアへの"food for thought" (JaSST'18 Kansai)
ニューノーマル時代のテストエンジニアへの"food for thought" (JaSST'18 Kansai)ニューノーマル時代のテストエンジニアへの"food for thought" (JaSST'18 Kansai)
ニューノーマル時代のテストエンジニアへの"food for thought" (JaSST'18 Kansai)
 
世界に目を向けよう - ASTER国際連携活動事例(JaSST'15 tokyo)
世界に目を向けよう - ASTER国際連携活動事例(JaSST'15 tokyo)世界に目を向けよう - ASTER国際連携活動事例(JaSST'15 tokyo)
世界に目を向けよう - ASTER国際連携活動事例(JaSST'15 tokyo)
 
ICST 2017の歩き方 -歴史、開催概要、聴きどころ、Who's Who ・・ -
ICST 2017の歩き方 -歴史、開催概要、聴きどころ、Who's Who ・・ -ICST 2017の歩き方 -歴史、開催概要、聴きどころ、Who's Who ・・ -
ICST 2017の歩き方 -歴史、開催概要、聴きどころ、Who's Who ・・ -
 
テスト自動化クロニクル (JaSST 東海 2016)
テスト自動化クロニクル (JaSST 東海 2016)テスト自動化クロニクル (JaSST 東海 2016)
テスト自動化クロニクル (JaSST 東海 2016)
 
TERAS Conference
TERAS ConferenceTERAS Conference
TERAS Conference
 
テスト自動化のこれまでとこれから
テスト自動化のこれまでとこれからテスト自動化のこれまでとこれから
テスト自動化のこれまでとこれから
 
Language presentations at WOCS and after.
Language presentations at WOCS and after.Language presentations at WOCS and after.
Language presentations at WOCS and after.
 
運用に自動化を求めるのは間違っているだろうか
運用に自動化を求めるのは間違っているだろうか運用に自動化を求めるのは間違っているだろうか
運用に自動化を求めるのは間違っているだろうか
 
カバーフローで見る5分間ソフトウェアテスト・ヒストリー
カバーフローで見る5分間ソフトウェアテスト・ヒストリーカバーフローで見る5分間ソフトウェアテスト・ヒストリー
カバーフローで見る5分間ソフトウェアテスト・ヒストリー
 
AJ2010_20100409_maegawasensei
AJ2010_20100409_maegawasenseiAJ2010_20100409_maegawasensei
AJ2010_20100409_maegawasensei
 
WACATE09冬_線・Maniax_発表版
WACATE09冬_線・Maniax_発表版WACATE09冬_線・Maniax_発表版
WACATE09冬_線・Maniax_発表版
 
ソフトウェアテスト年表 - テストのニューノーマルへの流れ
ソフトウェアテスト年表 - テストのニューノーマルへの流れソフトウェアテスト年表 - テストのニューノーマルへの流れ
ソフトウェアテスト年表 - テストのニューノーマルへの流れ
 
ビルドプロセスとCI #STAC2014
ビルドプロセスとCI #STAC2014ビルドプロセスとCI #STAC2014
ビルドプロセスとCI #STAC2014
 
SeasarCon 2009 White TDD
SeasarCon 2009 White TDDSeasarCon 2009 White TDD
SeasarCon 2009 White TDD
 

More from Keizo Tatsumi

組み合わせテストの設計(PictMaster勉強会) 2008年7月17日
組み合わせテストの設計(PictMaster勉強会) 2008年7月17日組み合わせテストの設計(PictMaster勉強会) 2008年7月17日
組み合わせテストの設計(PictMaster勉強会) 2008年7月17日Keizo Tatsumi
 
Timeline to the New Normal for Software Testing
Timeline to the New Normal for Software TestingTimeline to the New Normal for Software Testing
Timeline to the New Normal for Software TestingKeizo Tatsumi
 
世界のソフトウェアテストの会議 (JaSST 2018 東京)
世界のソフトウェアテストの会議 (JaSST 2018 東京)世界のソフトウェアテストの会議 (JaSST 2018 東京)
世界のソフトウェアテストの会議 (JaSST 2018 東京)Keizo Tatsumi
 
日本における組み合わせテスト - 歴史、適用状況、技法、ツール -
日本における組み合わせテスト - 歴史、適用状況、技法、ツール -日本における組み合わせテスト - 歴史、適用状況、技法、ツール -
日本における組み合わせテスト - 歴史、適用状況、技法、ツール -Keizo Tatsumi
 
Introduction to ICST 2017
Introduction to ICST 2017Introduction to ICST 2017
Introduction to ICST 2017Keizo Tatsumi
 
Test Automation - Past, Present and Future
Test Automation - Past, Present and FutureTest Automation - Past, Present and Future
Test Automation - Past, Present and FutureKeizo Tatsumi
 
SQuBOKガイドV2で測る日本のソフトウェア品質技術力
SQuBOKガイドV2で測る日本のソフトウェア品質技術力SQuBOKガイドV2で測る日本のソフトウェア品質技術力
SQuBOKガイドV2で測る日本のソフトウェア品質技術力Keizo Tatsumi
 
SQuBOKガイドで測る日本の実力(2007年12月10日)
SQuBOKガイドで測る日本の実力(2007年12月10日)SQuBOKガイドで測る日本の実力(2007年12月10日)
SQuBOKガイドで測る日本の実力(2007年12月10日)Keizo Tatsumi
 
Software testing magazines in the world
Software testing magazines in the worldSoftware testing magazines in the world
Software testing magazines in the worldKeizo Tatsumi
 
ソフトウェアテストの最新動向
ソフトウェアテストの最新動向ソフトウェアテストの最新動向
ソフトウェアテストの最新動向Keizo Tatsumi
 
How to Learn The History of Software Testing
How to Learn The History of Software Testing How to Learn The History of Software Testing
How to Learn The History of Software Testing Keizo Tatsumi
 
Conceptual support for test case design (COMPSAC 87)
Conceptual support for test case design (COMPSAC 87)Conceptual support for test case design (COMPSAC 87)
Conceptual support for test case design (COMPSAC 87)Keizo Tatsumi
 
The genealogy of combinatorial testing
The genealogy of combinatorial testingThe genealogy of combinatorial testing
The genealogy of combinatorial testingKeizo Tatsumi
 
Combinatorial testing in Japan
Combinatorial testing in JapanCombinatorial testing in Japan
Combinatorial testing in JapanKeizo Tatsumi
 
The History of Software Engineering and Software Testing (World and Japan)
The History of Software Engineering and Software Testing (World and Japan)The History of Software Engineering and Software Testing (World and Japan)
The History of Software Engineering and Software Testing (World and Japan)Keizo Tatsumi
 
History of combinatorial testing
History of combinatorial testingHistory of combinatorial testing
History of combinatorial testingKeizo Tatsumi
 

More from Keizo Tatsumi (16)

組み合わせテストの設計(PictMaster勉強会) 2008年7月17日
組み合わせテストの設計(PictMaster勉強会) 2008年7月17日組み合わせテストの設計(PictMaster勉強会) 2008年7月17日
組み合わせテストの設計(PictMaster勉強会) 2008年7月17日
 
Timeline to the New Normal for Software Testing
Timeline to the New Normal for Software TestingTimeline to the New Normal for Software Testing
Timeline to the New Normal for Software Testing
 
世界のソフトウェアテストの会議 (JaSST 2018 東京)
世界のソフトウェアテストの会議 (JaSST 2018 東京)世界のソフトウェアテストの会議 (JaSST 2018 東京)
世界のソフトウェアテストの会議 (JaSST 2018 東京)
 
日本における組み合わせテスト - 歴史、適用状況、技法、ツール -
日本における組み合わせテスト - 歴史、適用状況、技法、ツール -日本における組み合わせテスト - 歴史、適用状況、技法、ツール -
日本における組み合わせテスト - 歴史、適用状況、技法、ツール -
 
Introduction to ICST 2017
Introduction to ICST 2017Introduction to ICST 2017
Introduction to ICST 2017
 
Test Automation - Past, Present and Future
Test Automation - Past, Present and FutureTest Automation - Past, Present and Future
Test Automation - Past, Present and Future
 
SQuBOKガイドV2で測る日本のソフトウェア品質技術力
SQuBOKガイドV2で測る日本のソフトウェア品質技術力SQuBOKガイドV2で測る日本のソフトウェア品質技術力
SQuBOKガイドV2で測る日本のソフトウェア品質技術力
 
SQuBOKガイドで測る日本の実力(2007年12月10日)
SQuBOKガイドで測る日本の実力(2007年12月10日)SQuBOKガイドで測る日本の実力(2007年12月10日)
SQuBOKガイドで測る日本の実力(2007年12月10日)
 
Software testing magazines in the world
Software testing magazines in the worldSoftware testing magazines in the world
Software testing magazines in the world
 
ソフトウェアテストの最新動向
ソフトウェアテストの最新動向ソフトウェアテストの最新動向
ソフトウェアテストの最新動向
 
How to Learn The History of Software Testing
How to Learn The History of Software Testing How to Learn The History of Software Testing
How to Learn The History of Software Testing
 
Conceptual support for test case design (COMPSAC 87)
Conceptual support for test case design (COMPSAC 87)Conceptual support for test case design (COMPSAC 87)
Conceptual support for test case design (COMPSAC 87)
 
The genealogy of combinatorial testing
The genealogy of combinatorial testingThe genealogy of combinatorial testing
The genealogy of combinatorial testing
 
Combinatorial testing in Japan
Combinatorial testing in JapanCombinatorial testing in Japan
Combinatorial testing in Japan
 
The History of Software Engineering and Software Testing (World and Japan)
The History of Software Engineering and Software Testing (World and Japan)The History of Software Engineering and Software Testing (World and Japan)
The History of Software Engineering and Software Testing (World and Japan)
 
History of combinatorial testing
History of combinatorial testingHistory of combinatorial testing
History of combinatorial testing
 

ソフトウェアテスト・ヒストリーの学び方 (WACATE 2010冬 クロージングセッション) 20101219

  • 1. HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 20101 ソフトウェアテスト・ヒストリーの学び方 辰巳 敬三 2010年12月19日 ~ タメにならなければ学ばない。 面白くなければ学ぶ資格がない。 WACATE 2010冬
  • 2. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 20102 自己紹介 : マイ ヒストリー1975 1990 2000 1980 1985 2010 1995 2005 1976-富士通入社、ソフトウェア事業部検査部 1990-ソフトウェア品質管理ガイドブック(共著) 2007-ソフトウェア品質知識体系ガイド(SQuBOK)(共著) 2009-ソフトウェアテスト・ヒストリー(テストPress Vol.8) 2009-続ソフトウェアテスト・ヒストリー日本編(テストPress Vol.9) 1976-メインフレームOSの製品検査 1990-UNIX/PCソフトウェア製品検査 1999-製品適用サービス 2006-知財/特許 2009-高度情報通信人材育成支援センター 1989-富士通におけるソフトウェア品質保証の実際(共著) 1990-ソフトウェア品質管理事例集(共著) 1987-Conceptual Support for Test Case Design 1987-Test Case Design Support System
  • 3. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 20103 内容  ソフトウェアテスト前史  コンピュータとソフトウェア技術の歴史  テストの考え方の進化  テスト技法の歴史  日本の品質・テスト技術の歴史  世界のテスト技術の研究最前線  まとめ
  • 4. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 20104 ソフトウェアテスト前史  コンピュータの原型 (1/2)  Charles Babbage(英国)の「解析機関」 • 1837年に設計を開始 (完成には至らず) • 入力(プログラムとデータ)はパンチカード • 出力はプリンター、曲線プロッター、ベル  最初のプログラマー  Ada Byron, Lady Lovelace • 解析機関のプログラムを作成(1843年) – Babbageの講演記録の翻訳の注釈の中に記述
  • 5. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 20105 ソフトウェアテスト前史  最初のテスターは ? (2/2) Ada Loverace女史はプログラマの第1号として、19世紀、 Charles Babbageの壮大にして未完成に終わったコン ピュータのプログラム作成にたずさわったが、「あと1週間 あれば大丈夫です、バベッジ博士。それですべて終わり ます」と何度も言っていたにちがいない。幸いにもハード ウェアが完成しなかったため、Loverace女史は机上デ バッグに巻き込まれずにすんだ。 (ボーリス・バイザー,「ソフトウェアテスト技法」,1994,日経BP)  Boris Beizerによると・・・ • 『テストやデバッグの最初の議論はAdaのメモに遡る』 • Software System Testing and Quality Assurance [Beizer,1984] では
  • 6. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 20106 内容  ソフトウェアテスト前史 コンピュータとソフトウェア技術の歴史  テストの考え方の進化  テスト技法の歴史  日本の品質・テスト技術の歴史  世界のテスト技術の研究最前線  まとめ
  • 7. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 20107 コンピュータとソフトウェア技術の歴史  別紙の歴史年表参照 2010.11.18 辰巳 ▲ ▲ ▲ ▲ EDSAC(最初のノイマン型コンピュータ) IBM System/360 IBM System/370 Cray-1(スパコン) ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ UNIVAC1(世界初の商用コンピュータ) DEC PDP-1 DEC PDP-8 Apple PC IBM PC ▲ Apple Macintosh iPhone iPad ▲ ▲ ▲ Sun-1 ▲ ▲ IBM 701 IBM 704 Intel 4004MPU Sun SPARC Intel Pentium Pro (科学演算用) ● ● (Apple社設立) (Sun Microsystems社設立) ▲ ▲ ▲ ▲ ▲ ▲ ▲ OS/360 UNIX CP/M MS-DOS UNIX System V Linux Windows NT (4004MPU用OS) Netware ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ Windows 3.1 ▲ J2EE .NET ▲ SpeedCode FORTRAN FORTRAN COBOL LISP PL/I C言語 ▲ C++ ▲ Java ▲ Ajax 開発開始 ▲ ALGOL Smalltalk-72 Smalltalk-80 Eiffel ▲ ▲Internet Explorer Ruby on Rails FLOW-MATIC ▲ Netscape ▲ ▲ ● ● HTML/HTTP/WWW XML ● SOAP ● (Microsoft社設立) (Free Software Foundation) (Apache Software Foundation) (Eclipse Foundation) ▲SAGE(防空管制システム) ▲ ● ● ▲ ▲ ▲SABRE(航空座席予約システム) CompuServe America Online Amazon.com Amazon Web Services Amazon EC2 ▲マーキュリー計画 (商用オンラインサービス) ● ● Google Docs & Spreadsheets ▲ジェミニ計画 Yahoo! Google ☆ ▲アポロ計画発表 ▲アポロ11号 有人月面着陸 ● ● クラウド・コンピューティング eBay Salesforce.com ▲ ▲ ▲ ▲ ▲ ▲ ▲ ETL Mark I<電気試験所> FUJIC<富士写真フイルム> NEAC2200<日本電気> DIPS-1<電電公社> PC-8001 PC-9001 UNIXサーバ (日本初のディジタル式自動計算機) (日本初の電子計算機)[真空管式] FACOM230<富士通> ▲ ▲ <日本電気> <日本電気> <日立,日本電気,富士通,三菱,沖> [リレー式] ▲ HITAC8000<日立> 国産メーカ・3グループ化 計算機完成 ▲ ▲ ▲ ETL MarkⅢ<電気試験所>[トランジスタ式] Mシリーズ<富士通・日立> FM-8<富士通> PCサーバ FACOM100 ▲MUSASINO-1<電電公社>(日本初のパラメトロン計算機) ACOSシリーズ<日本電気・東芝> <三菱,富士通,日立> ▲ [リレー式] ▲HIPAC MK-1[パラメトロン式] COSMOシリーズ<三菱・沖電気> ▲ Express5800<日本電気> ▲NEAC-1101[パラメトロン式] 日本語ワープロJW-1<東芝> (WinNT3.5搭載PCサーバ) ▲ ▲ ▲ NEAC-1101用ローダなど NEAC2200用の最初のOS DIPS-103-10OS HIPAC-101用記号入力ルーチン HITAC-5020用モニタ (タイムシェアリングシステム用OS) ▲ ▲ ▲ 自動プログラム(FORTRAN)など(HIPAC 103用) FACOM 230-20/30用モニタ MCPII OSIV<富士通>、OS<日立> ▲ (マルチプログラミング処理) ACOS<日本電気・東芝> FORTRAN/アセンブラ/IOCS/SORT(FACOM 222A) UTS<三菱電機> ▲ ▲ ▲ ▲ ▲ ▲ ▲ 日本最初の商用コンピュータ稼働 国鉄座席予約システム 国鉄オンライン座席予約システムMARS101 JUNET PC-VAN Yahoo! JAPAN アマゾン・ジャパン UNIVAC120(真空管式) ▲ MARS1 JAL国内線座席予約システム ▲ ▲ ▲ 東京証券取引所、野村證券 気象庁予報部 東京オリンピック・リアルタイム記録管理システム NIFTY 楽天市場 iモード ▲ ▲ ▲ ▲ 三和銀行 三井銀行オンラインバンキング 全銀システム ▲ ▲ ジャパンネット銀行 (初の銀行への導入) 第一次金融オンラインシステム 第二次金融オンラインシステム 第三次金融オンラインシステム (日本初のネット銀行) ▲ ▲ ▲ ▲1st NCSE(ICSE) NATO Software Engineering Conference Symposium on Computer Software Reliability ▲ ▲ ▲ ▲ ▲ ▲ 構造化定理 段階的詳細化 構造化設計 CASE Booch法 UML UML 2.0 ▲ ▲ ▲ (Computer aided ▲ ▲ ▲ 構造化プログラミング トップダウンプログラミング▲ データフロー図 software engineering) オブジェクトモデル化技法 デザインパターン アスペクト指向プログラミング ▲ 抽象データ型 ▲ ▲ ▲ ▲ 抽象モジュール ▲ オブジェクト指向ソフトウェア工学 Software Architecture テスト駆動開発(TDD) 形式手法 ERモデル ▲ ▲ ▲ 契約による設計 ▲ ワーニエ法 ジャクソン法 アジャイル宣言(Agile Manifesto) ▲ ▲ ▲ ▲ ▲ Waterfall Model(Royce) DoD-2167 DoD-2167A MIL-498 XP ▲ ▲ ▲ Spiral Model(Boehm) ISO/IEC 12207 ISO/IEC 15288 ▲ ▲ (ソフトウェアライフサイクルプロセス) ▲ (システムライフサイクルプロセス) ISO 9000 CMM CMMI ▲ ▲ ▲ △ ▲ ▲ ▲ プログラム品質特性(Ruben) 品質特性(Boehm) 品質モデル(McCall) ▲ ISO9126標準化開始 ISO/IEC 9126 ISO/IEC 14598 ISO/IEC 15939 1965 19701950 1955 1960 20102000 20051975 1980 1985 1990 1995 ハードウェア ソフトウェア 開発技法/開発方法論 マネジメント/プロセス コンピュータの歴史とソフトウェアテスト・品質技術の歴史 コンピュータ時代の幕開け 「計算機」パラダイムの時代 「日の丸コンピュータ」 の開発促進期 分散処理ネットワーク の普及期 IBMを中心とする 市場開拓期 ミニコンと汎用機ソフト 市場の成長期 パソコン, ワークステーション の誕生・普及期 オープンシステムへの 転換期 「情報処理」パラダイムの時代 インターネットの 急成長期 社会インフラとしての IT浸透期 「ネットワーク」パラダイムの時代 ソフトウェア ハードウェア 世界 (米国) 日本 稼働システム 稼働システム ITパラダイム の変遷 (*1) コ ン ピ ュ ー タ の 歴 史 ソ フ ト ウ ェ ア 技 術 の 歴 史 品質モデル、品質測定 会議・シンポジウム 品質特性・品質モデル クラウド・コンピューティン グの時代? ソフトウェア・マネジメントの観点(*2) ソフトウェア・エンジニアリングの進化(*3) 品質の時代機能の時代 スケジュールの時代 コストの時代 <反> 並行プロセス 対 順次プロセス<反> ソフトウェア工芸(Crafting) <合と反> 形式化とウォータフォールプロセス <合> 生産性と拡張性<正> ハードウェア工学的なソフトウェア工学 <反、部分的に合> 俊敏性と価値 世界 (米国)
  • 8. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 20108 [出典] Basili, Musa, “The Future Engineering of Software: A Management Perspective,“ 1991  1960年代: 機能の時代  ITが社会に入り始めた  社会的ニーズに応えられる機能の開発が主要課題  1970年代: スケジュールの時代  ソフトウェア危機(NATO会議,1968年)  計画期間内にソフトウェア開発を完了させることが主要課題  工程を明確化したライフサイクルモデルが紹介され始めた ex. Royce waterfall model、品質モデル 1950 1980 19901960 1970 2000 2010 スケジュールの時代 コストの時代 品質の時代機能の時代 ソフトウェア・マネジメントの観点 (1/2)
  • 9. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 20109  1980年代: コストの時代  ハードウェアコストの継続的低減、パソコンの出現  ソフトウェアの価格の高さに目が向き始め、コスト/生産性が 主要課題  各種のコストモデルが提案され、適用され始めた ex. Function Point、Putnamモデル、COCOMO  1990年代: 品質の時代  ソフトウェアに対する社会の依存度の増大  マスマーケットでの利用者が増え、ソフトウェアの故障や使 いにくさが深刻な事態を招くことが広く認識されはじめる 1950 1980 19901960 1970 2000 2010 スケジュールの時代 コストの時代 品質の時代機能の時代 ソフトウェア・マネジメントの観点 (2/2)
  • 10. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201010 ソフトウェア工学の進化  Boehmのヘーゲル的進化ビュー  ソフトウェア工学の歴史を弁証法で捉える テーゼ(正) 対 アンチテーゼ(反) → ジンテーゼ(合) 自律; バイオ・ コンピュー ティング 1990年代 2010年代2000年代1970年代 1980年代1960年代1950年代 COTS 工芸品 としての ソフトウェア テーゼ (正) ジン テーゼ (合) アンチ テーゼ (反) 形式化; ウォータ フォール 生産性; 再利用; オブジェクト; ピープルウェア 計画駆動の ソフトウェア 成熟度 モデル アジャイル メソッド ハードウェア のような ソフトウェア の扱い リスクベース・ アジャイルと 計画駆動の ハイブリッド; モデル駆動開発 ソフトウェア 工学と システム工学 の統合 バリューベース法; コラボレーション; グローバル開発; エンタープライズ・ アーキテクチャ ソフトウェアと ハードウェアの違い, 技術者の不足 多くの欠陥 スケーラビリティ, リスクマネジメント プロトタイピング Time to Market, 迅速な変化 スケーラビリティ ドメイン工学 リスクマネジメント 準拠 プロセス・オーバヘッド ソフトウェアの 付加価値 ソフトウェア- システム工学 グローバルな Systems of Systems [出典] B. Boehm, A View of 20th and 21st Century Software Engineering, 2006のプレゼンテーションスライドから引用
  • 11. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201011 内容  ソフトウェアテスト前史  ソフトウェア技術の発展過程 テストの考え方の進化  テスト技法の歴史  日本の品質・テスト技術の歴史  世界のテスト技術の研究最前線  まとめ
  • 12. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201012 テストの考え方の進化  D. Gelperin and W. Hetzel, “The Growth of Software Testing,” 1988 • テストの歴史的成長過程を5段階に区分 • 区切りは各段階開始のマイルストーンとなった文献  1. デバッグ指向の時代 ( ~1956年)  2. 論証指向の時代 (1957年~1978年)  3. 破壊指向の時代 (1979年~1982年)  4. 評価指向の時代 (1983年~1987年)  5. 予防指向の時代 (1988年~ )
  • 13. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201013 1. デバッグ指向の時代 (~1956年)  デバッグとテストが区別されていなかった時代  ソフトウェアはハードウェアの信頼性の一部  『難しいのは間違いを検出することではなく、 異常原因の究明である』 (Gill <EDSAC開発メンバー>, 1951)  プログラムを書いたらチェックする(check it out)程度の認識 checkout, debugging, testingの定義はまだ不明確  McCracken, "Digital Computer Programming,“ 1957 (最も初期のプログラミング教科書) • ”Program Checkout”の章でデバッグやテストを説明 評価 指向 論証指向 破壊 指向デバッグ指向 予防指向 1950 1980 19901960 1970 2000 2010
  • 14. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201014 2. 論証指向の時代 (1957年~1978年)  テストはプログラムが仕様を満足していることを示す ためのもの  Baker, "Digital Computer Programming"の書評, 1957 • 『デバッグとテストという二つのフェーズを区別すべき』 – デバッグ : コーダの目論見どおりにプログラムが動くことを確認 – テスト : 解決しようとした問題が解決されていることを確認  大規模プロジェクト(1950年後半~1960年代) • 軍や航空・宇宙関係のシステム開発 – SAGE(防空管制システム), SABRE(航空座席予約システム), 宇宙(マーキュリー計画,ジェミニ計画,アポロ計画) • コンピュータメーカでの基本ソフトウェア開発 – IBM OS/360 (参考) Brooksの「人月の神話」  ソフトウェア工学の歴史の幕開け(1968, 1969) • NATO Software Engineering 会議 「テストではバグの存在は示せるがバグがないことは示せない」(Dijkstra,1969) (1/2) 論証指向デバッグ指向 評価 指向 破壊 指向 予防指向 1950 1980 19901960 1970 2000 2010
  • 15. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201015 2. 論証指向の時代 (1957年~1978年)  テストのコミュニティの開始 • Debugging Techniques in Large Systems シンポジウム(1970年) • 最初のテストのシンポジウムの開催(1972年6月) The Computer Program Test Methods Symposium • 最初のテストの書籍 Hetzel(Ed.), "Program Test Methods," 1973  テスト技術の研究の拡大 • 最初のテストケース設計の理論付け Goodenough, Gerhart, "Toward a Theory of Test Data Selection," 1975 • テスト・ワークショップの開始 (現在のISSTAの源流) Software Testing and Test Documentation Workshop, 1978 <参考>1973年, Wulfの品質属性の定義, Boehmらの品質モデル (2/2) 論証指向デバッグ指向 評価 指向 破壊 指向 予防指向 1950 1980 19901960 1970 2000 2010
  • 16. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201016 3. 破壊指向の時代 (1979年~1982年)  テストとは、エラーをみつけるつもりでプログラムを実 行する過程(テストの成功とはエラーを見つけること)  Myers, "The Art of Software Testing," 1979 テストでは、経済学的・心理学的な観点が大切 • 投資対効果の最大化を目的とすべき (限られたテストで検出できるエラー数を最大に) • 『完全なテストは不可能であるから、いかなるプログ ラムのテストも不完全にならざるを得ない。だから、 作戦としては、この不完全さをできる限り減らすこと であることが明らかである。』 ⇒ これが、きちんとテスト設計することの意味であり、 テスト設計技法の目的 1950 1980 19901960 1970 2000 2010 論証指向デバッグ指向 評価 指向 破壊 指向 予防指向
  • 17. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201017 4. 評価指向の時代 (1983年~1987年)  ソフトウェアのライフサイクルを通じた評価活動の中 にテストが位置付けられた時代  FIPS 101 (米国標準局(NBS)規格), 1983 "Guideline for Lifecycle Validation, Verification, and Testing of Computer Software" • ライフサイクルの中で、解析、レビュー、テストの活動 を統合する方法論、各フェーズのVV&T技法 ⇒ ソフトウェアの品質は単一の技法で保証できる ものではない。個々のプロジェクトで吟味して 選んだ技法群を使うことにより品質のよい ソフトウェアの開発が可能になる 1950 1980 19901960 1970 2000 2010 論証指向デバッグ指向 評価 指向 破壊 指向 予防指向
  • 18. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201018 5. 予防指向の時代 (1988年~)  ソフトウェアライフサイクルと並行して進められる予防 指向のテストプロセス  テスト方法論STEP (Systematic Test and Evaluation Process) Hetzel, "The Complete Guide to Software Testing 2nd Ed.," 1988 • ソフトウェアライフサイクルと並行してテスト活動を実施 • テスト計画の立案、テストの設計、テストのメトリクスの収集方法、 リスク分析法などから構成 現在の“Wモデル”につながる考え方 <補足> Hetzelは既に1973年の"Program Test Methods"で 「テストは設計とコーディングの全プロセスにおいて 計画されなければならない」 と書いている。 1950 1980 19901960 1970 2000 2010 論証指向デバッグ指向 評価 指向 破壊 指向 予防指向
  • 19. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201019 Beizerのテスト道  テスト担当者の精神面による区分 • フェーズ0 : テストとデバグには何の差もない。デバグ以外 にはテストには特別な目的はない。 • フェーズ1 : テストの目的は、ソフトウェアが動くことを示す ことである。 • フェーズ2 : テストの目的は、ソフトウェアが動かないという ことを示すことにある。 • フェーズ3 : テストの目的は、何かを証明することではなく、 プログラムが動かないことによって発生する 危険性をある許容範囲にまで減らすことである。 • フェーズ4 : テストは行動ではない。テストをしないで品質の 高いソフトウェアを作るための精神的な訓練である。 [出典] B. Beizer, "Software Testing Techniques,2nd Ed.," 1990 (電通大・西先生の命名)
  • 20. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201020 内容  ソフトウェアテスト前史  ソフトウェア技術の発展過程  テストの考え方の進化 テスト技法の歴史  日本の品質・テスト技術の歴史  世界のテスト技術の研究最前線  まとめ
  • 21. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201021 テスト技法の歴史 : 胎動期 テスト技法の多くが確立する1970年以前の状況  1960年代前半はテストに関する論文は少ない  テスト文献数(累積) 1969年-57件、1973年-200件、1977年-400件以上  内容的にもテストの手順やテストの自動化に関するもので、 テスト技法に関する内容は見受けられない。  1960年代後半  IBMのOS/360の開発プロジェクト (Brooksの「人月の神話」) • 1966年リリース、1967年に本格的マルチタスクOSのMVTをリリース かなりのテスト作業が行われ、テストプロセス、テスト技法、 テストマネジメントに関するノウハウが蓄積された筈 (1/2)
  • 22. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201022 テスト技法の歴史 : 胎動期  IBM社のElmendorfのテスト制御プロセス  Elmendorf, "Controlling the functional testing of an operating system," 1969 • Elmendorfは1965年からOS/360の ソフトウェアテストを担当 • この論文から、きちんとしたテストプロセス が実践されていたことが伺える。 • このプロセスによりテストを自由放任から 統率へ、芸術から科学的なアプローチに 変えていくことができると言っている。 予防指向プロセス, Wモデルの先駆け (2/2) 設計 仕様化 実装 テスト プログラム目標 テスト目標 プログラム仕様書 調査 識別 評価 レビュー 監視 機能バリエーション テスト計画 テスト仕様書 テスト資材 プログラム テスト結果 【開発工程】 【テストプロセス】
  • 23. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201023 同値分割、限界値分析  入力データを「同じ出力結果が得られるグループ」に 分割して各グループ(同値クラス)の代表値、および 同値クラスの端に着目してテストケースを作成 <歴史>  同値分割、限界値分析という名称でテスト技法として確立 したのは、1979年のIBMのMyersの"ソフトウェア・テストの 技法"  Myers以前からテストデータ選定の考え方はあった • 1967年のElmendorfの論文には、ソフトウェアの機能のバリエー ションを変数とその状態で定義し、状態として正常値、最大値、最 小値、それらを越える値を含める考え方が書かれている
  • 24. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201024 原因結果グラフ  外部仕様を、原因(入力条件)と結果(出力や状態)の 論理関係、および原因間の関係(制約条件)を示すグ ラフで表現し、それにもとづいてテストケースを作成 <歴史>  Myersの"ソフトウェア・テストの技法"(1979年)で紹介され たことにより広く知られるようになった  技法を考案したのはElmendorf(1970年頃) • スイッチング回路の故障点の発見のための手法を元に、制約条件 の考え方を追加してソフトウェアの機能を記述できるようにした • 原因結果グラフからテストケースを作成するツールTELDAP(TEst Library Design Automation Program)を開発。ハードウェアの論 理回路のテストパターン作成ツールを元に作成
  • 25. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201025 デシジョンテーブルテスト  プログラムの仕様を条件部とアクション部からなるデ シジョンテーブルに整理してテストケースを作成 <歴史>  1958年:システム設計の道具としてGeneral Electric(GE) 社やSutherland社でデシジョンテーブルを考案  1960年:GE社はデシジョンテーブルから直接ソースコード を生成するプログラム言語TABSOLを開発  1965年:RCA社のScheffがテスト設計にデシジョンテーブ ルを用いた論文を発表 • 条件部にテストカテゴリとパラメタを、アクション部に結果とテストア クションを整理 • 縦の列(ルール)をテストケースとして自動テストツールへ入力  1975年:Goodenough&Gerhartはテスト理論の論文でプロ グラム構造に基づくテストをデシジョンテーブルで設計する 方法(Condition table method <条件表法>)を提案
  • 26. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201026 直交表/Pairwiseテスト  任意の二つの因子間で組み合わせが網羅されるよ うにテストケースを作成 (直交表やpair生成ツールを使用) <歴史>  実験計画法は1920年代に英国のFisherが農業実験の合 理化のために開発した手法。これをもとに田口玄一博士が 品質工学(タグチメソッド)を開発  テストへの直交表の適用は、1983年に富士通で開始、同 時期に米国でもMandlがAdaコンパイラのテストに適用  米国で活用されるようになったのは、AT&T社(Bell Labs, Bellcore)の成果が発表された1990年代半ばから。 • 1992年に直交表によるテスト設計ツールOATSを開発 • 1994年に制約条件を考慮した組み合わせ表ツールCATSを開発 • 1994年に逐次的な手法によるPairwise生成ツールAETG を商用化
  • 27. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201027 組み合わせテスト (1957: Decision table) ~1967: Equivalence partitioning, Boundary value analysis 1970: Cause Effect Graph [Elmendorf] (1983~)1985: Orthogonal Latin Squares [R. Mandl] (1983~)1984: 直交表/組合せ表 [佐藤,下川(富士通)] 1987: ATAF [辰巳(富士通)] (198x~)1992: OATS [Brownlie, Prowse, Phadke] (1990~)1994: CATS [Sherwood] (1992~)1994: AETG [Cohen, et. al] 1998: IPO [Lei, Tai] 2000: Covering arrays [Williams] 2000: CTE XL [Daimler Chrystler] (2000~)2004: PICT [Microsoft] 2007: FireEye 2009:ACTS (IPOG)[Lei, Kuhn] AT&T社, Bellcore社 で開発 1988: Category-partition method [Ostrand, Balcer] 1993: Classification-tree method [Grochtmann, Grimm] (1976: テスト要因分析) [富士通] (199x~)2004: 直交表(HAYST法) [富士ゼロックス] 1980 1990 2000 20101950 1960 1970 ‘85 ‘95 ‘05 組み合わせ手法 入力条件分析手法
  • 28. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201028 制御フローテスト (1/2)  プログラムの制御の流れをフローグラフで表現し,基 準に従ってグラフを網羅するテストケースを作成 <歴史>  グラフ理論の適用 • 1960年にソフトウェア開発(コンパイラ)へグラフ理論を適用(Karp) • 1963年にテスト設計へ適用。フローチャートをグラフ化し、ブール 行列に変換後、分岐点に着目してテストを設計(MillerとMaloney) • 1976年にMaCabeがグラフ理論を元にプログラムの複雑度を表す サイクロマチック複雑度、基礎パステスト法を提案  カバレッジの計測 • 1960年代前半には意図したルートが通過したかどうかの計測開始 • IBM社のPoughkeepsie地区でコードカバレッジ・ツールを開発 – [Warner,1964] : COBOLとFORTRANソースプログラムを対象にした ハードウェアの命令語モニタについてのいちばん最初の解説書 – [Hirsh,1967] : ソフトウェアのステートメントカバレージとブランチカバ レージアナライザについての初期の論文
  • 29. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201029 制御フローテスト (2/2) <歴史> (つづき)  動的解析システム(カバレッジ計測ツール) • 1970年代初めに各社で本格的な動的解析システムを開発 – TRW社のPACE(Product Assurance Confidence Evaluator) [Brown,1972] – McDonnell Douglas社のPET(Program Evaluater and Tester) [Stucki,1972] – General Research社のRXVP [Miller,1974] など  カバレッジ基準 • TER(Test Effectiveness Ratio:テスト有効度) [Brown,1972] – TERとして命令網羅、分岐網羅を定義 • C0, C1, C2, ・・・ [Miller,1975] – 1975年時点では、 C0 : プログラマの直感、C1 : 命令網羅、C2 : 判定条件網羅、・・・ – 1977年頃に、 C0 : 命令網羅、C1 : 判定条件網羅、C1p : 判定条件/条件網羅、 C2 : C1基準+ループ網羅、・・・
  • 30. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201030 データフローテスト  プログラムの制御フローを元に、変数の定義、変数 の使用の関係に着目してパスを選択することにより テストケースを作成 <歴史>  1960年後半、コンパイラ分野でプログラム最適化技術とし てデータフロー解析の研究が進められた(IBM社のAllenら)  1974年の米国コロラド大学のOsterweilとFosdickのデータ フローテストの論文がテスト技術としては最初と思われる  その後、データフローテスト基準の提案や制御フローテスト も含めた構造テストの基準間の包含関係の研究が進めら れている(RappsとWeyuker,1982 など)
  • 31. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201031 状態遷移テスト  プログラムの仕様を状態遷移図や状態遷移表を使っ て整理し、それにもとづいてテストケースを作成 <歴史>  状態遷移図や状態遷移表は、元来は有限オートマトン(有 限状態機械:FSM)の仕様を記述するためのもの • デジタル回路の設計ソフトウェア、コンパイラのための字句解析(言 語理論)、通信プロトコルのような有限状態をとるシステムのチェッ クをするソフトウェアなどの分野に用いられている計算モデル  1956年のMooreの論文"Gedanken-experiments on sequential machines"(順序機械の思考実験)がFSMベー スのテスト生成の研究の先駆け  1978年にChowが状態遷移テストにおけるカバレッジ基準 "n-switch cover"を提案
  • 32. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201032 内容  ソフトウェアテスト前史  ソフトウェア技術の発展過程  テストの考え方の進化  テスト技法の歴史 日本の品質・テスト技術の歴史  世界のテスト技術の研究最前線  まとめ
  • 33. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201033 日本の品質・テスト技術の歴史 (1/3)  1958年 テストに関する初期の文献  藤原, "大型電子計算機 IBM 704をプログラムテストして," 1958 • 気象庁の数値予報のプログラムのテストをしたときの状況の報告  1964年 プログラムの検査に関する議論  情報処理学会, 「情報処理」ソフトウェア特集, 1964 • 仕様を決める段階からその検査をやる組織というものが加わって、最終製品につい てつくった側とは独立に、いろいろなテスト・プログラムをかけて検査するというよう なことをやっていかなければいけないんじゃないかと思います。 • 検査部門というのは工程の状況を把握するための情報をとる感覚器官。それを工 程に正しくフィードバックして初めて工程をよい状態に維持できるし、ときには改善も 可能になるんだというような解釈が、近代的品質管理における検査の職能である。  1969年 日立製作所でソフトウェア工場を開設  工場制度におけるソフトウェアの検査機能を確立  1971年、富士通も出荷前のソフトウェア製品検査を制度化
  • 34. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201034 日本の品質・テスト技術の歴史 (2/3)  1972年 ソフトウェアの検査の考え方  菅野, “ソフトウェア検査の考え方,” 1972 • われわれは、過去数年間ソフトウェア検査の確立に努力 してきた。当初ソフトウェアにおいては、検査という語は 存在していなかった。単に言葉がなかったばかりではな く、検査という行為もそれまではなかったといってよかろ う。このような周辺事情のなかで、ソフトウェアは製品で あるという認識のもとに、近代的ソフトウェア・エンジニア リング確立の一つとして、現在まで検査技術の設定に努 力し、一応軌道に乗った様相で、ソフトウェア検査業務を 遂行している現状である。  1974年 検査技術の開発  坂田, "ソフトウェアの生産管理における予測技 法の定式化," 電子通信学会, 1974 • 静的な予測および故障率推移モデル 成長曲線やゴンペルツ曲線などを使った品質予測手法 • 動的な予測:先取評価手法 先取り評価手法(QP:Quaity Prove)(探針と呼ばれている)
  • 35. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201035 日本の品質・テスト技術の歴史 (3/3)  1980年~ テスト技法の研究開発  1980年 AGENT(Automated GENeration system for Test cases)、日立 • 原因結果グラフからテストケースを生成するツールAGENTの開発  1984年 AGENT機能図式、日立 • 機能仕様の動的部分を状態遷移で、静的部分をデシジョンテーブルや原因結果グ ラフで表現し、これらを組み合わせてテストケースを生成する機能仕様表現形式  1984年 ソフトウェアテストへの直交表の適用、富士通 • 直交表を応用してテストケースを生成する方法とツールの開発  1988年 CFD(Case Flow Diagram)、NEC ※現在はCause Flow Diagramと呼んでいる • 原因流れ図で仕様を整理し、デシジョンテーブルを作成する技法  1991年 Japan's Software Factories  日本のソフトウェア開発が米国の驚異の的に • Cusumano, "Japan's Software Factories: A Challenge to U.S. Management", 1991 (日本のソフトウェア戦略-アメリカ式経営への挑戦, 三田出版会, 1993) • MITのCusumano教授の日立、東芝、NEC、富士通の調査報告
  • 36. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201036 内容  ソフトウェアテスト前史  ソフトウェア技術の発展過程  テストの考え方の進化  テスト技法の歴史  日本の品質・テスト技術の歴史 世界のテスト技術の研究最前線  まとめ
  • 37. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201037 世界のテスト技術の研究最前線  A. Bertolino, "Software Testing Research: Achievements, Challenges, Dreams," 2007 • 2007年 ソフトウェア工学国際会議(29th ICSE) Future of Software Engineering trackの論文 • Bertolinoはソフトウェアエンジニアリング基礎知識体系 (SWEBOK)の5章 Testingの執筆者  Achievements : 達成できたテーマ  Dreams : 4つの夢  Challenges : 夢の実現に向けた研究課題
  • 38. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201038 テスト技術の6つの側面  テストは  実行サンプルの観測と結果の判定  テスト技術を特徴づける6つの側面  WHY : テストの目的 バグの検出、製品の出荷判断、 UIのユーザビリティ評価、・・・  HOW : テストの選択方法 アドホック、ランダム、系統的な 方法  HOW MUCH : テストの量 テスト充分性、網羅度合い、 信頼性尺度  WHAT : テスト対象 ユニット、コンポーネント/サブ システム、システム(全体)  WHERE : 観測場所 社内(in house)、疑似環境、 実環境  WHEN : 実施時期 ライフサイクルのどこで
  • 39. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010 ソフトウェアテストの研究ロードマップ Software testing research roadmap テストベースド・ モデリング 100% 自動テスト 有効性最大化 テスト工学 普遍的テスト理論 テスト プロセス 信頼性 テスト WHY How How much What Where When プロトコル テスト テスト基準 テスト基準の比較 コ ン ポ ー ネ ン ト ベ ー ス ド ・テ ス ト オ ブ ジ ェ ク ト 指 向 テ ス ト テスター教育 テストパターン 進化の制御 ユーザ人口や資源の活用テストのコストの理解 テスト入力の生成 オンライン・テスト テスト 結果判定 モデルベースド・テスト アンチ・モデルベースド・テスト テストの仮説 の明示 テスト有効性 実証体系化 合成テスト ドメイン固有 テストアプローチ Achievements Challenges Dreams テストの目的 テストの選択方法 テストの量 テスト対象 観測場所 実施時期 [出典] A. Bertolino, “Software Testing Research: Achievements, Challenges, Dreams,” FOSE’07, p.85-103, 2007, Figure 1
  • 40. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201040 達成テーマ (1/2)  テストプロセス (Testing process)  テスト技術やツールの開発プロセスへの組み込み  Vモデルなどのプロセス、新モデル(Agile/TDD)  テスト基準 (Test criteria)  テスト基準を利用した系統的なテストケース選択  テスト基準の比較 (Comparison among test criteria)  テスト技法の評価、テスト基準の階層化  オブジェクト指向テスト (Object-oriented testing)  OO開発に伴う新しいリスクや問題への対応
  • 41. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201041 達成テーマ (2/2)  コンポーネントベースド・テスト (Component-based testing)  コンポーネントを使って組み立てたシステムのテスト  テストしやすくするために、適切な情報、あるいはテスト ケース自体(Built-in Testing)をコンポーネントへパッケージ  独立にテストされたコンポーネントのテスト結果から、組み 立てたシステムの特性を推定(継続課題)  プロトコル・テスト (Protocol testing)  プロトコルの仕様と実装の適合性検証  信頼性テスト (Reliability testing)  運用プロファイルによるテストで頻度の多い障害を除去  信頼性モデルに基づくテスト
  • 42. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201042 夢 (1) 普遍的テスト理論 (Universal test theory)  テスト技術の支援と育成に役立つ包括的な理論  各々のテスト技法の強み弱みが理解でき、適切な技法が選択できる指 針のフレームワーク (2) テストベースド・モデリング (Test-based modeling)  モデルからテストを設計するのではなく効果的にテストできるモデルを 開発者が考慮(テスト容易化設計のように) (3) 100%自動テスト (100% automatic testing)  テスト入力の生成手法、テストプロセス自動化手順  ソフトウェアの組み込み、テスト環境構築、テストケース生成・実行・レ ポートを自動的に行う統合テスト環境 (4) 有効性最大化テスト工学 (Efficacy-maximized test engineering)  高品質ソフトウェアの開発のための実践的テスト手法、ツール、プロセ スに関する費用対効果の高い工学技術
  • 43. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201043 夢: (1)普遍的テスト理論  テスト技術の支援と育成に役立つ包括的な理論  各々のテスト技法の強み弱みが理解でき、適切な技法が 選択できる指針のフレームワーク <研究課題>  テストの仮説の明確化 (Explicit test hypotheses) • 各テスト技法が前提とする仮定(ex. こういうプログラムのときに、こうい うバグを検出)を明らかにすることにより、テストの目的を明確化  テスト有効性 (Test effectiveness) • 各種テスト基準の有効性を評価し、テスト技法の組み合わせを支援  合成テスト (Compositional testing) • 個々のテスト結果の再利用、コンポーネントベースの信頼性理論  実証体系化 (Empirical body of evidence) • テスト理論の構築と進化の基礎となる実証データの体系
  • 44. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201044 夢: (2)テストベースド・モデリング  モデルからテストを設計するのではなく効果的にテストでき るモデルを開発者が考慮(テスト容易化設計のように) <研究課題>  モデルベースド・テスト (Model-based testing) • 異なるモデル(遷移、事前・事後条件、シナリオベース)の組み合わせ • ソフトウェア・プロセスへのMBTプラクティスの統合(実行可能なテスト の生成、要件からテストへのトレーサビリティの維持)  アンチ・モデルベースド・テスト (Anti-model-based testing) • モデルがない、あるいはアクセスできない場合(商用ソフト-COTS-、レ ガシーコンポなど)はプログラムの実行結果から帰納的にモデル化  テスト結果判定 (Test oracles) • まだ人の目に頼るところが多く、複雑度や重要性が増大している今日 では不十分。テスト自動化の障壁
  • 45. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201045 夢: (3)100%自動テスト  ソフトウェアの量、複雑性の増加に対して品質を維持する 手段として自動化が重要  テスト入力の生成手法、テストプロセス自動化手順  ソフトウェアの組み込み、テスト環境構築、テストケース生 成・実行・レポートを自動的に行う統合テスト環境 <研究課題>  テスト入力の生成 (Test input generation) • モデルベースドテスト生成、ランダムテスト生成、search-based test generation(メタヒューリスティックな探索手法-遺伝アルゴリズムなど)  ドメイン固有テストアプローチ (Domain-specific test approaches) • 特定ドメイン(DB、GUI、Webアプリ、航空、通信)のテスト技法は研究さ れているが、ドメイン知識を利用する方法論の研究は少ない  オンライン・テスト (On-line testing) • 動的解析や自己テスト手法を用いて、実運用でのシステムの振る舞い をモニターしてテストする技術
  • 46. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201046 夢: (4)有効性最大化テスト工学  高品質ソフトウェアの開発のための実践的テスト手法、 ツール、プロセスに関する費用対効果の高い工学技術  主要な障壁はシステムの複雑度の増大 <研究課題>  進化の制御 (Controlling evolution) • 稼働後も動的に進化するソフトウェアの品質の維持。進化の中での回 帰テストの意義の理解、および回帰テスト選択手法の修正と拡張  利用人口・資源の活用 (Leveraging user population and resources) • 動的にフィールドから収集したデータを使って社内の品質保証活動を 拡大(ex. 多数のユーザのコンフィグレーション情報をテストに活用)  テストパターン (Testing patterns)  テストのコストの理解 (Understanding the costs of testing) • テストの予算の効果的な使用、各テスト技法の費用対効果の見積もり  テスター教育 (Education of software testers)
  • 47. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010(C) K. Tatsumi 201047 夢: 横断的な課題 <研究課題>  最新開発パラダイムにおけるテスト手法 (Testing within the emerging development paradigm) • サービス指向コンピューティングにおけるサービス指向アプリケーショ ンのテスト • サービスのテストではオンライン・テストが特に重要(アプリケーションの 振る舞いを観察する唯一の方法は稼働中のモニタリング)  機能特性と非機能特性の整合性テスト (Coherent testing of functional and extra-functional properties) • 従来の機能テストには時 (いつ、時間) や、リソース使用量やワークロードの考 慮がない • モデルベースのアプローチの研究が進んでいるが、非機能特性の制約を考慮 できるモデルへの拡張が必要
  • 48. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010 まとめ : あらためて『温故知新』 [出典] 論語百選 http://shamada.net/weblog/rongo/ から引用  温故而知新 • 故(ふる)きを温(たず)ねて新しきを知る、以(もつ)て師と為るべし。 • 「古典や歴史を学んで、そこから現代に通用する新しい意義を見出すことがで きれば、立派な指導者になれるだろう」  學而時習之 • 学びて時にこれを習う、亦た説(よろこ)ばしからずや。朋遠方より来たる有り、 亦楽しからずや。人知らずして慍(うら)みず、亦君子ならずや。 • 「学んでは適当な時期におさらいをする、いかにも心嬉しいことだ。友が遠い所 からからも尋ねて来る、いかにも楽しいことだ。他人が理解してくれなくても気 することはない、凡人にはできないことだから」  學而不思則罔 • 学びて思わざれば則(すなわ)ち罔(くら)く、思いて学ばざれば則ち殆(あやう)し。 • 「学ぶだけで、じっくりと自分の頭で思索してみなければ、真に活きた学問とは ならない。逆に、自分の頭で思い巡らすだけで、博く学ぶことをしなければ、危 なっかしくて頼りにならない」  誨女知之乎 • 女(なんじ)に之(これ)を知るを誨(おし)えんか。之を知るを之を知ると為(な)し、 知らざるを知らずと為す。是れ知るなり。 • 「お前に知るとはどういうことか教えようか。知っていることは知っているとし、 知らないことは知らないとはっきりさせる。これが本当に知るということだ」
  • 49. HISTORYOFSOFTWARETESTING HISTORYOFSOFTWARETESTING (C) K. Tatsumi 2010 の力で歴史をつくろう ご清聴ありがとうございました