参考文献が少ないので、内容の正確性に疑問がある部分もあります。
あくまで現時点で得た情報や理解を整理した記事です。
この記事について
ソフトウェア品質に含まれるTestability（試験性）について、自分なりに整理したことのまとめです。
- Testability（試験性）とは
- Testabilityの特性
- Testabilityが低い状態とは
- Testabilityを向上させるには
Testability（試験性）とは
まずソフトウェアの品質について、ISO/IEC25010 SQuaREの”ソフトウェアの製品品質モデル”にて次のように定義されています。
- 機能適合性：機能完全性、機能正確性、機能適切性
- 性能効率性：時間効率性、資源効率性、容量満足性
- 互換性：共存性、相互運用性
- ユーザビリティ：適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユーザインタフェース快美性、アクセシビリティ
- 信頼性：成熟性、可用性、障害許容性、回復性
- セキュリティ：機密性、インテグリティ、否認防止性、責任追跡性、真正性
- 移植性：適応性、設置性、置換性
- 保守性：モジュール性、再利用性、解析性、修正性、試験性
この８つの品質特性のうちの保守性を構成する品質副特性の中に試験性（Testability）があります。
（試験性の他にはテスト容易性という訳も見かけます）
Testabilityの７つの特性
Testabilityの定義として、７つの特性があるようです。
- 実行円滑性（Operability）
- 観測容易性（Observability）
- 制御容易性（Controllability）
- 分解容易性（Decomposability）
- 単純性（Simplicity）
- 安定性（Stability）
- 理解容易性（Understandability）
これらの特性はJames Bach著『ソフトウェアテスト293の法則』やRoger S. Pressman著『実践ソフトウェアエンジニアリング』 で挙げられているようです。書籍が手元に無いので末尾に記載した記事を参考にさせていただきました。
1. 実行円滑性（Operability）
ソフトウェアが効率的に実行され、必要な操作や監視がスムーズに行えるかどうかを表す特性です。
例えば次のような状況は、実行円滑性が低くそうです。
- テストの準備や実行にコスト（時間、費用）がかかる
- 安全に実行できる環境が無い
2. 観測容易性（Observability）
システムの内部状態がテスト中にどれだけ容易に観察できるかを表す特性です。
例えば次のような状況は、観測容易性が低くそうです。
- 外部から状態の観測ができない（結果を返さない、privateになっている）
- 影響が観測範囲外に発生する（外部サービス、メール送信など）
- デバック情報が不足していて、エラーやテスト失敗の原因を追跡できない
3. 制御容易性（Controllability）
テスターがシステムの異なる部分をどれだけ容易に制御できるか、特定の条件や状態を作成できるかどうかを表す特性です。
例えば次のような状況は、制御容易性が低くそうです。
- パラメータや依存関係がハードコーディングされていて、制御が出来ない
4. 分解容易性（Decomposability）
システムを分割して個々の部分を独立してテストすることがどれだけ容易かを表す特性です。
例えば次のような状況は、分解容易性が低くそうです。
- テスト対象と直接関係がないパラメータや依存関係が必要になる
- 依存をテストスタブに置き換えられない
5. 単純性（Simplicity）
テスト対象となるシステムやコンポーネントがどれだけ簡単に理解し、分析し、そしてテストできるかを表す特性です。
例えば次のような状況は、単純性が低くそうです。
- 過度に複雑な機能や仕様
- 複数の責務を持つ
6. 安定性（Stability）
同じ条件や環境で何度テストしても、一貫した振る舞いができるかという特性です。
恐らくですが、コンポーネントの安定度についてち、実行結果が不安定ではないことを含むものと思われます。
例えば次のような状況は、安定性が低くそうです。
- 変更が頻繁で、テストへの影響が大きい
- 外部環境へアクセスしたり、乱数や時刻を使用したりして、同じ条件下でも結果が安定しない
7. 理解容易性（Understandability）
ソフトウェアの構造と動作をどれだけ容易に理解できるかという特性です。
例えば次のような状況は、安定性が低くそうです。
- 適切ではない命名
- 過剰な複雑性
- ドキュメントやコメントの不足
Testabilityが低い状態とは
ここまでの特性などを踏まえて３行でTestabilityが低い状態を考えると
- テスト対象の理解が困難
- テストの実施が困難
- テストの結果が不安定
のような状態が考えられました。
Testabilityを向上させるには
Testabilityが低い状態を解消し、テストを容易にするにはどうするか考えてみます。
”テスト対象の理解が困難”を解決するには
- コードをリーダブルにする
- 高凝集にすることで、テスト対象の責務を明確にする
- コードを補うドキュメントを用意する
- 追跡するためのログを出力する
”テストの実施が困難”を解決するには
- 安全にテストを実施できる環境を用意する
- 高コストな依存をテストダブルに置き換える
- 必要最小限のテストケースにする
”テストの結果が不安定”を解決するには
- 乱数や現在日時など非決定的な処理をテストダブルに置き換える
- 外部環境への依存をDockerコンテナやテストダブルに置き換える
まとめ
Testabilityが高い/低いとはどういう状態なのか？という点の理解がぼんやりしていたので、理解を深めるために調査し、自分の経験も踏まえて整理してみました。
大きくわけると、テスト対象の理解のしやすさ、テスト実施のハードルの高さ、テスト結果の信頼性あたりがTestabilityにつながるイメージを持ちました。
Testabilityの７つの特性については、一次情報である書籍を読んで改めて整理したいと思います。
参考記事
こちらの記事を参考にさせていただきました。