自律型ソフトウェアテストの4つのレベル

  • 1. テスト作成の支援。 何をテストするかを人が指定し、コードはツールが書きます。時間は確かに短縮されます。それでも、決めるのはすべて人です。

  • 2. カバレッジの生成。 仕様書や稼働中のアプリケーションから、何をテストすべきかをツールが提案します。人はその計画をレビューします。大半の製品が実際に到達しているのはこの段階です。

  • 3. 自己保守。 製品が変化してもカバレッジが追従し、人手による修復を必要としません。そのためには、意図した変更とリグレッションを区別できることが前提になります。

4つ目は クローズドループです。失敗を検知し、証拠をコーディングエージェントに渡し、その修正を検証します。これは現在、限定的な形で存在します。対象は再現手順が明確な挙動上の不具合に限られ、製品としての判断を要するものには及びません。

各レベルがあなたに求めるもの

  • レベル1: 何をテストすべきかを知っていること。判断はすべて人の手に残ります。

  • レベル2: 計画をレビューすること。自分で書くより速く、それでも手間はゼロではありません。ここを飛ばすと、誰も中身を理解していないカバレッジができあがります。

  • レベル3: 何を意図した変更とみなすかを決めること。あるフローが意図的に作り直されたことを、ツールは知りようがありません。

  • レベル4: 人が関与しなくても修正を検証できる程度に、正しさを厳密に定義すること。

注目すべきは、段を上がっても人間の仕事がなくなるわけではないという点です。仕事はより上の層へ移っていきます。入力することから、決めることへ。それはより価値が高いと同時に、人に委ねるのが難しい仕事でもあります。

誰も売り文句にしない天井

どのレベルであっても、何が正しいのかを決める必要はなくなりません。ツールは、あるエンドポイントが存在すること、あるフィールドが文字列であることを導き出せます。しかし、2つの割引を併用すべきでないことは導き出せません。それは、誰かが下した判断の中にあるビジネスルールだからです。

そうでないかのように示唆する製品は、レベル2を説明しながら、それをレベル4と呼んでいるだけです。

製品をはしごのどこに位置づけるかを見極める質問

ベンダーは、自社が説明しきれる範囲で最も高い段を名乗ります。だからこそ、その位置を正確に特定する質問を用意しておく価値があります。

何をテストするかを誰が決めるのか。答えが「自分たちが決める」であれば、テストがどのように書かれていようと、それはレベル1です。

インターフェースは変わったが挙動は変わっていないとき、何が起きるのか。人がテストを直すならレベル2です。テストがそのまま生き残るならレベル3です。生き残ったうえで、挙動が実際に変わったときにはきちんと失敗するなら、正しく実装されたレベル3であり、これはさらに稀です。

そして、失敗した後に何が起きるのか。出力が人の見るダッシュボードに届いて終わりなら、そこが到達点です。レベル4とは、その出力を問題を修正する側がそのまま利用でき、人が何も仲介することなく修正が検証されることを意味します。この3つを順に尋ねれば5分で済み、どんな機能一覧よりもはるかに正直な位置づけが得られます。

始め方

ターミナル

npm install -g @testsprite/testsprite-cli
testsprite setup

何もインストールしたくない場合は、ダッシュボードでも同じことができます。コマンドラインで実行できるその他のすべては、次の場所にまとまっています: CLI リポジトリ。

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

TestSprite ははしごのどこに位置するか

全体としてはレベル2、挙動の変化についてはレベル3、そして限定的な形でのレベル4です。失敗はコーディングエージェントがそのまま扱える形で返り、その修正は、修正を生み出した推論ではなく、同じチェックによって検証されます。

具体的には、カバレッジは製品そのものから生成され、平易な言葉で調整できます。ステップは意図として表現されるため、見た目だけの変更では壊れません。そして検証のスキルは、すでに使っているコーディングエージェントに組み込まれるため、ループは作業している場所でそのまま回ります。

人の側に残るのは、前述の天井です。つまり、曖昧なルールについて何が正しいのかを決めることです。それより下はすべて動かせます。その結果、カバレッジが「人がどれだけテストを書けるか」に縛られなくなります。

現時点で現実的なレベルはどれですか?

レベル2です。挙動の変化についてはレベル3、再現手順が明確な不具合については限定的な形でレベル4までです。

自律化は人員が減ることを意味しますか?

意味するのは、仕事の中身が変わることです。機械的な半分は縮み、判断を伴う半分が仕事そのものになります。

単にノイズを生成しているだけではないと、どう確かめられますか?

計画を読み、重要でないものを削り、テストの本数ではなく流出した不具合を測ってください。

レベル3では何が壊れますか?

意図した変更です。作り直されたフローは、誰かがそう伝えない限り、リグレッションと見分けがつきません。

クローズドループは安全ですか?

再現手順が明確な挙動上の不具合で、かつ失敗しうることを確認済みのチェックがあるなら、安全です。それを超える範囲では、楽観的すぎます。

要点

スイッチではなく、はしごです。

自律型ソフトウェアテストは、テスト作成の支援からクローズドループまでの幅を持ち、大半の製品はカバレッジの生成にとどまっています。人間の仕事はなくなるのではなく、はしごの上へ移っていきます。そしてどのレベルでも、何が正しいのかを決める必要はなくなりません。