ノーコードテスト：解決したことと、場所を移しただけのこと

ノーコードテストが本当に解決したこと

• テスト作成の間口。 フレームワークを知らなくても、プロダクトを理解している人ならテストを作れます。これは事実であり、大きな意味があります。

• エンジニア以外にも読めること。 ビジュアルフローはプロダクトマネージャーにも中身が読み取れますが、コードファイルはそうはいきません。

• 最初のテストまでが速いこと。 最初に動くチェックができるまでの時間は大幅に短縮されました。

取り除かれたのではなく、移されたもの

いずれも致命的ではありません。ただ、約束が中途半端に感じられた原因はここにあり、多くのノーコードのテストスイートが最初の四半期を過ぎたあたりで成長を止めてしまう理由もここにあります。

前提にあるもの

ノーコードのプラットフォームは、テストフローを作ることを仕事にしている人がいることを前提にしています。その役割が存在する組織では、うまく機能します。存在しない場合、プラットフォームは遊休状態になります。開発者はたいていビジュアルエディタを使いませんし、ほかに担い手がいないからです。

この前提が崩れることが、ノーコードのテストスイートが成長しなくなる最も一般的な理由であり、これは技術的な問題ではなく組織的な問題です。

引き継ぎの問題

このカテゴリ特有の失敗があり、あらかじめ手を打っておく価値があります。徐々にではなく、ある日突然訪れるからです。

ビジュアルフローは一人で作られ、誰にでも読めます。一見すると、バス係数の問題とは正反対に思えます。しかし、読めることと保守できることは別です。30のステップと条件分岐、共有変数を持つフローはコードと同じくらい込み入っており、各ステップがなぜそこにあるのかという理解は作った本人が抱えたままで、エディタ上には現れません。

その人が去っても、何かが変わるまではフローは動き続けます。そして変化が起きた瞬間、どのステップが本質的だったのかを誰も判断できなくなります。コードには少なくとも、コメントとコミット履歴が残ります。対策は、それぞれのフローに「何を守るためのものか」を説明する短い記述を必ず添えさせることです。作成者がいる間は冗長に感じられますが、その人がいなくなったあとに残るのはそれだけです。

新しい世代が変えること

確認したい内容を自然な言葉で記述し、その構築と保守をエージェントに任せれば、間口の広さを保ったまま、作成の工程そのものをなくせます。意図として表現されたステップは、記録されたフローを壊すようなデザイン刷新にも耐えます。メンテナンスの手間の大半は、まさにそこに費やされていました。

引き換えに、自分で作ったわけではないカバレッジをレビューすることになります。これは、作ることとは別のスキルです。

ここまでの話にターミナルは必要ありません。TestSprite のダッシュボードでプロジェクトを作成し、確認したい内容を自然な言葉で記述して、対象のアプリを指定するだけです。コマンドラインのほうが好みであれば、チームの開発者は同じことをそこから実行できます。それを収めているのが CLI リポジトリ。

ダッシュボードからリポジトリを接続すれば、すでに行っているデプロイをきっかけにテストが実行されます。代わりに、自分たちのワークフローにステップを追加することもできます。

チェックを言葉で記述することが変えるもの

作成の工程は、ビジュアルになるのではなく、なくなります。何が成り立っているべきかを自然な言葉で伝えれば、TestSprite がその確認方法を組み立てます。カバレッジが、エディタの前に座ってフローを組み立てる誰かに依存しなくなります。

ノーコードが取り除かずに場所を移しただけだったメンテナンスの負担も減ります。ステップが、記録された操作経路ではなく意図として保存されるからです。ボタンの位置が変わるようなデザイン刷新があってもチェックは壊れません。これは、前の世代で最も繰り返し発生していたコストでした。

代わりに求められるのは、自分で作ったわけではないカバレッジをレビューすることです。これは作ることとは別のスキルであり、必要な時間もはるかに少なくて済みます。どちらのアプローチを採用するにしても、この引き換え関係は理解しておく価値があります。