APIテスターの仕事を構成する二つの側面
機械的な作業
エンドポイントの洗い出し、正常系の作成、レスポンス構造の確認。
セッション、フィクスチャ、クリーンアップの保守。
テストスイートの再実行と、毎回同じ不安定なテストの切り分け。
判断を伴う作業
仕様に記載がない場合に、何をもって正しいとするかを決めること。
誰かに悪用されうるビジネスロジックを見つけ出すこと。
どの失敗が重要で、どれがノイズなのかを見分けること。
自動生成は一つ目の列をうまく引き受けられますが、二つ目には手が出せません。二つ目は、プロトコルではなくプロダクトに関する話だからです。
価値が高まるもの
曖昧なケースにおける正しさを定義すること。 割引とプロモーションが同時に適用されたとき、どう振る舞うべきか。仕様書はそれを語らず、生成ツールにも推測できません。
攻撃者の視点で考えること。 数量をマイナスにして注文できないか、このリクエストを再送できないか、識別子を書き換えて他人のアカウントにアクセスできないか。生成されたカバレッジには認可のチェックも含まれますが、あなたがまだ思いついていない悪用の手口までは生み出してくれません。
生成されたカバレッジをレビューすること。 100個のエンドポイントにまたがるテスト計画には、ノイズを削り、プロダクト固有のルールを加える人が必要です。これは短時間で効果の大きい作業であり、まさにAPIテスターが持つ知識を必要とします。
手作業でやるのをやめるべきこと
200個目のCRUDテストを書くこと。トークンのリフレッシュを保守すること。依存関係のグラフに合わせてフィクスチャを組むこと。同じ不安定なテストスイートを再実行し、切り分けること。どれもAPIテスターを価値ある存在にしている知識を使うものではありませんが、時間が消えていくのはすべてこの部分です。
APIテストスイートが最初の1年を乗り切れるかどうかは、四つの要素で決まります。期限切れになるセッション、実行時にしか存在しない値、互いに依存し合う呼び出し、そして誰も片付けないレコードです。TestSpriteはこれらをAuto-Authentication、Dynamic Variables、Dependency Chains、Auto-Cleanupとして扱います。詳細は APIテストのドキュメント。
最も置き換えが難しいスキル
何を極めるべきか迷っているなら、その答えはツールではありません。曖昧な要件を前にして、それが解釈されうる三通りの読み方を言葉にできる力です。
たとえば「ユーザーは自分の注文しか閲覧できない」というルールを考えてみます。この仕事をある程度続けてきたテスターなら、すぐにこう問いかけます。管理者の場合はどうなるのか、誰かの代理で行われた注文はどうか、他者に移管された注文はどうか、アカウントが無効化された後はどうなるのか、削除された注文は見えないだけなのか、それとも存在しないのか。いずれも要件には書かれていません。そして、いずれも本番環境で必ず起こります。
このリストを生成ツールが作り出すことはありません。仕様から導かれるものではなく、プロダクトが壊れる場面を見てきた経験から導かれるものだからです。機械的な側のコストが下がるほど価値が高まるのは、まさにこの部分です。
現実的な一手
自動生成を自社のサービスに向け、コードではなくテスト計画に時間を使います。管理用のルートを削り、誰も文書化していないプロダクト固有のルールを加え、ドメインを知っているからこそ思いつく異常系を足していきます。手書きで1週間かけるよりも1日で広い範囲をカバーでき、しかもそのカバレッジには、仕様書ではなくあなたの知識が反映されます。
ターミナル
npm install -g @testsprite/testsprite-cli
testsprite setup
ローカルに何もインストールしたくない場合は、TestSpriteのダッシュボードから同じ設定を行えます。CLIのその他のコマンドについては CLIリポジトリ。
重要なのは仕組みよりもトリガーです。デプロイのイベントに紐づけておけば、誰かがそう判断しなくてもすべての変更がチェックされます。ダッシュボードから設定するなら GitHub App が、ワークフローの内側で実行するなら GitHub Actions のステップが、その役割を担います。
TestSpriteが判断をあなたに委ねる領域
TestSpriteが引き受けるのは機械的な側の列です。API Discoveryがサービスの公開している内容を洗い出し、機能、スキーマ、認可、エラー処理、境界値の各カテゴリにわたってテスト計画が生成されます。実行中はAuto-Authenticationがセッションを維持し、Dynamic Variablesが呼び出し間で値を受け渡し、Dependency Chainsが各ケースの必要とするものと生成するものから実行順序を導き出し、Auto-Cleanupがその実行で作成されたものだけを削除します。
一方で意図的に行わないのが、何をもって正しいとするかの判断です。生成されたテスト計画はあくまで出発点であり、それを削り、直し、広げるのはあなたです。その編集作業を通じて、プロダクトに関するあなたの知識がテストスイートに入り込みます。計画に1時間かければ手書きで1週間かけるよりも広くカバーでき、そのカバレッジには仕様書ではなくあなたの判断が反映されます。
役割の面での実際的な帰結はこうです。200個目のCRUDテストを書くのをやめ、その時間を曖昧なルールや悪用のシナリオに充てるようになります。それこそが、もともとあなたが必要とされてきた理由である仕事です。
自動化はAPIテスターに取って代わるのでしょうか？
取って代わられるのは機械的な側だけです。何をもって正しいとするかを決めることと、攻撃者の視点で考えることはなくなりませんし、どちらも担える人はますます希少になっています。
何を学ぶべきでしょうか？
プロダクトのドメインを、深く学ぶことです。ツールは移り変わりますが、自分のシステムがユーザーに何を約束しているのかを知っていることこそが、テスターを置き換えにくい存在にします。
手動のAPIテストにはまだ意味がありますか？
新しいAPIや変更されたAPIに対する探索的なテストであれば、意味があります。手作業で繰り返す回帰テストには意味がなく、そもそも最初からありませんでした。
生成されたカバレッジを効率よくレビューするには、どうすればよいですか？
コードではなく計画を読むことです。ノイズを削り、足りないものを加え、間違ったときの代償が大きいエンドポイントに注意を集中させます。
チームにテスターが一人もいない場合はどうなりますか？
その場合、判断を伴う側の作業は開発者が暗黙のうちに担っているか、まったく行われていないかのどちらかです。最終的に誰が担うにせよ、その作業を名指しして可視化することが第一歩です。