Scrum Alliance Regional Gathering Tokyo 2013セッションメモ

Scrum Alliance Regional Gathering Tokyo2013でテストについて話しました - Yasuo's Notebookのセッションのメモを公開しておきます。どうも私は文章を書いているときのアウトプットが一番良さそうだと感じていて、ここ数回のセッションの試みで、まず記事を書いてから、セッション資料を作るという方法をやっています。
あくまでスライド検討用の文章にスライドのページ数を補足で付けただけなので、実際に話したことと少し違う点もあるかもしれませんがご容赦ください。

（ここから）
アジャイル開発でテストというと、真っ先に思い浮かぶのはTDDでしょう。その次に思い浮かぶのが、継続的インテグレーションで実行するテスト、そしてテスト自動化というような感じでしょうか？
今日の話は個々のプラクティスではなく、製品開発におけるテスト全体をどのように考えていけば良いか？その中でTDDなどのプラクティスをどのように位置づけていけば良いかについてお話します。

1.従来の開発でのテストの役割

まず、従来の開発においてテストがどのように行われているかをおさらいしましょう。

　・V字モデルのテスト工程について。（スライド３ページ）

このやり方の場合、テストは市場に出す製品に不具合を流出させない最後の砦のような役割を持っています。この砦の役割は「あたりまえ」のものとして意識されていることが多いですが、あえて掘り下げると市場での利用において不具合を発生させない品質であることを確認するために設計、開発されたテストを実施し、発生した不具合に対処することによって、目標の品質（市場での利用におおいて不具合を発生させない）を達成する。という行為になります。

つまりテストという行為は、
目的：目標の品質を達成すること
方法：目標の品質であることを確かめるためのテストを設計、開発、実施して発見した不具合を是正することによって、製品の品質を目標の品質まで向上させる。

のように捉えることができるでしょう。重要なのは、目標の品質を達成することです。

2.テストの積み上げ
もう一つテストについてV字モデルから読みとれることがあります。
それは、テストフェーズです。
テストを単体テスト、結合テスト、システムテストというように積み上げています。システム全体を構成するソフトウェアは多くの要素の組み合わせによって成立しています。組み上げたシステム全体の品質を高めるためには、個々の小さな要素の品質を高めておく必要があります。そのため、従来のテスト工程では、小さな要素から順番に品質を高めていきます。そして段階的に粒度を高めていって、最終的にシステム全体の品質を高めるという方法を取っています。

2.アジャイル開発でのポイント
アジャイル開発におけるテストも本質的には、従来の開発とそんなに代わりがないと思っています。

ポイント
・いつ、どのような品質を達成するかを考える
・どのような粒度のテストを行うかを考える

2-1 いつ、どのような品質を達成するかを考える

すべてのタイミングのでのテストで達成すべき品質の目標が市場に製品を出すための品質であるとは限りません。
反復型の開発であるアジャイル開発においては、設計、実装、開発が時間軸ではっきりと分かれていないため、いつ、どんなテストをするかということをよく考えることが大切です。

スクラムでは、スプリントで作成するインクリメントについて以下のようなことが言われています。

(1)スプリントでの成果物では出荷可能か判断可能であること
(2)実際に出荷するためにエンドゲームを実行する。

(1)と(2)の割合はコンテキストによって異なります。(2)の作業が非常に小さいものもあるし、とても大きくなるものもまります。

実際の開発を考える次のようなパターンが考えられます。

・毎リリースで市場に出荷する例
・何回かに1回市場にリリースする例
・最後に市場にリリースする例

どの段階でどのような品質を狙うのかを共有する必要があります。
フィードバックの回数と範囲がその方針を決める指針になるでしょう。
フィードバックの回数が多く、その範囲が広いほど、(2)の比重を小さくしなければなりません。
逆にフィードバックの範囲を限定することにより、(2)の作業を行う回数を回数を減らすことができます。フィードバックの回数と範囲を適切に定めることにより、手動テストにかかる時間をトータルで削減するアプローチも考えられます。

2-2 どのような粒度のテストを行うか考える

従来は、単体テスト、結合テスト、システテストのように対象の粒度を細かいもの順番に積み上げていくことによって、製品の品質を高めていくというアプローチを取っています。

ソフトウェア技術者の認定資格を運営しているISTQB（International Software Testing Qualifications Board)のシラバスでは、テストレベルという用語が定義されています。ISTQBの認定資格は、日本ではJSTQBとして運営されています。JSTQBの用語集ではテストレベルは以下のように書かれています。

テストレベル(test level): 系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。

この定義からテストレベルはテストフェーズだと思いがちですが、工程との対応付けはこの用語定義からは読みとれません。私はテストレベルは、テストの設計、実施をマネジメントする単位であると解釈しています。
アジャイル開発のプロジェクトでは、バージョン管理システムへのコミットをトリガにユニットテストからインテグレーションテスト、システムテストを自動で実施することがあります。このような場合、複数のテストフェーズを実施しているという意識はないと思います。しかし、それぞれのテストの設計は、それぞれの対象や観点をもって行いますし、実施結果についてもどの種類のテストの結果がどうだったかという意識をしていると思います。そういうマネジメントの単位で考えると、アジャイル開発では複数のテストレベルを並行してマネジメントしていると言えます。
アジャイルプロセス協議会のテスト、レビューWGでは、アジャイル開発におけるテストレベルについて議論をしました。メンバーの様々なアジャイル開発でのプロジェクト経験において、どのような単位でどのようなテストを実施してきたかを、出し合いました。その結果から、プロジェクトの特性によって、テストを実施する単位と観点の組み合わせが異なるということが分かってきました。
自分たちのプロジェクトの特性合わせたテストの粒度と観点をどのように計画していけば良いか？それを次のような表を使って考えていくのはどうかと思っています。

テストの粒度の表参照。(22ページ）

この表を使ってテストの全体像を共有し、その中でテスト駆動開発や継続的インテグレーションなどのプラクティスをどう位置づけるかを話し合い共有すると良いでしょう。

従来の開発においてテストは最後の砦としての役割を持っていることを冒頭で説明しました。
砦に対して大量の攻撃があると、砦は破られてしまいます。また、破られなかったとしてもその維持に多大な犠牲を払う必要があります。つまり、あまりに品質の悪いプロダクトはテストでは改善しきれません。逆に、敵から攻められない平和な世界では、門は開け放たれて日常を過ごすことができます。アジャイル開発であってもそうでなくても、テストを最後の砦から当たり前の日常にしていくために、私たちに何ができるかを考えていきたいです。