APIテストサービスがうまく担える部分
網羅性。 エンドポイントを洗い出し、機械的なケースを埋めていく作業です。これは他者に任せられますし、その成果物は持ち出しが利きます。
初期セットアップ。 テストハーネスと環境を立ち上げ、パイプラインに組み込む作業です。終わりのはっきりした一度きりの仕事であり、まさに外部委託が得意とする類のものです。
積み残しの解消。 未テストのエンドポイントが一覧としてわかっているなら、それは定義の明確な仕事です。
担えない部分
何を正しいとするかの判断
仕様書ではなく、自社のプロダクトに関する意思決定の中にあります。
外部チームが書くアサーションは、一見もっともらしくても、ルールではなく思い込みを写し取ったものになります。
保守
スイートはAPIとともに古くなっていきますが、契約はいずれ終わります。
外注したスイートの多くは、ここで静かに息絶えます。
トリアージの判断
今日どの失敗が重要なのかを見極めるには、どの文書にも書かれていない文脈が必要です。
契約前に確認すべき問い
7か月目にこれを保守するのは誰か。答えが「引き継ぎ後は自社で」であれば、引き継ぎが何を指すのかを具体的に詰めてください。自社のチームは、ベンダーなしでテストを読み、書き換え、実行できるのか。社内の誰も知らないフレームワークで書かれたスイートなら、それは保守できない資産を買ったということです。
成果の出る契約の組み立て方
セットアップと網羅性は買い、正しさは手元に残します。 何が真であるべきかは自社チームが定義し、ベンダーは表面を広くカバーします。
自社チームが保守できるスタックを譲らずに求めます。 最も持ち出しの利くスイートとは、自社のエンジニアが初日から読めるスイートです。
ベンダーのパイプラインではなく、自社のパイプラインで動くことを要件にします。 契約期間中しか動かないスイートは、契約が終われば存在しなくなります。
引き継ぎは実演として定義します。 最終支払いの前に、自社のメンバーが誰の助けも借りずにテストを1件追加し、壊れたテストを1件修正します。
最も重要な条項
実際に外部委託するのであれば、1年後にも価値が残っているかを決めるのは一つの条項です。そしてそれは、交渉で最も力が入る条項であることはめったにありません。
価格でもスコープでもありません。重要なのは、引き継ぎの時点ではなく最初の週から、スイートが自社のインフラで、自社の環境に対して、自社が管理する認証情報を使って動くことです。ベンダーのマシンでしか動いたことのないスイートは、実際に生きていくことになる条件で試された経験が一度もなく、引き継ぎの段になって3か月分の積み上がった思い込みが見つかることになります。
譲らずに求めたい二つ目の条項は、納品されるたびに各バッチをレビューする担当者を自社側に指名することです。門番役を置くためではなく、最後の時点で全体に目を通した人間が社内に一人いる状態を作るためです。この役割にかかるのは週に数時間で、それが資産を引き継ぐのか、フォルダを引き継ぐだけなのかを分けます。
見積もる価値のある選択肢
外部委託が網羅性として提供するものの多くは、今では仕様や一度のディスカバリから生成できます。それによって計算が変わります。高くつくのは判断の部分になり、そこはそもそもうまく引き継げなかった部分です。四半期分のコンサルティングを決める前に、両方のやり方で見積もってみる価値があります。
APIテストスイートが最初の1年を生き延びられるかは、4つの要素で決まります。期限切れになるセッション、実行時にしか存在しない値、互いに依存する呼び出し、そして誰も片付けないレコードです。TestSpriteはこれらをAuto-Authentication、Dynamic Variables、Dependency Chains、Auto-Cleanupとして扱います。その内容を説明しているのが APIテストのドキュメントです。
ターミナル
npm install -g @testsprite/testsprite-cli
testsprite setup
ローカルに何もインストールしたくない場合は、同じセットアップをTestSpriteのダッシュボードからも利用できます。CLIのそれ以外の機能がまとまっているのが CLIリポジトリです。
ダッシュボードからリポジトリを接続すれば、すでに作成しているデプロイを起点に実行が始まります。あるいは、自分のワークフローにステップを追加する方法もあります。
生成されたカバレッジが判断を変える点
外部委託が主に売っている網羅性は、今では生成できます。API Discoveryがエンドポイントを洗い出し、テスト計画は機能、スキーマ、認可、エラー処理、境界値の各カテゴリをカバーし、それを普通の言葉で調整できます。Auto-Authenticationは実行を通じてセッションを維持し、Dynamic Variablesは呼び出し間で値を引き渡し、Dependency Chainsは各ケースが必要とするものと生成するものから実行順序を導き、Auto-Cleanupはその実行が作成したものだけを削除します。
これは選択肢をなくすというより、計算を変えるものです。ベンダーだけが持ち込めるのは人手と外からの視点であり、持ち込めないのは自社プロダクトにとって何が正しいかという理解です。見積もりの中で高くついている部分が網羅性なら、四半期を投じる前に両方のやり方で見積もる価値があります。
そして実際に委託する場合も、カバレッジは自社のプロジェクトに置かれ、自社のパイプラインで動き、最初の週から自社チームが読める状態にあります。1年後にも資産が残っているかは、この条件で決まります。
APIテストサービスに費用をかける価値はありますか。
セットアップと積み残しの解消については、多くの場合あります。継続的な正しさの担保と保守については、ほとんどありません。どちらも、ベンダーが持っていない文脈に依存するからです。
社内に残すべきものは何ですか。
何を正しいとするかの決定、トリアージ、そしてスイートを変更できる力です。カバレッジを長持ちさせるのは、この3つです。
ベンダーロックインはどう避けますか。
自社チームがすでに知っているスタックと、自社が管理するパイプラインを要件にしてください。テストがベンダーのインフラでしか動かないなら、それはカバレッジを借りているだけです。
良い引き継ぎとはどのようなものですか。
自社のエンジニアが、助けを借りずにテストを1件追加し、失敗しているテストを1件修正できることです。それができないなら、引き継ぎは行われていません。
生成は外部委託の代わりになりますか。
網羅性の大部分は代替できます。ただし、何を正しいとするかを決める人の代わりにはなりません。そこは、どちらを選んでも自社チームが関わり続ける部分です。