[イベント]JaSST'10 Tokyo 申込み開始

久しぶりの投稿になってしまいましたが、、、

==

来年1月末に国内で最大規模のソフトウェアテスト関連イベント「JaSST'10 Tokyo」が開催されます。先週末から申込みが始まってました。僕も原因結果グラフの支援ツールで発表させていただきます。

　JaSST'10 Tokyo　開催要項
　http://jasst.jp/archives/jasst10e.html

　参加申込み
　http://jasst.jp/archives/jasst10e/attention.html

日程　　　2010年1月28日(木)～29日(金)

場所　　　目黒雅叙園　(東京・目黒)

参加費
　　1日券 5,250円 （税込）
　　2日券 8,400円 （税込）
　　（　チュートリアルを受講される場合　）
　　1日券＋チュートリアル1受講券 21,000円 （税込）
　　1日券＋チュートリアル2受講券 15,750円 （税込）
　　2日券＋チュートリアル1受講券 24,150円 （税込）
　　2日券＋チュートリアル2受講券 18,900円 （税込）
　　2日券＋チュートリアル2回 （1、2）受講券 34,650円 （税込）
　　情報交換会 5,250円 （税込）
　　会場での弁当購入 各日1,050 円（税込）

主催　　　特定非営利活動法人 ソフトウェアテスト技術振興協会 (ASTER)

基調講演　　　Johanna Rothman (Rothman Consulting Group, Inc.)
　　　「Successful Software Management: 17 Lessons Learned」

協賛
　　オブジェクト倶楽部
　　組込みシステム技術協会
　　NPO法人 組込みソフトウェア管理者・技術者育成研究会（SESSAME）
　　高品質ソフトウェア技術交流会（QuaSTom）
　　情報サービス産業協会
　　情報処理学会ソフトウェア工学研究会
　　ソフトウェア科学会ソフトウェア工学の基礎研究会
　　ソフトウェア技術者協会
　　ソフトウェア技術者ネットワーク（S-open）
　　電子情報通信学会 ソフトウェアサイエンス研究会
　　日本科学技術連盟
　　日本信頼性学会
　　日本ネットワークセキュリティ協会
　　日本品質管理学会 ソフトウェア部会
　　プロジェクトマネジメント学会
　　日本情報システム・ユーザー協会

後援
　　独立行政法人 情報処理推進機構　(IPA)

原因結果グラフの勉強会 宿題を解いてみよう

昨日、勉強会があって、原因結果グラフを作成する宿題が出ました。そのうちの1問はこちら。

JR乗車券類の誤購入の場合の取扱方

第293条
1 旅客が、誤つてその希望する乗車券、急行券又は特別車両券と異なる乗車券、急行券又は特別車両券を購入した場合で、その誤購入の事由が駅名の同一・類似その他やむを得ないと認められ、かつ、係員がその事由を認めたときは、正当な乗車券、急行券又は特別車両券に変更の取扱いをする。
ただし、指定急行券及び指定特別車両券については、この取扱いをしない。

2 前項の場合は、既に収受した旅客運賃、急行料金又は特別車両料金と正当な旅客運賃、急行料金又は特別車両料金とを比較し、不足額は収受し、過剰額は払いもどしをする。

今回の勉強会で学んだ、

仕様をわかりやすい言い方に変換する

仕様に印をつけて、ノードを洗い出す

結果から探してみる

中間ノードは観測可能なものはいっしょくたにしない

といったところに注意してみたい。

「乗車券、急行券又は特別車両券」・・・これはA,B,orC＝AorBorCという意味のはず。なので、同じような表現である「旅客運賃、急行料金又は特別車両料金」も同じ。

僕が作ってみた解答はこちら。

で、今回の勉強会では登場しなかったのですが、制約条件を付けてデシジョンテーブルにしてみるとこちら。

でも、よく見ると「差額がゼロ円という」ケースがテストされていない。。。どこで間違えたかしら。

ceg2dtツール - 65%くらい完成

今日は深夜メンテナンス。少し休憩。

==

原因結果グラフをデシジョンテーブルにするツールを勉強のために作成しているが、6割くらいできた。未実装なのは、

制約条件（REQとMASK）

Tとt、Fとfの違い

最適化

何とかなりそうな気がしているが、コードがまったくエレガントではないし、長い。。。。

1. サンプル１：チケットの学割
デシジョンテーブル（２） - たまゆら雑記の例を使わせていただきました。

この例だと、なんかあってそうな感じ。でもよくみると、偏ってる。#5は「埼玉に在住でない」「学生証を提示していない」のほうがベターか。

2. サンプル２：ログイン画面

原因結果グラフ - 論理点カバレッジの解剖の例を使ってます。


これは、マス目の埋まっていないところの決め方が偏っているため、テストケース数が多い。最適化の課題か。

3. サンプル３：結婚

結婚できるかどうかの原因結果グラフ。


一見うまくいってそうだが、「16歳以上」「18歳以上」の組み合わせが矛盾。制約条件が中途半端だから。

制約条件からデシジョンテーブルを埋めていく

今日はお風呂を掃除して、近所のスタバのドライブスルーでラテ買ってきて、和室でお勉強。amazonから本も届いたし読むかな。

==

原因結果グラフを元にしてデシジョンテーブルを作成していく手順を自動化して、理解を深めようとしてるのだが、以下の例でいろいろ考え中。

制約条件（男性と女性）

まずは、3つのテストケースを列に組み込んでみた。これは論理接点1～3について、行列を転置したもの。ここで、制約条件（「男性」「女性」はONE制約）から、空欄となっている原因ノード「女性」は自動的に決定される。

制約条件（年齢）

原因ノード「18歳以上」がTrueである場合は、もうひとつの原因ノード「16歳以上」も自動的に決定される（REQ制約）。んー、年齢は「15歳以下」「16歳か17歳」「18歳以上」にしたほうがよかったかな。

たぶん、こういうようにTrue/Falseを決定しつつ、カバレッジ率をあげて、未確定のマス目も埋めていく感じですすめていくかな。

原因結果グラフ→デシジョンテーブル（途中までツール化）

JacaScriptが初心者向けなのかどうかは別として、手ごろだったので原因結果グラフからデシジョンテーブルを作成するツールをJavaScriptでためしに作り中。エクセルVBAとかのが使えるんだろうな。

原因結果グラフ→デシジョンテーブル（v0.2）
# Opera9.26で確認中。まだブラウザによっては動作しないかも。。。

以下、TODOとして。

ブラウザ違いでのチェック

ノードやリンクの入力方法を考える

制約条件の実装

Don't Care状態のマス目対応の実装

検算の実装

原因結果グラフ - 論理点カバレッジの解剖

方針転換。JaSSTの「三賢人、テストを語る」のPDF資料にある、カバレッジ表を読み解く。

また例題。

IDとパスワードを入力して、ログインする画面についての原因結果グラフとします。ここでまず、網羅すべき論理展開式（論理接点、論理点？）がいくつあるかを調べる。これは、それぞれのエッジの交叉点に注目するとわかる。ANDであれば、Tになる1通りとFになるn通りがあるので、(n+1)通り。ORであれば、Fになる1通りとTになるn通りがあるので、(n+1)通り。ということはこのグラフで言えば、3＋3＋3＋3＋2＝14通りとなる。14通りの論理展開式がどのように出現するかをマトリックスにするため、行には論理展開式を、列にはノードを並べた14×10行列を用意する。

ちなみに、薄緑色は原因ノード、イタリックは中間ノード、薄オレンジ色は結果ノード。ここにどんどんT/Fの組合せを記入していく。

ここからは、すべての論理展開式が出現するようにテストケースを組み立てていくのだが、この場合だと4組ですべて網羅した。

出現した論理展開式をチェックするとこんな形のマトリックスが完成する。「x」は1回だけ出現し、「#」は2回以上出現したことを表している。「#」は1回だけ出現し、「x」は2回以上出現したことを表している。

この流れでツールを作ってみるといいかな。ただ、PDF資料だと、最後のテストケースの選び方は割愛されている模様。

原因結果グラフを解剖 - 原因から？結果から？

BlackBerryのメールは本文をBase64にするみたい。

==

原因結果グラフをデシジョンテーブルに変換する際、まずは小さなテーブル（サブテーブル）を作成してから、全体のテーブルを作っていく手順で僕は行っていたが、サブテーブルはどちらから結合したほうが簡単なのだろうか。ごくごくシンプルな原因結果グラフであれば、中間ノードと結果ノードから大枠をサブテーブル化して、細部を組み立てるほうがわかりやすそうだけれども、制約条件が関係してくると、原因ノードと中間ノードからサブテーブルを作成して、制約条件を先に考慮したほうがよさそうにも思える。

などと考えてみる。

今のところの結論としては、原因側から右側へ結合させていくほうがよさそうに思える。原因ノードと中間ノードについてのサブテーブルを作成する際に、原因ノードと制約条件をもつ原因ノードも一緒にしてしまうといいのではないか。

原因結果グラフを解剖 - 制約記号

原因結果グラフを解剖 - AND/ORなど

引き続き、制約条件を表すグラフをチェック。制約とはありえない組合せを表現するための表記で、ソフトウェアテストではとても重要。

EXCLUSIVE OR（EXC、排他的）

排他的EXCは、原因ノードのうち「T」になれるのはひとつだけ。「NHKを見るか、フジテレビを見るか、それともテレビを見ないか」。

INCLUDE（INC、包含）

包含INCは、原因ノードのうち、少なくともどれかが「T」でなければならない。「自動販売機の、コーヒーを押そうか、お茶を押そうか、それとも両方押しちゃおうか」。

ONE（ONE、一方のみ）

ONE制約は、原因ノードのうち、どれかひとつだけが「T」でなければならない。「じゃんけんの結果は、勝ちか、負けか、あるいはあいこ」。

REQUIRE（REQ、必要）

REQ制約は、原因ノードが「T」ならば、かならず結果も「T」にならなければならない。「充電がなくなれば、携帯電話はつながらない」。ちょっと違うか。

この他にも、隠蔽（M）があるらしいのだが、お目にかかったことがない。どういうときに使う制約なんだろう。

原因結果グラフを解剖 - AND/ORなど

NHKクローズアップ現代でソフトウェア品質のプログラムがこの前やってた。見逃した。

「ソフトウエア危機　～誤作動相次ぐハイテク製品～」

ブログで少し検索したので、リストアップ。

ソフトウェアの欠陥はなぜ無くならないのか

NHKクローズアップ現代 ソフトウェア危機

==

原因結果グラフのテーブル作成をツール化する前に、基礎的なことを復習・まとめてみる。小さなテーブル作成をしているうちに何かいいことが気づけるかなあと。手持ち資料で原因結果グラフを勉強するとなると、マイヤーズ本くらいしかないが、わかりにくい表現が多い。自分なりの言葉でまとめてみる。

IDENTITY(同値)

原因が「T」なら、結果も「T」。原因が「F」なら、結果も「F」。原因と結果が同値な状態をさしていて、デシジョンテーブルも非常にシンプル。

これは中間ノードが入ってもデシジョンテーブルは同じ。

NOT(否定)

原因が「T」なら、結果は「F」。原因が「F」なら、結果は「T」。原因と結果の関係が逆になるケース。

AND(積)

原因が2ノード以上関係して、さらにその論理積で結果を決定するケース。「身長が高くて、学歴が高くて、高収入なら結婚する」みたいな。下図にあるように原因ノードが3つある場合は、デシジョンテーブルは4列（結果が「T」＝１、「F」＝３）となる。

単純に考えてみると、原因（真／偽）が3つあるので、全数では2^3＝8列になるはずである。しかし、原因の複数項目が「F」だと、どの原因が結果を決定しているかが判断できない。つまりは、#2、#3、#4の3列は、それぞれノード11、ノード12、ノード13が結果を「F」にする原因となっていることを確認することが目的であるため、下図#5のようなテストケースは適当ではないのだ。これは経路感光（path sensitizing）というそうです。

OR(和)

原因が2ノード以上関係して、さらにその論理和で結果を決定するケース。「医者か、弁護士か、あるいはIT長者なら結婚する」みたいな。下図にあるように原因ノードが3つある場合は、デシジョンテーブルは4列（結果が「F」＝１、「T」＝３）となる。

ORとANDは表裏の関係なのがポイント。高校のときに習った、ド・モルガンを思い出せ。

さーて、続きはまた今度。次は制約記号だな＞EXC、ONE、INCなどなど

デシジョンテーブルの結合（具体例）

[サイト]ソフトウェアテスト、HAYST法、などなどのサイト紹介で紹介したサイトにあった、原因結果グラフによるテストケース作成を実際に試してみたが、あきやまさんご指摘のとおり、間違えていた。もう一度順を追ってやり直してみたので、その結果を書いてみた。

==

まずは、原因結果グラフを簡略化してみる。

中間ノードは存在しないので、4つの結果に対するデシジョンテーブルを作成。

そして、これらを単純に結合する。ここまでは素直。太枠の部分がそれぞれのサブテーブルにあたる。

ここでONE制約があるので、必然的にT/Fが決定する部分を埋める。便宜上小文字のt/fとする。

このデシジョンテーブルにはすでに重複する列があるので、それらを除外する。

この時点でデシジョンテーブルを整理してみると、左側7列の中に、最初に作成したサブテーブルの組み合わせが全て出現していることがわかる。ということは残りの#12と#13の空欄をどのように組み合わせても重複する列になってしまうため、除外する。
2008/02/06追記。#2のテストケースの結果が間違っていましたので、修正しています。あきやまさん、ご指摘ありがとうございます。

あとは、ナンバリングしなおして、#7の13のマス目に適当なt/fを埋めて完成。今回は「f」とした。
2008/02/06追記。上図同様#2のテストケースの結果を修正。

==

さて、ここで自分への問題。どうしてテーブルの結合で誤りがあったのか。考えうる原因として、

重複列の判断を間違えた（判断の仕方が適切でなかった）

空欄・DCの考え方が間違っていた

検算を忘れた（サブテーブルの組み合わせの確認）

あたりか・・・