Agile2012 Day 2 : システム品質を考えるキャンバス

AsianPLoP でお世話になった Joe Yoder さんと、Agile2009 でお世話になった Rebecca Wirfs-Brock さんのセッション。すでにスライドが公開されている。

Testing System Qualities: Rebecca Wirfs-Brock, Joseph Yoder

アジャイルにかんしてあった神話

  • システムの品質は最後の段階で付与される (これアジャイルかなぁ)
  • 変更要求(追加要件)には簡単に応じられる
  • システムの変更はすぐできる!
  • アーキテクチャなんで心配しなくていい

システム品質として考えるべき点はこんなかんじ

機能テストと、システム品質テスト (System Quality Test)は別のもの。後者は特に負荷テストやユーザビリティテストなどをカバーする。

まず、計測できる結果は何か、を検討する。

  • Meter: 妥当な計測方法
  • Scale: 期待される数値
    • 自然の単位 ミリ秒とか
    • 人工の単位 1-10までのランキング
    • 代用: サンプルデータを使ってスループットを再現、計測する

一口にユーザビリティといってもいろいろな要因があるのでもうちょっと細かく分割した方がよくて、レスポンス問題ならパフォーマンスになるし、という話が印象に残った。

たとえば、パフォーマンシナリオであれば、以下のような構成要素が考えられる。

  • 発生源 Stimula: ユーザ
  • 刺激 Stimulas: 発注を行う
  • モノ Artifact: システム
  • 反応 Response: トランザクションが行われる
  • 反応の基準 Response Measure: 平均所要時間が2秒以下であること
  • 環境 Environment: 平常時
  • シナリオ: 「ユーザ全体として、平常時は秒間1000個の発注トランザクションを行う。トランザクションは平均2秒以内に完了する。」

(シナリオを考えるときに、パフォーマンスであれ、セキュリティであれ、明確なアクターを考えることが、ROIの高い対策を取る際に必要なことだと思うので、キャンバスに描くという方法は共通理解を作るうえで有益だと感じた。図自体はいわゆるシステムへの入力と出力の図なので、まあ誰にでも分かりやすいと思われる。)

このあと、実際に仮想のシステムについてシナリオを上記のキャンバスに落としてみる演習があった。

「テスト成功か失敗か」を越えた議論を

着地点はいろいろある。少なくとも、最低限許容できる(Minimum)、現実的な目標(Target)、期待以上の結果(Outstanding)、という受入条件を考えておきたい。

着地点のメタファーで考えれば、地図上のどこに着地するかは、いろいろなシナリオが考えられる。

これと同様に、各種の品質シナリオを考えていこう。

このあと TDDを用いた品質テストサイクルの説明と議論があったが、理解できてないので写真だけ。

結合テスト、スモークテスト、品質シナリオ、受入テスト、ユニットテストの守備範囲は重なる部分がある。