2015年2月20日(金)YAMASAKI Takashi

自己紹介

山﨑 崇@yamasaki696

2001年トレンドマイクロ株式会社入社。同社製品開発部において、QAエンジニアとして様々なプロジェクトに参加し、特にソフトウェアテストの活動全般を担う。
現在はエンタープライズの開発プロジェクトにおいてテストを担当する傍ら、品質・テストに関連する社内コンサル的な活動にも手を広げている。
社外活動にも積極的に参加しており、JaSST Tokyoや、
WACATEなどでも活動。また、2012年よりSQiPセミナーにてJSTQB認定ソフトウェアテスト技術者Foundation Levelトレーニングコースの講師を務めている。

テスト駆動開発 ブラックボックステスト
負荷テスト
性能テスト
スモークテスト
テストデータシステムテスト
テストウェアベータテストテストベース ユニットテスト
非機能テストテストツール テスト戦略テスト環境
モンキーテスト
テスト技法 グレーボックステスト
機能テスト
ペネトレーションテスト ホワイトボックステスト 探索的テスト
ステートメントテスト 結合テスト
セキュリティテスト
テスト設計
テスト条件 テスト実装
パステスト
テスト実行 テストフレームワーク
テスト分析
テスト管理 テストアプローチ テスト手順
テストケース
テスト報告
コンパチビリティテスト
受け入れテスト
テスト計画

統合テスト

10501980

1985

1990

1995

2000

2005

2010

※著者当人による、あまり厳格ではない調査に基づいて作成したものです本日使う道具はこの三点ですテスト分析

システムテストの自動化

非機能テストブラックボックス
テスト
テストタイプ

こんな感じで、随時気になったキーワードを独断と偏見によって貼り付けていってください

テストプロセス

人によっても違うし成熟度によっても違うし千差万別…
フェーズ4

テストは行動ではない。
大げさなテストをすることなく品質の高いソフトウェアを作るための精神的な訓練である。

フェーズ3

テストの目的は、何かを証明することではなく、プログラムが動かないことによって発生する危険性をある許容範囲までに減らすことである。

フェーズ2

テストの目的は、ソフトウェアテストが動かないということを示すことにある。

フェーズ1

テストの目的は、ソフトウェアテストが動くことを示すことである。

フェーズ0

テストとデバッグには何の差もない。
デバッグ以外にはテストには特別な目的はない。
ボーリス・バイザー著 「ソフトウェアテスト技法」よりテスト担当者の精神面による区分を引用

本稿でのテストは次とします「品質に関わる新たな情報を提供するための諸活動」
対象ソフトウェアの欠陥を摘出する

品質レベルが十分であることを確認する

意志決定のための欠陥の作り情報を示すこみを防ぐ

Industry References:3 B. Boehm and V. Basili, "Software Defect Reduction Top 10 List" IEEE Computer Society, Vol. 34, No. 1, Jan 2001

品質コスト
適合コスト

不適合コスト

欠陥を回避するためにプロジェクト
期間中に支出する金額

障害によりプロジェクト期間中および期間後に支出する金額

予防コスト

内的障害コスト

品質上の欠陥の発生を早い段階で防止するために支出される欠陥コスト

製品の出荷以前に欠陥や品質不良が発見された場合の処理に付随して発生する内部障害コスト

検出コスト

外的障害コスト

製品ないし部品の品質を評価することによって品質レベルを維持するために支出される評価コスト

製品出荷後に市場で欠陥や品質不良が発見された場合の処理に付随して発生する外部障害コスト

図：品質コスト / Rex Black著「ソフトウェアテスト12の必勝プロセス」の品質コストの説明をもとに図にしたもの

プロジェクト期間中の品質コスト
適合コスト

不適合コスト

欠陥を回避するためにプロジェクト期間中に支出する金額

障害によりプロジェクト期間中および期間後に支出する金額

予防コスト

内的障害コスト

品質上の欠陥の発生を早い段階で防止するために支出される欠陥コスト

製品の出荷以前に欠陥や品質不良が発見された場合の処理に付随して発生する内部障害コスト

検出コスト

外的障害コスト

製品ないし部品の品質を評価することによって品質レベルを維持するために支出される評価コスト

製品出荷後に市場で欠陥や品質不良が発見された場合の処理に付随して発生する外部障害コスト

図：品質コスト / Rex Black著「ソフトウェアテスト12の必勝プロセス」の品質コストの説明をもとに図にしたもの

テストの七原則＠JSTQB
原則 壱• テストは欠陥がある事しか示せない

原則 弐• 全数テストは不可能

原則 参• 初期テスト

原則 四• 欠陥の偏在

原則 五• 殺虫剤のパラドックス

原則 六• テストは条件次第

原則 七• バグゼロの落とし穴
テスト技術者資格制度 Foundation Levelシラバス日本語版 Version 2011.J02より引用 (JSTQB FL)

テストの原則を学ぶにはコレ！

テスト技術者資格制度 Foundation
Levelシラバス日本語版
JSTQB FL シラバス (PDF)

通読すればテストの全体像を俯瞰できるようになる。また、共通言語としても有効。

ISTQBシラバス準拠
ソフトウェアテストの基礎 Foundation Level

ソフトウェアテスト教科書
JSTQB Foundation 第3版
著者多数/翔泳社

著者多数/BNN新社

シラバスの副読本として次の2冊もお勧め。シラバスだけでは理解しきれないところなどはこれで補おう。2冊とシラバスを比較することでより理解が進むテストの七原則＠ヘッツェル
原則 壱• セグメンテーション

原則 弐• 可テスト性を持つ設計

原則 参• シミュレーション

原則 四• サンプリング

原則 五• 論理的簡約

原則 六

• 標準化

原則 七

• 自動化
ウイリアム.C.ヘッツェル著 「プログラム・テスト法」 (1974) 近代科学社刊) より引用

こっちも見てみると良いですよ！

プログラム・テスト法 (1974)
ウイリアム.C.ヘッツェル著/近代科学社刊

日本で初めてのソフトウェアテストの書籍。
引用元の翻訳本。残念ながら絶版…。この書
籍を紹介したスライドがSlideShareで公開されているのでそれを読むと良いかと思います。

ソフトウェアテストがおもしろい理由(2008)
秋山浩一 著 / SlideShare

富士ゼロックスの秋山さんがWACATEという若手テスト技術者向けワークショップで講演した際の資料。ヘッツェルのテストの原則をまとめていて参考になります。

テストプロセス＠JSTQB「テスト技術者資格制度Advanced Levelシラバス日本語版テストマネージャ Version 21012.J02」を元に図にしたもの

テストに必要な一連の流れを知る！

テスト技術者資格制度 Foundation
Levelシラバス日本語版

テスト技術者資格制度 Advanced Level
シラバス日本語版 テストマネージャ

JSTQB FL シラバス (PDF)

JSTQB FL シラバス (PDF)

まずは、FLシラバスのテストプロ
セスを読んで概観を把握しよう。場
合によっては先の副読本も一緒に！

FLは割とざっくりとしているので、より詳しく知るためにはALのシラバスも読んでみましょう！

具体的な例がないとイメージが沸かないという方には…

クリティカル・テスト・プロセス(CTP)という12個からなるテストプロセスを解説した書籍。
仮想プロジェクトを例にした具体的な記述のため、イメージしやすい。
また、CTPの中で作成している中間成果物などのテンプレート(Word/Excelなど）が公開されておりダウンロード可能(但し英語)

ソフトウェアテスト12の必勝プロセス
レックス・ブラック著/日経BP社刊

レックスのクリティカルテストプロセス
実行するテスト作業を正しく理解する

要因を確保し、テストを準備する•テストの諸状況を理解する•品質リスクを分析する•テストの見積りをする•テスト計画を立てる• テストチームを編成する• テストシステムを設計し、実装する

計画

準備
テスト
プロセス

手直しと改善を進める•バグを報告する•テスト結果を報告する•変更点を管理する

改善

実行

テストを実施し、その結果を収集する• テストリリース版を入手する• テストを行って結果を追跡する

図：テストプロセス / Rex Black著「ソフトウェアテスト12の必勝プロセス」P-6より

テスト分析は現在進行形で発展している分野です！

要求分析アーキ設計

詳細設計

実装

実行

報告

評価

「SSFに基づくテスト技術スキルフレームワーク スキル標準 -テストプロフェッショナルの戦略的育成に向けて- Version1.0」より

特にこの分野は日本がリードしており現在進行形で切磋琢磨している分野。成果物も公開されていたりするので、具体的なものを見たい知りたいという人にも最適！

テスト分析-設計のとっかかり！

マインドマップから始める
ソフトウェアテスト (2007)池田暁・鈴木三紀夫著 /技術評論社 刊

テストの様々な活動をマインドマップを使って分析している。テスト設計技法を知ってるけど上手く使えないという人は、設計前の分析のとっかかりとしてこれを読んでみて。
ただ、現在は新品での購入は難しいかも…。

体系化された方法論 進化中 を知りたい人！
()• VSTeP• 西康晴氏（電気通信大学）• PDFを公開• HAYST• 秋山浩一氏（富士ゼロックス）• 書籍2冊• ゆもつよメソッド• 湯本剛氏（日本HP）• バリ本• ソフトウェア・テストプレス Vol.10 特集1

分析したら設計次は設計
テスト設計技法の分類

同値分割法

テ
ス

仕様ベースのテスト設計技法
 仕様化したモデルを基にしてテストケースを作成する、体系的なテスト設計技法。
 モデルに対応したテスト設計技法を用いる。
 ブラックボックステストとも呼ばれる。

境界値分析
ﾃﾞｼｼﾞｮﾝﾃｰﾌﾞﾙﾃｽﾄ
状態遷移テストト

ユースケーステスト

設

その他

計
技
法の分
類

構造ベースのテスト設計技法
 ソフトウェアやシステムの構造を基にしてテストケースを作成する体系的なテスト設計技法。
 対象となる構造をどれだけ網羅したかというカバレッジを測って実施する。
 ホワイトボックステストとも呼ばれる。

経験ベースのテスト設計技法
 テスト担当者のスキル、知識、経験を基にテストケースを作成する、体系的ではない（経験に基づいた）テスト
ケース設計技法。
 ステークスホルダの知識、過去の類似した欠陥なども情報源となる。

ステートメントテスト
デシジョンテスト
その他

エラー推測
フォールト攻撃その他「テスト技術者資格制度Foundation Levelシラバス」を元に図にしたもの

ブラック/ホワイトボックスはこんなイメージです
入力

出力

対象の中身が見えない＝ ブラックボックス

入力

void hoge(int i){
float x2;float x=x2;y){void leap_year(intfor(;i<100;i++)while(1){x=(x+x2/x)/2.0;
printf("Year= ");int fizzbuzz(void){
printf("%f",scanf("%d",&y); x);
int i; if(y%4==0}&& y%100!=0 ||for(i= 1; i <= 100; i++){
y%400==0)
if(i % 15== 0)
printf("LeapYear", y);printf("FizzBuzz¥n");else
else if(i%3==0)
printf("Not Leap Year¥n",
printf("Fizz¥n");y);else} if(i % 5 == 0)}printf("Buzz¥n");else
printf("%d¥n", i);}return 0;}

出力

対象の中が見える＝ ホワイトボックス

テスト設計技法の最初に読むのにお勧めソフトウェアテスト技法ドリル

はじめて学ぶソフトウェアのテスト技法

秋山浩一著/日科技連出版刊

リー・コープランド著/日経BP刊

代表的なブラックボックステストの技法を取り扱った書籍。非常に分かり易い文章でお勧め。特に様々な技法を次元という観点でまとめているところが秀逸。

ブラックボックステストとホワイトボックステストの様々なテスト設計技法を掲載。
いろいろなテスト設計技法を知るとっかかりとしてお勧め。

将来的にはこれを読むべし！！

ソフトウェアテスト技法
ボーリス・バイザー著/日経BP刊

バイザーによるテスト設計技法を詳細に説明した書籍。ホワイトボックステストのテスト設計技法をしっかり学びたいならこれしかない！ブラックボックステストについても書かれている。

実践的プログラムテスト入門
ボーリス・バイザー著/日経BP刊
バイザーのブラックボックステスト本。右の書籍からブラックボックステストのみに特化した書籍。いかんせん、ちょっと右の書籍は読むのがハードな部分もあるので…

テストプロセスを通じてツールの活用しよう！

一連のテストプロセスでは様々な活動があり、効率や効果の観点から様々なツールを活用します。
様々なツールの情報をまとめたガイドがPDFで公開されているので参考にしてみましょう。
特に、現在のプロセスの習熟度に沿った導入をアドバイスしてくれる診断
ツールが面白い！
テストツールまるわかりガイド
ASTERテストツールWG著
PDFダウンロード

テストレベルによる分類「小さなことからコツコツと」――― 西川きよし
大受け入れテスト
システムテスト
統合テスト
コンポーネントテスト
小実装終わったらテストって乱暴すぎよね
要件定義
基本設計

詳細設計
実装
テスト

上流工程と下流工程の対応関係
ユーザ要求

受け入れテストシステム要件システムテスト

基本設計

統合テスト

コンポーネント
テスト

詳細設計

実装

対応関係

テスト活動は直ぐにはじめよう！
テスト活動の開始

要求定義

システム要件受け入れテストの実施

システムテストの計画

基本設計

システムテストの実施

統合テストの計画

統合テストの実施

コンポーネント
テストの計画詳細設計

コンポーネント
テストの実施デバッグと修正デバッグと修正デバッグと修正デバッグと修正

実装

対応関係サイクル:テスト、デバッグ、修正、再テスト

From The W-MODEL Strengthening the Bond Between Development and Test by Andreas Spillner

テストレベルの比較
テストレベル

内容

コンポーネント
テスト

分離してテストが可能な
ソフトウェアコンポーネント（部品）ごとに単体で行うテスト

••
•
•
•
•

コンポーネント要件
詳細設計
ソースコードコンポーネントの仕様
ソフトウェアの設計
データモデル など

•
•
•
•
•
•

コンポーネントプログラム
データ変換/移行プログラム
データベースモジュール
モジュール ・オブジェクト
クラス など

統合テスト

テスト済みのコンポーネントやシステムを統合して行うテスト•

ソフトウェア設計もし
くはシステム設計
アーキテクチャ
ワークフロー
ユースケース など

••
•
•
•

サブシステムのデータベース実装
インフラストラクチャ
インターフェース(コンポーネント間/システム間)システム構成・構成データ
OS、ファイルシステム、HWなどのシステムの別の部分との相互処理など

最終的に統合されたシス
テム全体を、実環境（またはそれに準ずる環境）で実施するテスト••••

システム要求仕様もしくはソフトウェア要求仕様ユースケース機能仕様
リスク分析レポート

••
•
•
•

システム、ユーザとオペレーションマニュアル
システム構成・構成データ ・リスク
ビジネスプロセス ・ユースケース
システム動作を高レベルで記述したテキストもしくはモデル
OSとの相互作用/・システムリソースなどの要求仕様

••
•
•
•

ユーザ要件
システム要件ユースケース
ビジネスプロセス
リスク分析シート

••
•
•
•
•

統合が完了しているシステム上のビジネスプロセス
操作と保守プロセス
ユーザ（の利用）手順
書式
レポート
構成データ

システムテスト受け入れ
テスト

開発したシステムがユーザの求めているものに合致しているか確認する（受け入れ可能かどうか判断する）テスト

テスト分析の入力例•••

典型的なテスト対象

テストレベルを学ぶにはこれ！

テスト技術者資格制度 Foundation
Levelシラバス日本語版
JSTQB FL シラバス (PDF)

テストレベルとテストタイプは、押さえておきたいポイント。これもシラバスを読むことで学べる

ISTQBシラバス準拠
ソフトウェアテストの基礎 Foundation Level

ソフトウェアテスト教科書
JSTQB Foundation 第3版
著者多数/翔泳社

著者多数/BNN新社

シラバスの副読本として次の2冊もお勧め。シラバスだけでは理解しきれないところなどはこれで補おう。2冊とシラバスを比較することでより理解が進むテストの自動化は低レベルから！
低低

遅

手動テスト
GUIテスト

費用
対効
果保守性実
行
速度

APIレベルのテスト
ユニットテスト/コンポーネントテスト

高高速「実践アジャイルテストのテスト自動化のピラミッドを元に作成（オリジナルから改変している）

コンポーネントレベルでの自動化
コンポーネントテスト(ユニットテスト)
レベルでの自動化は、xUnitなどのテストフレームワークを使って自動化される。

使うユニットテストフレームワークや開発言語など様々なので自分の状況に合ったものを選択するとよい。
テスト開発駆動(TDD: Test DrivenDevelopment)のアプローチが有名。

テスト駆動開発入門
ケント・ベック著/ピアソンエデュケーション刊
TDDの提唱者ケント・ベックの書籍。決して読みやすいわけではないが、やはり原点として読んでおきたいところ。ピアソン・エデュケーションの技術書は廃刊になったのでこれも古本になるか？

各地域のコミュニティーが中心となって全国各地でTDD Boot Camp開催しているので、これに参加して体験してみるのもお勧め！

統合レベルでの自動化
統合テスト(インテグレーションテスト)
レベルでの自動化に関しては、CI環境を用いることが一般化してきた。

継続的インテグレーション(CI:Continuous Integration)は、日毎、時毎、コミット毎といった短いサイクルでテストを走らすことで、統合に関係する問題を素早く見つけることを目的としている。

継続的インテグレーション入門
著者多数/日経BP刊
特定のCI環境に特化したものではなく、概念レベルからしっかりと解説している書籍。特定のCI環境に特化した書籍と合わせて読むと効果的かと。

オープンソースではJenkinsが有名。商用のCIアプリやサービスなども存在するので、自分のチームにあったものを選択するとよい。

システムレベルでの自動化
コンポーネントテストや統合テストレベルでのテスト自動化は一般化してきたものの、システムテストレベルはこれからか。

そんな方には、最近出たばっかりのこちらの書籍をオススメします。
また、この書籍を翻訳したテスト自動化研究会が開催したシステムテスト自動化カンファ
レンス(2013, 2014)関係の資料も公開されているので参考にすると良いかと。
もし2015も開催するなら参加をお勧め！
シスエムテスト自動化標準ガイド
マーク&ドロシー著/翔泳社刊
テスト自動化研究会が翻訳したマーク&ドロシーのSoftware Test Automation。邦題はシステムテスト全般を指しているように見えるが、主に機能テストの自動化に関してが主。非機能はいくつか書籍があるもののなかなか少ない…

テストレベルのによる分類(再掲)「小さなことからコツコツと」――― 西川きよし
大受け入れテスト
システムテスト
統合テスト
コンポーネントテスト
小テストは機能のテストだけじゃない！
テス
トタ

機能テスト

セキュリティテスト

ソフトウェアの機能（What）に着目したテストタイプ

その他
性能テスト

ロードテスト

非機能テストソフトウェアの非機能的な特性（How）に着目したテストタイプ

ストレステスト
使用性テスト
保守性テスト
信頼性テスト
移植性テストイプ

構造テストのソフトウェアの構造やアーキテクチャに着目したテストタイプ

その他
条件テスト
ステートメントテスト
パステスト
判定条件テスト分類

相互運用性テスト

複合条件テスト

変更部分のテストその他

欠陥が正しく修正されるか確認するテストと変更が他に悪影響を及ぼさないか確認する
テスト

回帰テスト

確認テスト(再テスト)

様々な品質特性の何をテストで検証するの？
システム/ソフトウェア製品品質

機能適合性

性能効率性

互換性

• 機能完全性• 機能正確性• 機能適切性• 時間効率性• 資源効率性• 容量満足性• 共存性• 相互運用性

使用性

信頼性

セキュリティ

適切度認識性
習得性
運用操作性
ユーザエラー
防止性• ユーザインターフェース快美性• アクセシビリ
ティ

• 成熟性
• 可用性
• 障害許容性(対故障性)• 回復性• 機密性• インテグリティ• 否認防止性• 責任追跡性
• 真正性

•
•
•
•

保守性

••
•
•
•

移植性

モジュール性 • 適用性
再利用性
• 設置性
解析性
• 置換性
修正性
試験性

“製品品質特モデル “ from “JIS X 25010:2013” 図4

情報としてはこっちの方が豊富だがちと古い
外部及び内部品質

機能性

信頼性

使用性

効率性

保守性

移植性

合目的性
正確性
相互運用性
セキュリティ

成熟性
障害許容性
回復性

理解性
習得性
運用性
魅力性

時間効率性
資源効率性

解析性
変更性
安定性
試験性

環境適応性
設置性
共存性
置換性

機能性標準適合性

信頼性標準適合性

使用性標準適合性

効率性標準適合性

保守性標準適合性

移植性標準適合性

Figure. “外部及び内部品質のための品質モデル” from JIS X 0129-1:2003 ソフトウェア製品の品質 –第1部:品質モデル P-9 図4より

テストタイプについてはコレ！
特に非機能テストに関しては、各品質特性毎に専門性の高いテストが必要になってくる。
そのため、概要的なエントリーポイントとしてはJSTQBのシラバスをお勧めするが、具体的なそれぞれのテストタイプについては、個別に詳細に当たる必要がある。
また、このドメインに関しては情報が充実しているわけではない。専門性が高いといいうことは、逆説的に一般化しにくくドメインに依存しやすいとも言える。
テスト技術者資格制度 Foundation
Levelシラバス日本語版
JSTQB FL シラバス (PDF)

テストレベルとテストタイプは、押さえておきたいポイント。これもシラバスを読むことで学べる

様々な品質要素のエントリーポイント
日本発のソフトウェア品質に関する知識体系(BOK: Body Of Knowledge)。最近第2版がリリースされた。

BOKといえばPMBOKが有名であるが、PMBOKがガイドライン的に読めるのに対し、SQuBOKは辞書的に読める。
様々な品質やテストに関するトピックスの概要と参考文献が示されているので、なにか分からない事があった場合は、まずSQuBOKに当たって概要を把握し、詳細な情報を参考文献に当たると良い。

ソフトウェア品質知識体系ガイド
SQuBOK Guide V2
SQuBOK策定部会著/オーム社刊

樹系図概観(上位4層まで)
Guide to Software Quality Base of Knowledge
1．ソフトウェア品質の基本概念
1.1 品質の概念

2． ソフトウェア品質マネジメント

3．ソフトウェア品質技術

組織レベルのソフトウェア品質マネジメント

1.1.1 品質の定義(品質の考え方の変遷)
1.1.2 ソフトウェア品質モデル
1.1.3 ディペンダビリティ
1.1.4 セキュリティ
1.1.5 ユーザビリティ
1.1.6 セーフティ

1.2 品質のマネジメント
1.2.1 品質コントロール
1.2.2 品質保証の考え方
1.2.3 改善の考え方
1.2.4 ソフトウェア品質マネジメントの特徴
1.2.5 ソフトウェア測定の考え方
1.2.6 ソフトウェア評価の考え方
1.2.7 V&V (Verification ＆ Validation)
1.2.8 検査

2.1 ソフトウェア品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの構築と運用
2.1.1 品質マネジメントシステム
2.1.2 ソフトウェア品質推進活動
2.1.3 品質マネジメント組織

2.2 ライフサイクルプロセスのマネジメント
2.2.1 ライフサイクルモデル
2.2.2 プロセスモデル

2.3 ﾌﾟﾛｾｽｱｾｽﾒﾝﾄ・ﾌﾟﾛｾｽ改善のマネジメント
2.4 検査のマネジメント
2.5 監査のマネジメント
2.6 教育・育成のマネジメント
2.7 法的権利・法的責任のマネジメント
プロジェクトレベル(共通)のソフトウェア品質マネジメント

2.8 意思決定のマネジメント
2.9 調達マネジメント
2.9.1 バートナーとのコミュニケーション

2.10 構成管理2.10.1 変更管理
2.10.2 バージョン管理
2.10.3 不具合管理

2.11 リスクマネジメント
2.12 プロジェクトマネジメント全般
プロジェクトレベル(個別)のソフトウェア品質マネジメント

2.13 品質計画のマネジメント
要求分析のマネジメント(*1)(アーキテクチャ設計)のマネジメント(*1)
実装のマネジメント(*1)
2.14 レビューのマネジメント
2.15 テストのマネジメント
2.16 品質分析・評価のマネジメント
2.16.1 製品品質の分析・評価
2.16.2 プロセスの分析・評価

2.17 運用・保守のマネジメント
2008/01/18

3.1 メトリクス
3.1.1 測定理論
3.1.2 プロダクトメトリクス
3.1.3 プロセスメトリクス

3.2 品質計画の技法
3.3 要求分析の技法
要求獲得(*1)
3.3.1 品質要求定義(アーキテクチャ)設計の技法(*1)
実装の技法(*1)
3.4 レビューの技法
3.4.1 レビュー方法
3.4.2 仕様・コードに基づいた技法
3.4.3. フォールトに基づいた技法
利用に基づいた技法(*1)

3.5 テストの技法
3.5.1 経験および直感に基づいた技法
3.5.2 仕様に基づいた技法
3.5.3 コードに基づいた技法
3.5.4 フォールトに基づいた技法
3.5.5 利用に基づいた技法
3.5.6 ソフトウェアの形態に基づいた技法
3.5.7 組み合わせの技法
3.5.8 リスクに基づいた技法
3.5.9 テスト技法の選択と組み合わせ
3.5.10 テスト自動化技法

3.6 品質分析・評価の技法
3.6.1 信頼性予測に関する技法
3.6.2 品質進捗管理に関する技法
3.6.3 障害分析に関する技法
3.6.4 データ解析・表現に関する技法

3.7 保守・運用の技法

この樹形図はV1でV2のものではないので注意注意事項！

テスト技術者に必要なスキル領域
テストスキル

ソフト
スキル

ITスキル

ドメイン知識Fig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf)

テストスキル

ソフト
スキル

ITスキル

ドメイン知識Fig. “Tester Skillspace” by Stuart Reid from JaSST Tokyo’14 Session Material (H8-2-2.pdf)