前回の記事で、「テストのアトミック性」というコンセプトについて書きました。
ISO/IEC25010ではソフトウェアの品質特性、つまりソフトウェアの価値や良し悪しを測るための軸を提示してくれていますが、「ソフトウェアのテスト」の良し悪しはどのように考えればいいのでしょう。
プロダクトと違ってテストはユーザが（少なくとも直接には）使うものではないから、良し悪しの軸などいらないでしょうか？ いやいや、開発においてベロシティやコードカバレッジを計測することで改善や維持を図れるように、テストの良さを測ることで、それをさらに良くしていくモチベーションにすることはできそうです。
テストの品質特性
テストの品質特性の提案例として秋山浩一さんから、JaSST'09 Tokyoでの加文字諭さんのライトニングトークスの資料を紹介していただきました。テスト（スイート）の品質特性として、12個の主特性と81個の副特性が提案されています。
それぞれの特性についての説明までは書かれていないので推測になってしまいますが、ソフトウェアの品質特性とはかなり違います。一つの傾向として、テストの各プロセスをスムーズに行えるかというところに焦点が当たっているように見えます。
たとえば主特性「テスト実施性」に対し、以下の9つの副特性が定義されています*1。
- 手順可読性
- 手順実施容易性
- 対象結果確認容易性
- 期待結果可読性
- 結果比較容易性
- 不具合検討容易性
- 環境復元容易性
- 復元確認容易性
- テスト実施内容記入判断容易性
「〇〇容易性」が多いことから、「テストを実施するにあたり、実施者がどれだけスムーズにテストを行えるか」ということを重視していると読み取れます。
もちろんそれだけということではなく、たとえば「網羅性」という主特性の下には
- 網羅信頼性
- 網羅妥当性
- 実施可能性
- 必要テスト実施誤差性
という副特性がぶら下がっています*2。これはいわゆる「テスト分析」プロセスでのアウトプットに対応する特性といえそうです。「網羅」を定量的に証明することは困難なので、「信頼性」という、「ステークホルダーが納得・合意してできるものか」という尺度を入れているのが面白いですね。
主特性「ピンポイント性」の副特性である「対象関連明確容易性」は、先の記事に書いた、テストケースとテスト条件のトレーサビリティが取れていることに相当しそうです。
一方見たところ、個々のテストケースが抱えるテスト条件の数、目的のシンプルさといったものに該当するものはなさそうです。もちろん「再利用独立性」など、間接的に関係しそうなものは見当たるのですが。ただ、主特性の名前が「ピンポイント性」なので、意図しているところは「アトミック性」に近いのかな、と感じます。
アトミック性とやらに触れている文献
辰巳敬三さんにリサーチいただいたところ、いくつかの文献がありました。
多くは「ほかのテストケースを前提とせず、独立して実行できる」という意味で使っています。こちらの書籍
- 作者:Daniel Ståhl,Torvald Mårtensson
- 出版社/メーカー: Lulu.com
- 発売日: 2018/09/06
- メディア: Kindle版
では、以下のように言及しています。
The second prerequisite is atomicity. By atomicity we mean the property of test cases behaving as independent entities, which can be executed in isolation without assumptions as to any particular state resulting from the execution other set of test.
なお別の箇所では、atomicity 以外の特性にも言及しているようなので、この箇所は面白そうです。
we argue that these prerequisites are test case homogeneity, test case atomicity and tractability
自動テストの品質特性
自動テストの文脈における品質モデルについては、テスト自動化研究会の井芹洋輝さんの発表資料がわかりやすいです。
まず、テスト自動化に関わる品質モデルを、3つに分けています。
そのうち1つは、実はテスト自体ではなく、テスト対象のプロダクトのテスタビリティに対するモデルです。Pressmanによる例を提示しています。
テスト自体のモデルは2つ。
1つは「テスト環境の品質モデル」とあります。この「環境」という言葉がちょっとわかりづらいのですが、これは「テスト実行環境」という意味ではなく、自動テスト自体の品質の考え方といってよさそうです。
テストコード自体の不良やプロダクト側の変更に合わせて、テストコードを容易に修正できるか（保守性）。そもそもバグが少なく、正しくテストを行うことができるか（機能性）。といったものが特性になります。
もう1つが「テスト設計の品質モデル」で、これはテスト自体の品質と言える内容もあります。
十分性 網羅すべき実行領域に対してテストが十分かどうかの程度
加文字さんの分類でいう「網羅性」ですよね。
この資料で紹介される例が少ないこともあり、やはり「アトミック性」に近いものは見当たりません。
引用元をあたってみるか・・・とよく見てみたら、自分が翻訳に関わった本からの引用じゃないか・・・。こんな話が書かれていたなんて記憶のかなたなので、あらためて読み直してみようと思います。
システムテスト自動化 標準ガイド CodeZine BOOKS
- 作者:Mark Fewster,Dorothy Graham
- 出版社/メーカー: 翔泳社
- 発売日: 2014/12/17
- メディア: Kindle版
@yattom さんからは、TDD FIRST principle をご紹介いただきました。
stackoverflow.com自動テストやTDDでF.I.R.S.T.という指標(というか心がけ？)がありますが、すみません違う話な気が。。。 https://t.co/wkpRaSzrX2
— YASUI Tsutomu (@yattom) 2020年2月14日
以下は勝手訳です。
- Fast: テストを迅速に実行できること
- Independent: テスト同士が依存しておらず、どんな順番でも実行できること
- Repeatable: 何度実行しても同じ結果となること
- Self-checking: 成功したかどうかが自動的にわかること
- Timely: テスト対象のコードと同時に、そのテスト自体が書かれていること
多くは自動テストで重要なものですが、手動テストにおいても通ずるものもあります。
わたしとしては、テストの品質特性を一から網羅的に議論したいわけではないですが、ちょっと調べただけでもいろんな観点での価値・軸があり、面白いですね。
