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

ソフトウェアの品質、テストなどについて学んだことを記録するブログです。旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

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

 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つの属性を見て感じるのは、「とにかくコケずに流し終わるテストを作ろう!」ということですね。