テスト設計
チュートリアルちびこん編

2021年度版
ソフトウェアテスト技術振興協会（ASTER）© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

1© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

2

チュートリアルの流れ
1. テスト観点を整理して網羅的に挙げよう
2. テストフレームを考えよう
3. テストコンテナとその間の関係性を考えよう
4. テスト観点からテスト値を網羅しよう

5. テスト開発を意識して進めてみよう© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

3チュートリアルの流れ
1. テスト観点を整理して網羅的に挙げよう
2. テストフレームを考えよう
3. テストコンテナとその間の関係性を考えよう
4. テスト観点からテスト値を網羅しよう

5. テスト開発を意識して進めてみよう© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

4以下のプログラムをテストするのに充分と思われるテストケースを網羅してください• このプログラムは、入力ダイアログから３つの整数を読む• この３つの値は、それぞれ三角形の三辺の長さを表すものとする• プログラムは、三角形が不等辺三角形、二等辺三角形、正三角形のうちのどれであるかを示すメッセージを表示する
Glenford J. Myers著 「ソフトウェア・テストの技法 第2版」P-2より引用© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

5同じ机の人と共有してみましょう© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

6参考書による解答例（14点満点）
1. 有効な不等辺三角形

9. 二辺の和がもう一辺より小さい

2. 有効な正三角形

10. 二辺の和がもう一辺より小さい
際の三種類の辺の組み合わせ

3. 有効な二等辺三角形

4. 有効な二等辺三角形の際の三種類の辺の組み合わせ

11. 三辺がゼロ
12. 整数でない辺

5. 一つの辺がゼロ

13. 辺の数が三つ以外

6. 一つの辺が負の値

14. 各ケースに
期待結果を
示している

7. 二辺の和がもう一辺と等しい

8. 二辺の和がもう一辺と等しい際の三種類の辺の組み合わせ© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

7© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

8実際にテストケースを網羅するのは難しい…
• 仮に簡単な仕様であってもテストケースを網羅することは難しい• 人によってテストケースの表現（テストケースが含む要素。
例えば具体的な値、期待結果、前提条件、ケースの意図など）も異なる• そもそも導出しているテストケースが何をどれだけ網羅しているか、
テストケースから読み取るのは困難• 網羅的なテストだけではなく、ピンポイントにバグを狙いだすようなケースもありえる© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

9先ほどの例でテストすべきことを少しまとめてみる(構造化)
Before
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

有効な不等辺三角形
有効な正三角形
有効な二等辺三角形
有効な二等辺三角形の際の三種類の辺の組み合わせ一つの辺がゼロ一つの辺が負の値
二辺の和がもう一辺と等しい
二辺の和がもう一辺と等しい際の三種類の辺の組み合わせ
二辺の和がもう一辺より小さい
二辺の和がもう一辺より小さい際の三種類の辺の組み合わせ
三辺がゼロ整数でない辺辺の数が三つ以外各ケースに期待結果を示している

After
1. 三角形の形に関するテスト• 三角形が成立する場合のテスト• 有効な不等辺三角形• 有効な二等辺三角形• 有効な正三角形• 三角形が成立しない場合のテスト• 直線になってしまう場合• 二辺の和がもう一辺が同じ• 面を構成できない場合• 二辺の和がもう一辺より短い• 長さが0の辺がある
2. 辺の組み合わせに関するテスト• 三種類の辺の組み合わせ
3. 入力の仕様に関するテスト• 整数でない辺• 辺の数が三つ以外
4. 期待結果を示してあるかどうか© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

10「テストすべきこと 」を考えると少し網羅しやすくなった気がしますね※※本講では「テストすべきこと」を「テスト観点」と呼ぶこととします

いくつかの点に注意しないと思いつきでは上手く整理してテストケースを挙げることはできません© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

11「テストすべきこと(テスト観点)」の様に抽象化すると見通しが良くなる
•

三角形の形

•

辺の組み合わせ

•

入力の仕様

•

負荷、使う人数、稼働させる時間
•

•

•
•

androidのバージョン、
文字コード

電源コードを抜く想定されるバグ••

入力しやすいか

障害対応性
•

•

クロスサイトスクリプティング

操作性•

動作環境、互換性••

signed int

セキュリティ
•

内部設計

•
•

連打、100万人、1ヶ月連続稼働•

メモリーリーク

誰が使うか
•

子供

期待結果

© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

12

的に観点を整理していく方法
三角形の種類

正三角形(1, 1, 1)

二等辺三角形(2, 2, 2)

不等辺三角形(3, 3, 3)© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

13

的に観点を整理する方法
三角形

成立

正三角形

直線

二等辺三角形

不成立

不等辺三角形© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi14実際にはトップダウンとボトムアップをさせながらテスト観点を網羅していく© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

15テスト観点を整理した例
電子メール

GUI

機能

動作環境

ネットワーク

OSの種類

データ

プラットフォーム
OS

ハードウェアOSのバージョン

IEのバージョン© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

16基本的なテストの方針

網羅

ピンポイント「隅から隅までテストする」「ヤバいところをテストする」• 漏れなくテストを行う• 動作実績を積み上げて品質を保証する「保証型」のテスト

テストはと• バグが起きそうな所を狙ってテストする• 少ない手間で沢山危険なバグを検出する「検出型」のテストの2種類を適切に組み合わせて行う© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

17© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

18

ラルフチャート
Noise/Active Noise
誤差号因子 z{z1, z2, z3, …}
az{az1, az2, az3, …}

Input
信号因子
M{M1, M2, M3, …}

対象

Read

Output
レスポンス R

Write

内部変数の組み合わせ（＝State）
信号因子 m{m1, m2, m3, …}「高信頼化ソフトウェアのための開発手法ハンドブック」より引用© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

19Tiramisで使用している基本構造構成要素「https://twitter.com/mkoszk/status/509922586294112256 」より引用© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

20論理的機能構造「ゆもつよメソッドにおけるテスト分析とテスト設計」より引用
一部変更

テスト実行
入力
外部観察
できる仕様

出力

FeatureFeatureInput Adjustment

FeatureOutput Adjustment

Conversion
内部に
関わる仕様

Storage

Support
機能組み合わせ

AUT外部Interactive

External© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

21

「テスト観点」といっても様々な抽象度がある？

「三角形が成立する場合」がテストケースだよ© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

22

本講では以下の様に整理します◼ 「3」のような具体的なものをと呼ぶ◼ 「辺の長さ」のようにテスト観点の最も具体的なものをと呼ぶ◼ テストパラメータの特定の要素がテスト値となる◼ 「 (3,3,3) を 入 力 す る と 正 三 角 形 と 表 示 さ れ る 」 のようにである◼ 「有効な正三角形」から「ドメイン知識」まで、や、をと呼ぶ◼ テストパラメータやテスト観点をとも呼ぶ◼ マ イ ン ド マ ッ プ や UML ツ ー ル な ど を 用 い る と 描 きやすいが一覧表やマトリクスでも構わない(表現は自由）© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

23

用語集

用語の定義

用語

意味

テスト観点

テストすべきこと。テストパラメータや、テストパラメーターを抽象化したもの

テストフレーム

テストケースの構造。テストケースを構成する複数のテスト観点

テストコンテナ

テスト観点やテストフレームをまとめたもの

テストアーキテクチャ

テストコンテナ間の関係性（前後関係や並列関係や依存関係や包含関係など）を決めたもの

テストパラメータ

テスト観点の最も具体的なもの

テストモデル

テストパラメータの属性（範囲タイプ、一覧表タイプ、マトリクスタイプ、グラフタイプの4つ）

テスト値

テストパラメータが取る具体的な値（数値や経路などテスト値の集合でテストパラメータを網羅する）

テストデータ

テスト値をテスト手順として実装する際に実際のデータとして定義されるインスタンス

テスト条件

テスト観点やテストフレームの別称。JSTQBやISO/IEC/IEEE 29119などで使われている表現

注：これらの用語およびこれらの用語に基づく考え方は本チュートリアルやテスト設計コンテストの文脈における用語の定義です。JSTQBやISO/IEC/IEEE 29119などの文脈とは異なる点に注意していください。

© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

24テスト観点には様々な抽象度があるので整理して網羅しましょう© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

25仕様書の文･単語を単に書き写してもテスト
観点は網羅できない

テスト観点は特定の則面だけではなく、多面的に挙げる必要がある

テスト観点を挙げるだ
けでバグが見つかることもある

仕様書は通常不完全で、特に致命的なバグは仕様書に書かれていな
いテスト観点でしか見つからない
ことがある

入力に関するテスト観点だけを挙げたり、期待結果やその観測に関するテスト観点だけを挙げたり、品質特性だけをテスト観点として採用すると、漏れが発生する

開発者が考慮していなかった
テスト観点はバグの温床であり、テストしなくてもバグだと分かることも多々ある

これまでに挙げたテスト観点は、みなさんの組織の仕様書にすべて書いてありましたか？

期待結果に関するテスト観点を挙げて詳細化すると、仕様の抜けが分かることがある※テストケースにも期待結果を必ず書くのを忘れないこと。「正しく動作すること」は期待
結果ではない！

© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

26

テスト観点の導出結果は実施者によって異なります！
とはいえ、どうやって分析するの？
そもそも「全数テストは不可能 」ですし「テストは条件次第」なのでとっかかりは？
テストが一意的に収束することはなく、絶対的なテスト観点モデルもありません※1※2

下記についてはJSTQB Foundation Levelのシラバスを参照のこと※1: テストの七原則の一つ。すべてをテストすることは現実的に不可能である(組み合わせも考慮するとすぐにテストが発散する）。そのため、テストはサンプリングになるため、何をテストしてなにをテストしないかが重要になる。
※2: テスト七原則の一つ。条件が異なればテストの方法や内容もことなる。コンテキストにあったテストを実施するためにも、テストを説明できることが重要。
© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

27

どんなテストをするのかを利害関係者とコンセンサスを得ることが重要であり 、そのためにテストを説明する必要ある© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

28ピンポイント型のテスト観点もきちんと挙げよう© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

29

どれだけ適切なピンポイント型のテスト観点を挙げられるかは、テストの質を示す重要な要素
後工程でバグを引き起こしそうな罠や弱点

起きて欲しくないことバグ

危険事象やハザードなど様々

絶対に入って欲しくないバグ

例)顧客データ喪失、出火、顧客のお金に関わるデータの計算ミス例） バッファオーバーフロー、
クロスサイトスクリプティング、
SQLインジェクション

構造が歪んでいるところや分かりにくいところ
全体が1対1に対応しているが実は一部
のみ多対多になって入り組んでしまっているところ

HAZOPや意地悪漢字などを仕様や設計にぶつけて想起

よく作り込んでしまうバグ

例） もし辺の入力がなかったら？
（ガイドワード「ない」）

例）小数の丸め誤差、メモリの解放忘れ、
例外に対する処理忘れ、初期化忘れ

プラットフォームや
言語仕様に潜む罠や弱点
過去の技術的負債により、互換性のために残っているOSのAPIMISRA-Cのいくつかの項目（if文では=で変数に代入でき、値を持ってしまう、など）© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

30ソフトウェアHAZOPのためのより詳しいガイドワード
強度

強い

弱い

多い

少ない

長い

短い

上限

下限

タイミング

範囲

早く

遅く

広く

狭く

多く

少なく

多く

少なく

高く

低く

拡張

増加

減少

広い

狭い

余分

不足

最大限

最小限

数量
頻度
ある

ない

ゼロ

高い

低い

頻度
種類

多種

小種

多い

少ない

程度

いつも

たまに

規模

大きい

小さい

早く

遅く

回数

多く

少なく

距離

遠い

近い

長く

短く

接続

つなぐ

切り離し

方向

上へ

下へ

高い

低い

超過

不足

高く

低く

遠く

近く

切り替え

時期
速度

速い

遅い

広く

狭く

高速

低速

長く

短く
負荷

緩

急

許容

禁止

設定
金額

さきに

あとで

同時に

並行に

順序

位置

必須

任意

早く

遅く

大きい

小さい

逆転

反復

鈴木三紀夫さん、秋山浩一さんがご作成

限界

挿入© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

31ソフトウェアHAZOPのためのより詳しいガイドワード
原則

例外

正常

異常

全体

部分

通常

非通常

全部

一部

通常

例外

主

従

定期

臨時

正

誤

通例

異例

常例

無事

有事

平時

非常時

緊急時

公正

不正

定常

可変

任意

強制

尋常

非常

基本

詳細

一般

特別

完了

未完

普通

特殊

有効

無効

並

特異

起動

停止

主要

準正常

代替

鈴木三紀夫さん、秋山浩一さんがご作成© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi32和風のガイドワード「意地悪漢字」

鈴木三紀夫さんがご作成© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

33チュートリアルの流れ
1. テスト観点を整理して網羅的に挙げよう
2. テストフレームを考えよう
3. テストコンテナとその間の関係性を考えよう
4. テスト観点からテスト値を網羅しよう

5. テスト開発を意識して進めてみよう© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi34☑ （3,3,3）を入力して動作すること☑ iPhone6s/iOS9.3.2で（3,3,3）の入力を1ヶ月連続で行っても「有効な正三角形」☑ （3,3,3）を入力して「有効な正三角形」とと見やすく表示され、メモリリークが起きな表示されること
いこと☑ iPhone6s/iOS9.3.2で（3,3,3）を入力☑ iPhone6s/iOS9.3.2 上 の Safari
して「有効な正三角形」と表示されること（3,3,3）の入力を子供が1ヶ月連続で連打☑ iPhone6s/iOS9.3.2で（3,3,3）を入力しても「有効な正三角形」と見やすく表示さして「有効な正三角形」と見やすく表示されれ、メモリリークが起きないことること

人によって簡単なテストケースもあれば複雑なものもある© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

35テストケースの構造(テストフレーム)を考えよう

同じボタンでも、それぞれ色や形や模様が違うように、
テストケースも単純なものから複雑なものまで色々ありうる© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

36テストフレームの単純な例と複雑な例
三辺の長さ

連続稼動時間

三角形種別
判定機能

入力頻度

期待結果
三角形種別
判定機能

ユーザ種別

期待結果

三辺の長さ
ブラウザ

視認性

狙っている
バグ
OS

ハードウェア

例えば同じ三角形の種別判定機能をテストするといってもそのテストの関心事はテストフレームによって異なります© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

37テストフレームに沿ったテストケースの構造を作成する
三角形種別
判定機能

三辺の長さ

期待結果

ブラウザ

ID

三辺の長さ

ブラウザ

期待結果

1

(3, 4, 5)

Edge「不等辺三角形」と表示される

2(3, 3, 4)

Edge「二等辺三角形」と表示される

3(3, 3, 3)Edge「正三角形」と表示される

…

...

...

...
© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

38

チュートリアルの流れ
1. テスト観点を整理して網羅的に挙げよう
2. テストフレームを考えよう
3. テストコンテナとその間の関係性を考えよう
4. テスト観点からテスト値を網羅しよう

5. テスト開発を意識して進めてみよう© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

39テストコンテナ（テスト観点やテストフレームをまとめたもの）
動作環境テスト
ブラウザ
OS

OS
ハードウェアブラウザ
OS

OS
ハードウェアネットワーク種別

ネットワーク種別

低電力モード/通常モード

低電力モード/通常モード

テスト観点やテストフレームが増えてきたら、「テストコンテナ」に
うまくまとめあげると見通しのよいテスト設計になる© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

40テストコンテナにも様々な種類がある
テストレベルコンポーネントテスト
統合テスト
システムテスト
受け入れテスト など

テストタイプ
負荷テスト
ストレステスト
構成テスト
セキュリティテスト など

テストコンテナは各組織で定められたものをそのまま使うことも多いため、あまり自分たちでは設計したことがないかもしれない• たとえば「社内標準で決まっている」「過去プロジェクトのテストコンテナを再利用している」など• そのため、よく意味の分からないテストコンテナを適当に解釈して使っていることもある• もしくは、意識せずに自分たちでテストコンテナを定義してしまっている場合もある
自分たちで無意識にテストコンテナを定義してしまっているくらいなら、きちんと設計した方がよい

テストサイクル
1回目の機能テスト
2回目の負荷テストなど

その他
RAT/FAST/TOFT/FET
手動テスト/自動テスト
etc

本来は、それぞれの開発プロジェクトにおけるテストごとに、改めてテストコンテナを設計する方がうまくまとまる
どんなテストコンテナを用いるかによってテスト設計の良し悪しが変わるので、なぜこれらのテスト
観点やテストフレームをまとめてこのテストコンテナにしたか、はきちんと説明できないといけない

テストコンテナの責務の分担と呼ぶ© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

41

既に存在したり一般に紹介されたりしているテストコンテナを参考にして、なぜそのようにまとめたのか、リバースエンジニアリングしてみることから初めてみよう

テストレベルの例

テストタイプの例• 単体テスト/ユニットテスト• 結合テスト/統合テスト• システムテスト/総合テスト• 受け入れテスト など

Ostrandの4つのビュー
ユーザービュー
仕様ビュー
設計・実装ビュー
バグビュー

•
•
•
•

テストタイプの例

テストタイプの例

Myersの14のシステムテストカテゴリ

ISO/IEC 9126の品質特性※

ボリューム/ストレス/効率/ストレージ/
信頼性/構成/互換性/設置/回復/操作性/
セキュリティ/サービス性/文書/手続き

機能性/信頼性/使用性
効率性/保守性/移植性※現在はISO/IEC 25000（SQuaREシリーズ）に置き換えられている© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

42

よいテストコンテナってどんなものだろう？

が低い
例えば、結合度の低いテストコンテナは、
テストコンテナ間の依存性といった関連性が低く、他のテストコンテナの影響を受けにくい。一般的に結合度は低いほうが良く、テストコンテナ間の関連性を最小化するとよいが高い
例えば、凝集度の高いテストコンテナは、
テストコンテナ内の要素の関係性が高く、テストコンテナの意図が明確で分かり易く多義的ではない。一般的に凝集度は高いほうが良く、テストコンテ
ナ内の関連性を最大化するとよい

低結合度、高凝集度を目指し、テストアーキテクチャ設計の品質特性(e.g. 保守性、自動化容易性、環境依存性)を高めていくとよい© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

43テストコンテナの関連性をモデリングする
単体テスト

結合テスト

構成テスト

呼びだし
テスト

例外テスト

割り込み
テスト

MBCS
テスト

共有メモリ
テスト

配列境界
テスト

デバイス
制御テスト

※図はあくまで表現方法の一例であることに注意

統合テスト
サイクル1

サイクル2

機能
テスト

機能
テスト

負荷
テスト

負荷
テスト

動作環境
テスト

リグレッション
テスト

セキュリティ
テスト© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

44テストアーキテクチャとは？

テストコンテナ間の関係性（前後関係や並列
関係や依存関係や包含関係など様々）を決めたものを「テストアーキテクチャ」と呼ぶ© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

45テストアーキテクチャを考える意味
テストアーキテクチャを描くことで、テストの全体像を俯瞰しやすくなる• 通常はテスト戦略やテスト計画書に文章で記述されているため、全体像を俯瞰しにくくなっている• UMLツールなどを用いると描きやすいが、自然言語の文章や一覧表、マトリクスでも構わない

後工程や次プロジェクトでテストしやす
いようにテストコンテナをまとめ前後関
係や並列関係を考える必要がある• テストコンテナをまとめている段階で、コンテナごとのテストの厚みやコンテナ間のバランスを考える必要がある• どんな責務のテストコンテナをどんな順序で並べるかによってテスト設計の良し悪しが変わるので、なぜこのテストコンテナをこの厚みでこの順序に並べたか、はき
ちんと説明できないといけない

テストコンテナを適切に配置しないと、開発がやり直しになるような不具合が出荷間際に見つかったりする羽目になる• 最後の最後にまとめて性能テストを行うと、期待した性能よりもかなり遅かった場合にシステムアーキテク
チャ設計からやり直さなくてはならない事態が発生することがある• 開発がやり直しになるような不具合が出てしまうような基本的な性能テストでなく、それに関わるテスト観点だけに責務を分担させた基本的な性能テストコンテナ
をテストの初期段階から反復的に拡張しながら行っていくようなテストアーキテクチャを設計していれば 、早いうちにそのような不具合を防げていたかもしれない

テストコンテナ間の関係性は様々だが、最初の1歩はまず順序性を考えてみよう© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

46

チュートリアルの流れ
1. テスト観点を整理して網羅的に挙げよう
2. テストフレームを考えよう
3. テストコンテナとその間の関係性を考えよう
4. テスト観点からテスト値を網羅しよう

5. テスト開発を意識して進めてみよう© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

47

テスト観点からテスト値を網羅しよう①

テスト観点がどのタイプのテストモデルなのかを見極める②

テスト観点を十分詳細化してテストパラメータを導く③

網羅基準（カバレッジ基準）を定める④

定めた網羅基準でテストパラメーターを網羅するようにテスト値を設計する© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

48

テストモデルには4つある

範囲タイプ

一覧表タイプマトリクスタイプ

グラフタイプ© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

49テスト値には2種類あるので注意する必要がある
テスト値が直接テスト手順の一部（テストデータ）として実施できるもの

テスト値からさらにテストデータを導く必要があるもの

テストパラメータ：

辺の長さ

テストパラメータ：

制御パス

テスト値：

(1, 2, 3)など

テスト値：

パス1(a→b→d)など

テストデータ：

パス1を通るために必要なデータ
セットを指定する

テストデータ：

テスト値と同じ※テストパラメータを網羅するために必要なカバレッジ
アイテムは「データのバリエーション」であり、テスト値として導出するものは様々なデータ。テストデータとしてそのままテスト値を使うことができる。

※ テ ス トパ ラ メータ を 網 羅す る た めに 必 要 な カ バレ ッ ジ
アイテムは「パスのバリエーション」であり、テスト値として導出するのは様々なパス(経路)。テストデータとしては、
特定のパスを通るようなデータを作成する必要がある。
© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

50テストパラメータやテストモデルを
特 定 せ ず に 、 闇 雲 に テス ト ケ ースを挙げるのは質の高いテストではない

テスト観点（テストパラメータ）に対してどのような網羅基準をもった
テ スト ケ ー スの セッ ト で あ る の かを
しっかりと説明できる必要がある© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

51テストモデルには4つある

範囲タイプ

一覧表タイプある連続した範囲を意味する
マトリクスタイプ
グラフタイプ
テスト観点を網羅する時に用いる
例) 辺の長さ（0以上65535以下の整数値）
範囲のことを「同値クラス」と呼び、同値クラスを導出する技法を同値分割法と呼ぶ© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

52

範囲タイプの網羅基準例

代表値網羅
テスト値は少数に収まるが漏れが発生する例) 3

境界値網羅
範囲が開いている(上限/下限が不定)時は自分で定める必要があるがよほど良く検討しないと漏れが発生する 例)0, 65535, -1, 65536

全網羅
漏れはないがテスト値が膨大になるため現実的ではない
例)0, 1, 2, 3, 4, … , 65534, 65535© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

53同値分割法・境界値分析
テストパラメータ：
テストモデル：カバレッジ基準：

有効同値クラス

無効同値クラス

7•••「パスワードの文字列長」「範囲タイプ」「境界値網羅」8

無効同値クラス

16 17

境界値分析や境界値テスト、ドメインテストなど独立した技法として説明されることが多い
有効同値クラスの境界値だけではなく、無効同値クラスの境界値も忘れないこと
範囲が開いている（上限や下限が定まっていない）時は、自分で定める必要があるが、よほどよく検討しないと漏れが発生しやすくなる© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

54テストモデルには4つある

範囲タイプ

一覧表タイプ

複数の要素からなる集合を意味する
マトリクスタイプ
グラフタイプ
テスト観点を網羅する時に用いる
例)ブラウザの種類© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

55

一覧表タイプの網羅基準例

代表値網羅
テスト値は少数に収まるが漏れが発生する例) Chrome

境界値網羅
要素の何らかの属性に順序性がある場合、属性の境界近傍を
境界値要素とみなせるが、よく検討しないと漏れが発生する
例)一番昔にリリースされたブラウザと一番直近にリリースされたブラウザ

全網羅
漏れはなく、通常はテスト値もそれほど膨大にならないこともあるが、組み合わせになったら無視できない程度にテスト値が多くなってしまう
例) Chrome, Firefox, Safari, Internet Explorer, Opera, etc© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

56

一覧表タイプの指標例
テストパラメータ：
テストモデル：カバレッジ基準：
1
2
3
4
5
6

「ブラウザの種類」「一覧表タイプ」「代表値網羅（シェア80%以上）」

ブラウザ

マーケットシェア

網羅率

Internet Explorer
ChromeFirefox
Safari
Opera
その他

43%
30%
13%
3%
1%
10％

43%
73%
86%
89%
90%
100%
© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

57テストモデルには4つある

二つ以上のテスト観点の組み合わせを網羅するときに用いる
範囲タイプ
一覧表タイプ例)OSとブラウザの種類

マトリクスタイプ

グラフタイプ© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

58マトリクスタイプの網羅基準例

代表値網羅
テスト値は少数に収まるが漏れが発生する例)一番新しいOSと一番シェアの高いブラウザ

N-wise網羅
N+1以上の段数による組み合わせの網羅を意図的に無視することによって現実的な数でNまでの組み合わせを全網羅するN-wise系の網羅手法と、
直交配列表を用いた網羅手法がある

全網羅
漏れはないが掛け算によりテスト値が膨大になるため現実的ではない例) OS(Win 10, 8.1, 8, 7, Vista, etc) × ブラウザ(IE, Edge, Firefox, Chrome)※マトリクスタイプでは禁則(無効な組み合わせ)に注意する必要あり © 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

59

ペアワイズテスト
テストパラメータ： 「OS」「ｱｰｷﾃｸﾁｬ」「ブラウザ」の組み合わせ
テストモデル：「マトリクスタイプ」
カバレッジ基準： 「 2-wise網羅（ペアワイズ）」 ※N=2のときペアワイズと呼ぶ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

OS
Windows 10
Windows 8.1
Windows 7
Windows 10
Windows 8.1
Windows 10
Windows 7
Windows 8
Windows 8.1
Windows 8
Windows 7
Windows 7
Windows 8.1
Windows 8
Windows 8
Windows 10
Windows 10

アーキテクチャ
32bit
32bit
32bit
64bit
64bit
64bit
64bit
32bit
32bit
64bit
64bit
32bit
32bit
32bit
64bit
32bit
32bit

ブラウザ
IE11
ChromeFirefoxEdge
IE11
ChromeIE10
Chrome
IE10
Firefox
Chrome
IE11
Firefox
IE10
IE11
FirefoxEdge

2因子網羅100％の場合、以下の組み合
わせのすべてが少なくとも1回以上表中に出現している。

• OSとアーキテクチャ• OSとブラウザ• アーキテクチャとブラウザ
全網羅の場合38通りの組み合わせになるが、ペアワイズでは17通りの組み合わせになる。

ペアワイズの網羅で十分かどうかを検討しないと漏れが発生する。
© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

60テストモデルには4つある

丸と線で図を描けるようなテスト観点を網羅するときに用いる
範囲タイプ
一覧表タイプ例)プログラムのロジック、状態遷移図、シーケンス図、ユーザシナリオ、地下鉄の路線図など

マトリクスタイプ

グラフタイプ※折線グラフや棒グラフのグラフではない
丸と線で図をグラフ、丸をノード、線を
リンク、丸と線による経路をパスと呼ぶ© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

61グラフタイプの網羅基準例

代表パス網羅テスト値は少数に収まるが漏れが発生する

ノード網羅（C0網羅）
グラフのノードを網羅するパスを生成(リンクの漏れ発生)

リンク網羅（C1網羅/0スイッチ網羅）
グラフのリンクを網羅するパスを生成(1スイッチ以上のパスの漏れ発生)

Nスイッチ網羅
Nスイッチのパスを網羅（N+1スイッチ以上のパスの漏れ発生）

全パス網羅
漏れはないがテスト値が膨大になるため現実的ではない© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

62状態遷移テスト
テストパラメータ:
テストモデル：カバレッジ基準：
E1: ログアウト
E2: タイムアウト

S1
ログイン中

「ログインステータスの遷移」「グラフタイプ」「1スイッチカバレッジ」

E5: ロックアウト

S2
ログアウト中S3
ロック中遷移前/遷移後

ログイン中

ログイン中

E1E3+E2E
3

E3: ログイン

ロック中
E1E5＋
E2E5

E3E1+E３
E2＋E5E4

ログアウト中
ロック中

ログアウト中E4E3

E4E5

E4: ロック時間経過《状態遷移図》《状態遷移表》1スイッチカバレッジのパスは全部で９つ© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

63

様々なテスト設計技法を使ってテストパラメータを網羅する
同値分割法・境界値分析

仕様ベースのテスト設計技法

デシジョンテーブルﾃｽﾄ⚫ 仕様化したモデルを基にしてテストケースを作成する、体系的なテスト設計技法⚫ モデルに対応したテスト設計技法を用いる⚫ ブラックボックステスト技法とも呼ばれる

状態遷移テストト

構造ベースのテスト設計技法

ステートメントテスト

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

テ
ス

計
技
法

組み合わせテスト
その他

デシジョンテスト
データフローテスト
その他

経験ベースのテスト設計技法
⚫
⚫

エラー推測

テスト担当者のスキル、知識、経験を基にテストケースを作成する、体系的ではない（経験に基づいた）テスト設計技法
ステークスホルダの知識、過去の類似した欠陥なども情報源となるフォールト攻撃その他© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

64チュートリアルの流れ
1. テスト観点を整理して網羅的に挙げよう
2. テストフレームを考えよう
3. テストコンテナとその間の関係性を考えよう
4. テスト観点からテスト値を網羅しよう

5. テスト開発を意識して進めてみよう© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

65チュートリアルの流れ
テスト要求分析
1. テスト観点を整理して網羅的に挙げよう

2. テストフレームを考えよう

テストアーキテクチャ設計(テストフレームモデリング)

テストアーキテクチャ設計
3. テストコンテナとその間の関係性を考えよう(テストコンテナモデリング)
テスト詳細設計
4. テスト観点からテスト値を網羅しよう

5. テスト開発を意識して進めてみよう© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

66

テストを開発する段階的なプロセスが必要
昔の
テスト開発
プロセス

JSTQBの
テスト開発
プロセス

本講での
テスト開発
プロセス

テスト設計※またはテスト計画、テスト準備など表現は様々

テスト分析

テスト
要求分析
テスト要求の獲得と整理/
テスト要求
モデリング

テスト実装

テスト
実行

テスト
詳細設計

テスト
実装

テスト
実行

テスト技法の適用によるテストケースの列挙

手動/自動化
テストスクリプト(テスト手順)の
記述

テスト設計
テスト
ｱｰｷﾃｸﾁｬ
設計
テスト
アーキテクチャ
モデリング

テスト
実行

© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

67テストベースからいきなりテストケースを作るのは無理筋テストベース※

テストケース※テストを考える上で入力となる情報の総称。主として要求仕様書や外部設計など
開発成果物© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

68テストケースを開発成果物と捉えて段階的に詳細化していく
ソフトウェア開発プロセス
要求の
源泉

要求分析

要求仕様
(要求モデル)ｱｰｷﾃｸﾁｬ設計

ｱｰｷﾃｸﾁｬ
ﾓﾃﾞﾙ

詳細設計

モジュール
モデル

実装

プログラム

ソフトウェア開発プロセス/成果物と、テスト開発プロセス/成果物を対応させてとらえる
テストの
源泉/
テスト
ベース

テスト
要求分析

テスト
要求仕様
(要求モデル)

ﾃｽﾄ
ｱｰｷﾃｸﾁｬ
設計

ﾃｽﾄ
ｱｰｷﾃｸﾁｬ
ﾓﾃﾞﾙ

テスト
詳細設計

テスト
ケース

テスト
実装

テスト手順
(手動/自動化
ﾃｽﾄｽｸﾘﾌﾟﾄ)

テスト開発プロセス© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

69テスト要求分析の一例
テスト要求の源泉/テストベース

テスト
すべきことを
洗い出す

様々な
テスト観点

ドメイン知識/経験/モデル/
ガイドなど

テスト観点を構造化する《リファイン》

構造化された
テスト観点※テスト要求分析を定義したものではなく、具体的にイメージするためにテスト要求分析をプロセス設計した一例© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

70テストアーキテクチャ設計の一例

構造化された
テスト観点

テスト観点間の関係性を見出す

テスト
フレーム

テストコンテナ間の関連性を整理(モデル化)する

同じような
意味を持つ
テスト観点や
テストフレーム
をまとめる

テスト
コンテナ

テスト
アーキテクチャ※テストアーキテクチャ設計を定義したものではなく、具体的にイメージするためにテストアーキテクチャ設計をプロセス設計した一例© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

71テスト観点

テスト
モデルを
特定する

4つの
テスト
モデル

モデルに
紐づいた
テスト観点

テスト
観点を
詳細化
する

網羅基準

コンテキスト

テスト
パラメータ

網羅
基準を
設定する

テスト
設計技法

網羅基準に
紐づいた
テスト
パラメータ

基準に
基づいて
ケースを
導出する

テスト詳細設計の一例※テスト詳細設計を定義したものではなく、具体的にイメージするためにテスト詳細設計をプロセス設計した一例

テストケース(テスト値)© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

72大規模化・複雑化する一方で高品質・短納期も求められるソフト
ウェア開発のために、柔軟で高速かつ精度の高いソフトウェア
テストを開発することが社会的な急務になってきている
10 万 件 を 超 え る 様 々 な 観 点 に よ る 質 の 高 い テ ス ト ケ ー ス を、 い か に 体 系 的 に
スピーディに開発するか、が課題である

そのため「テスト開発プロセス」を構築し、見通しがよく保守性の高いテスト設計を行う必要がある
テストケースを開発成果物と捉え、開発プロセスを整備する必要がある
柔軟かつ高速に、質の高いテストケースを開発するために必要な作業や、テスト観点、
テスト値、テストフレーム、テストコンテナといった中間成果物を明らかにする

このチュートリアルとテスト設計コンテストは、そのための第一歩
高度な内容も含まれているが、テスト技術は奥が深いということを感じ入ってもらい、自分の腕を上げる機会が準備されているのだとワクワクして欲しい
チュートリアルとコンテストでの経験や気づきを自分の日々の仕事に活かしてほしい
チュートリアルを聞くだけでは腕は上がらないし、コンテストに出るだけでは一過性のイベントになってしまう
悩みながら自分の日々の仕事に活かしてこそ、腕が上がったと言えるし身についたと言える© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

73

付録1：

テスト設計コンテストU-30クラスについて© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

74

テスト設計コンテストとは（特にU-30クラスについて）目的

形式• ソフトウェアテストを分析設計から行うことを周知し 、ソフトウェア
テストエンジニアに対する教育の機会を提供する• OpenクラスとU-30クラスの2つあり、U-30クラスは30歳以下向けのクラス• コンテストという形式をとることにより、ソフトウェアテストが創造的な作業であり楽しいということを経験してもらい 、若年層及び初級
テストエンジニアからベテランテス
トエンジニアまでテストへの興味を高める• ソフトウェアテスト業界における技術開発を、競技を通じて促進する• バグ出しコンテストではない。
テスト設計成果物の良さを競う
コンテスト• 各チームは共通のテストベースに対するテスト設計を行い、その成果物で競う• 書類審査による予選を通過したチームが決勝に進出して、プレゼンテー
ションを行う© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

75

テスト設計コンテスト 今までの優勝/準優勝チーム
2011
大賞
湯本賞
にし賞

めいしゅ館
奥村 健二
堀米 賢

2012
（東海）
（東海）
（東京）

最優秀賞
TETTAN（東京）審査員特別賞
あまがさきてすとくらぶ（関西）2014
優勝
TFC KA・RI・YA（東海）
準優勝 MKE98（審査委員推薦枠)

2013

2015
優勝
しなてす
（東京）
準優勝 TEVASAKIplus （東京）優勝
TETTAN（東京） 2連覇
準優勝 Yuki Da RMA（北海道）

2016
優勝
SASADAN Go （書類選考）
準優勝 しなてす （東京）

2017

2018

2020

OPENクラス
優勝 STUDIO IBURI （北海道）
準優勝 わんだーズ （東京）OPENクラス
優勝てすにゃんV3 (東海/関西)
準優勝 フワパン (東京)OPENクラス優勝
セクシーゴリラ(東京)
準優勝 出席番号となり同士 (東京)U-30クラスを新設！
U-30クラス優勝
でこパン462
準優勝 SHINNOSUKE

U-30クラス
優勝
TBD
準優勝 新米

U-30クラス優勝
一等米
準優勝 王バーフロー© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

76

付録2：

U-30クラスの過去の傾向から見る注意点© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

77

テスト開発プロセスに関する理解を深めよう！
⚫ テスト要求分析、テストアーキテクチャ設計、テスト詳細設計、テスト実装というテスト開発プロセスの意味を腹落ちさせて、納得感のあるテストを作ろう

成果物であるドキュメントの質を高めよう！
⚫ 成果物は、納品物として第三者が読んで理解できるかどうかの視点で書こう⚫ ドキュメントの体系を示し、トレーサビリティを持たせ、理解容易性を高めよう⚫ 用語の定義を示そう（又は特定のコンテキストの用語を踏襲することを示そう）

プロセスや成果物に対する意図を伝えよう！
⚫ 特に成果物のWhatとWhyとHowをしっかり示して、第三者に意図を伝えよう

テスト設計技法を使いこなそう！
⚫ テスト設計技法を使うことで、テスト観点に対するテストのカバレッジをしめそう⚫ 世にある演習問題などを通じて、テスト設計技法を手になじませよう© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

78

付録3：

U-30クラスの審査基準について© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

79

審査基準を読み解くにあたってのアドバイス
様々な審査基準をフラットに考えると項目が多くて手に余りやすいので
U-30向けに意識したほうがよい審査基準を参考として示します
優先度

説明

High

テスト開発において基礎・基本となる要素であり、U-30としてまず初めに意識して検討していただきたい項目

Mediumより良いテスト開発のために必要となる要素であり、基礎・基本を押さえたう
えで意識して取り組んでいただきたい項目

Low

より納得感を与え、流用・展開可能な高度なテスト開発になる要素であり、OPENクラスも見据えて意識していただきたい項目© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

80テスト妥当性点（20点）

優先度

指定されたテストの目的に対して成果物は妥当かHigh指定されたテストの制約（工数、リソース、テストレベル、
テストタイプなど）を満たしているかHigh

U-30クラスの2021年度審査基準として、新しく「テスト妥当性点」を定義しています。もともと、テスト要求分析・テストアーキテクチャ設計点が40点だったのを、テスト妥当点として半分切り出しました。

テストの目的や制約と言ったプロジェクトのコンテキストに沿ったテストを開発してほしいメッセージと捉えてください。
© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

81テスト要求分析・テストアーキテクチャ設計点(40点)※審査基準は変わっていませんが、合計点が20点になっています。
•

テスト要求分析・テストアーキテクチャ設計点（20点）
テスト観点を適切に考慮しているか– テスト要求分析・テストアーキテクチャ設計レベルでテスト要求分析・テストアーキテクチャ設計レベルでテストすべきこと(テスト観点)が考慮されているか
テストすべきこと（テスト観点）が考慮されているか– テスト観点がすべて盛り込まれているか
テスト観点がすべて盛り込まれているか– テスト観点が適切な粒度で表現されているか

•

優先度
High
High

テスト観点が適切な粒度で表現されているか
テスト観点間の関係やテストコンテナを適切にMedium考慮して全体像を俯瞰できているか

テストレベルやテストタイプ、テストサイクルなどを– テストレベルやテストタイプ、テストサイクルなどを用いるなどして、テストの全体像が把握しやすいか用いるなどして、 テストの全体像が把握しやすいか
テスト対象やテスト目的など、テスト観点間の関係が分かりやすいか– テスト対象やテスト目的など、テスト観点間の関係が分かりやすいか••

MediumLow

リスクやスコープを適切に考慮しているか
テストの厚みやバランスが考慮されているか
Medium– テストの厚みやバランスが考慮されているか
テストスコープが明示されているか、明示されたHigh– テストスコープが明示されているか、明示されたスコープは妥当性があるか
スコープは妥当性があるか
仕様書の問題を指摘できているか

仕様書の問題を指摘できているかHigh© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

82

テスト詳細設計・実装点(30点)
優先度

テスト詳細設計・実装点（30点）
特定のテスト観点において、テストケースが十分に記述されているかHigh選択したテスト観点が適切か

Medium

テストケースの構造が適切に表現されているか

Medium

テスト詳細設計・実装のための適切なテストの技法や記法を用いているかHigh

網羅性やピンポイント性は適切に考慮されているか

Medium

リスクを考慮した優先順位付けが行われているか

Medium© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

83

工程間一貫性点(10点)・文書点(20点)
工程間一貫性点（10点）

優先度

テスト要求分析・テストアーキテクチャ設計とテスト詳細設計・実装の間のトレーサビリティが取れているか

Medium

テスト要求分析・テストアーキテクチャ設計とテスト詳細設計・実装のバランスが良いかHigh

文書点（20点）

優先度

文書の情報量は適切か

Medium文書の構造は適切か

Medium文書の論理性は高いか

High

文書は分かりやすいか（正確な情報が速やかに伝わるか）

Medium

文書の説得力は高いか

Low

文書体系が示されているかHigh

文書の保守性を考慮しているか

Medium© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

84

総合点（20点）

優先度

技術レベルが高いかLow

独自性は高いかLow

新規性は高いかLow

発想は豊かかMediumプレゼンテーション技術点（15点）※

内容、表現手法、その他特別点

優先度
Low

※U-30の予選（書類審査）ではプレゼンテーションを行いません。プレゼンテーション技術点は、決勝戦のプレゼンテーション審査時に加点されるものです。
© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

85

テスト設計コンテストの審査ポイントを活用しよう
テスト設計コンテストの審査基準の多くは、普段の業務におけるテスト設計のレビューにも有効であるコンテスト用に特化したテスト設計では勝てないように工夫されている(はず)テストは説明責任の塊であるので、説明責任の果た
されていない成果物は点数が低くなりやすいし、実務において「ふーん、それで？」的になりやすい
ダメなテストは単なる作業報告になっている•

これをやりました、あれをやりました、こう書きました…

•

これでは単なる作業報告や日報である

審査基準は自組織のテスト設計レビューのチェックリストや
ガイドラインの素案になりうる

よいテストは、説明責任がきちんと果たされている•

そもそも自組織でテスト設計をレビューしていますか？

•

説明すべきことが必要十分に説明されている•

テスト設計レビューのチェックリストやガイドラインをきちんと作成し、成長させていますか？

•一貫した、統一の取れた説明がなされている•

粒度のそろった説明がなされている•

自組織のチェックリストやガイドラインによく引っかかるテスト設計の問題
点や、それらでは検出できない問題点を把握していますか？

•

全体像が把握しやすい•

意図や目的、根拠、理由が明示されている

自組織の技術レベルに応じて、審査基準の解釈のレベルも
変わりうる

•

トレードオフや設計選択の根拠や選択肢が説明されている•構成要素とその構造が明示されている•

自組織のテストアーキテクチャ設計の技術レベルに応じて「全体像を把握」
できているかどうかを判断する基準は当然異なる•

なぜその構造が適切なのかが理解できるようになっている•

同じ審査基準でも、判断基準の妥当性を常に見直さないといけない•

意図や目的、根拠、理由がきちんと果たされたことが一目で分かるように
なっている

•

レビューしやすい配慮がなされている© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

86最新情報はWebサイト
にて随時発表します！
http://aster.or.jp/business/contest/rulebooku30.html

87© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

88

写真・画像素材
PAKTASO
REEIMAGES
Designed by Freepik.com

是非、実務に活用してテ ス ト の 説 明 責 任 をすこしでも高めてください※もちろん、テスト設計コンテスト（U-30クラス/Openクラス）へのご参加もお待ちしております

参考資料
ソフトウェア・テストの技法 第2版 Glenford J. Myers
ソフトウェアテスト標準用語集(日本語版)Version 2.2.J03
テスト観点に基づくテスト開発方法論VSTePの概要 西康晴氏
事例とツールで学ぶHAYST法 秋山浩一氏
基本構造構成要素 鈴木三紀夫氏
ゆもつよメソッドにおけるテスト分析とテスト設計 湯本剛氏
高信頼化ソフトウェアのための開発手法ガイドブック
テスト設計コンテストOPENクラス チュートリアル資料 2017年度版
テスト設計コンテストU-30クラス チュートリアル資料 2017年度版
テスト技術者資格制度Foundation Levelシラバス日本語版Version 2011.J02© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

89

テスト設計チュートリアル ちびこん編 資料 2021 Ver. 1.0.0
2021年03月01日発行
編集・発行 テスト設計コンテスト審査委員会・実行委員会
特定非営利活動法人 ソフトウェアテスト技術振興協会(ASTER)
連絡先 特定非営利活動法人 ソフトウェアテスト技術振興協会(ASTER) 事務局〒１０５－００１４東京都港区芝2-29-10 ユニゾ芝2丁目ビル 7F
電話 ０３－５４４４－７６０１ FAX ０３－５４４４－８０９５
E-MAIL aster-tdc-query@qualab.jp
URL http://aster.or.jp/© 特定非営利活動法人 ソフトウェアテスト技術振興協会
無断転載・複製を禁ず© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

90

改訂履歴
発行日

改訂履歴
タイトル

備考

2016.08.06

テスト設計 チュートリアル U-30版 資料 2017 Ver. 1.2

初版。U-30クラス向けに新規に作成。

2017.07.01

テスト設計チュートリアル U-30版 資料 2018 Ver. 1.2

2017年度の7章構成をベースに再構成し、5章構成に変更。
また、大幅にデザインを変更。

2018.10.01

テスト設計チュートリアル U-30クラス版 資料 2019 Ver. 1.0.1

2018年度版を踏襲しつつ、文言やデザインを微修正。
また、審査基準についての補足を追加。

2019.11.22

テスト設計チュートリアル U-30クラス版 資料 2020 Ver. 1.0.0

2019年度版を踏襲。ほぼ、年度のみインクリメント。

2021.03.01

テスト設計チュートリアル ちびこん編 資料 2021 Ver. 1.0.0

2020年度版を踏襲しつつ、文言やデザインを微修正。
また、新しいU-30クラスの審査基準に差し替え。

© 2016-2021 NISHI Yasuharu / YAMASAKI Takashi

91