5月15日（火）に行われた、実践アジャイルテスト読書会06 に参加しました。
あっという間に2回お休みしていてびっくりした。
前々回は業務多忙で参加できず、前回はゴールデンウィーク中の開催だったため札幌にいませんでした。
（このブログを書く前になんとか休みの範囲も読み終えました。読書会があって良かった。）
気を取り直しての参加です。
今回からいよいよテストについての章に入りました。
テストの目的ごとに分類した「アジャイルテストの4象限」についての話がメインです。
アジャイルテストの4象限
テストの目的を
- チームを支援する⇔製品を批評する
- 技術面⇔ビジネス面
という2つの側面から分類し、4つに分けた物がアジャイルテストの4象限になります。
それぞれの特徴が書かれていたのをざくっとまとめてみる。
第1象限
（チームを支援する・技術面）
単体テスト。主にTDDなどで作ることになるテスト。コードに対するテスト。
コードの品質を高める、プログラマのためのテスト。
基本的にテスト実行は自動化されてなければいけない。
第2象限
（チームを支援する・ビジネス面）
機能テスト。ストーリーに対するテスト。第1象限より粒度が大きくなり、1つ1つがビジネス的な意味のかたまりになる。
ストーリーの開発が完了することを保証する、開発チームのためのテスト。
継続的ビルドの対象として自動化されているべき。
第3象限
（製品を批評する・ビジネス面）
ソフトウェアが顧客の求めるものになっているかをテストする。
ユーザー受け入れテスト、ユーザビリティテスト、探索的テスト。
創造能力と直感力が必要になる、基本的に手動で行われるテスト。
※これは実際にテストの質を（数値的に）保証するのが難しいテストだね、という話が出ました。
第4象限
（製品を批評する・技術面）
パフォーマンス、堅牢性、セキュリティなどの評価を行うテスト。
非機能要求テスト。専用のツールを使用してテストする。
アジャイルテストの4象限をチームにどのように適用するか
もちろん、全ての象限のテストを十分に実行できることが望ましいのですが、それが叶わない場合もある（時間や予算）。
その時に、何を選んでいくべきかという話。
大事なことは
「ストーリーごとに検討する前にやらないという選択をするのではなく、
全ての象限のテストについて検討した後にやらないことを決める」
こと。そのためには全象限のテストに関するスキルは必要。
また、ここで「（必要なのはわかっているけれど）やらない」という選択をするということは、技術的な負債を積み上げることになるわけです。
実際に負債が積上っていった経験談などを交えて、どうするのがよいのかなあという話をしました。
製品を長期にわたって開発、メンテナンスするかなどとの兼ね合いも考えないといけない。
コンテキストのテスト
「それぞれの組織、製品、そしてチームはそれぞれの状況があり、それぞれ必要なことがある」ということを忘れてはいけない。
コンテキスト（組織、製品、チームの流れや空気、慣習のようなもの？）意識したテスト設計が必要。
この章はなるほどなあと思いました。
製品に対するテストを機械的に行うだけではなく、プロジェクトやチームメンバーのことを考えたテストを作っていこう、とする気持ちも大事なのですね。
導入部分の読書会に参加できて良かったです。
次回からはそれぞれの象限のテストを掘り下げていきます。参加できますように！