テスト戦略

1.はじめに

継続的デリバリーにおける、テスト戦略についての調査記録です。
継続的デリバリーの中での、テスト戦略の実装方法について記載します。
『継続的デリバリー信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』の第4章に対応します。
メモ：以下、文中はである調になります。

2.概要・目的

(1)概要

W・エドワード・デミングが挙げた14のポイントのうちの一つに、「高品質を実現するために、大人数での調査に頼るのをやめよ。まずはプロセスを改善し、本番の品質を作りこめ」とある。
テストは職務横断的な活動であり、チーム全体を巻き込む。
品質を作りこむために、自動テストを様々な抽象度(ユニットテスト・コンポーネントテスト・受入テスト)で書く必要がある。
デプロイメントパイプラインの一部としてこれらのテストを実行し、さらに、あらゆる変更に対してデプロイメントパイプラインをトリガーする。
この自動テストに加えて、品質を作りこむために、手動テストも実施する。
ショーケース・ユーザビリティテスト・探索的テストを、プロジェクトを通じて継続的に実施する。

(2)目的

テスト戦略の設計は、第一に、プロジェクトのリスクを識別して優先順位をつけ、そのリスクを緩和するためのアクションを決定するプロセスである。
さらに、優れたテスト戦略によって、以下のような作用が生じる。

テストによって、ソフトウェアが期待通りに動いていることを保証できる。バグ・サポートのコストを減らし、製品に対するユーザの評価を高められる。
テストをすることで開発プロセスに制約を課し、優れた開発プラクティスを促進する。
包括的な自動テストスイートが、アプリケーションに関する最も完全で最新化された形式のドキュメントとなる。実行可能な仕様のかたちを取り、システムがどう動くべきか、実際にどう動くかを表す。

3.対応概要

(1)テストの種類

テストは上記の画像のように分類できる。
y軸は価値を表し、x軸はフィードバック先を表す。

(2)第2象限のテスト

この区画には機能の受入テストがある。
受入テストは、ストーリーに対する受け入れ基準が満たされていることを保証するテスト。
受入テストによって、開発者の完了条件と、ユーザの要件を表現する。

(3)受入テストの自動化

受入テストの自動化の作用は、以下の通り。

フィードバックループの加速
テスターが、探索的テストやもっと価値の高い活動に集中できるようになる
受入テストが強力なリグレッションテストスイートとなる
テストから要件ドキュメントを自動生成でき、要件ドキュメントが陳腐化しない

自動受入テストは、通常、正常パス的なふるまいを完全に網羅するのみとする。
このとき、ほかの種類の自動リグレッションテストは包括的なものが一式揃っている必要がある。
優先して自動化すべきテストが、主要な正常パスに対するテストである。
代替正常パスと異常パスの優先度は、アプリケーションの安定性に依存する。

(4)第3象限のテスト

第3象限のテストは、ユニットテスト、コンポーネントテスト、デプロイメントテストである。
ユニットテストは、システムのコンポーネント間でやりとりしないテスト。
この制約により、ユニットテストは非常に高速に実行でき、素早いフィードバックを実現する。
コンポーネントテストでは、アプリケーションの様々な構成要素間のやりとりで発生する問題を検出する。
デプロイメントテストは、アプリケーションをデプロイする際に必ず実施する。
アプリケーションが正しくインストールされ、正しく設定され、必要なサービスと接続できて、レスポンスが戻ってくることを確認する。

(5)第1象限のテスト

第1象限のテストでは、期待されている価値をアプリケーションがユーザに対してデリバリーしていることを検証する。
カナリアリリースなどの発展的なアプローチによって、効果の高い機能を採用することができる。

(6)第4象限のテスト

非機能テストでは、機能以外のシステムの品質をすべてテストする。
システム全体にフィードバックするテストであり、機能要件と同じ検証方法を用いる。
非機能のテストのためのツールを使用することで、非機能の問題を早期検出できるプロセスを構築する。

(7)テストダブル

テストダブルとは、テスト対象の検証のためのシミュレーション用部品である。例として、モックやダミーがある。モックはコラボレーターとのやり取りをアサートし、コードの動作に関する詳細はアサートしない。

4.対応詳細

(1)起こりうる状況と戦略

a.新規プロジェクト

新規プロジェクトにおいては、受け入れ基準をドメインの観点で表現することが重要である。
これにより、保守性の高いテストスイートを作成できる。

b.プロジェクトの途中

プロジェクトの途中においては、ドメインの核となるユースケースをリグレッションから守る、正常パステストを優先して自動化する必要がある。
さらに、変更のないテストについても、自動化を進める。
シンプルなスクリプトと多様なデータによって、アプリケーションの状態を多く表現する。

c.レガシーシステム

レガシーシステムでは、まず自動ビルドを構築する。
次に、リグレッションテストスイートを作成する。
その後、自動テストをレイヤ化するアプローチを取る。
自動テストは、リグレッションから守るという目的に対して、価値がある。
あるいは、数多くの別々の環境でソフトウェアを実行する必要がある場合も、価値が生まれる。

d.インテグレーションテスト

インテグレーションテストでは、アプリケーションの各部分が、依存サービスと連携できることを保証する。
テストダブルの構築では、正常系と異常系をそれぞれシミュレートする必要がある。
外部サービスとの統合の問題として、以下が挙げられる。

使えるテストサービスがあるか。性能は十分か。
サービスプロバイダは、質問に答えたりバグフィックスをしたりカスタマイズ機能を追加したりしてくれるか。
システムの本番バージョンにアクセスして、キャパシティや可用性の問題を診断するためにテストすることができるか。
サービスAPIはアプリケーション開発に使っている技術を用いて簡単にアクセスできるか。あるいはチーム内に専門スキルを持つ人が必要か。
自分たちで使うテストサービスを書いたり保守したりする必要があるか。
外部サービスが期待通りふるまってくれなかった場合に、自分たちのアプリケーションはどう動くべきか。

(2)受入テストの作成プロセスの最適化

受入テストや受入テストの目的を簡潔に書くことで、開発者はストーリーの概要を適切にとらえ、最も重要なシナリオを理解できる。
テスターと開発者が早いうちから協力関係を築くことで、開発者とテスター間のフィードバックサイクルの量を減らすことができ、機能の漏れやバグの数も削減できる。

(3)欠陥バックログの管理

バグのバックログがあるとき、問題が誰にでもはっきりとわかるようになっていること、また、開発チームのメンバが責任をもってバックログを減らすためのプロセスを推進することが重要である。
あるいは、欠陥をフィーチャと同様に扱うというアプローチを取る。

5.影響、作用

テストによるフィードバックループを構築することで、各プロセスの「完了」を表現できる。
これにより、プロジェクトの前進性を保証することができる。

6.おわりに

以上が、継続的デリバリーの中での、テスト戦略の実装方法です。

7.参考文献

『継続的デリバリー信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』第4章　テスト戦略を実装する

Learning Records

『継続的デリバリー』第4章学習メモ