【読書記録】Complete Guide to Test Automation (2)

books

前回の投稿はこちら

3章 People and Tools(人々とツール)

テスト自動化にあたっては、正しいツールを選ぶことが重要だが、そのためにはまず誰がテストを書くのかを決めないといけない。いくつかのオプションが提示されている。

  • 手動テスターや経験の浅いプログラマを自動化開発者に育てる。
  • 手動テスターと自動化プログラマで作業分担。
  • 専任の自動化チームを置く。
  • 各チーム内に専任の自動化開発者を置く。
  • 開発者全員がテスト自動化を行えるようにする。

アジャイルな開発チームだと、4つ目か5つ目だろう。この2つのオプションの利点は、イテレーション毎にフィーチャとそれに対応する自動テストが同時に実装されるようにできる点だ。

4章 Reaching Full Coverage(フルカバレッジに到達する)

自動テストによるフルカバレッジの実現について述べられている。

カバレッジ測定方法は幾つかあるが、コードカバレッジが最も客観的で正確な指標となる。仮に100%カバレッジを達成したとしてもバグゼロとは言えないし、事実上到達不能なコードもあるので、その点は注意。

フルカバレッジを実現する前提は、

自動化のペース > 機能追加のペース

であること(そうでないと追いつけない!)

サニティ・テスト(基本機能を検証するテストケース)の自動化から始めて、横展開していくのがよい(もちろん、最初のイテレーションから常に自動化するようにできれば理想だが)

その他、自動化対象を選定する上での優先度付け方法などが述べられている。

5章 Business Process(業務プロセス)

ここでいう業務はテスト自動化に関わる業務を指す。まず大事なのは、定常的にテストを実行すること。これが大前提。そして、テストの失敗はASAPで修正すること。

いつ、だれが、どうやってテストを書くか。
これについてはATDD/BDD/SbEが紹介されている(これらはほぼ同じ手法)。ユーザーストーリーの受け入れ条件を明確にし、それを検証するテストコードプロダクトコードに先んじて書く、その後プロダクトコードを書く。テストが通ったらユーザーストーリーが完了となる。ってやつ。

あとは継続的デリバリと継続的デプロイ、カナリアリリース、A/Bテスト、といった話題が書かれている。

6章 Test Automation and Architecture(テスト自動化とアーキテクチャ)

ここでいうアーキテクチャは2種類のものを指す。
自動テスト自体のアーキテクチャと、テスト対象システム(SUT)のアーキテクチャだ。

自動テストのアーキテクチャ(ハイレベルの方針、決断)はテストがどのように書かれるか、どう実行されるか、何ができて何ができないか、に影響を与える。その選定にあたってはSUTのアーキテクチャも考慮に入れる必要がある。

SUTのアーキテクチャをよくあるレイヤード・アーキテクチャと想定して、自動テストのテストスコープ(SUTのどの範囲を自動テストするか)には幾つかの選択肢があるそうだ。

E2Eユーザが行うことにもっとも近い。
遅い、安定しない、脆いなどの欠点あり。
片道のE2E結果はDBを覗いて確認。あるいは入力データをDBに直接投入。
実装の詳細に依存することになり、設計変更でテストが壊れるリスクも。
サーバ側だけ(往復)Web層のコントローラをテスト。
サーバ側だけ(片道)Web層のコントローラをテスト。
入力データの投入や結果検証はDBを直アクセス。
クライアント側だけ・クライアント・リッチなアプリケーション
・サーバがレガシーやサードパーティなど
上記のようなケースで、サーバから隔離してクライアント側をテスト。
Under the Skin実際のUIではなく、その下のViewModelと直接やり取りする。
純粋なロジックビジネスロジックを直接テスト。
(ユースケースロジックやドメインロジックだろうか?)
コンポーネントテスト単一コンポーネントを他から独立してテスト(モックを多様)。
ユニットテスト最小単位でのテスト。
テストスコープ

テストシナリオが抽象化されビジネスの用語で記述されていれば、テストスコープはシナリオには非依存。
たしかにCucumberのようなBDDツールで、Gherkin形式で記述されたシナリオに対する自動化コードは、Seleniumを使ってUIを操作することもできるし、アプリケーションサービスを呼び出すこともできるよな。抽象化バンザイや。

実際には、複数のテストスコープを組み合わせてね、とある。例えば、フィーチャ毎の代表的シナリオはE2Eで、バリエーションはサーバ側だけ、とするなど。このあたりはテストピラミッドを意識してテスト戦略を立てる必要があるよね。

7章 Isolation and Test Environments(隔離とテスト環境)

システムの出力は、入力と、現在の状態によって決定される。

状態にはいろいろある。

  • CPUレジスタ
  • RAM
  • ハードドライブ(ローカル、ネットワーク)
  • リモートのマシンやサービスの状態
  • ブラウザのキャッシュやクッキー

など。ちなみに、SUTに対する直接的な入力以外の、諸々の前提となる条件のことをテスト用語でテストフィクスチャというのだけど、要は状態のことである。

テストケースの実行毎に状態が完全に隔離されてれば何の問題もないんだけど、状態が共有されている場合、しばしば問題を生じる。DBのデータなんかは特に問題になりやすいよな。

本章では、どんな問題が生じるかの例示と、解決手段がいくつか紹介されている。

8章 The Big Picture(全体像)

ソフトウェアアーキテクチャとビジネス構造との関係性に影響を与えるコンウェイの法則について触れられている。

その他はScrapboxのメモが保存失敗してたので割愛(涙)

この先

9章から第2部となり、具体的にどのようにテスト自動化をしていくかを、チュートリアル形式で説明してく構成となっているようだ。.NETとC#の環境が手元にないので、ぼくは読むだけにする。

ちょっと見た感じ、C#のコードからSeleniumを操作する感じだったので、ある程度プログラミング能力のあるテスターまたは開発者自身によるテスト自動化を想定しているようだ。

続きはそのうち。