セッション:Testing System Qualities |
Agile Conference 2日め、13:30〜15:00に行われたRebecca Wirfs-BrockさんとJoseph Yoderさんのワークショップ「Testing System Qualities」に参加しました。
■スピーカーについて
お二人とも、パターンランゲージ・オブジェクト指向・フレームワークの専門家です。
Rebecca Wirfs-Brockさん
- Website:http://www.wirfs-brock.com/
日本では、書籍『オブジェクトデザイン』でご存じの方も多いかと思います。もともと、QAからキャリアをスタートしたということで、特にテストや品質に関心が強いそうです。
Joseph Yoderさん
- Website:http://www.joeyoder.com/
Asian-PLOPなどにも参加している、パターンランゲージ界の大物です。
■参加目的 – Receptionで生まれた縁
Agile Conference 2012初日の「ICE BREAKER RECEPTION」(いわゆる懇親会)で、Yoderさんにたまたまお会いし、
「明日、セッションやるから来てくれ!
パターンランゲージに詳しいから、日本に呼んでセッションやらせてくれ!」
と、猛烈なアタックを受け、これは是非!と思い参加した次第です。事前に予習をする時間もありませんでしたが「これも何かの縁だろう」と参加してみました。
■ワークショップの概要
今回のワークショップは、システム品質のテストを考えるためのフレームワークを使って「アジャイルに即した」テストシナリオを実際に作ってみよう、という内容でした。
■システム品質テストの必要性
アジャイルには以下のような誤解があり、テストは簡単に済ませてよいと思われがちとのことです。
アジャイルの誤解
- アジャイルだと簡単に機能を追加できる。
- アジャイルだとすぐに機能を変更できる。
しかし実際には、要求・ユーザストーリー・機能要件・非機能要件など、システムで実現しなければならないことはたくさんあります。また、システムのテストは、開発者やテスターだけが責任を持てばよいものでもありません。ユーザやマネージャなどステークホルダー全員が関与することで初めて「システムの品質」が担保できます。
従って「どうシステムが動くか」という機能テスト(Functional Test)の視点だけでは不十分で「誰がいつシステムを動かして」・「誰がどのような成果を享受できればよいのか」を明確化してテストする「システム品質テスト(System Quality Test)」の視点が必要とのことです。
■システム品質テストとは
簡潔に言うと、下記の画像にあるモデルを活用して、何をシステムの品質としてテストすればよいのかを整理・明確化しましょうということです。
それぞれの項目の意味は、以下のとおりです。
Source of Stimulus | いわゆるアクター |
---|---|
Stimulus | システム・機器に対するアクション |
Artifact | 動作するシステム・機器 |
Response | システム・機器の動作結果 |
Response Measure | システム・機器の動作結果のうち、計測可能なもの →システム品質テストの対象 |
Environment | システム・機器の動作する環境 |
Quality Scenario Description | 当該のシナリオ記述 (いわゆるユーザストーリー的なもの) |
要求・ユーザストーリー・機能要件・非機能要件をこのモデルに落とし込むことで、何を定量的にテストすればよいのかを明確化できれば、システムの品質を担保しやすくなります。ちなみに、テストすべき点は定量化・計測可能にすることが重要です。
■ワークショップの内容
冊子で配布された「森林における気候測定システム」のシナリオから、実際に上記モデルを作成、何をテストすればよいのかを議論しながら明確にしましょうというワークショップでした。
時間が15分しかなかったこと、シナリオ内に代替フローが大量にあったことから、モデルを完成することはできませんでした。無念。
■システム品質テストでステークホルダーの合意を取るためのTips
- 合理的な数値を提示しましょう。
- 「合理的に行動する人」で仮定して考えてみましょう。
- 既に存在しているシステムの品質を参考値に利用してみましょう。
- 似たようなシナリオがあれば、その内容を活用しましょう。
- ベンチマークを使ってみてもよいでしょう。
■着陸ゾーン ‐ 定量化・計測可能化が難しい場合の考え方
テストの合格ラインは、一般にOK/NGの二択ですが、シナリオによっては二択にできないことも多いものです。その場合は、以下のような「着陸ゾーン(landing zone)」で考えればよいとのことでした。
- システム動作のために最低限必要なレベルを合格ラインとする。
- 理想像ではなく、現実的なところを合格ラインとする。
- 品質の中でも特に目立つものの実現を合格ラインとする。
■現実的なテスト
最後に、現実的なテストの考え方(The Pragmatic Test-Driven Development)について紹介がありました。
ポイントは次の3点。
- Practical
- Thoughtful
- Realistic
要は、完璧主義である必要はなく、そのシステム・サービス・プロジェクトで必要なラインをそれぞれ明確にすればよいということです。
■所感
今回のワークショップは、スピーカーの売り込みを受けて実際に参加してみたら、非常に有益な情報・考え方を教えてもらえたという感じでした。
人と人とのめぐりあわせが、大きな知識に遭遇するチャンスを広げてくれる。これは、平鍋さんがちょうど投稿していたブログの内容にも符合するものでした。
奇縁を良縁に変える。
これが、Agile Conferenceへ参加すること、実践者と実際に会って話をすることの醍醐味だと思います。
Agile2012現地レポーター隊「アジャイルクローバーZ」 伊藤 宏幸