[イベント]WACATE 2009 冬 ～基礎・おぼえていますか～ 参加申し込み開始

年2回開催される「WACATE」が今年の12月に開催です。定員は48名ですが、前回は60名の応募があったので、すぐに満席になるかも？

　WACATE 2009 冬　開催概要

　参加申し込み

開催概要

WACATE 2009 冬　～基礎・おぼえていますか～【主　催】 WACATE実行委員会
【日　時】 009年12月12日（土）　9:00　受付開始（予定）　2009年12月13日（日）　16:30　終了（予定）　（1泊2日　4食付き)
【会　場】 マホロバ・マインズ三浦　神奈川・京浜急行三浦海岸駅徒歩5分
　　　http://www.maholova-minds.com/

協賛（予定）
NPO法人 ソフトウェアテスト技術振興協会（ASTER）

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

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

プログラム
12日9時受付開始（9時30分開会）、13日16時30分ごろ終了予定です。プログラム内容の詳細につきましては、WACATE-Webに随時掲載＆更新していきます。

http://wacate.jp/2009/winter/program.html

参加募集人数
先着合計48名を予定しています。

参加にあたってお持ちいただくもの
・合宿費（受付時にお支払いいただきます）
・筆記用具一式（演習などで使用します）
・予習に利用した書籍や論文、参考となる情報
・名刺（受付時の本人確認と当日の参加者交流のため）

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

　query@wacate.jp

実行委員会
実行委員長
　池田　　暁　（日立情報通信エンジニアリング）

副実行委員長
　山崎　　崇　（WACATE実行委員会）

実行委員
　安達　　賢二（WACATE実行委員会）
　奥村　　健二（WACATE実行委員会）
　加瀬　　正樹（WACATE実行委員会）
　加文字　諭　（電気通信大学大学院）
　川西　　俊之（WACATE実行委員会）
　河野　　哲也（電気通信大学大学院）
　小山　　竜治（WACATE実行委員会）
　澤田　　悠介（WACATE実行委員会）
　武市　　喜博（WACATE実行委員会）
　西　　　康晴（電気通信大学）
　坂　　　静香（WACATE実行委員会）
　村上　くにお（WACATE実行委員会）
　森　　　孝夫（WACATE実行委員会）

アドバイザ
　猪股　　宏史（WACATE実行委員会）
　原　　佑貴子（WACATE実行委員会）

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

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

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

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

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

今回の勉強会で学んだ、

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

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

結果から探してみる

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

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

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

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

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

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

状態遷移表と論理決定表で機能図式

状態遷移図を工夫してみるの続き。

コメント欄にて教えていただいた「機能図式」を自分なりに少しまとめてみて、そのあとで例題に適用してみようと思います。

機能図式とは、ソフトウェア機能仕様を

「入力データ」と「入力順序」を状態遷移モデル

「入力データ」と「出力データ」と「遷移先状態」を論理モデル

を使って表現することを指しています。
機能図式の記法については、論文を参照してください。基本的には状態遷移図、原因結果グラフ、デシジョンテーブルの記法の組み合わせ。

では、メール一覧のアプリを例にとって実際に機能図式を作ってみる。

仕様を箇条書きでまとめると、以下のようなアプリケーションです。

1. デスクトップのアイコンをダブルクリックして、アプリが起動


2. メールが1通もない場合は、メールがない旨の表示


3. メールがあればメール一覧をリスト表示。5通ずつのページング表示で、必要に応じて「前リンク」「次リンク」が表示


4. 前リンクをクリックすると、前のページの5通を表示。次リンクをクリックすると、次のページの5通を表示


5. （上図にはないが、）右上の[x]をクリックするとアプリ終了

このメール一覧のアプリを機能図式で表現すると、まずは状態遷移部がこのようなグラフとなる。

また、論理関係部はこのようなテーブル（決定表）となる。

決定表の各列にはパス名としてPxxを名付けてみました。
テスト経路作成基準は論文中では「全遷移を少なくとも1回、ループについては0回と1回の2通りを実現する」とある。論文には具体的なテスト経路作成アルゴリズムも紹介されているが、まだ消化不良なので、今日はここまで。

状態遷移図を工夫してみる

簡単な状態遷移図を作ってみるの続き。

メールソフトを起動するときに、メールがある場合とない場合で初期画面が異なります。この部分についての状態遷移図はどうやって作るか。僕の場合は観測できない状態を１つ用意して、内部イベントの違いによって遷移を分ける方法をとっている。

実際には「メールが5通以下」「メールが6通以上（すなわち、次リンクが表示される）」「メールがない」の3パターンが考えられるので、「S1→(S2)→S3」「S1→(S2)→S4」「S1→(S2)→S5」の3パスが表現できる状態遷移図を作成。ここでは観測できない状態S2を終了状態にはできないので、実際のテストケースを作成するときには、少し注意が必要。

ただし、分岐条件が複雑になった場合はこの手法だけでは難しくなってくる。たとえば、「インストール後最初の起動時にはお知らせ画面を表示する」とか、「未読メールがある場合はその旨を通知するダイアログを出す」とか、そういった仕様があったとすると、どうします？

そこで「機能図式」という考え方へ進んでいきます。続く～。

簡単な状態遷移図を作ってみる

状態と遷移とイベントとアクションの続き。

具体的に状態遷移図を作ってみますかね。一つ目は比較的シンプルなもの。

「電源ボタン」と「強さボタン」をもつヒーター

電源ボタンを押すと、電源のON/OFFが切り替わり、強さボタンを押すと、「強」「弱」が切り替わるヒーターです。

状態は「電源OFF」「電源がONで、強さが弱」「電源がONで、強さが強」の3つ。イベントは「電源ボタンを押す」「強さボタンを押す」の2つ。

では、こちらはどうでしょうか。

メールソフトのメール一覧機能

デスクトップにアイコンがあって、ダブルクリックすると起動するメールソフトですが、メールが受信箱にある場合とない場合とで、初期画面がが異なります。

上の図はメールソフトの起動時のみを表現したものです。が、状態遷移図は、状態とイベントが一つ決まれば遷移先の状態とアクションも決まる、はず。でも、この図を単純に状態遷移図にしたら、ちょっとへんですね。左の状態では「次>>」というイベントが可能ですが、左の状態では不可能のようです。みなさんは、どんな状態遷移図を考えますか？

状態の洗い出しへHAYST法かpairwise法の適用

状態遷移モデルを使ったソフトウェアテストを勉強するためのテキストとしてボーリス・バイザーの「ソフトウェアテスト技法」「実戦的プログラムテスト入門」などを読んでみた。手順の最初に出てくるのが、仕様書からの状態とイベントの洗い出し作業。そもそも状態遷移図や状態遷移表を作ることって設計工程のツールなので、上流工程でのこういった作業が作りこみを減らすことにつながる。

で、ソフトウェアテスト技法のほうで状態の数を探るところ（第11章　4.2）があるのだけれど、具体例としてエンジンを題材にして、

ギア　　　（R、N、1速、2速、3速、4速）　＝　6要素
進行方向　（全身、後退、停止）　＝　3要素
エンジン　（動作中、停止）　＝　2要素
トランスミッション　（正常、異常）　＝　2要素
エンジン　（正常、異常）　＝　2要素

合計　＝　144要素

という記述がある。ここでいっている不可能な状態への考察って、禁則の考え方じゃないのかしら？だとすると、HAYST法を使って状態を絞り込むことができるのかな。ただ、本質的には同じことだけどHAYST法（＝直交表）の特徴である、「どの条件も同じ程度出現する」というのはいらないので、pairwise法のほうが状態数が少なくなるのかな。

ソフトウェアテスト技法―自動化、品質保証、そしてバグの未然防止のために

posted with All Consuming at 2008.12.27

by ボーリス バイザー
日経BP出版センター
定価： ￥ 5,607

Amazon.co.jp で詳細を見る
ブックオフオンラインでチェックする
All Consuming でブログの評判を見る
crossreview のレビューを見る

実践的プログラムテスト入門―ソフトウェアのブラックボックステスト

posted with All Consuming at 2008.12.27

by ボーリス バイザー
日経BP社
定価： ￥ 4,095

Amazon.co.jp で詳細を見る
ブックオフオンラインでチェックする
All Consuming でブログの評判を見る
crossreview のレビューを見る

状態と遷移とイベントとアクション

状態遷移図や状態遷移表を使う場合（ここでは状態遷移モデルを扱う、と同義）に、まずは構成要素である「状態」「遷移」「イベント」「アクション」を確認しておこう。

• 状態
• 遷移
• イベント（入力）
• アクション（出力）

状態とは、状態遷移モデルでも通常の言葉と同様の意味で使われ、「システムの当分の間の状況と特性」というとらえ方をする。基本的な考え方としては状態は同時にはただ一つしかありえない。排他型と並列型という状態のとらえ方もあるが、ここでは割愛する。たとえば、「電源がOFFである/ONである」「インターネットが切断状態である/接続状態である」「検索状態である/検索結果表示状態である」など。

遷移とは、ある状態からある状態へ状態が移り変わることを表す。たとえば、「電源が（電源ボタンを押したことで）OFF状態へ遷移する」「インターネットが（認証成功によって）接続状態へ遷移する」「（検索結果が確定して）検索結果を表示する」など。

イベントとは、遷移をもたらす外的刺激や内的変化などを表し、入力とも事象とも表現される。ひとつのイベントは一つの遷移を決定するが、それらはイベント発生時の状態によって変化する。場合によっては、イベントはシステムに関するものではなく、システムのユーザへの刺激で表現される。たとえば、「電源ボタンを押す」「接続の認証が成功する」「検索クエリーのレスポンスが確定する」「○○さんに連絡する用事が発生する」など。

アクションとは、遷移の結果生じる分析が可能な対象物を意味し、入力と対照的に出力とも表現される。混同されやすいが、アクションと遷移後の状態は区別される。ただし、出力も遷移後の状態も同じ名称で表現されることが多いのは確か。たとえば、「（電源がONに遷移して）ディスプレイが点灯する」「（接続の認証が成功して）アイコンが点滅する」「（検索結果が確定して）検索結果が表示される」などである。

さて、これらのうち「状態」「遷移」「イベント」を使って、状態遷移図と呼ばれるグラフを作成してみる。

一般的には、状態はマルで表現して、中に状態名を記述する。ただし、必要なのはモデルであるため便宜上はS1,S2などと記載される。遷移は矢印で表現され、始点は遷移前の状態と、終点は遷移後の状態と接している。イベントは状態同様にE1,E2などで省略され、対応する遷移（矢印）のそばに記述する。

あれ、アクションがでてきません。アクションは状態遷移表で記述しましょう。今日はここまで。

[サイト]SEのためのソフトウェアテスト再入門

SEのためのソフトウェアテスト再入門　第1回「あなたのテスト、単なる動作確認になっていませんか？」

「どんなテストケースを書いたらよいか分からない」「自分のやっているテストに自信が持てない」そんな悩みをお持ちの方は多いのではないでしょうか。テストは、技術や経験を必要とするたいへん奥の深い世界です。この連載では、皆さんが今後開発を行っていく上での、ヒントや指針となる「テストのマインド」を紹介していきます。

こんなサイトができていました。テストの意図は明確に。僕の中では「動作確認」と「テスト」は包含関係かなあ。

データフローテストを調べてみる

制御フローテスト、データフローテスト、トランザクションフローテスト、業務フローテスト。○○フローテストっていろいろあるけど、あんまりきちんと勉強したことがない。まずはデータフローテストを勉強してみようかと。同値分割や境界値分析はテストエンジニアが本能的に使ってたりするといいますが、このデータフローテストはレビュアーが本能的に使ってたりするのかなと思います。

（「本能的に使っている」ということが、どれほど危ういスキルなのはか、最近しみじみ思います＾＾；）

まずはGoogleで検索してみたが、1ページ目ではほとんど解説ページは検索できないです。ソフトウェアテスト関連書籍の目次なんかが多いですね。

ということなので、手元にはバイザー本があるのでそこからまず読みましょうかね。

レビュー設計

TEFの過去ログを1から見直そう、という活動が若手テストエンジニアの何名かで行われてます。僕のその「探検家」の一人ですが、今日は「レビュー設計」という言葉を見つけました。（設計レビューではないです）

テスト（あるいは動的テスト）という大きなアクティビティでは「分析」「計画」「戦略」「設計」「実装」「評価」というステップがありますが、レビューについてはそういったステップわけというをあまり聞いたことがありませんでした（ググってもあまり見かけないのでこの感覚は一般的かも）。過去ログを読みつつ、もんもんと考えていて、いくつか記事の中にもあったキーワード・ポイントを自分なりに整理してみました。

レビュー設計とレビュー指摘項目とガイドライン

テスト設計というのは分析した結果を元に、たとえば、ここでは論理が複雑なのでデシジョンテーブルを使おう、そこでは状態遷移が複雑なのでk-スイッチテストを使おう、といった戦略をより詳細にブレークダウンしたもの。レビューというアクティビティも同型だと考えると、たとえば、このコードについてはメンバー内ピアレビューで、このドキュメントはインスペクションで、このコード群はコミット後コードレビューもやろう、といった作業かなと。レビュー指摘項目は、より細かい勘所という意識で「変数参照に着目せよ」とか「入出力周りに着目せよ」など。ガイドラインはどちらかというと「心構え」なのかなあと考えました。

レビューと検査の違い

検査は問題を指摘することで、レビューは知恵を出し合う場・議論、という考え方があった。これについては自分の中の定義と少しギャップがあった。もしかしたら、広義のレビュー＝検査（問題を指摘し、議論・解はのちほど）＋狭義レビュー（プレゼンテーションとディスカッション）、みたいなイメージのがしっくりくるかな。

指摘本位とディスカッション本位

「限られた時間で問題をどんどん指摘してもらう」という考え方と、せっかく知恵袋が集まってるんだから、レビュー対象（やレビュー対象作成者）を練って練って練りまくるという考え方。目的には違いがあるが、レビュアーの限りある時間を頂戴する＝効率よく目的を達成させる、という前提は一緒か。前者は短期的な視点（このプロダクト・プロジェクトでの品質向上）で、後者は中期的な視点（このプロダクト・プロジェクトも品質向上させつつ、ディスカッションによる参加者の品質？向上）だろうか。

ブラックボックスレビューとかホワイトボックスレビューとか、いろんな用語をs/テスト/レビュー/gにしてみたらどうなるかな。

# ちなみに過去ログ連番だと「4098」あたりの話題。
# 全部見終わってないので、この続きがまだあるのかもしれない。