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

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Continuous delivery chapter4

Similar to Continuous delivery chapter4 (20)

Continuous delivery chapter4