Continuous delivery chapter4

『継続的デリバリー』読書会
第４章
テスト戦略を実装する
大崎的デリバリー
@favril

4.1 導入 (1/5)
• 「高品質を実現するために、大人数での調査
に頼るのをやめよ。まずはプロセスを改善し、
本番の品質を作り込め。」
• テストは
– 職務横断的な活動
– プロジェクト初期から継続的に行う必要がある
• デプロイメントパイプラインの一部としてテストを実
行し、アプリケーション、設定、環境などに変更があ
るたびに実行されるようにする
– テストが通る＝顧客が求める機能が完全に正し
く実装されたことの証明になる

4.1 導入 (2/5)
• 品質を作り込むとは
– 自動テスト戦略を改善するために定期的に作
業するということ
– 自動テストをさまざまな抽象度で書く
• ユニットテスト、コンポーネントテスト、受け入
れテスト
– 手動テストを継続的に実施
• ショーケース、ユーザビリティテスト、探索的テ
スト

4.1 導入 (3/5)
• 機能面だけでなく、キャパシティやセ
キュリティなどの非機能要件も、それを
守らせるためのテストを書く
– それらの要件を破る問題を早期に検知可能
• 発見が早ければ、修正コストも安くすむ

4.1 導入 (4/5)
• 既存プロジェクトに、理想的なテスト戦
略を導入するのは簡単ではない
– 自動テストのカバレッジを高めるのに時間が
かかる
– 自動テストに関してチームが学習している間
も、開発が続けられるようにする必要がある
– 最初から自動テストを導入して構築されたシ
ステムと同じレベルの品質に至るまでには長
い時間がかかる
– レガシーシステムに適用する方法は後半で

4.1 導入 (5/5)
• テスト戦略の設計とは
– プロジェクトのリスクを識別して優先順位をつけ、
それを緩和するためにどんなアクションを取ればよ
いか決定するプロセス
• さらに
– ソフトウェアが期待どおりに動くという自信
• バグが減り、サポートのコストも安くあがり、製品の評判も
よくなる
– 開発プロセスに制約
• 優れた開発プラクティスが促進される
– 最も完全で最新化された形式のドキュメント
• システムがどう動くべきかだけでなく、実際にどう動くかも
書いてある

4.2 テストの種類
ビジネス視点
自動手作業

ショーケース
プ
ロ機能の受け入れテストユーザビリティテストプ
グ探索的テストロ
ラジ
ミェ
ユニットテストク
ン
グインテグレーションテスト
非機能の受け入れテスト評
支ト
援システムテスト価

手作業／自動
自動
技術視点

4.2.1 開発プロセスをサポートする
ビジネス視点のテスト (1/3)
• 受け入れテスト
– ストーリーに対する受け入れ基準が満たされている
ことを保証するテスト
– 開発前に書かれていて、自動化されているのが望ま
しい
– 疑似本番環境で実行すべき
• ただし、外部サービス連携部分に対してはモックを使うかも
– アジャイルには欠かせない
• 開発者の「何ができれば実装完了か？」と、ユーザの「必要
なものは手に入ったか？」という問いに同時に答える
– 理想的には、顧客やユーザが受け入れテストを書くショーケース
のが良い機能の受け入れテストユーザビリティテスト
探索的テスト
ユニットテスト
インテグレーションテ非機能の受け入れテス
ストト
システムテスト

• 受け入れテストツール
– Cucumber, Jbehave, Concordion, Twist
– テストスクリプトを実装と切り離しつつ、シ
ンプルに実装と同期できる仕組みを提供

• 正常パス
– あるストーリーや要件における、正常動作の流れ
– Given-When-Then モデルで表現されることが多い
• ○○な状態が、ユーザが△△することで、××になる
• 代替パス
– 初期状態や、実行されるアクション、最終的な状態
にはバリエーションが存在する場合が多く、別の
ユースケースになることがある
• 異常パス
– 正常でも代替でもないエラーになるべき流れ
• 最も適切なテストケースを拾い出すには直感が必
要

4.2.2 受け入れテストを自動化する
(1/4)
• 自動受け入れテストの価値
– フィードバックループを加速させる
– テスターの作業負荷を軽減する
• 探索的テストやもっと価値の高い活動ができる
– 強力なリグレッションテストスイートになる
• 大規模アプリ、大規模チームの際に重要
– 要件ドキュメントが自動生成可能になる
• ドキュメントが陳腐化しない
ショーケース
機能の受け入れテストユーザビリティテスト
探索的テスト
ストト

(2/4)
• リグレッションテストは特に重要
– 四象限のカテゴリをまたがる
– 自動テストが全体のリグレッションテストに
なる
– 変更をした際に、既存機能を壊していないこ
とを保証する
– リファクタリングも安心して行える
– 優れたプラクティス＆適切なツールの使用で、
恩恵がコストを明らかに上回る
• 詳しいテクニックは８章で

(3/4)
• すべてを自動化する必要はない
– ユーザビリティやルックアンドフィールの一貫性、
探索的テストなどは自動化するのが難しい
– 多くの場合、手動テストで十分だし、手動テストの
方が自動テストより優れている
– 自動テストでは正常パス的ふるまいを網羅し、それ
以外は一部だけ
• 安全だし効率的
• ただし、他の種類の自動リグレッションテストで包括的なも
のが一式揃っていることを前提とする
• 包括的＝カバレッジ８０％以上
– とはいえ品質が重要で、カバレッジは貧弱な尺度
– 単体／統合／受け入れテストが含まれるていて、それぞれが８
０％以上

(4/4)
• いつテストを自動化すべきか
– 経験則としては、同じテストを２回繰り返したら
– ただし、テストの保守に大量の時間を費やさなく
てもよいと自信のあるとき
• どこを自動化すべきか
– 主要な正常パスに対するテスト
• 開発者のスモークテストとして使われる
– 作業中の機能の一部を壊してないか、素早くフィードバッ
クを提供すべき
– さらに
• アプリが安定してるなら、代替正常パス
• バグが多いなら、異常パス

受け入れテストはUIを叩くべき
か？
• 理想的にはアプリのUIに対して直接実行すべき
• だがUIテストツールは、UIとテストを密結合させ
る
– 誤った判定が多く下される
• アプリにはまったく問題がなくても、チェックボックスの名
前が変わっただけでテストが壊れる
– テストをアプリと同期させておくために、大量の時
間を浪費する
• 解決策
– １、テストとUIの間に抽象レイヤを設ける
– ２、UIのすぐ下に公開APIを設け、それに対してテス
トする
– 詳細は８章

技術視点のテスト (1/2)
• ユニットテスト
– コードの特定の一部を個別にテストする
– DBにアクセスしたり、ファイルシステムを使ったり、
外部システムと通信したりしてはならない
– 非常に高速に実行でき、変更によって既存の機能が
壊れていないか素早くフィードバックを受けれる
– システム内のほぼすべてのパスを網羅する必要あり
（最低でも80%）
– アプリの様々な構成要素間でやりとりが行われた結
果発生するバグは取りこぼす
ショーケース
探索的テスト
ストト

技術視点のテスト (2/2)
• コンポーネントテスト（インテグレーショ
ンテスト）
– ユニットテストより大きな機能のクラスタをテス
トする
– ユニットテストが取りこぼす問題を検出可能
– ユニットテストよりは遅い
• セットアップに時間がかかる
• I/Oが多い
• DBやファイルシステム、他システムとも通信する

• デプロイメントテスト
– デプロイメント（インストール／設定／他サービ
スとの接続など）がうまくいったことを確認する

4.2.4 プロジェクトの評価をするビ
ジネス視点のテスト (1/4)
• 期待されている価値を、アプリがユーザに実
際にデリバリーしているかを検証するテスト
– アプリが仕様を満たしていることを検証するだけ
でなく、仕様がそもそも正しいのかを確かめる
– 仕様が前もって完璧に定義されたプロジェクトは
存在しない
– ソフトウェア開発は本質的にイテレーティブなプ
ロセスで、効果的なフィードバックループを構築
して初めてうまくいく
ショーケース
探索的テスト
ストト

• ショーケース
– ビジネス視点のプロジェクト評価用テストで最も
重要
– アジャイルでは、イテレーションが終わるごとに
ユーザに実施し、新しい機能をデモする
• 誤解や、仕様に問題があっても早期に検知できる

– 良い面／悪い面
• 良い面：ユーザ(顧客)が新しい成果を手にし、いろいろ
試せる
• 悪い面：その結果として、大量の提案や改善

• 探索的テスト
– テスト実施時、テスト設計を積極的にコント
ロールし、得られた情報を使ってよりよいテ
ストを新しく設計する
– 単にバグを発見するだけでなく、自動テスト
を新しく作ることにもつながる
– 潜在的には、アプリに対する新しい要件のた
めの素材も提供する

• ユーザビリティテスト
– アプリが実際にユーザに価値を提供できるかを測る
究極のテスト
• ユーザがソフトウェアを使って目的を達成するのが、どれほ
ど簡単かを知るために行う
– 開発をしていると、問題に視野が限定されてしまうことは(技術畑
でない人であっても)よくある
– アプローチの方法や、集積するメトリクスは様々
– カナリアリリース
• 実際のユーザに、ベータテストさせる
• 少しだけ異なるバージョンのアプリを同時に本番に置き、特
定のユーザにだけ使用させて効果を比較する
• 十分に価値をデリバリーしてなければ、その機能を破棄する
• 非常に効果の高い機能を採用できる

4.2.5 プロジェクトの評価をする技
術視点のテスト
• 非機能テスト
– 機能以外のシステムの品質をすべてテストする
• キャパシティや可用性、セキュリティなど
– 非機能の受け入れ基準はアプリの要件の一部として定義され
るべき
– テストやそのツールは、機能テストのものと異なるものにな
りがち
• 実行に特殊な環境が必要だったり、準備・実装に専門知識が必
要だったり
• 実行に長い時間がかかる
– 最近はテストツールが成熟してきているので、プロジェクト
開始時に、少なくとも基本的な非機能要件のテストはいくつ
か準備しておくことをお勧めするショーケース
探索的テスト
ストト

4.2.6 テストダブル
• テストダブル(モックやスタブ、ダミー)のタイプ
– ダミーオブジェクト
• 実際に使われることはなく、パラメタリストを埋めるためだけ
に使われる
– フェイクオブジェクト
• 実際に動くが、手抜きをしている
– スタブ
• テスト中に行われる呼び出しに対し、お決まりの回答を返す
– スパイ
• スタブの一種で、どう呼ばれたかに関する情報をある程度記録
する
– モック
• 呼び出されるであろう内容をあらかじめ定義しておき、期待し
てない呼び出しには例外をスローし、期待される呼び出しがす
べて行われたことをチェックできる
• 間違って使われることが多い

4.3 実際に起こりうる状況と戦
略
• テスト自動化時にチームが直面するであ
ろう典型的シナリオの紹介

4.3.1 新規プロジェクト (1/2)
• 理想を実現するチャンス
• 基礎的ルールを定めて、テスト基盤を構築すれば、継続的インテグ
レーションに向けた良いスタートが切れる
– 変更のコストも低い
• 重要なのは一番最初から自動受け入れテストを書くこと
• そのためには
– テクノロジープラットフォームとテストツールを選択する
– シンプルな自動ビルドを準備する
– INVEST(Independent-Negotiable-Valuable-Estimable-Small-Testable)原則に
従ったストーリーを受け入れ基準と合わせて導き出す
• その上で厳格なプロセスを実装
– 顧客、アナリスト、テスターが受け入れ基準を定義
– テスターは、受け入れ基準に従った受け入れテストを自動化する
– 開発者は、受け入れ基準を満たすふるまいをコーディングする
– 自動テストが、種類問わず１つでも失敗したら優先度を最大にして修
正する

4.3.1 新規プロジェクト (2/2)
• 顧客やプロジェクトマネージャーを含むチームの全員が、受
け入れテストによる恩恵に賛同することが重要
– テストの品質を犠牲にしてでも、早期のリリースを顧客が優先
するなら、従わないといけない
– ただし、その結果何が起こるかははっきりさせておくべき

• 受け入れ基準を注意深く書き、ストーリーによってデリバ
リーされるビジネス価値を、ユーザ視点から表現するように
しておくことが重要
– テストが保守できなくなる主要な原因は、下手に書かれた基準
のせい

• これらのプロセスに従った開発者のコードは、
– カプセル化がうまく行われ、意図がわかりやすく、関心事が明
確に分離され、コードの再利用もよく行われている

4.3.2 プロジェクトの途中
• 導入するための最善の方法
– 最も一般的で価値が高く重要なユースケースから始めるこ
と
• 本当のビジネス価値がどこにあるかを明確に特定
• その機能をテストを使ってリグレッションから守る
• 価値の高いシナリオを網羅する正常パステストを自動化する
– 網羅するアクションの数を最大化しておくことは有益
– 同じ機能に対して手動テストを２回以上やっていたら
• 今後も変更するかを確かめ、変更がなさそうなら自動化する
– 逆に、自動テストでよく修正しているものがあったら
• その箇所のテストを無視する設定をする
• （無視していいの？）
– 時間が無いときは、さまざまなパターンのテストデータを
使って、カバレッジを保証するのが良い

4.3.3 レガシーシステム
• 存在しなければ自動ビルドを作ることを優先する
– 作成はドキュメントがあれば容易、チームメンバーと話せればなお簡
単
– スポンサーなどの理解を得るには、リグレッションテストを作り、シ
ステムの機能を保護する価値を説明する
– 価値の高い機能を網羅する自動テストを幅広く作る

• 自動テストをレイヤ化する
– １、シンプルで高速に実装できるテスト
– ２、特定のストーリー用の重要な機能のテスト
– 新規機能は、新規プロジェクトのときと同様にする

• 自動テストを書くのは価値をデリバリーできるときだけにすべき
– アプリは、機能を実装するコードと、フレームワークコードに分けら
れる
– リグレッションバグはほとんど後者の変更が原因
– したがって後者を変更しない機能を追加する際は、包括的な自動テス
トを書くことにあまり価値がない

4.3.4 インテグレーションテスト
(1/4)
• インテグレーションテストとは
– アプリ内の独立した各部分が、依存しているサービスとう
まく連携できることを保証するテスト

• 受け入れテスト
– 実際の外部システムや、サービスプロバイダの制御するレ
プリカに対して実行するもの
– テストハーネスに対して実行するもの

• 本番以外で実際の外部システムを叩かずにアプリを安
全にテストするために
– 外部システムへのアクセスをファイアウォールで隔離
– 擬似的な外部サービスと通信する設定を用意

(2/4)
• 自前でテストハーネスを開発するケース
– インタフェースは定義されているが、外部システ
ムがまだ開発中
– 開発は終わっているが、テスト用のインスタンス
がない
– テストシステムはあるが、レスポンスが入力によ
らず固定やランダム
– インストールが難しい or UIを通じて手作業の必
要がある
– 外部サービスを含んだ機能用に、自動テストを書
く必要がある
– テスト環境が、CIの負荷に耐えられない

(3/4)
• 状態を記憶するサービスの場合の、テスト
ハーネスはきわめて凝った作りになる
– この状況で最も価値の高いテストは、ブラック
ボックステスト
• 外部システムが返してくる可能性のあるレスポンスを
すべて考慮し、そのレスポンスそれぞれに対してテス
トを書く
• モックでは、リクエストを識別して適切なレスポンス
や、例外を返す必要がある
– 期待されるレスポンスだけでなく、予期せぬもの
もテストできるようにする必要がある
• 可能な限り多くの異常な状況に対し、アプリが対処で
きることを確認する

(4/4)
• 自動インテグレーションテスト
– システムを本番にデプロイした際のスモークテスト
として使える
– 本番システムを監視するための診断アプリとしても
使える
– 統合の問題をリスクとして認識したなら、このテス
トは最も重要
• テストサービスはあるか？性能は十分か？
• サービスプロバイダのサポートはあるか？
• 本番バージョンで、キャパシティや可用性の問題を診断する
テストができるか？
• APIは簡単にアクセスできるか？チーム内に専門家が必要
か？
• 自分たちでテストサービスを開発、保守する必要は？
• 外部サービスが期待通りにふるまわなかった際の、挙動は？

4.4 プロセス
• 受け入れテストを作る最適な方法
– 各イテレーションの最初にステークホルダー(顧客、
アナリスト、テスター)全員を集めて、打ち合わせを
行い、テストする優先度が最も高いシナリオを決め
る
• Cucumberなどのツールを使うと、受け入れ基準を自然言語
のかたちで出力できる
• DSLを使うと、受け入れ基準をDSLで書ける
• 少なくとも、シナリオの正常パスを網羅するできる限りシン
プルな受け入れテストを、顧客にその場で書いてもらう
– これにより
• 開発者はストーリーの概要を適切にとらえ、最も重要なシナ
リオが何かを理解できる
• 開発者とテスター間のフィードバックサイクルを減らせる
• 機能漏れやバグの軽減につながる

4.4.1 欠陥バックログを管理する
(1/3)
• 欠陥バックログをうまく作る方法、ある
いはそれにどう取り組むか
– 欠陥ゼロ（ジェームズ・ショア）
• バグが見つかったらどんなときもすぐに修正され
るようにしておく
• テスターがバグを早期に発見し、開発者がすぐに
直せるようなチーム編成
– バックログがある場合、
• 問題が誰にでもはっきりとわかるようになってい
ること
• 開発チームのメンバーが責任を持って、バックロ
グを減らすためのプロセスを推進すること

(2/3)
• 欠陥バックログの放置にはリスクがある
– バグを無視し、修正を先延ばしにし続けると、
重大なバグもノイズの中に消える
– 受け入れテストがまったく無かったり、ブラ
ンチがtrunkから離れすぎて受け入れテストが
効果的でないと、問題はさらに悪化する

– 詳細な議論は１４章

(3/3)
• 欠陥を機能と同じように扱うアプローチ
– 機能と、特定のバグを比べて、どちらの優先
度が高いかを決めるのは顧客の仕事
– バグを分類し、優先度をつけることは意味が
ある
• 致命的、作業の妨げになる、中、低
• 発生頻度、ユーザ影響、回避方法の有無を考慮す
るアプローチもある
– バグが分類できれば、ストーリーと同様に優
先順位を付けることができ、一緒に見ること
ができる

4.5 まとめ
• 高品質なソフトを作るには、
– デリバリーに関わるすべての人が、テストに責任を
負う
– プロジェクト初期から実践する
• テストの第一目的は、開発、設計、リリースを駆
動するフィードバックループを構築すること
– 最も短いフィードバックループは、システム変更時
に実行される自動テスト一式によって作られる
• テストは「完了」の定義と本質的に相関している
– テストによって機能の１つ１つが理解できる
– プロセスを通じてどこでもテストが実行されるよう
にする

感想
• ニホンゴムズカシイ
• 割と拷問

• 普段はRspecで、Model と Controllerのテス
トしか書かないので、Cucumberを使った
受け入れテストを一度試してみたいと
思った

Continuous delivery chapter4

More Related Content

What's hot (19)

Similar to Continuous delivery chapter4 (20)

Continuous delivery chapter4