アジャイルテストのテスト設計の話

Incremental test design

　昨年度追加されたISTQBのFoundation Level Extension Syllabus Agile TesterのAgile Testing Practicesの項にはテスト設計に関する興味深い記述がある [1]。

Incremental test design: Test cases and charters are gradually built from user stories and other test bases, starting with simple tests and moving toward more complex ones.

アジャイルテストのテスト設計の特徴として

ユーザーストーリーをテストベースとして用いる事
シンプルなテストケースの追加から始まり、より複雑なものへと変化して行く事
Incrementalである事

が挙げられている。

アジャイルテストについておさらい

　アジャイルでは顧客に価値を届ける最小単位の要求をユーザーストーリーと呼ぶ。スプリント等と呼ばれるタイムボックスの中で、複数のユーザーストーリーの開発を行う[2]。

　アジャイルテストではこのユーザーストーリーをテストベースとして用いる。ユーザーストーリーに記載されている顧客目線でのシステムの期待される振る舞いを、テスターはテスト可能なストーリーへと変換する。ExampleやBDDなどの記法とコミュニケーションを通じて顧客、開発者、テスター間で期待するシステムの仕様について合意する[3]。また、シンプルなハッピーパスのテストから始め、そのテストがパスしてからエッジケース等の複雑なテストケースに進む[4]。

　厳密にはアジャイルテストではないが、アジャイルテストの原型となっているのがテスト駆動開発(TDD)だ。テストを先に書く事によってレビューとリファクタリングを繰り返しながら設計を改善していく事が可能であると言われている [5]。

　アジャイルテストにはもう一つ、アジャイルテスト４象限という大切な概念がある。アジャイルテストが取り扱うテストを４つのグループにカテゴライズし、テスト計画を立てて行くというものだ[6]。

開発者のためのテスト=内部品質
顧客のためのテスト=利用時品質

のようにカテゴライズし、それらのテストをいつどのように実施するか計画を立てる事を推奨している。

アジャイルテストのテスト設計の特徴

これらを踏まえ、アジャイルテストのテスト設計には以下の特徴がある。

顧客のテスト設計への参加

　アジャイルテストでの重要なテスターの役割は、顧客のビジネス的なシステムへの要求を非エンジニアである顧客にも理解可能なExampleやテストに変換する事だ。これにより、テスト設計への顧客の参加が可能になる。

開発開始前のテスト設計の実施

　アジャイルテストではスプリントの開始前、つまり開発の開始前にテスト設計を行い顧客、開発者と合意する。ここでいうテスト設計は一般的な意味での網羅的なテスト設計ではなく、

テスト観点の洗い出し
Happy path（やCritical path）のExample

のみしか含まないかもしれないが、あえてここではテスト設計と書く。

　これはテストプロセス視点で見ると、テスト設計を通じて仕様についての抜け漏れや間違いのレビューを早期に実施している事になる。

ユーザーストーリーとテストの追跡性

　ユーザーストーリーをテストベースとしてテスト設計を行うため、ユーザーストーリーとテストの追跡性が担保される[7]。そのため、ユーザーストーリーへの変更要求に起因するようなテストスクリプトへの変更や、ユーザーストーリーレベルでのテスト設計の変更が容易であるという長所がある。また、ユーザーストーリーの範囲で、単体テストやコンポーネントテストの継続的なリファクタリングが行われる[8]。

Happy path から Edge caseへ

　Incrementalなテスト設計と呼ばれる理由の一つがここにあると考えている。アジャイルテストでは、スモークテストで実施するようなhappy pathのテストとedge caseのテストのテスト実施を段階を分けて行う。実際にはテスト実施だけでなく、テスト設計も段階を分ける事が多い（と身の回りでは感じる）。

　テストの優先順位付けを行いリスクの大きいバグを早期に発見する事で、より俊敏で安定した開発•テストプロセスを築く事が出来る。

スプリントごとのアドホックなテスト設計の追加

　アジャイルテストのテスト設計がIncrementalであると言われるもう一つの理由がここにあると考えられる。テスト設計はスプリントの開始前にユーザーストーリーをテストベースとして実行される。そのため、テスト設計はスプリントごとに追加される。

アジャイルテストのテスト設計が苦手な事

　こうやって書いてくると良い事ずくめに感じられるアジャイルテストのテスト設計だが、これらの特徴に起因する苦手な事が存在する。

スプリントをまたいだ機能のテスト設計が苦手

　ユーザーストーリーをテストベースとしてテスト設計を行うので、どうしてもスプリントをまたいで実現される機能のテストが苦手という特徴が生じる。この弱点は通常は問題にはならない。優秀なプロダクトオーナーやアーキテクトは、システム要求をよしなに分割してストーリーは作られているはずである。例えば、機能BとCが機能Aに依存している場合、

スプリント1: 機能A の開発とテスト
スプリント2: 機能B の開発と　機能AとBの結合テスト
スプリント3: 機能C の開発と　機能AとCの結合テスト

といったように。しかし、ここで、

スプリント1: 機能AとCの一部を開発
スプリント2: 機能BとCの一部を開発
スプリント3: 機能AとBの一部を開発

のように、ユーザーストーリーがきちんと整理されていないと、結合テストをいつやるか？結合テストのスコープは何か？といった問題が生じる。（そんなのScrumじゃないと言ってしまえばそこまでだが、Scrumじゃない事を見落とすと非効率なテスト設計の本質を見失う。）

スプリントをまたいだテスト設計の最適化が苦手

　テスト設計の重要な役割として、テストカバレッジを担保しながらテストケース数を減らすテストの経済学の考慮がある[9]。しかし、アジャイルテストではスプリントをまたいだテスト設計の最適化が苦手である。

　何故か？第一にユーザーストーリーに対するカバレッジを100%にする事を大前提としている事、次にユーザーストーリーに対する追跡性を重要視しているため、システム全体でどのようなテストがどれくらいの規模で行われているのかを可視化する事が苦手な事に起因している。

　例えば今回のスプリントで追加した10件のテストケースによって、前回のスプリントで作成した100件のテストのテストケースを削除しても同等のパスカバレッジを担保出来るといった状況であっても、一般的にテストケースの最適化は行われていないのではないかと思う。

　こう考えている理由は、○○百億件のテストを自動化しナイトリービルドで実行しているエンジニアから「実はテストケースの減らし方が分からない」という話を聞いた事があるからだ。この会社では、テストの最適化をテスト実行の優先順位付けで行っているのは有名な話だ。

　また、実践アジャイルテストの著者のJanet Gregoryの"Traceability"というタイトルのブログエントリが興味深い。ユーザーストーリに対する"Traceability"そのものは重要だが、"Traceability Matrix"のような全体を俯瞰するための表はいらないと述べている[10]。

アーキテクチャのテスト設計が苦手

　賛否両論あると思うが、アジャイルテスト４象限の第４象限に非機能要件のテストが定義されているのにも関わらず、アジャイルテストは非機能要件のテストが苦手だと指摘されている[11][12]。

　この問題は根が深い。アーキテクチャが自律的に、継続的に進化するのであれば、当然その反映であるシステムの品質、例えばパフォーマンスや運用性と言った品質も継続的にテスト、モニタリングされる必要がある。

　これは、アジャイルでのアーキテクチャの肩身の狭さのため、アーキテクチャの反映であるシステム品質がおろそかにされがちな為なのでは、と考えている。この問題の解決策として、パフォーマンスやユーザビリティ等の非機能要件もユーザーストーリとしてバックログに追加する事が提案されている[13]。

まとめ

　アジャイルテストではユーザーストーリーを中心に据える事で、

顧客がテスト設計に参加
テスト設計を通した仕様のレビューの前倒し
Incrementalにテスト設計

をし、アジャイルなテスト設計を実現している事を挙げた一方で、

スプリントをまたぐテスト設計の最適化、
ユーザーストーリーとの関連が低いアーキテクチャ等の品質のテスト

が苦手な事を述べた。

　アジャイルテストを導入するにあたっては、その長所はもちろんだが苦手な部分についてもきちんと考慮する必要がある。苦手な部分を無視するとテストの作り過ぎによる炎上やテストの抜け漏れを引き起こす。それらにきちんと対処すれば迅速で安定したテストプロセスの構築を可能にする。

　一方でこれらのアジャイルテストのテスト設計の苦手な部分は、これからアジャイルテストが体系化していくにあたっての課題であると考えられる。現在までアジャイルテストはどちらかというと「開発者側のもの」という印象があったが、これらの課題を解いていくにはテストや品質のスキルも必要になると考えられる。

Test Automation

テスト自動化とか品質とか勉強会とかやってるエンジニア（Automation Architect）のブログです。