ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

TABOK粗読による自動化の座学 - カテゴリー7「品質属性の最適化」(1)

TABOK テスト計画 テスト自動化
　9月は仕事とイベントにかまけてました。低品質を誇る当ブログ、質の悪さを量で補おうと、今年は50本のエントリーを書くことを目標にしています。これで36本目みたいです。
　さて、カテゴリー7は、「品質属性の最適化」です。初めは「Quality Attribute」を「品質特性」と訳していましたが、ISO/IEC 9126のソフトウェア品質特性は「Quality Characteristics」なので、一応、訳し分けています。
7.1　代表的な品質属性
　TABOKでいう品質属性は、以下の8つ。ISO9126を意識しているものとは思いますが、9126に対応するものが見当たらない属性（★）が3つもあります。ソフトウェアなんだから、ほとんど一致するのではという予想に反する。
  1. maintainability（保守性）
  2. portability（移植性）
  3. flexibility（柔軟性）★
  4. robustness（堅牢性）★
  5. scalability（拡張性）★
  6. reliability（信頼性）
  7. usability（使用性）
  8. performance（性能）
　なぜかと考えてみますと、ここでいう属性は、テストスクリプト自体の属性というより、自動テストフレームワークの属性なんですね。なので、たとえば「新しいテストケースを追加することの容易さ」である拡張性が前面に出てきているのではないでしょうか。一方で、機密性（security）などは求められない。
　TABOKではそれぞれの属性について、意味・メトリクス例・改善方法の例を説明しています。なんか、無駄に表が多い。
　少しだけ触れます、詳しくはTABOKを購入して読んでくださーい。購入ガイド（笑）はコチラです。※購入時には「ぐるなびで見た」とお伝え下さい。

保守性

　最初に出てくるのが保守性、というのがテストフレームワークらしいですね。ISO9126で機能性（functionality）が初めに出てくるのと対照的です。
　保守性は、変更や修正のかけやすさ。定量的には、変更・修正にかかる時間がメトリクスの1つになります。テスト側に欠陥があって修正するということであれば、ハードウェアのアナロジーで、MTTR（平均復旧時間）とも呼べます。

移植性

　異なる環境への移植のしやすさ。メトリクスとしては、「別の環境用に一から作るのと、既存のものを直して流用するのと、どのくらい違うか」という比が使えます。改善の方法として、自動化のためのコンポーネントをroot直下にディレクトリにおいておけば、ディレクトリ構成的には移植しやすくなる、など。

柔軟性

　テストのために与えられたリソースに応じた、テスト実行の行いやすさ、といえばいいのでしょうか。リグレッションテストをすべてやりきれる場合と、最重要メインルートを通すだけの時間しかない場合、どちらも同じようにしかテストを流せないのでは困ります。
　改善のためには、テストセットのグループ化、優先順位付け。これはカテゴリー6で言及されていました。

堅牢性

　システム側の変化にどれだけ強いか。たとえば、テスト対象のソフトウェアの欠陥によって、自動テストがいちいち止まる（halt）ようでは、堅牢とは言えません。
　保守性のMTTRに対し、堅牢性は平均故障間隔（MTBF）で表現することができます。改善のためにできるのは、たとえば例外処理を強化することです。

拡張性

　テストのスコープの拡大・縮小のしやすさ。テストする対象が増えても、簡単にテストケースを追加できるかってことですね。4.2で説明されているデータ駆動だと、同じシナリオのテストを別のパラメターで実行するというテストケースが追加しやすいのは明白です。

信頼性

　堅牢性と同じくMTBFで表すことができますが、その違いは、この「F」が、テスト側の故障だということです。堅牢性では、テスト対象ソフトウェアに起因するものでした。とはいえこちらの改善策も、例外処理の強化がメインです。
使用性
　ここは人間に関わる属性ですね。そのフレームワークにどれだけ早く馴染めるか。それに要するトレーニングコスト・時間などがメトリクスになります。キーワード駆動のような形だと、スクリプトの中身が隠蔽されているので、すぐにシナリオを組み立てられる、といったことがあります。

性能

　自動テストのうれしさの1つは、その驚きのスピード感なのですから、性能は重要。メトリクスとしては、実行に要する時間など。
　それを改善する手段の1つは、やはり、例外処理をしっかり書くこと。実行速度を何より落とすのは、「テストが止まる」という事態ですからね。
　8つの属性を見て感じるのは、「とにかくコケずに流し終わるテストを作ろう！」ということですね。