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

1

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

2

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

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

| | コメント (1) | トラックバック (0)

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

Xlsx

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

URL はこちら。

CEGTest(ウェブ版)
CEGTest(ダウンロード版:v1.6-20130907)

| | コメント (0) | トラックバック (0)

CEGTest の js アップデート中

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

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

| | コメント (0) | トラックバック (0)

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

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

==

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

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

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

Ceg2

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

Dt2obs

では、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つの列を追加すべきと考える。

Dt2kase

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

| | コメント (1) | トラックバック (0)

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

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

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

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

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

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

まずは技(わざ)。

Waza

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

次は術(じゅつ)。

Jutsu

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

最後は芸(げい)。

Gei

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

==

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

Stm

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

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

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

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

| | コメント (5) | トラックバック (0)

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

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

==

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

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

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

Statechart_2


参考: 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 では、サブ状態の内部には開始疑似状態は作れなかった。

| | コメント (0) | トラックバック (0)

[イベント]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日間です。ご興味のある方はぜひご参加ください。


| | コメント (0) | トラックバック (0)

出力の組合せ

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

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

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


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

{ディスプレイ:”エラーA”を表示、”エラーB”を表示、”エラーA・B”を表示}、{エラー音:音1、音2}

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

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

ひとつだけディスプレイに表示される場合は音1が鳴り、”エラーA・B”が表示される場合は音2が鳴る
みたいな。こういう仕様がわかっているならば、デシジョンテーブルなどで表現する方法もある。この場合、ディスプレイ表示(または、ディスプレイ表示を引き起こすイベント)が入力条件に位置する。


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

{広告A:a1、a2}、{広告B:b1、b2、b3}、{広告C:c1、c2}

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

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


| | コメント (0) | トラックバック (0)

第6回「ソフトウェアテスト技法ドリル」勉強会 - ペアワイズ

今週末は台風12号の影響で大雨や交通機関の乱れが見られましたが、9/2(金)の勉強会は開催されました。

第6回「ソフトウェアテスト技法ドリル」勉強会
http://atnd.org/events/18949

ツイートのまとめ
http://togetter.com/li/182805


今回も講義担当・演習担当のお二人にご協力をいただきました。jp_watanabe さん、tosikawa さん、ありがとうございました。演習では、スターバックスコーヒーのメニューと注文方法についての組合せが題材でした。

マイフラペチーノ
http://www.starbucks.co.jp/customize/frappuccino/

ベースとなるフラペチーノによって、コーヒーの量やミルクの量、カスタマイズができたりします。今回はペアワイズ法の勉強なので組合せを実際に作ってみようということでしたが、「何をテストするのか」によって実施したいテストが違ってきます(秋山さんも当日おっしゃっていました)。ということで、僕がいくつか想定した検証目的を書いてみます。

店員の教育テスト
メニューを覚えたか、それぞれのフラペチーノに対してどんな変更やカスタマイズが可能かどうかを覚えているかを確認するための組合せテストが考えられます。この場合は、ありえない組合せも考慮して、被験者が「その変更はできない」と判断できるかも確認すべき事項になってきます。コーヒーの量、ミルクの量、全てのカスタマイズに対して組合せを作成して、いくつか試験するのがよさそう。

食券システムのテスト
スターバックスは食券システムではないですが、学食や牛丼チェーン店のそういうシステムのテストはありえそう。この場合は、食券が正しく印刷されるか、選択したフラペチーノに対して可能な変更ボタンが有効になるかどうか等を確認したい。組合せテストともに、論理関係を考えたテスト(制約を含む)も一度検討したほうがよいと思います。入金の金額や釣銭状態もも条件に含まれそう。

味のテスト
変更やカスタマイズを組み合わせて、仕様となる禁則を決定するためのテスト。少ない組合せ数で、お客様に提供できないような味になりそうな組合せを見つける、といった目的になるでしょうか。


それにしても、こんなカスタマイズは今まで注文したことがないです^^;

| | コメント (0) | トラックバック (0)

WACATE2011 夏 ソフトウェア品質にこだわるエンジニアはぜひ!

若手テストエンジニアと銘打っていますが、実は開発者(設計、プログラミングするエンジニア)も多数参加する「WACATE」。6月のワークショップの〆切が5月末ということなので、ソフトウェアテストのみならず、サービスや製品の品質に興味のある方はぜひともご参加ください。

クロージングセッションの森崎先生のお話も楽しみですが、2日目の細川さんのモーニングセッションも期待。朝からどんなテンションになるのだろうか!

また、夜の分科会ではワークショップでは取り上げない話をお酒を交えながらディスカッション!濃い話が分科会の真骨頂!


WACATE2011 夏 ~誰がためにレポートはある~
http://wacate.jp/2011/summer/gaiyo.html

参加申し込みページ
http://wacate.jp/entry/

WACATEとは?
http://wacate.jp/about.html

| | コメント (0) | トラックバック (0)

より以前の記事一覧