ちわ！！
やったよ！！
書籍
『ソフトウェアテスト技法ドリル』著：秋山 浩一
を使った勉強会。
開催日：6/17
内容：
本の要約解説しながら、参加者同士でディスカッション。
最後にアル課題を使ってワーク。
範囲：第３章 ドメイン分析テスト、デシジョンテーブル
～面で逃がさない～入力が系統的にロジックを網羅し、正しく動作することを確認する
まずは「ドメイン分析テスト」を例題に沿って解説。
ドメイン分析と言えば、
onポイント、offポイント、inポイント、outポイント
これらの定義がややこやしい。onポイントなんかが特に。
定義は下記のような感じです。
onポイント ：着目している境界値
offポイント：onポイントに隣接する境界値
inポイント ：ドメインの内側の値（on/off以外）
outポイント：ドメインの外側の値（on/off以外）
x≧10とx＞10の場合は以下のようになる
| 説明 | x≧10の場合 | x＞10の場合 |
|---|
| on | 10 | 10 |
|---|
| off | 9 | 11 |
|---|
| in | 例：15 | 例：15 |
|---|
| out | 例：5 | 例：5 |
|---|
図で表すとこうなる。
かならずしもonポイントが有効な値になるわけではないことに注意。
あと、定義からoffポイント一つではなく二つ存在することになる。
（in-offポイント、out-offポイント）
これらを整理するのに「Binderの分析テストマトリクス」を使います。
と言ったところで、問題。
【半オリジナル（？）問題】
===================================================================================
あるロールプレイングゲームで攻撃時に相手に与える基本ダメージは次の式で決まります。
基本ダメージ値＝（自分の攻撃力÷２）×（武器の熟練度÷１０）
ー（敵の守備力÷４）
自分の攻撃力の最大100
武器の熟練度の最大20
敵の守備力の最大80
ドメイン分析マトリクスを作成しなさい。
解答（省略、考えてみて）
===================================================================================
境界値をBeizerの方法とJorgensenの方法の考え方で
ドメイン分析マトリクスの大きさは変わるかも。
というご意見。
確かに、offポイントをoutのoffだけじゃなくて、in側のoffも考えるとケースが増えますね。
というところで、
開発者による単体テストと第３者によるシステムテストだとテストケースはどう変わる？
を考えてみたら、こんな意見がでてきた。
【単体テスト】
ドメイン分析マトリクスのパターン
各項目に負の値を入れる
各項目に最大値を設定する
各項目に最小値を設定する
【システムテスト】
ダメージが当たるかを確認
乱数を使って連続耐久テスト
システムテスト…、ドメイン分析関係ねぇ～
という感じでした。
ただし、システムテストまでに、単体テストで先であげたものが確認されていること、
というのが前提となります。
ドメインと言うだけあって、用途は単体テストに向いているのかな？
続いて「デシジョンテーブル」
デシジョンテーブルとは？
ドリル本での説明によると
==============================================
・ドメイン分析テストマトリクスの変数は数式
・デシジョンテーブルで取り扱う変数は論理式
論理式とは
AND(∧)、OR(∨)、NOT(¬)
→プログラムの中ではif文やswitch文に相当
==============================================
先のドメイン分析マトリクスとか、いるの？
みたいな意見もあったのですが、
デシジョンテーブルとドメイン分析の説明を並べてみると違いがわかった（気がする）。
まだ本題に入らず
ここでデシジョンテーブルで使われる記号あれこれ
ということで、人や組織によって使用されてる記号が違うよ～、というお話。
==============================================
◆条件の判定
Y/N(Yes/No)
T/F(True/False)
○/×
◆どちらでも良い時の記号
―(ダッシュ、マイナス)
DC(Don’t Carful)
◆ありえない
×(バツ)
N/A(NotApplicable（該当せず）)
==============================================
自分的にはわかりやすければ何でも良いと思います。
ただチーム内で合わせておきましょう。
＃自分は○、×派かな
では、例題を使った演習に入ってみた。
=======================================================================
インターネットショッピングで、書籍を1,500円以上購入した場合、
配送料が無料となる。
=======================================================================
これだけでもわかるけど、なんか条件にあいまいさを感じる。
ということで、条件の箇条書きに書き換える。
==============================================
購入対象が書籍
且つ
購入合計金額が1,500以上
配送料が無料
==============================================
ここでは条件が２つなので、これでも十分読み取れる感じ。
でも以下の問題がありそう。
・有料になる場合が明示的ではない。
・要求元も抜けている条件に気づきづらい。
・条件が追加されたら読み取りづらくなる。
じゃあ、どうするの？
ということでデシジョンテーブルの登場
デシジョンテーブルを使いこなすために必要（と思う）圧縮もやってみる
圧縮①
圧縮②
①と②の違いますよ～と説明
①は条件が処理される順番を知らないと成立しない
②どれかひとつでも条件を満たさない場合、無料にならない、という目的のテストならばに対するデシジョンテーブル。
ちなみに、これは処理順に依存していない(はず）。
圧縮体験したあとは、例題のロジックを書いてみよう！！のコーナー
解答例㋑
if (TYPE_BOOK != goodsType)
{
return false;
}
if (PRICE_1500 > totalPrice)
{
return false;
}
if (TRANSPORT_RITO == transport)
{
return false;
}
return true;
解答例㋺
if (TRANSPORT_RITO != transport)
{
if (PRICE_1500 >= totalPrice)
{
if (TYPE_BOOK == goodsTyp)
{
return false;
}
}
}
return true;
㋺場合、処理順番が異なるため、最初の例①で示した圧縮は不可。
なんでこんなことが起きるか？
を参加者で考えてみた。
・改修、仕様追加が影響
たとえば、仕様が
「書籍を1,500円以上購入し、配送先が離島以外の場合、配送料が無料となる」
と明記されていたとする。
でも、もともと離島以外で1,500円以上無料という仕様があったところに、
対象の品物が書籍という仕様が追加されたら、例のようなコードになるかもしれない。
・上記に加えて「元のコードをできるだけ変更するな」という裏の事情があるとなりえる
デシジョンテーブルを使ったことある参加者から
「デシジョンテーブルの圧縮のテクニックを覚えると何でも圧縮したくなる」
との声があり。
＃自分もそうでした。圧縮する目的を気にしましょう（汗
デシジョンテーブルの圧縮について、注意を整理
・できることなら圧縮せずに全部やる
・圧縮したところにバグが潜んでいることがある
・バグを見つけたいのか？仕様を確認したいのか？目的を明確にした上で圧縮を考える
・テストするタイミングと期間でトレードオフ
圧縮することによるテストを実施しないリスクを受け入れるかどうかにも検討
ここまで整理したところで、場合によるデシジョンテーブルを圧縮してみた。
・単体テストでは
・システムテストでは
・仕様の確認なら
・バグを見つけるなら
（考えてみてね）
ここまで来て、最後にとっておきのお題
【お題】
給湯ボタンと解除ボタンの操作可能条件をデシジョンテーブルで整理する。
最後は第３章の内容を踏まえて、
SESSAMEの組込みシステム教育教材
『話題沸騰ポット GOMA-1015型』要求仕様書の給湯機能とロック機能に関する仕様を抜き出したものを課題として、
「デシジョンテーブル」を実施。
デシジョンの条件抽出で、みな手が止まった…
したっけ！！【参考情報】①組込みシステム教育教材話題沸騰ポット
(
http://www.sessame.jp/workinggroup/WorkingGroup2/POT_Specification.htm)
ソフトウェアテスト技法ドリル
JSTQB用語集
ソフトウェアテスト実践ワークブック
はじめて学ぶソフトウェアのテスト技法
