状態遷移のテスト設計について出題&解説

 今月初め、WACATEつながりの、課題に対して参加者が各々の方法でテスト設計するという趣旨のハンズオン勉強会に参加。
 いい機会だったので、今回は以下の状態遷移のテストについて出題し、解説させていただいた。


●出題課題
http://infog.0ch.biz/download/jissen_swtest_1__work.pdf

●解説
http://infog.0ch.biz/download/jissen_swtest_1__ans.pdf

テスト設計技法の威力

 色々勉強になる機会だったけれど、今回は特に原因結果グラフのメリットを手で体感できたのが良かった。

 というのも、今回他の参加者の方が以下のようなテストケース設計課題を出題された。

  • 会員向けにメールボックスサービスを提供している
  • オプションとして「メール転送機能」があり、以下の設定ができる
    • 転送先アドレス(TEXT): 自アドレスは設定不可
    • サーバ上に残す(RADIO): 残す(初期値)/残さない
  • 「メール転送設定」にしたがって転送処理等するが、以下は例外処理
    • スパムフィルタを有効にしていて、スパム判定されたメールは転送しない
    • 送信元アドレスと転送先アドレスが同一の場合は、メール転送しない
    • サーバ上に残さない設定でも、スパム判定されたメールはサーバ上に残す
  • テスト実施は社内のテスト環境で行う


 これに対する自分の作った組み合わせテストが以下。デシジョンテーブルによるオーソドックスなテストケース設計方法を取った。

アドレス重複テスト
設定アド 設定結果
自分のアドレス 拒否
その他アドレス 成功
メール転送テスト
・スパムブロック
フィルタ設定
スパム判定
スパムブロック
・メール転送
スパムブロック
フィルタ設定
スパム判定
送信元、転送先同一
サーバ保存設定
転送する
サーバ残す


 一方出題者の方の解答例が以下。その方は原因結果グラフを使って組み合わせを設計していた。

転送設定あり T F T T T T
サーバ上に残すON F F F T T F
スパムフィルタ有効 T T T t T f
スパムメール F F T F T F
送信元と転送先が同一 F F F T F F
通常の場合 F T F T T F
スパムの場合 F F T F F F
転送される T F F F F T
サーバ上に着信 F T T T T F

 これを比べると、やはりというか、明らかにDTと比べよりコンパクトな組み合わせが得られていた。またさらに色々問題(例えばオールペアを壊すとか)を持つ制約も別途抽出されていて、結果がかなり洗練されている印象だった。小さな仕様でさえこれだけ差が出るのだから、大きな仕様だと効果も相応の大きさになってくると思う。
 また他に凄かったのが、出題者の方がグラフからDTを出力する作業をウェブベースのツールで自動化していたこと。原因結果グラフはTEFの勉強会で知恵熱が出るぐらい頭を使った経験があり、仕様変更や分析漏れへの対応を気軽にできなそうな印象を受けていたので、これは結構なブレークスルーになると感じた。


 最後に運営者の方、出題者の方々には改めてお礼申し上げます。おかげで大変勉強になる一日になりました。