こんにちは。ダイの大冒険エンジョイ勢のbun913と申します。
わたしはSDET（Software Development Engineer in Test）という職種で働いており、API のテスト自動化だけでなく、システムの品質を向上させるための様々な活動を行っています。
今回は Testing Web APIs という洋書を読んで、単なるAPIテストのテクニック集を期待していたら、それ以上の学びがあったので記事にまとめました。
この書籍の概要
| Key | value |
|---|---|
| タイトル | Testing Web APIs |
| 作者 | Mark Winteringham |
| 出版社 | Manning Publications |
| 出版年 | 2022年10月 |
タイトルからREST APIのテスト技法や実装方法が中心の内容かと想像していましたが全12章に渡って、「ちゃんとプロダクトを理解し、計画を立ててから機能・非機能双方でAPIに対するテストを行う」という包括的な内容で良い意味で驚きました。
特にテスト計画に時間をかけすぎずに整理する考えや、 Explore It! という探索的テストの本を参照しながら、何をテストするか整理する方法は具体的なHowに寄りすぎず、非常によかったです。
心に残ったポイントの紹介
ここからは書籍を読んで特に私の心に残ったことを紹介します。
Chapter 2: Beginning our testing journey
本書の第2章では、APIテストを始める前の重要なステップとして「プロダクトを深く理解すること」が強調されています。
The more we learn, the clearer our strategic choices will become when it comes to implementing our strategy.
この一文が特に印象的でした。私のメモには「デモを頼んだり、ドキュメントを読むでもいいからまずはプロダクトをよく知る」と書いています。これは 世界一流エンジニアの思考法 でも似たような記述があったと記憶しています。
以前別の記事（ゆるい習慣と工夫で時間を削減せよ!SDET（SET)が1人DevOpsタイムでしている改善 | APIのコールを見る習慣）でも書きましたが、Webシステムに対してフロントエンドシステムから実行しているバックエンドAPIのコールを日々みておくことは重要だと考えています。
本書ではAPIコールだけでなく、ネットワークの通信レベルでの理解についても触れながら、以下のような方法でツールやプロダクトの理解を深めることが紹介されています：
- Dev tools の活用: 実際のシステムがどのようなAPIを叩いて動作しているかを開発者ツールで確認する
- Source code の読解: コードを読むことで内部実装を理解する（今はCursorなどのツールで開発者以外でもソースコードを読みやすくなっています）
- モデルの構築とフィードバック: システム構成を図表化してチームで理解を深める
初期の理解では、単純にフロントエンドからバックエンドを経由してデータベースやストレージにアクセスしているという程度の理解でした。
しかし、実際にDevToolsでAPIコールを観察することで、より詳細な動作が見えてきます：
さらに理解を進めると、「どうやらS3というストレージ自体の可用性はとても高いので、あまりダウンのシナリオを気にしないで良いらしい」といったリスクの理解にもつながると思います。
モデリングというと重いですが、軽い図を通してチームで理解を深めるというのは大事ですね。
Chapter 3: Quality and risk
テストを考える前に、そもそも「何が品質なのか」を定義することの重要性が第3章で強調されています。
By establishing a better understanding of what quality means to our users, we can use that knowledge to guide what we test and what we don't.
私としては「テストを考える前に、ユーザーにとっての価値が何かを考えて優先づける。何をするかしないかを考える」というメッセージとして受け取っています。
以下のような方法が紹介されています:
- ステークホルダーやユーザーへのインタビュー: システムの価値について開発チームやPOにインタビューする（3冊以上の書籍で見かける重要なポイント）
- リスクマトリクスの作成: 重要度と可能性でリスクを整理し、何からテストするかを明確化する
私も「重要性」と「テスト実装の容易性」などの軸でリグレッションテストの優先度を整理していました。一つでも動く自動テストを実装するのも大事ですが、どのようなリスクに対処するためのテストなのかを優先づけることも重要ですね。
Chapter 5: Exploratory testing APIs
第5章は探索的テストに焦点を当てており、APIテストにおいてもどのように探索のためのチャーターを設計するかという考え方が紹介されています。
先に紹介した Explore It! という書籍の形式の他、別の書籍のチャーターの書き方も紹介されているので、他の書籍を読む前にこの章を読んでおくと進めやすいかもしれません。特に私のように開発のバックグラウンドからテストの技術を学んでいる方は、チェック の観点に加えて 探索 の視点を持つことが重要だと思います。
探索的テストのサイクル
本書では探索的テストのサイクルとして「探索→学習→実験」のループが紹介されており、テストの結果から学ぶというプロセスを重視している点が良いと感じました。
APIテスト向けのチャーター例
一般的な探索的テストのチャーターをAPIテストに適用した例：
EXPLORE: PUT /branding/ API endpoint
Using: different data sets
To: discover issues in which data is incorrectly handled
便利なツールの活用
書籍では以下のようなツールが紹介されています：
- Dev Tools / Postman: Webエンジニアがよく利用する基本ツール
- Java: 書籍内のAPIテストコード例で多用
- Burp Suite: セキュリティテスト向けツール（fujiyamaorangeさんの記事も参考になります）
セッションの目的
Our goal in a session is to learn as much information related to the charter we set as is reasonably possible.
テストケースの実行だけでなく、学習が目的であることが強調されています。探索的テストは文字通り "What if（これならどうなるんだろう）" の精神で実行していくと思うので、チェックではなく「よーし。探検するぞぉ」という気持ちで取り組むことが私のいつもの気持ちです。
Chapter 6: Automating web API tests
第6章では、ただ自動化するのではなく、価値のある自動化を実現するためのポイントが示されています。
how to create automated regression testing that is of value to us. To do this, we need to consider two challenges:
- Picking the right things to automate
- Implementing our automation in a way that is reliable and easy to maintain
テストコードの品質
We should use the same techniques and approaches for our automation code that we use for keeping our production code clean,
私はテストコードに対してフォーマッターやリンターを適用しているのですが、開発の方に「セキュリティIssueには対応してね」などとお願いするのに、長くメンテナンスするテストコードに対して自分が甘く考えるのはおかしいですよね。改めて深く心にささりました。
フレームワークの構造化
本書ではテストコードを以下の3つのレイヤーに分けることが推奨されています：
To help keep our code DRY ("don't repeat yourself") and maintainable, we organize it into three distinct sections: tests, requests, and payloads.
この書籍では Java を利用したテストコードで、リクエストやレスポンスの型を定義しながらコードを書かれています。
私がAPIテストを実装する際にはこれらの定義すら非常に手間に感じるし、間違うのは嫌なので以下のような仕組みで自動生成しています。
SwaggerのようなAPI ドキュメントからも自動生成できるツールがありそうなので、まだAPI仕様書がないような環境であれば、私ならその定義を継続的に生成できる仕組みを作ることから始めるかもしれません。
Chapter 7: Establishing and implementing a testing strategy
第7章では、テスト戦略を立てる際の具体的な手法が紹介されています。
テスタビリティの理解
テスト戦略を実装する前に、チームのテスタビリティ（テストのしやすさ）を考慮することの重要性が強調されています。
Therefore, when planning our testing, we need to take into account how hard or easy it is for our team members to carry out the specific testing activities we care about.
ISTQB Test Automation Engineer という世界的なテスト自動化に関する認定試験のシラバスにおいても、チームのスキルセットを考慮することの重要性が書かれています。
私のチームではPlaywrightなどのツールを使ってAPIテストを実装していますが、もしチームメンバー全員がコーディングに不慣れであれば Postman などのGUIベースかつ自動化の仕組みが実装しやすいツールを選択すると思います。
If, after discovering that our context's testability is low and that the testing activities we want to implement as part of our test strategy will require considerable investment to make them successful, we might want to reconsider.
書籍では「9つのP」という視点でテスト可能性を確認することが推奨されています。例えば：
- Pipeline: 自動化パイプラインの構築しやすさ
- People: チームのスキルレベル（コーディング vs GUI操作）
- Process: 既存の開発プロセスとの親和性
- その他6つの観点
テスト計画のドキュメント化
This mindset can and should be applied to our test documentation. It is possible to strike a balance between capturing and communicating the right amount of information for a test plan without it becoming oversaturated with detail or too vague.
この書籍では他の部分でも「詳細すぎるテスト計画は不要だが、1ページでテストをどのように考えているか明確に理解できるテスト計画は重要だ」といったメッセージが出てきています。
テストから見えてくる グーグルのソフトウェア開発 などの書籍にも同じような考え方が書かれており、テスト計画には時間をかけすぎずに簡単にまとめつつ、アップデートできるようにしておくことが重要そうですね。どこか別の機会でテスト計画にどのようなことを書いた方がいいか、色々な本をみながらまとめてみたいです。
その他の章で学んだこと
Kindleのハイライトを見返すと、後半の章でも多くの学びがありました：
Chapter 8: Advanced web API automation
ATDDについての記述があり、「The difference between TDD and ATDD is that the expectations of the automated check come from a conversation with the business about what they want an API to do.」という点が印象的でした。
また、「The goal of collaborative conversations is to dispel any miscommunication or misunderstandings before work begins, so our team can deliver the right thing the first time.」という考え方も重要です。
Chapter 9: Contract testing
契約テストについて考え方がまとめられており、この考え方は ISTQB Test Automation Engineer にも同様に紹介されています。
非常にざっくりと私の理解を述べると、「サーバー側と呼び出す側で合意しているAPIの仕様について、インターフェースがその契約に答えられるものになっているかを確認するもの」として理解しています。
例えば、GraphQLを利用しているシステムの場合、クライアント側はGraphQLで定義されたスキーマに基づかないとサーバーにすら到達できないので、契約テストを意識しなくてもある程度担保できていると思います。一方でサーバーサイドとしては、「本当に今の状態がクライアントからの要求に答えられるのか」ということは検査しないとわからないですよね。
そのため契約テストという考え方が重要だと思います。社内の複数のマイクロサービスなどからリクエストされるようなシステムであれば書籍内で紹介されるような Pact といったツールを利用することも検討できると思います。
一方であまり数が多くなくクライアント側のリクエストに使っているインターフェースや型を入手できる場合には、簡単な静的解析の実装で十分かもしれません。私の場合、Graphql Inspectorというツールを利用して、サーバー側の破壊的な変更によるクライアント側の影響を検査したことがあります。
10章から12章は非機能的なパフォーマンスやセキュリティテストに関する内容が中心であり、非常に有益な内容でしたが、趣旨からややずれるのでここでは割愛します。
全体的な感想
本書を読んで、APIテストが単なるエンドポイントの動作確認ではなく、システム全体の品質を向上させるための総合的な活動であることを改めて認識しました。
本書は単なるAPIテストのテクニック集ではなく、テスト戦略全体を考えるための包括的なガイドのようであり、テスト計画にどのようなことを整理し、何を自動化するか/しないかを考え、実装する時のアーキテクチャの注意点などが非常に具体的に書かれています。
SDETとして、技術的な側面だけでなく、チーム全体で品質を作り込んでいくという視点を持つことの大切さを再認識できた一冊でした。
以上、ありがとうございました。
Discussion