テスト自動化フレームワークの構築：誰も見積もらない部分

テスト自動化フレームワークが実際に抱えるもの

さらに、実際に読まれるレポート、環境設定、リトライ方針、そして不安定なテストを見失わずに隔離する手段も必要です。テストそのものは、たいてい最も小さな部分です。

見えないコスト

これらの部品はすべて、フレームワークを立ち上げた本人によって、その人だけが完全に理解できるスタイルで作られます。その人が去ると、フレームワークはチームが変更を恐れる存在になります。そして、変更を恐れられるスイートは、修復されずに隔離されていきます。

自前で作るべき場合

• 特殊な要件。 既製のツールでは扱えないプロトコル、プラットフォーム、あるいはコンプライアンス上の制約がある場合。

• テストが製品の中核です。 信頼性を売りにしているのであれば、テスト基盤を自社で持つことには戦略的な意味があり得ます。

• 継続的に人を割ける体制があります。 1四半期だけの人員ではありません。何年も担当し続けるオーナーです。

そうでない場合

正直な動機が、チームがツールづくりを楽しんでいることや、製品の評価が決め手を欠いたままだったことにあるなら、そのフレームワークは作られたあと、ゆっくりと放置されていきます。これはよくあるケースであり、最初のコミットの前に口に出しておく価値があります。

フレームワークが製品になってしまった兆候

この移行は少しずつ進み、誰も宣言してくれないため、具体的な兆候をいくつか持っておくと役に立ちます。

誰かにテストの追加方法を尋ねられ、その説明に2分以上かかります。新しいメンバーは、土台にあるフィクスチャを理解しないまま、既存のテストをコピーして値を書き換えることで最初のテストを書きます。テストが失敗すると、フレームワーク側が変わったのではないかという疑問が浮かびます。誰も触りたがらないファイルがあります。フレームワークの作業が、スプリントプランニングに独立した項目として定期的に登場します。

このうち2つでも当てはまれば、社内の1チームだけを顧客とする製品を抱えていることになります。それが直ちに間違いというわけではなく、多くの組織が意図してその選択をしています。問題になるのは、誰も選んだつもりがないままそうなっていた場合だけであり、たいていはそちらです。

中間の道

意図して仕様化したケースには手書きのテストを残し、網羅の幅は生成されたカバレッジに任せます。セッション、データ、実行順序、クリーンアップの問題は、自社のインフラとしてではなく、製品の一部として解決された状態で使えます。

ローカルに何もインストールしたくない場合は、TestSprite のダッシュボードから同じセットアップを利用できます。CLI で使えるその他の機能は、こちらにまとまっています： CLI リポジトリ。

パイプラインが別のチームのものである場合、最も抵抗の少ない経路は GitHub App です。これは webhook であり、リポジトリには何の変更も加えず、ビルドが新しいバージョンの公開を報告した時点で実行されます。代わりにリポジトリ上でチェックを見せたい場合は、 GitHub Actions のステップで同じことができます。

自前で作る代わりに手に入るもの

自社のインフラになるはずだった部分が、製品として提供されます。Auto-Authentication は実行中もセッションを維持し、Dynamic Variables は呼び出し間で値を受け渡し、Dependency Chains は実行順序を導き出し、Auto-Cleanup はその実行で作成されたものだけを削除します。レポーティング、環境設定、リトライの挙動もあわせて備わっているため、どれも誰も触りたがらないファイルにはなりません。

カバレッジは製品そのものから生成され、平易な言葉で調整できます。これにより、もう半分のコスト、つまりすべてのテストを、時間の取り合いになっている人が書かなければならないという部分がなくなります。

価値の本質は、自前で作ることが間違いだという点にはありません。多くのチームは作ると決めた覚えもないまま、9か月目になって、社内に顧客が1つしかない製品を抱えていることに気づく、という点にあります。意図して仕様化したテストは手元に残し、テスト基盤は他社の問題として任せる。それが、見積もりに入れていなかったオーナーを抱え込まずに済むやり方です。