テストについて3
id:shot6氏ことshotタンに拾っていただいたので、このネタをもう少し考えてみました。（と言っても、ColdFusionのフレームワーク的な何かについて、に沿った話になっちゃいますが
ちなみに位置づけはめも。というか、僕自身の脳内整理ですね。
まずはUTで機能単位でテストしておき、ITで大枠からのテストを施すのが王道じゃないですかね。
2008-07-06
言い方を変えればミクロ視点・マクロ視点になるわけです。
UTにおけるxUnitは本当に各機能・部品の振る舞いを確認するためのものです。
メリットはもちろん自動化されていて回帰性が高いことで、一番ミクロな単位での品質の確保です。
ミクロ視点なので各部品ごとの振る舞いは担保されますが、もっとマクロな視点でみたときの
挙動を担保はしてくれません。
よりマクロ視点ではITでの確認が有効だと思います。
おっしゃる通り。UnitTestの視点がすべてではないので、別の視点のテストについても考慮しておかないといけません。
で、「別の視点のテスト」について今日一日考えておったのですが、現場や企業、チームによってテストのスコープと対象が違います。これを考慮に入れると非常に複雑な「テスト・プロセス」が出来上がってしまいそうなのと、でも何も考えずに「単体テスト」等と言うと伝わらない人には伝わらない。別にそれぞれが文化的経緯で作り上げてきた工程は工程で、プロジェクト・チームの中で共有されていれば良い訳ですし、これを統一させようとしても労力ばかりが掛かってしまいそうです。
という事で勢いよくテキトーなエイリアスを与えてみました。（例えは僕が思い描くレンタルビデオ屋のお仕事を踏まえていたりします）
- テストA
- モジュール(Funtion/Method)を対象にしたテスト。
- 例えば、「登録画面の入力チェック」とか。
- モジュール(Funtion/Method)を対象にしたテスト。
- テストB
- １つのオペレーション、挙動を対象にしたテスト。
- 例えば、「登録ボタンを押す」とか。
- １つのオペレーション、挙動を対象にしたテスト。
- テストC
- １つの画面を対象にしたテスト。
- 例えば、「登録画面」とか。
- １つの画面を対象にしたテスト。
- テストD
- １連のオペレーション（業務）を対象にしたテスト。
- 例えば、「入会申し込み（操作だけ）」とか。
- １連のオペレーション（業務）を対象にしたテスト。
- テストE
- １連の業務を対象にしたテスト。
- 例えば、「入会申し込み（お客様とのやり取りを踏まえて）」とか。
- １連の業務を対象にしたテスト。
- テストF
- システムを導入する事の意義のテスト。
- 例えば、チェーン展開していない極めて小規模の店舗でTSUxxYAなみの大規模なシステムが必要なのか、とか。
- システムを導入する事の意義のテスト。
こんな感じでしょうか。
テストAからテストFに向けて、視点がマクロなものになっていきます。
テストDとテストEが微妙に被りますが、例えばレンタルビデオ屋の入会手続きをする上で画面操作とお客様への説明とがそれなりにリンクした形になっていないと、場合によっては（説明）→（操作）→（説明）→（操作）→（やっとこ会員証発行）のような、非効率的なプロセスを店舗で行わなければならなくなるかも知れません。
ここで手間取ってしまった結果、カウンターが塞がってしまい機会損失が発生するかも知れません。
せっかく業務改善や効率化を願って導入したシステム／ソフトウェア／アプリケーションによって、機会損失を被るなんてまるで悪い夢のようです。
翻ってテストAに目を向けてみます。
これはid:shot6氏の言われるように「挙動」を担保するものではないので、テストAの結果を評価する基準はやはりテストBの結果と連動するのかな？
以上は、コードを書き始めてから稼働するまでの工程に連動したレイヤなので、今度はテスト対象の分類をしてみました。
- 領域1
- モジュール間の関係を保つ為の部分。
- 例えば、フレームワーク。
- モジュール間の関係を保つ為の部分。
- 領域2
- システム外部との連携を図る部分。
- 例えば、商品の情報をAmaxxnから取得する部分。
- システム外部との連携を図る部分。
- 領域3
- 何かを記録する部分。
- 例えば、会員の有効期間をデータベースにデータを記録する部分。
- 何かを記録する部分。
- 領域4
- 業務的な意味合いしかない部分。
- 例えば、入会手続きをした日から有効期間を算出する部分。
- 業務的な意味合いしかない部分。
- 領域5
- ユーザへの応答を作成する部分。
- 例えば、算出した会員の有効期間を登録画面に表示するよう書式を与えたりする部分。
- ユーザへの応答を作成する部分。
- 領域6
- ユーザへの応答を返す部分。
- 例えば、ユーザの操作から開始された一連の処理の完了をさせて結果をブラウザなりに返す部分。
- ユーザへの応答を返す部分。
- 領域7
- ユーザの操作を受け付ける。
- ユーザの操作をフレームワーク上に伝達する部分。
- ユーザの操作を受け付ける。
- 領域8
- システムの見栄えに対して動作を与える部分。
- ユーザが会員の都道府県を選ぶ際に、小粋に日本地図を出して選択してもらうとか。
- システムの見栄えに対して動作を与える部分。
- 領域9
- システムの見栄えに関する部分。
- 長時間使うなら目が疲れない配色にするとか。
- システムの見栄えに関する部分。
次この話題に触れる時は、前述のテストA〜Fと領域1〜9のマトリクスを作った上で、ColdFusionのフレームワーク的な何かでカバーできそうな部分とそうではなさそうな部分について、考えてみたいなーと思います。（こうして考えると、今回のColdFusionのフレームワーク的な何かは以前僕が思いつきで書いた「テストの、テストによる、テストの為のフレームワーク」と発想が変わっていませんね）
