第6回 実践アジャイルテスト勉強会

11月16日(水)開催の「実践アジャイルテスト」の勉強会(第6回)に参加してきました。
前回の内容は「第5回」を参照のこと。
agile_test_.jpg
第11章 技術面のテストを使った製品の批評
「アジャイルテストの4象限」の中の『第4象限』のテストについて述べています。(図の右下に該当)
matrix_06.png

第11章のマインドマップ
agile_test_03_11.png

第4象限テストの目的は、いわゆる非機能要求(要件)が満たされていることを確認することです。
この非機能要件は、国際規格であるISO 9126として知られています。そこではソフトウェアの品質が、次に示す6つの品質特性で表現されます。

  • 機能性:目的から求められる必要な機能の実装の度合い
  • 信頼性:機能が正常動作し続ける度合い
  • 使用性:分かりやすさ、使いやすさの度合い
  • 効率性:目的達成のために使用する資源の度合い
  • 保守性:保守(改訂)作業に必要な努力の度合い
  • 移植性:別環境へ移した際そのまま動作する度合い

なお、各品質特性にはさらにブレークダウンした「品質副特性」が定義されています。
この品質特性の各項目はしばしばトレードオフの関係であることがあります。例えば、効率性(レスポンスの速さ)を優先することで、保守性(修正のしやすさ)を犠牲にする、といった具合です。
開発側の人間はこうした品質上のトレードオフや制約をきちんと顧客に説明する責任がある、と本書では謳っています。確かにこれは疎かになりがちなことで、非常に痛いところを突いています。(ノ∀`)
こうしたことに対する気づきを得るために、テスター(に限らずですが)は、顧客に質問をすることが重要です。ここで、書籍「アジャイルサムライ-達人開発者への道-」インセプションデッキで紹介されている「10個の手ごわい質問」に通じるものがある、という話題になりました。
とにもかくにも、第4象限で行うテストとは、品質特性に基づく「○○性」を検証するテストということが言えます。
■誰がやるのか?
この種のテストは、例えば「セキュリティ」のように専門性が求められるケースがあります。チームメンバーがこうしたスキルを備えていれば問題ないのですが、そうでない場合は外部(他チーム/他部門/他社・・・)から支援を仰ぐことになります。
外部から専門家をアサインする場合は交渉が必要になる(特に他社の場合)ことを考えても、非機能要件は早い段階で顧客に確認することが必要なのです。
チームの成長という観点では、常に「現時点で自分のチームが何ができて、何ができないのか」を見極めつつ、少しずつ自分達のできることを広げていくことも大切です。
■いつやるのか?
性能テストなどは、早い段階でやっておくことが推奨されています。全て出来上がってからではなく、できるだけ早期に実施できるよう工夫することが必要です。
当然、初期の段階(リリース計画時やテーマ計画時)で非機能要件のテストについて考えておかなければなりません。
ここから、第4象限で行うべき「~性テスト」について触れられています。
■セキュリティ
「セキュリティ」は「~性」ではないですが、仲間に含まれるそうです。確かに!
同じセキュリティでもユーザの権限によって利用できる機能を制限するいわゆる「権限付与機能」は業務機能の一部と考えられますが、ソフトウェアの脆弱性を狙った攻撃を想定したテストはまさに非機能要件のテストと言えます。
セキュリティテストは、様々な攻撃パターンや悪用/誤用を想定してリスクの高いものを優先的にテストしていく手法が適しています。セキュリティ上の脅威は常に新しいものが生み出されているので、最新の情報を知っておくことと、探索的テストによって自動化テストが見逃す問題を検出することが重要です。
ここで「80/20ルール」という面白い考え方が紹介されていました。セキュリティに関する予算の20%で一般的な脅威の80%は防げるが、残りの20%を防ぐには予算の80%を使って専門家の支援を仰ぐ必要がある、というものです。
■保守容易性
保守容易性とはプログラムのソースコードの「保守しやすさ」を表しますが、テストで担保するのはなかなか難しいです。
方法としては、ペアプログラミングで継続的にソースコードレビューを行うことと、標準やガイドラインを作っておくことです。標準/ガイドラインを作成するのは今まで私もよく実践してきた手法ですが、これをいかに守らせるかが苦労するところです。(;´Д`)
保守性が重要なのはソースコードだけでなくデータベースも同様だと、本書では謳われています。移行のしやすさ、データ品質、運用しやすさということを言っているのでしょう。同感です。
■インターオペラビリティ
聞き慣れない言葉ですが、日本語に翻訳すると「相互運用性」です。ここでは、異なるデバイスや異なるシステムとの接続性を意味しますが、非要件定義とはまたちょっと違う気がします。
テストの観点としては、スタブやドライバを活用すること、連携相手のリソースに応じて事前に計画しておくことの重要性を説いています。
■互換性
異なる環境での動作を保証することを意味します。身近な例では、異なるブラウザ(Internet Explorer、Firefox、Safariなど)で同じように動作するかを検証することなどがあげられます。
■信頼性
「平均故障時間(MTTF)」や「平均故障間隔(MTBF)」といった指標に代表されるように、システムがいかに止まることなく稼働し続けられるか、といったことを表します。
本書でこれまでに紹介された継続的な自動化テストを実施することで、信頼性のテストも可能と考えられます。
もう一つ重要なのは、「何をもって信頼性OKとするか」を顧客に確認することです。サービスレベル合意書(SLA)等できちんと合意しておく必要がありますね。
■導入容易性
デプロイを自動化することで導入作業の一部を省力化することができます。現実にはデプロイ以外にも導入作業(マスタデータのセットアップ、M/Wの設定 etc)があるので、それらも考慮することが必要だと個人的には思いました。
■拡張性
例えば、将来的にユーザが増えた場合でも安定してシステムが稼働できるか、といったことを検証するテストです。将来の見通しも必要で難しい問題ですが、開発チームだけではなく外部から観察することと早めに計画することが重要とされています。
■パフォーマンステストと負荷テスト
このテストには様々なツールがあり、本書でもそのいくつかが紹介されています。(詳細は割愛)
ポイントは、ある時点でのパフォーマンスの「ベースライン」を設定しておいて、バージョンアップの際に比較できるようにしておくことです。そうすることで、継続的にパフォーマンステストを行う際の指標とすることができます。
あと重要なのは、用語の定義を明確にして関係者で共有すること。例えば「トランザクションの実行最大時間」とは具体的に何?といったことです。
とにかく、反復の一部として継続的にパフォーマンステストを実施することが大事ですね。
第12章 テストの4象限のまとめ

第12章のマインドマップ
agile_test_03_12.png

第7章から第11章までで、アジャイルテストにおける4つの象限について学んできました。
この章は、油田/ガス田を監視し衛星を経由して遠隔地でモニタリングするシステムを例に、これまで出てきた4つの象限のテストについて具体例を交えながらおさらいする内容になっています。
本の内容は文字通りこれまでの「おさらい」なので詳細は省きます。
議論の中で、名古屋アジャイル勉強会として来年はテスト自動化ツールの実習勉強会を予定していることや、CI(継続的インテグレーション)ツールの1つである「Jenkins」の話題が出ました。
自動化ツールの勉強会、楽しみですね。( ´∀`)b
(終)


** 参考図書 **