うえだ＠北の蒼い流星です
5/31の第三回「HOTATEw」ワークショップが完了しました。
なんと２７名もの参加者が集まりました！
大盛況で熱のこもった議論が繰り広げられましたよ！
懇親会（という名の飲み会）も大いに盛り上がりました。
今回のお題は
「テスト技法の基礎をじっくり学ぶ」シリーズの第二回目
「状態遷移技法」
でした。
会場の参加者も殆どが「聞いたことがある」技法ですが、
「使いこなせている」という人は殆どいませんでした。
なんででしょう？
その秘密を紐解くワークショップ・・・だと勝手に思ってました（笑）
例題は、ありがちな
「ビデオデッキ」
です。
再生、停止、一時停止のボタンが付いたビデオデッキで
ビデオの状態とボタンを押下した時の動作を、状態遷移【表】と【図】で整理して
テストに繋げます。
・・・これは分かりやすいですね。
イベントと状態の関係が一目瞭然だし、
テスト対象が「ビデオデッキ」という普遍のものなので。
さて、この例題を理解して貰ったところで、
ワークショップのお題は・・・・
我々が考えた架空のゲームソフト
「キノコを食べると大きくなる、ヒゲの生えた土管工事オヤジのゲーム」
です。
ええ、実在しない、架空のゲームですからね（笑）
・キノコを食べると大きくなる
・花を食べると火を投げることが出来る
・星を取ると無敵になる
・敵に当たると、小さいヒゲオヤジは死亡
・大きいヒゲオヤジと火を投げるヒゲオヤジは敵に当たると小さくなる
・穴に落ちたりタイムアップになるとどんなヒゲオヤジも死亡
・無敵ヒゲオヤジは敵にあたっても死なず、敵が死亡
・ヒゲオヤジは３人。全員死亡でゲームオーバー
・残りヒゲオヤジが１人以上残っていた場合は、小さいヒゲオヤジからリスタート
あとの仕様は勝手に考えるか、かの有名な大ヒットゲームに準じてください（笑）
というわけで、
「ヒゲオヤジに降りかかるイベントと、ヒゲオヤジの状態についての関係をテストしたいので
状態遷移図と状態遷移表を作ってください」
というお題。
架空のゲームのはずなのに、なぜかみんな知ってる雰囲気でしたが、
議論はチームごとに大盛り上がり。
状態遷移【図】を書くに当たって、今回の仕様で難しい点が
「ヒゲオヤジ自身の状態に関わらない仕様」
が入り込んでいるところがミソでした。
そこを「どう扱うか」、または「適用範囲をどこにするのか」で
各チームの個性が出たと思います。
「ヒゲオヤジの状態」と「ゲーム全体の状態」に分けたチームもあれば
「ヒゲオヤジの生存の状態」と「死んでいる状態」に分けたチームもあり、
そもそも「死亡」を「状態」にするチームもあれば「イベント」にするチームもあり、
様々でした。
たぶん、組込で良く使われるこの「状態遷移」技法がアプリ系で使いづらいのは
状態遷移の「対象」が移り変わるからなのかもと思いました。
また「対象」と外の世界の境界が曖昧だったり、「対象」に降りかかる「イベント」の
分析も難しいからかと。
ただ、ここを上手く処理できれば、アプリ系でも状態遷移が使えるのかと。
具体的には
『確認対象を明確にする』
⇒「ヒゲオヤジ」自身なのか、さらに上位の「ゲーム全体の状態」なのか
状態の「レイヤー（層）」を揃えることが大事ですね。
また、「同じように見える状態でも、内部的には違う」事も
状態遷移の確認対象です。
星を取った後の「無敵ヒゲオヤジ」の状態も、実は
「元小さいヒゲオヤジ」「元大きいヒゲオヤジ」「元火を投げるヒゲオヤジ」
の三種類いるんですね。
これを分けるか分けないかは「同値分割」と同じ話でしょう。
要は、テスト目的に応じた「ズームイン／アウト」で決定するのが良いのかと。
また、状態遷移【図】は基本的に「パス」の確認に使います。
C0網羅やC1網羅、Nスイッチ網羅などの基準を用いて
「パス」経路による不具合を見つけます。
これにより、同じ状態でも内部的には異常が起きているバグの
発見率が高まると思います。
たとえば、有名（？）な「ちびファイヤーヒゲオヤジ」の裏技。
大きいヒゲオヤジが敵に当たりながら面をクリアすると、次の面は
小さいヒゲオヤジからスタートしますが、どうにも内部的には
「大きいヒゲオヤジ」として認識されてしまうようで、次に「花」を取ると
小さいまま火を投げることができます。
この裏技（バグ）も、状態の「パス」を意識すれば発見できたのかもしれませんね。
うって変わって、次は状態遷移【表】。
イベントと状態の総当りを記入していきます。
これも、【図】同様に「レイヤー（層）」を意識しないと
無駄な組合せや意味の無い組合せが出現したりします。
複数の表を作ってるチームもありましたね。
この状態遷移【表】の良さは
『想定していなかったイベントと状態の組合せ』が発見できることです。
設計やレビュー時に使うと、「こんなこと考えてなかった」といった組合せが
発見できます。
今回の例だと
「小さいヒゲオヤジが花を取ったらどうなる？」
「星を取って無敵になった状態でもう一回星を取ったらどうなる？」
といった組合せ。
もし仕様が考慮されていないのなら指摘しますし、テスト時には
バグの潜んでいそうなピンポイントテストで使えそうです。
また、例えば「大きいヒゲオヤジがキノコを取ったら？」という組合せに対して
「ありえない組合せ」と記入したチームもありましたが、ヒゲオヤジ側では
全てのイベント入力を考慮しないといけないといういう意見もありました。
（防御的設計）
状態遷移【表】は、仕様の漏れを発見するほかに
「遷移しないこと」
の確認に絶大な効果があると思いました。
人は「状態が遷移すること」の試験には必死で取り組みますが、
「遷移しないこと＝イベントを起こしても状態が変わらないいこと」の試験には
あまり気が向かないと思います。
普通は、遷移しないことは仕様からは直接読み取れないので、
こういった「技法」を用いて仕様の「裏」を意図的に見つめる必要がありそうです。
火を投げるヒゲオヤジは、いくら花をとっても状態は変わらないのです。
（点数は増えるけど ⇒たぶんそれは違うレイヤー）
あと、状態遷移で書くにくいところ（ヒゲオヤジのゲームオーバー条件）とかは
無理しないで、文章とフローかで書きましょう。
こういうところで無駄な神経と時間を費やすのは無駄です（笑）
というわけで、
・状態遷移【図】と【表】は用途が違う
・アプリ系で使うには「レイヤー」の整理が必要（ソフト／ハード／外の世界含めて）
・状態遷移図は、パスを考慮して内部の不具合を炙りだせ
・状態遷移表テストは実は「状態遷移しないテスト」
・書ける箇所だけかきましょう
・書いて嬉しい時に書きましょう
というわけで、結局今回も全ての内容が出来なかったので、
また次回に持ち越しです。
テスト技法基礎編、最終夜、
「デシジョンテーブル」
でお会いしましょう！
講師は、世界の「MAQ」氏です！
ソフトウェアテストのワークショップ
「HOTATEw」の第３回目を実施します。
前回、ワークショップ、懇親会共に大盛り上がりを見せた
「テスト技法」についてのワークショップです。
参加してみたい！と思う方は
会社名、お名前、お電話番号を記載の上
以下のアドレスに送信ください。折り返し連絡させていただきます。
tefdoblog@gmail.com
【開催要領】
--------------------------------------------------------------
北海道テスト勉強会（TEF-DO）公開ワークショップ
・開催日時：5/31（火）午後7時～9時まで（終了時間は予定）
・実施内容：テスト技法の基礎中の基礎をワークショップで再確認【Part2】
～本当にその技法、理解できてますか？その２～
・場所：札幌市中央区北3条西4丁目 日生ビル21階
東京エレクトロンソフトウェアテクノロジーズ会議室
・待ち合わせ場所：会場の21階エレベーターホール
当日18:50～18:55に集合
・資料：こちらで準備し、当日配付します
・持参：筆記用具
・参加費：無料
※ワークショップ後に懇親会も予定しています。
会場近くの居酒屋で、21:30～23：30の予定。
予算は3,000円程度です。
参加できる方は、事前もしくは当日にご連絡下さい。
--------------------------------------------------------------
前回のワークショップでは「同値分割」「境界値分析」という、
非常に基本的な技法を実践しながら議論していただきましたが、
イザ使うとなると非常に難しく、奥深いことに気づかされました。
http://ameblo.jp/tef-do/entry-10877993928.html
今回は「テスト技法」の後半です。
状態遷移とデシジョンテーブルを中心に、
技法の「使いかた」「使いどころ」「効果」
の議論が進むといいなと考えています。
みなさんは、本などで良く見聞きする「基本的なテスト技法」を
本当に使いこなせていますか？
結構、現場では使えてない事が多いように思います。
「完璧な答え」は誰も持っていないので、
我々も含めて全員で取り組んでいきましょう！
うえだ＠日本ビール党です
というわけで、第二回「HOTATEw」ワークショップが終了いたしました。
日時：2011/4/27
会場：東京エレクトロンソフトウェアテクノロージーズ様
一般参加者：７名（６社）
TEF道：５名
今回のテーマは「テスト技法の基礎中の基礎」をワークショップで
体験してみる事でした。
前回のお題は「技法とは何か？」でした。
「技法」を設計してみるというメタなワークショップでしたが、今回は
実際に「技法そのものを学んでみる」というお題です。
今回予定していた技法は
「同値分割」
「境界値分析」
「デシジョンテーブル」
「状態遷移」
の４つ。
本などで良く見かける技法たちばかりです。
実際に参加者の殆どがその名を知っている技法ばかりです。
でも、実際に現場で使えていない事が多いようです。
まずは、「同値分割」
例題を元に内容を説明して、演習へ。
お題は「エクセルのフォントサイズを変更する機能」の同値分割。
ドロップダウンで選択可能な数字
6,8,9,10,11,12,14,16,18,20,22,24,26,28,36,48,72
を提示します。
最初は上記数字の「同じグループの分割」を議論していた各チームも、やがて
「操作はドロップダウンだけじゃないのでは？」という議論に発展。
システムへの「入力」をユーザーの「操作」に拡張した時に、目に見える値だけでなく
入力可能な全ての数値に広がります。さらに「入力不可」な値も考慮する必要が出てきます。
各チームから出てきた内容をざっくりまとめると・・・・。
・ドロップダウンで選択可能な数値グループ
・ドロップダウンで選択できないが、直接入力が可能なグループ
⇒ドロップダウン選択可能値の間の値
⇒ドロップダウン選択可能値の最小値未満
⇒ドロップダウン選択可能値の最大値未満
・少数以下の値を持った値
・ドロップダウンの数値の増え方に着目
⇒１ずつ増えるグループ
⇒２ずつ増えるグループ
・無効値
⇒数字以外
⇒空白入力
・入力方法の同値
⇒数値入力グループにも、「直接入力」や「コピペ」がある
⇒ドロップダウンの選択グループにも「マウス選択」や「F4押下」がある
ここで、全員で議論。
・アウトプットをイメージする必要があるのでは？
⇒フォントサイズを変更した結果が、果たしてエクセルのセルだけだろうか？
印刷やプレビューもアウトプットに当たらないだろうか？
もしかしたら、「印刷」というアウトプット観点でインプットを分析した時に
別の同値分析が出てくるのではないだろうか？
・「コピペ」などの操作を「同値」として扱うには違和感があるが・・・
⇒システム的には「操作」も「値」で扱っていると考えてはどうか？
⇒「同値分割」ではなく「同類分割」というふうに考えても良いのでは？
・数値の増減が「変化する」箇所は別に扱っても良いのでは？
⇒8,12,28など
・その他
⇒データ型に注目すると、1～16や～256なども同値クラスになるかもしれない
⇒数値を文字コードに着目すると、別の同値クラスになるかも
・まとめ
⇒テストの「目的」や「テストフェーズ」によって、同値の「ズーム」が変わってくる。
⇒正しい答えは、この時点では出せない
⇒利用者や発注元やプロジェクト内容をよく考慮する必要がある
⇒インプットだけじゃなく「アウトプット」の整理も必要
⇒同じような「動作結果」が予想されるインプット項目（数値とは限らない）をグループ化
「同類分割」という言葉は自分的に「ヒット」でした。
「同値」の「値」にこだわりすぎると、利用シーンが限定されるのかなと。
現場で「あまり使えてない」理由ってこの辺りにあるのかなと感じました。
ちなみにこの問題、私が「WACATE」で体験したワークショップの内容を参考に
改編して題材にさせていただきました。
次のお題は、「境界値分析」。
その名を知らなくても、開発経験者なら直感で
「境界はバグが出る」と知っていると思います。
お題は「年月分秒」をセットしてアラームを鳴らすアプリケーション。
議論
・まずは同値分割をして、その境界値を見つける
⇒なので、「同類分割（数値じゃない同類グループ）」の境界分析もアリか？
⇒境界値分析にも流派アリ。
⇒同値分割から境界分析するか、境界値を見つけ出してその上値と下値をみつけるかの違いではないか
・同値分割は「テストケースを圧縮する」技法だが、境界値分割は「ピンポイント」の技法
ちなみに、各班の回答。
A藩
月 0｜1、12｜13
日 0｜1、28｜29｜30｜31｜32
時 -1｜0、1、23｜24
分 -1｜0、1、59｜60
K藩
月 0｜1｜2、11｜12｜13 + (空白)
日 0｜1｜2、30｜31｜32 + (空白)
27 ｜28｜29
時 0｜1｜2、22｜23｜24 + (空白)
分 0｜1｜2、58｜59｜60 + (空白)
B藩
日 -1、0｜1、12｜13
月 -1、0｜1、28｜29｜30｜31｜32
時 -1｜0、1、23｜24
分 -1｜0、1、59｜60
K藩は、正常境界の【一つ内側】も境界値としていますね。（11月など）
また、【27日】を境界値とするかで、各藩の同値分割の違いがあらわれますね。
全体的に、演習に関しては仕様や背景を曖昧にしてありました。
参加者が自ら「テストの目的」や「いま行なっているテストフェーズ」を
議論して欲しいからです。
それは、テスト技法は「使い方」や「使いどころ」を考えることが大事であって、
「テスト技法を知ってる」だけじゃ使えないと思ったからです。
現場では「○○○技法を使ってテストケースを作ってください」なんて指示は出ません。
技法は、「目的を達成するため」「問題を解決するため」のツールであるべきだと思います。
みんなで、その「つかいどころ」の議論が出来たのは、ある程度の狙い通りでしたし
自分としては想定以上の「気づき」がありました。
参加者、TEF道メンバ、会場提供企業様
みなさん、ありがとうございました。
結局、予定していたワークショップの半分しかできなかったので、
「第二部」も実施することになりました。
これに関しては、後日連絡します。
そして、懇親会・・・というなの飲み会に突入。
いつもの店にていつものメニューを食す（笑）
「テスト」というキーワードだけで、初めて会った人や馴染みの人々と
美味しいお酒がのめるって素晴らしいことだなあと思いました。
次回に乞うご期待！！！！！！
というわけで、第二回「HOTATEw」ワークショップが終了いたしました。
日時：2011/4/27
会場：東京エレクトロンソフトウェアテクノロージーズ様
一般参加者：７名（６社）
TEF道：５名
今回のテーマは「テスト技法の基礎中の基礎」をワークショップで
体験してみる事でした。
前回のお題は「技法とは何か？」でした。
「技法」を設計してみるというメタなワークショップでしたが、今回は
実際に「技法そのものを学んでみる」というお題です。
今回予定していた技法は
「同値分割」
「境界値分析」
「デシジョンテーブル」
「状態遷移」
の４つ。
本などで良く見かける技法たちばかりです。
実際に参加者の殆どがその名を知っている技法ばかりです。
でも、実際に現場で使えていない事が多いようです。
まずは、「同値分割」
例題を元に内容を説明して、演習へ。
お題は「エクセルのフォントサイズを変更する機能」の同値分割。
ドロップダウンで選択可能な数字
6,8,9,10,11,12,14,16,18,20,22,24,26,28,36,48,72
を提示します。
最初は上記数字の「同じグループの分割」を議論していた各チームも、やがて
「操作はドロップダウンだけじゃないのでは？」という議論に発展。
システムへの「入力」をユーザーの「操作」に拡張した時に、目に見える値だけでなく
入力可能な全ての数値に広がります。さらに「入力不可」な値も考慮する必要が出てきます。
各チームから出てきた内容をざっくりまとめると・・・・。
・ドロップダウンで選択可能な数値グループ
・ドロップダウンで選択できないが、直接入力が可能なグループ
⇒ドロップダウン選択可能値の間の値
⇒ドロップダウン選択可能値の最小値未満
⇒ドロップダウン選択可能値の最大値未満
・少数以下の値を持った値
・ドロップダウンの数値の増え方に着目
⇒１ずつ増えるグループ
⇒２ずつ増えるグループ
・無効値
⇒数字以外
⇒空白入力
・入力方法の同値
⇒数値入力グループにも、「直接入力」や「コピペ」がある
⇒ドロップダウンの選択グループにも「マウス選択」や「F4押下」がある
ここで、全員で議論。
・アウトプットをイメージする必要があるのでは？
⇒フォントサイズを変更した結果が、果たしてエクセルのセルだけだろうか？
印刷やプレビューもアウトプットに当たらないだろうか？
もしかしたら、「印刷」というアウトプット観点でインプットを分析した時に
別の同値分析が出てくるのではないだろうか？
・「コピペ」などの操作を「同値」として扱うには違和感があるが・・・
⇒システム的には「操作」も「値」で扱っていると考えてはどうか？
⇒「同値分割」ではなく「同類分割」というふうに考えても良いのでは？
・数値の増減が「変化する」箇所は別に扱っても良いのでは？
⇒8,12,28など
・その他
⇒データ型に注目すると、1～16や～256なども同値クラスになるかもしれない
⇒数値を文字コードに着目すると、別の同値クラスになるかも
・まとめ
⇒テストの「目的」や「テストフェーズ」によって、同値の「ズーム」が変わってくる。
⇒正しい答えは、この時点では出せない
⇒利用者や発注元やプロジェクト内容をよく考慮する必要がある
⇒インプットだけじゃなく「アウトプット」の整理も必要
⇒同じような「動作結果」が予想されるインプット項目（数値とは限らない）をグループ化
「同類分割」という言葉は自分的に「ヒット」でした。
「同値」の「値」にこだわりすぎると、利用シーンが限定されるのかなと。
現場で「あまり使えてない」理由ってこの辺りにあるのかなと感じました。
ちなみにこの問題、私が「WACATE」で体験したワークショップの内容を参考に
改編して題材にさせていただきました。
次のお題は、「境界値分析」。
その名を知らなくても、開発経験者なら直感で
「境界はバグが出る」と知っていると思います。
お題は「年月分秒」をセットしてアラームを鳴らすアプリケーション。
議論
・まずは同値分割をして、その境界値を見つける
⇒なので、「同類分割（数値じゃない同類グループ）」の境界分析もアリか？
⇒境界値分析にも流派アリ。
⇒同値分割から境界分析するか、境界値を見つけ出してその上値と下値をみつけるかの違いではないか
・同値分割は「テストケースを圧縮する」技法だが、境界値分割は「ピンポイント」の技法
ちなみに、各班の回答。
A藩
月 0｜1、12｜13
日 0｜1、28｜29｜30｜31｜32
時 -1｜0、1、23｜24
分 -1｜0、1、59｜60
K藩
月 0｜1｜2、11｜12｜13 + (空白)
日 0｜1｜2、30｜31｜32 + (空白)
27 ｜28｜29
時 0｜1｜2、22｜23｜24 + (空白)
分 0｜1｜2、58｜59｜60 + (空白)
B藩
日 -1、0｜1、12｜13
月 -1、0｜1、28｜29｜30｜31｜32
時 -1｜0、1、23｜24
分 -1｜0、1、59｜60
K藩は、正常境界の【一つ内側】も境界値としていますね。（11月など）
また、【27日】を境界値とするかで、各藩の同値分割の違いがあらわれますね。
全体的に、演習に関しては仕様や背景を曖昧にしてありました。
参加者が自ら「テストの目的」や「いま行なっているテストフェーズ」を
議論して欲しいからです。
それは、テスト技法は「使い方」や「使いどころ」を考えることが大事であって、
「テスト技法を知ってる」だけじゃ使えないと思ったからです。
現場では「○○○技法を使ってテストケースを作ってください」なんて指示は出ません。
技法は、「目的を達成するため」「問題を解決するため」のツールであるべきだと思います。
みんなで、その「つかいどころ」の議論が出来たのは、ある程度の狙い通りでしたし
自分としては想定以上の「気づき」がありました。
参加者、TEF道メンバ、会場提供企業様
みなさん、ありがとうございました。
結局、予定していたワークショップの半分しかできなかったので、
「第二部」も実施することになりました。
これに関しては、後日連絡します。
そして、懇親会・・・というなの飲み会に突入。
いつもの店にていつものメニューを食す（笑）
「テスト」というキーワードだけで、初めて会った人や馴染みの人々と
美味しいお酒がのめるって素晴らしいことだなあと思いました。
次回に乞うご期待！！！！！！