CEGTest にニフティクラウド(mBaaS)からインポートする機能を追加

CEGTest はJavaScriptを使って、オフラインでも動作するように実装していますが、ウェブ版ではニフティクラウド（mBaaS）を利用して、いくつかのサンプルデータを取得できるようにしました。

サンプルデータは、原因結果グラフの演習で公開しているデータが利用できます。なお、演習問題のページで紹介している模範解答はあくまで「解答例」の一つですので、仕様の考え方や何の検証を優先するのか、などによって原因結果グラフは異なります。

今後は、FacebookやTwitterなどSNSとの連携ログイン機能やログインユーザ毎のデータ保管などを考えてみます。

CEGTestにxlsx形式でのエクスポート機能を追加

CEGTest（セグテスト）のエクスポートに xlsx 形式でのダウンロード機能を追加しました。
1シート目はデシジョンテーブル、2シート目はカバレッジ表です。本当は、3シート目に原因結果グラフの元データを、4シート目に原因結果グラフの画像を張り付けたかったのですが、ちょっとそこまで実装できませんでした。

URL はこちら。

CEGTest（ウェブ版）
CEGTest（ダウンロード版：v1.6-20130907）

CEGTest サイト移行

原因結果グラフによるテスト設計支援ツール「CEGTest（セグテスト）」ですが、以下のドメインにURLを移行しました。

　CEGTest　http://softest.jp/tools/CEGTest/
　※最新バージョンは v1.6 です

# ブログ自体は今後も削除せず残しておきます

＝＝

その他のコンテンツ（zipファイル、テスト設計の演習問題など）を随時移動していきます。また、秋山浩一氏の「ソフトウェアテスト技法ドリル」には旧URLが掲載されていますので、当面は新URLへのリダイレクトを入れてあります。

ドメインを取得したので、これをいい機会にいろいろコンテンツを増やしたり、ツールを改良していこうかなと思います。

CEGTest の改良（多水準化、obs 実装、エクセル出力など）

drawCFD の移行・改良

HAYST ツールの移行

ラルフチャート作成支援ツール

デシジョンテーブル作成支援ツール

夢は広がるな。

CEGTest の js アップデート中

CEGTest の js ファイルをアップデート中ですが、プロパティの衝突か何かを起こしていて、ウェブサイト上で問題発生中です。ご利用の際は、zip ファイル版をご利用ください m(_ _)m

http://softest.cocolog-nifty.com/blog/cegtest.html

原因結果グラフの中間ノードが観測不可な場合について

TEFで原因結果グラフの「観測可能」についての解説があったので、すこしまとめてみました。

==

中間ノードが観測可能であるとは、テスト実施後にそのノード（状態や内部変数）が直接確認（観測）できることを言う。特に内部変数はデバッグ出力などを使わないと観測可能にはならないので、プログラムテストではデバッグ出力を用いて観測可能にすることが多い。

CEGTestでのデシジョンテーブル作成ロジックでは、すべての中間ノードが観測可能という前提で実装されています。グラフの形にもよりますが、デシジョンテーブルの1列が複数の論理関係を検証できるため、カバレッジ表よりもデシジョンテーブルの大きさが小さくなります。

では、観測可能ではない（観測不可）中間ノードがある場合はどう考えたらよいか。

このグラフではAが中間ノードになるので、Aが観測可能であればデシジョンテーブルは以下のように作成できる。

では、Aが観測不可である場合、他にどんなテスト条件を確認すべきでしょうか。

その前に上記デシジョンテーブルの各列が「何を」検証しているかを再確認。

• #1




• a1がTであることによって、中間ノードAがTになることを検証している。


• A,B,CがすべてTであることによって、結果ノードXがTになることを検証している。




• #2




• a2がTであることによって、中間ノードAがTになることを検証している。


• BがFであることによって、結果ノードXがFになることを検証している。




• #3




• a3がTであることによって、中間ノードAがTになることを検証している。


• CがFであることによって、結果ノードXがFになることを検証している。




• #4




• a1,a3,a3がすべてFであることによって、中間ノードAがFになることを検証している。


• AがFであることによって、結果ノードXがFになることを検証している。

さて、Aが観測不可と考えると、#1は、

• a1,B,CがTであることによって、結果ノードXがTになることを検証している。

というように見なせる。言い換えれば、a2,a3が結果ノードXがTになることに影響を及ぼしているかについては未検証と言える。さらに、#2～#4でもa2,a3がTになることが結果ノードXをTにする検証にはならない。

したがって、僕の解釈では、2つの列を追加すべきと考える。

ただ、テスト実施は#6からはじめたほうがいいかもしれないなあ。

技と術と芸で考えるソフトウェアテスト

このエントリーは、「Software Test ＆ Quality Advent Calendar 2011」の12/23分として書いています。

前日の12/21は、@takanorig さんによる「JaSST 10th Anniversary」でした。

僕は普段はソフトウェア開発とそのマネジメントをしていますが、ソフトウェアテストに関する活動・勉強会をしています。その中で「WACATE」と呼ばれる若手テストエンジニア向けのワークショップの実行委員をしています。今回のエントリーは、昨年のワークショップで少し話をした「技と術と芸」について個人の考えとしてまとめたものです。

同値分割やデシジョンテーブル、直交表などを一般的にはテスト技法と呼びますが、「技法」ってなんだろう？　とふと思ったのがきっかけでした。そして、技法、技、技術、・・・、といろいろな言葉を調べていて、「技」「術」「芸」の3つについて自分の中での定義を作り、ワークショップの最後に発表しました。

※もともとはウィキペディアに記述されている定義を参考にしています。

まずは技（わざ）。

技（わざ）とは、「特定の目的を持ち、その目的を果たすための手段・手法」、である。絵にもあるように、関節を攻めるための関節技のように、具体的な目的・標的があって、それを実現する手段である。逆にいえば、目的が合致しない場合はその技は効力を発揮できない。テスト技法と呼ばれるもののいくつかは、この「技」に分類できるのではないか。

次は術（じゅつ）。

術（じゅつ）とは、「技を体系的にまとめ、改変が施されて流派に分かれたり、統一されたすべ」、である。技よりもより体系化・フレームワーク化・パターン化されたり、いくつもの技の連なり・組合せを表すのではないか。テスト技法でいえば、テスト条件を同値分割を使ってグループ分けし、その境界値を狙う、といったものが当てはまる。戦術、あるいは戦法といった言葉に近づくイメージである。

最後は芸（げい）。

芸（げい）とは、「個性的・独創的で継承することが困難だが、作品を確認することで業績を知ることができる技能」
、である。結果については驚異的であり、劇的であり、感動すらありうるが、途中のプロセスはやや隠ぺいされているため、真似ることや教えること、説明することが難しい。当人にとっては理論的だが、それらの一部に飛躍が多いのかもしれない。

==

この3つについては、ある種の状態遷移というモデルが当てはまるのではないかと思いました。

「技」は鍛錬によって使い手のスキルとして身についていく。そして、「技」は体系化という行為によって「術」に変わる。技を覚えるだけでは、実践では役に立たない。それらを適切な場面、標的に使うことではじめて武器になる。また、「術」は使い手が日々磨きをかけていくとともに、アプローチの違いや特徴を持ち始め、流派が生まれることがある。

また、「技」は突如、独創性や直感的なエッセンスを得ることで「芸」に変化する。誤解を恐れずに言えば、突然変異かもしれない。そして、「芸」の驚異的な結果をどうにかして使いたいと思う。そのためには、「芸」を分析して、特定の切り口が解明されてくると、それはツール・道具となり、状態は「技」になる。

他にも遷移はあるかもしれないが、こういった「技」「術」「芸」の移り変わりがあってこそ、新しい考え方や概念が生まれ、ソフトウェア開発の質が向上し、ひいてはユーザへの価値が高まるのだ。

テスト技法やテスト手法を学び、プロダクトの品質を向上させつつ、こういった「技」「術」「芸」を磨くことも忘れてはならないなあと感じました。

シーケンス図を使ったステートチャートの作成(1)

状態遷移図・ステートチャートをシーケンス図から設計する手法があるようです。

モデル検査法
http://apal.naist.jp/~seki/Japanese/ss/2011-2.pdf

例に挙げているのは通信プロトコルのモデル化で、

(1) 正常系のシーケンス図の作成
(2) それぞれのラインに対して、トリガー（入力イベント）を見つける
(3) 状態を見つける
(4) 状態遷移図に起こす
(5) 書きづらい・読みづらいなど、必要に応じて階層化
(6) 上記を、その他の正常系や異常系で繰り返す

といったもの。

今回はサンプルとして、メールソフトからのメール送信について、この手順を追ってみようと思います。

(1) 正常系のシーケンス図の作成

利用者、メールソフト、メールサーバで正常系のシーケンス図を作成。

まずは、メールサーバの入力イベントで区切ってみると、入ってくる矢印、出ていく矢印に注目。

状態は、「idle」「新着確認」「受付中」がみつけられる。さて、メールサーバの状態はこれだけだろうか。

ハレルの状態遷移図 statechart を勉強する

twitter で @Unity1004 さんがファミコンで有名なスーパーマリオの状態遷移図（＝マリオチャート）を描きながら、ハレルの statechart 等の話題が出たりしていたので、僕も勉強してみようと思う。

==

仕様書や設計所が自然言語で記述されている場合、視覚的にわかりやすくするために図や表に整理することが多い。その整理方法のひとつとして状態遷移モデルを状態遷移図に記述する工夫がある。しかし、一般的な状態遷移図では、似たような状態が複数登場したり、オブジェクトがひとつの状態でしかなりえないが、実際のソフトウェアでは複数の状態をもつことも多い。

そこでデビッド・ハレル氏が提唱したハレルチャート（statechart）が登場します。

以下は、astah を使って記述した一般的な「キッチンタイマー」の statechart である。

参考：　http://www.ssi.ist.hokudai.ac.jp/Archives/.../systemdesign2011-5-24-1.pdf　
参考：　http://zone.ni.com/devzone/cda/tut/p/id/12848

参考にした2つの説明ページでは、どちらもズームインしながらチャートを作成していく手順である。また、特定のサブ状態（子要素を持つ状態）を検討しているときは、別のサブ状態を抽象化してわかりやすくしている。ちなみに今回使用した astah では、サブ状態の内部には開始疑似状態は作れなかった。

[イベント]JaSST'11 九州とWACATE2011 冬

10月～12月、そして1月はソフトウェアテスト関連のイベントがいくつも連なっていますが、今日は自分にも関係しそうなものを二つ。

==

JaSST'11 九州　2011年11月25日(金)

今年のJaSST九州は福岡です。金曜日なので、東京近辺から遠征される場合は週末も吸収を楽しむのもよさそうですね。今回は午前中のチュートリアルで「実践！　CEGTestで原因結果グラフを作ってみよう」と題して、CEGTestを使いながら原因結果グラフを学んでみるワークを担当させていただきます。

開催要項

基調講演は、尾縄 大輔さん（西日本旅客鉄道）による九州新幹線開通にまつわるお話のようです。今年のJaSSTは乗り物系がはやり？！

http://jasst.jp/archives/jasst11k/session_11k.html#s3

招待講演は、湯本 剛さん（日本HP)からテスト自動化を成功させるアドバイスがきけるようです。いろいろな場で湯本さんとお話しする機会はあるものの、落ち着いて講演を聞く機会がなかったので、楽しみです！
九州にみんなでいってみよう！

http://jasst.jp/archives/jasst11k/session_11k.html#s5

==

WACATE2011 冬　～咲かせてみせようテスト道～　2011年12月17日(土)～18日(日)

今年も実行委員を務めさせていただきます。今回のクロージングセッションは、「ソフトウェア品質会計」の著書でも有名な誉田直美さん（NEC）です。そして、2日間のセッションをモデレートする実行委員も女性が多く、今回はいつもよりも華やかな雰囲気です。

開催概要

プログラム

WACATE(わかて)とはいえ、ベテランのエンジニアでも参加されていますし、参加者それぞれが得るものを持ち帰っていただける2日間です。ご興味のある方はぜひご参加ください。

出力の組合せ

昨日の夜、twitter で @kyon_mm さんとやり取りをしていたことをもう少し考えてみようと思う。

もともとは数学的なテクニックを使って、自動的にテストパターンを作成する（したいけど、数学勉強しなきゃなあ）という話が発端だったかと思います。Inputは「入力条件」「出力結果」「論理関係を含むDSL」、Outputは「入力条件・出力結果を含んだ組合せテストケース（テスト条件）」というようなツールを目指しているのだと理解しました。

※DSLはドメイン特化言語で、仕様記述言語を意味するらしい。

ここで「出力結果の組合せ」というのは、何らかのシステムの端末で出力されるエラー通知方法

｛ディスプレイ：”エラーA”を表示、”エラーB”を表示、”エラーA・B”を表示｝、｛エラー音：音１、音２｝

といった要素と値の組合せを指している。

直感的には、出力結果の組合せを考慮するということは、それらになんらかの論理関係（主従関係）がある、ということになり、出力結果の要素のいずれかが他の要素の入力（原因）になっているんじゃないかなと思いました。

ひとつだけディスプレイに表示される場合は音１が鳴り、”エラーA・B”が表示される場合は音２が鳴る

みたいな。こういう仕様がわかっているならば、デシジョンテーブルなどで表現する方法もある。この場合、ディスプレイ表示（または、ディスプレイ表示を引き起こすイベント）が入力条件に位置する。

でも、「出力の組合せ」を考えたいというのは、おそらくはこういった関係性が仕様上ない場合を指しているのではないかと考えました。あるサイトに広告が3種類あって、

｛広告A：a1、a2｝、｛広告B：b1、b2、b3｝、｛広告C：c1、c2｝

といった広告がランダムに表示される、といったシチュエーション。

実際、JavaScriptを含むタグであったりすると、仕様上は存在しない影響を生み出す場合があり、組合せテストはしたいところ。でも、これも単純に広告A～Cの組合せを考えて、影響がないことをまずは確認することで、その後のさらなる結合テストでの検証範囲を狭めればよいのではないかと思いました。