Bj Rollison氏の『Testing in an Agile Environment』に参加してきました（但しDeveloper目線）

JaSST'12 Tokyoの初日、Bj Rollison氏（Microsoftのテストの偉い人）のワークショップに参加してきました。

そもそもテストエンジニアに向けたワークショップなのですが、私自身デベロッパーであり、かつ、たまたま同じテーブルになった方々全てデベロッパーという編成でしたので偏った感想になります。
資料は後日、JaSSTのWebサイト http://www.jasst.jp/ で公開されるというお話でしたので全容はそちらをご期待ください。

Review of Agile concepts

Agileの定義、MSの開発はAgileだよという話。強調されていたのは

Dailyにブランチのビルド＆自動テスト
WeeklyにSelf host（Dogfoodingみたいな）＆シナリオテスト、探索的テスト
Milestone単位にExit判定、レビュー、次のイテレーションのプラン

What is the value of Testing?

情報をタイムリーに提供する
品質は保証できない。出荷判断はテストの仕事ではない

Agile Testing Quadrants

4つの象限。上がBusiness, 下がEngineering. 左がTeam impact, 右がCustomer impact.

Business x Team	Business x Customer
Engineering x Team	Engineering x Customer

ここにユニットテスト、探索的テストなどを当てはめていくのですが、右上はマニュアル、左下は自動化で行なう。あと2つは手動/自動それぞれに分かれる、というのがポイント。
例えばConcurrency Testingは右下に入るのですが、これは自動化すべき。

Automation in an Agile Environment

テストレベル的な観点では、

システムテスト：dirty、end-to-end、GUI
結合以下（Integration, Component, Unit）：clean room、UIなし。

隣にTest Automation Pyramidとして、

GUI（Systemに相当）
API Integration
Component(Individual API)
Unit

が描かれ、システムテストから自動化しようとしがちだが*1下に行くほどちゃんと自動化すべき、という話。
GUIはよく変わるのでテストの再利用がしにくいという話の他、GUIによってAPI呼び出しの組み合わせやパラメタが制限されるためIntegration以下でないと十分なテストができない、とも話されました。

蛇足ですが、Integrationの層を指してFunctional testと言っていたのも印象的でした。
機能テストという言葉をシステムテスト/受け入れテストを指す言葉として使いがちですが、機能仕様に基づいたテストというテスト技法であるということ、またテスト対象がOSなのでレイヤ意識がアプリケーションとは違うということもあるでしょう。