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

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

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

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

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

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

まずは技(わざ)。

Waza

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

次は術(じゅつ)。

Jutsu

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

最後は芸(げい)。

Gei

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

==

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

Stm

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

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

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

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

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

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

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

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

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

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

といったもの。

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

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

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

Photo

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

Photo_4

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

| | コメント (0) | トラックバック (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)

[雑誌]ソフトウェア・テストPRESS 総集編

Vol10と総集編と混同しておりましたm(_ _)m
==


ソフトウェアテストの専門誌の総集編。過去の記事(1号~10号)を含めてCD-ROMに収録。巻頭企画は、大西さん、細川さん、町田さん、湯本さんによる特別座談会。座談会って面白いですね。Software Testing ManiaX でも確か座談会のところがありました。

特集2では、テストエンジニアのためのテスト駆動型開発入門と題して「検証指向TDD」などの記事が掲載されています。スピード感(駆動力)を損なう、単体テストはTDDとは別で実施している、前からこの考え方でTDDを実践している、といった指摘もされますが、プログラミングスキルとテスティングスキルを一緒に伸ばすという意味では十分面白い試みだと僕は思っています。例えば小さなロジックを組んで、そこでの最低必要なテスト条件数が見えていれば、必ずソフトウェア品質も上がるし、他者のコードの気持ち悪いところが見えやすくもなるでしょう。

TDD研究会
http://sites.google.com/site/tddstudygroup/

| | コメント (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)

[イベント]受付開始! WACATE2011 夏 ~誰がためにレポートはある~

今年も若手によるソフトウェアテストワークショップ「WACATE2011 夏」が開催されます!僕も当日は会場にいますので、興味のある方はぜひご参加を。

http://wacate.jp/2011/summer/gaiyo.html

==

WACATE(Workshop for Accelerating CApable Testing Engineers)...

この「ワカテ」は若手テストエンジニアを中心に企画された、若手テストエンジニアのためのワークショップです。

2007年12月に第一回のワークショップを開催してから3年が過ぎました。これまでに参加した数多くの若手エンジニアの皆様に、そして自身の知見・経験を継承するためにご協力いただいたベテランエンジニアの皆様に、この場を借りて御礼申し上げます。ありがとうございます。これからも、若手が主体的に活動できる場の創出を目指し、実行委員一同精進していく所存でおります。

さて、2011年の夏も「WACATE2011 夏」を開催します! 夏のWACATEのコンセプトは、一つのテーマを「狭く深く」。合宿形式の二日間、ソフトウェアテストやソフトウェア品質について学び、考え、語り合いましょう。一人ではできなかった経験がグループワークを通じて得られるかもしれません。自分と同じ課題を持った仲間と目標を共有できるかもしれません。実行委員会は、ディナーセッションや分科会など参加者同志の交流を深められるようなプログラムを準備しております。

WACATE2011 夏はサブタイトル「誰がためにレポートはある」です。ソフトウェアテストの経験がある方ならば、誰もが「インシデントレポート」を作成したことがあると思います。プロジェクトのさまざまな立場で利用されるこのレポートを、合宿の二日間でグループワークや実際のテスト対象を扱いながら、皆さんにはカイゼンしていただきます。

そして、恒例のクロージングセッションでは、レビュー・インスペクションの分野でご活躍されている森崎修司氏(国立大学法人 奈良先端科学技術大学院大学、静岡大学)をお迎えし、ご自身の活動や研究事例についてお話しいただきます。

なお、本ワークショップは若手中心となっておりますので、前回同様若手の参加を優先させていただく予定ですが、ベテランが持つ知見の継承を行う場としてもご活用頂きたく、幅広い層の方々に参加いただけるとありがたく思います。また、若手の気持ちを持ったベテランの方々の参加も歓迎しております。


開催概要
WACATE2011 夏 ~誰がためにレポートはある~

■主 催 WACATE実行委員会
■日 時 2011年6月25日(土) 9:00 受付開始
      2011年6月26日(日) 16:30 終了
     (1泊2日 4食付き)
■会 場 マホロバ・マインズ三浦
      神奈川・京浜急行三浦海岸駅徒歩5分
      http://www.maholova-minds.com/

メディアサポーター
gihyo.jp
ソフトウェアテストPRESS
@IT自分戦略研究所
Tech Village
Interface

合宿費
35歳以下(若  手):¥22,000
36歳以上(ベテラン):¥25,000

※宿泊費、宴会費、25日朝食、25日26日昼食、会場費、印刷費、その他運営にかかる事務費含む(キャンセル不可)

合宿費は開催当日受付にて、現金でお支払いください。引き換えに領収書を発行いたします。

プログラム
25日9時受付開始(9時30分開会)、26日16時30分ごろ終了予定です。
詳細についてはプログラム内容をご確認ください。


参加募集人数
48名を予定しております。


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


25日の宿泊について
25日の宿泊は3名~5名程度の相部屋となります。これは参加者同士の交流を深めていただく施策となります。
※男性と女性は別の部屋となります。


問い合わせ先
WACATE2011 夏 についてのお問い合わせは以下にお願いします。

query@wacate.jp


WACATE2011 夏 実行委員会

実行委員長
山崎  崇 (WACATE実行委員会)


副実行委員長
小山  竜治(WACATE実行委員会)
坂   静香(WACATE実行委員会)


実行委員
井芹  洋輝(WACATE実行委員会)
上田  卓由(WACATE実行委員会)
近江 久美子(WACATE実行委員会)
奥村  健二(WACATE実行委員会)
加瀬  正樹(WACATE実行委員会)
加文字 諭 (WACATE実行委員会)
川西  俊之(WACATE実行委員会)
澤田  悠介(WACATE実行委員会)
武市  喜博(WACATE実行委員会)

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

CFD法の流れ図の見つけ方

CFD法の補習会を企画中。

==

drawCFDではデシジョンテーブルを自動生成するわけではなく、作成者が「流れ」を描くことでデシジョンテーブルの1列(1ルール)が追加されていく。秋山浩一さんに教わった流れ図の描き方を下記の例題で試してみる。

1.横浜ベイクォーター
1店舗3,000円(税込)以上のお買上げで1時間無料 ※駐車券を売場でご提示ください。 2店舗目以降も各店舗3,000円(税込)以上のお買上げで 1時間の駐車サービス券をお渡しします。

2.そごう横浜店

2,000円(税込)以上のお買上げで1時間30分無料
※駐車券を売場でご提示ください。

Cfd3

# 前回の記事とはちょっとだけデシジョンテーブルの順番が違ったり、有効・無効が違いますが、描き方の例としては問題ないかと。



  1. 結果は何か

  2. 今回は駐車料金、特に「駐車料金がどれだけ無料になるか」を確認することが目的。1時間無料、1時間半無料、2時間無料、・・・、無料でないといった結果が考えられる。2時間無料以降は、N時間無料とした(Nは2以上の正数、以後も同じとする)。ということで、「N時間無料」「1時間半無料」「1時間無料」「無料でない」の4つの結果をお得な順序で上から配置した。


  3. 有効結果と無効結果を決める

  4. 4つ結果すべて有効結果ともみなせる(無料でない場合は、次にいくらになるかの処理に進むため)が、今回は「無料でない」は無効結果とした。drawCFDでは右クリックで有効結果・無効結果を切り替えられる。


  5. 横浜ベイクォーターでの買い物に関する同値図を描く

  6. 仕様ではまず、「横浜ベイクォーター」での買い物金額について言及しているので、この条件を(完全)同値分割する。

    この入力条件が引き起こす結果としては、「1時間無料券がN枚」「1時間無料券が1枚」「無料でない」の3つ。ということは同値分割も3つになりそうだ。ということで「N店舗で3000円以上買い物」「1店舗で3000円以上買い物」「どの店舗でも3000円未満の買い物」となる。文言は少し変えました。


  7. 横浜そごうでの買い物に関する同値図を描く

  8. 次に判定するのは、「横浜そごう」での買い物金額について。ここでの買い物が影響を及ぼす結果としては、「1時間半無料」「無料でない」の2種類。ということで、「2000円以上の買い物」「2000円未満の買い物」の(完全)同値分割を考えた。同じく、文言は少し変えました。


  9. 有効系同値クラス、無効系同値クラスを決める

  10. どれも有効系同値クラスとした。


  11. 流れを描く

  12. 流れ図は、結果から探していく。上に配置された結果からそこにつながる流れを以下の手順で見つけていった。


    N時間無料」の結果になるのは?


    仕様から、横浜ベイクォーターでN店舗で3000円以上の買い物をした場合、とわかる。横浜そごうでの買い物は関係しないので、
    IF ベイクォーター is N店舗3000円以上
     THEN N時間無料



    N時間無料」の結果になるのは?


    他の条件はない。ということで「N時間無料」に結ばれる流れはこれでおしまい。


    「1時間半無料」の結果になるのは?


    仕様から、横浜そごうで2000円以上の買い物をした場合、とわかる。では、そのひとつ前の「ベイクォーター」同値図のどこから結ばれるか?
    「N店舗3000円以上」だと、結果が「N時間無料」となるので、ありえない。
    「1店舗3000円以上」だと、ありえる。ということで、
    IF ベイクォーター is 1店舗3000円以上 AND 横浜そごう is 2000円以上
     THEN 1時間半無料



    1時間半無料」の結果になるのは?


    仕様から、横浜そごうで2000円以上の買い物をした場合、とわかる。では、そのひとつ前の「ベイクォーター」同値図のどこから結ばれるか?
    「N店舗3000円以上」だと、結果が「N時間無料」となるので、ありえない。
    「1店舗3000円以上」だと、ありえる。でもさっき通った。
    「3000円を超えない」だと、ありえる。ということで、
    IF ベイクォーター is 3000円を超えない AND 横浜そごう is 2000円以上
     THEN 1時間半無料



    1時間半無料」の結果になるのは?


    他の条件はない。ということで「1時間半無料」に結ばれる流れはこれでおしまい。


    「1時間無料」の結果になるのは?


    横浜そごうで2000円以上の買い物をした場合、1時間無料ではなくなるので、「2000円を超えない」を通ることがわかる。では、そのひとつ前の「横浜ベイクォーター」同値図のどこから結ばれるのか?
    「N店舗3000円以上」だと、結果がN時間無料」となるので、ありえない。
    「1店舗3000円以上」だと、ありえる。ということで、
    IF ベイクォーター is 1店舗3000円以上 AND 横浜そごう is 2000円を超えない
     THEN 1時間無料



    1時間無料」の結果になるのは?


    横浜そごうで2000円以上の買い物をした場合、1時間無料ではなくなるので、「2000円を超えない」を通ることがわかる。では、そのひとつ前の「横浜ベイクォーター」同値図のどこから結ばれるのか?
    「N店舗3000円以上」だと、結果がN時間無料」となるので、ありえない。
    「1店舗3000円以上」だと、ありえる。でもさっき通った。
    「3000円を超えない」だと、ありえない。ということで、他の条件はない。


    無料でない」の結果になるのは?


    横浜そごうで2000円以上の買い物をした場合、ありえないので、「2000円を超えない」を通ることがわかる。では、そのひとつ前の「横浜ベイクォーター」同値図のどこから結ばれるのか?
    「N店舗3000円以上」だと、結果がN時間無料」となるので、ありえない。
    「1店舗3000円以上」だと、結果が1時間無料」となるので、ありえない
    「3000円を超えない」だと、ありえる。ということで、
    IF ベイクォーター is 3000円を超えない AND 横浜そごう is 2000円を超えない
     THEN 無料でない



    無料でない」の結果になるのは?


    他に条件はない。ということで終了。




以上のような考え方で作成しました。最後に確かめ作業があるのだろうが、いまいちわからなかった。。。

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

«CFD法で同値図の順序を変えてみた