正常系テストとか異常系テストとかふだん使ったりします。この本では、機能が働くテストを「正常系」、機能がエラーなどで最後まで働かないテストを「異常系」と表現しています。また、異常に対して正しく実行できたことを確認するテストとして「準正常系」という考え方も紹介されています。何気なく使っているけど、もしかしたら人（文化？）によって定義が異なるかもしれない用語を自分なりに整理してみました。

準正常系

エラーを検知して、それを結果として出すこと。僕の場合は、実装時（ユニットテスト時）ではなるべく最初に確認します。それは、因子の積集合（テスト空間と呼ぶこともある）があって、それを同値分割していくイメージです。たいていの場合は、無効同値クラスを削っていって、削っていって、最後に有効同値クラスがいくつか残ります。防御的プログラミングの視点を意識します。

正常系

機能が働き、正しい結果を期待通り出すこと。僕の場合は、実装時（ユニットテスト時）ではなるべく最後に確認します。準正常系を削った後に残った有効同値クラスを期待する結果でさらに同値分割します。一旦は考えうる同値分割を想像して、ズームアウトしてバランスをとります。

異常系

この本ではエラーによって最後まで機能を果たさないことを確認するテストですが、僕の場合は、実装とは直接関係しない因子と考えています。タイミングの問題やネットワーク状態、負荷など実行しにくい場合が多く、ユニットテスト時には確認しないことが多いです。準正常系や異常系とは異なり、ラルフチャートを思い浮かべて、因子抽出を心がけます。
また、一般的に異常系（あるいは無効値）は一つずつしか確認できないといいますが、すべての因子の無効値を組み合わせた場合は、異常系として確認します。

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

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

まずは技（わざ）。

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

次は術（じゅつ）。

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

最後は芸（げい）。

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

==

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

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

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

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

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

※この記事は こちら からの一部修正をした転載です。