AIは間違いを犯します. 人間と同じように. それが私たちの仕事を独立して検証するためのQA業界全体を開発した理由です. このセクターは毎年7%成長し、達成する予定です. 部分的にAI生成出力の検証の必要性によって推進される。 2032年までに1145億ドル 一方、ブラウザ自動化はAIサービス開発の核心領域として現れました。 彼らの最も広く使われている製品です。それで、多くの人の心に明らかなアイデアが浮かび上がる――なぜ、AIによるコーディングの一環としてブラウザ自動化を使用し、コーディングエージェントにリアルタイムのフィードバックを提供しないのか?これはシステム全体をより安定させないだろうか?それでは、今日のAI駆動型QAツールはどれほど有用なのでしょうか?実際には、生産に提供されるソフトウェアの品質と全体的な開発者体験の両方を向上させることができますか? この機能を ChatGPT に追加 アイデア AI を駆動する品質保証サービスから何を期待するか? 最も合理的なアプローチは、実際のユーザーがテストタスクを実行する群衆テストプラットフォームから来ています。 この方法論は、テストケースをより抽象的に表現し、単純なパス/エラー結果を超えてより豊富なフィードバックを提供します。 AI は、現代の QA で最も重要なインフラストラクチャの課題の 1 つに対処することもできます: 保守の禁止的なコスト. テストケースは時代遅れになり、コンポーネントは移転され、CSS 選択器はスケーラブルであることが証明されます. QA メンテナンスは、チームがしばしば放置する別々の負担になります。 さらに、QAエージェントは、AIによるコーディングワークフローのサイドキックであり、開発のヒューマン・エージェント・ループに直接統合され、フィードバックを共有し、行動を起こし、いわゆる主要な役割を果たすことができます。 「アプローチ。 左転換 したがって、包括的なAIは一般的な要件を満たすべきである: 
 
 
 
 
 On-Demand Testing During Development. Developers should be able to complete a feature implementation and immediately request AI-powered testing. 開発中のオンデマンドテスト。 自動テストケース開発. AI は新しい機能のための包括的なテストケースを自動的に生成する必要があります. これらのテストケースは、コードベースの隣にローカルで、またはクラウドレポジトリでリモートで、柔軟なストレージオプションが必要です。 インテリジェントなテスト実行と管理. システムは自動更新でテスト実行と管理を処理する必要があります. 理想的には、コードベースとドキュメントの両方へのアクセスを維持し、要求が進化するにつれてテストケースをダイナミックに更新することができます. ビジネスインテリジェンスを使用した包括的なテストレポート テストレポートは、単純なパス/エラーメトリクスを超えて、複数の次元にわたって実行可能な洞察を提供する必要があります:ビジネスロジック分析、ユーザビリティ評価、パフォーマンスメトリクス。 以下では、すべての要求事項を満たす完全なサービスが存在しないことがわかります。しかし、これらの課題のいくつかは、かなりうまく解決することができます。QAツールは、LLMプロバイダー - 特にOpenAI - と独立したスタートアップ両方によって開発されています。 OpenAI:コンピュータ・ユーザ・エージェント ブラウザ・オートメーションはサム・アルトマンの会社に関係してかなり久しぶりです。6ヶ月前、2025年1月、ブラウザを使ってウェブ上でタスクを解決できるエージェントが発売されました。 そして、GPT-4o - Computer-Using Agent(はい、これはモデル名、CUAを短くする)に基づく専用モデルによって動作します。 チャットインターフェイスを介して管理します。 操作者 ブラウザ農場 同社は引き続きOperatorに投資し、Proサブスクリプションを持つChatGPTユーザーに幅広く利用できるようになっています。 先進的なブラウザ自動化が彼らの新しい製品機能の1つになると推測することができ、ChatGPTはこのテクノロジーの遊び場として使用することができます。 Chromiumベースのブラウザ Operator は具体的に QA ツールではありませんので、チャット UI を通じてその方法で動作させるのは困難になりますが、CUA の上に構築することは可能です。 OpenAIは、オープンソースツールと呼ばれる小さなツールでどのように行うことができるかを示しています。 . APIを通じて利用可能 テストエージェント Essentially Testing Agent は、Playwrightとその上にいくつかの基本的なUIへのアクセスを備えた CUA です。 あなたはエージェントに自然言語のタスクを与え、それをテストしたいいくつかのURLに指し、非常に限られたテストデータで構成し、開始して待つ。それからあなたのタスクに応じてテストプランを作成し、Chromeブラウザをローカルに起動し、スクリーンショットを撮影し、OpenAIのCUAモデルと交換し、LLMが生成するアクションを実行します。 それは単なるデモであるにもかかわらず、それは非常に制限的です: 
 
 
 
 
 
 これは、MCPサーバではなく、非常に基本的なUIで制御されていますので、選択したコードエディターに接続できません。 これは非常に遅いため、主にモデルがスクリーンショットを認識するのを待っているためです。 機械読み出しの出力を提供しない テストに env 変数を渡すことをサポートしません。 それは十分に指示に従わない. それは基本的に1つのケースにサービスするように設計されています 私はOpenAIのツールがQAに使用できるかどうかを疑いますが、その上にかなり洗練されたものが構築されていない場合があります。そして、現時点ではそのようなサービスはありません。これは、迅速な準備とブラウザ相互作用の契約の両方に適用されます - スクリーンショットだけでは、誤解や幻覚を効果的に回避するのに十分ではありません。 ブラウザ利用 ブラウザとLLMの間のより正確かつ制御された相互作用の課題は、 このカリフォルニアのスタートアップは、1700万ドルの種子ラウンドを収集し、 y. 彼らは、スクリーンショットではなく、インデックスされたインタラクティブ要素、開いたタブ、HTML属性、ユーザーパラメータなどを含むテキストベースの文脈に基づいて独自のブラウザ通信プロトコルを開発します。 . ブラウザ利用 たくさんの注目を集めているラテル DIVE IN IT SELF 拡張コンテキストアプローチ自体は、多くの問題を解決します: 
 
 
 
 
 
 
 , it doesn’t even require vision-LLM to operate Browser Use is LLM-agnostic 
 
  than screenshot-based solutions like Operator It’s more stable and performant 
 
  and accurately, as LLM has better understanding of the environment it operates with It can be prompted more specifically 
 
  with   and hooks it’s easy to build on top of it It’s extendable custom functions ブラウザ使用の主なアプリケーションの1つはもちろん、ウェブスクラップです。ターゲットウェブサイトのマークアップが変更されることを心配することなく、一度だけあなたのスクラップコードを書くことを想像してください。 
 
 私たちは今、不安定なツールに近づいており、それらのいくつかをローカルに実行するにはしばらくかかりました。それらはすべて、インターフェイスとしてMCPを使用しているので、利用可能な最高のデバッグツールはMCPインスペクターです。 私たちは今、不安定なツールに近づいており、それらのいくつかをローカルに実行するにはしばらくかかりました。それらはすべて、インターフェイスとしてMCPを使用しているので、利用可能な最高のデバッグツールはMCPインスペクターです。 ヴィンテージ使用 ブラウザの子供用ツールはとても便利です。 ユーザーは非常に限られたパラメータのセットを制御します:テストされているウェブページのURL、同時に実行されているエージェントの数、ヘッドレス/非ヘッドレスモード間の切り替え。 基本的なMCPツール ツールは、ページの主なインタラクティブ要素を識別し、テストエージェントのためのタスクを作成する「スカウトエージェント」を生み出すことから始まります。 次に、Vibetest Useは、エージェントにテストタスクを配布し、テストレポートを収集し、まとめ、ユーザーにフィードバックを提供します。 
 
 
 
 
 ジェミニファミリーのモデルにのみ適応しているため、Google API Key が必要です。 テストプロセスについて非常に制限された制御を提供します。 自動的に生成されたシナリオを拡張することはできません。 悪く保守されています. 実行するには、まず新しいバージョンのブラウザ使用の不互換性の問題を修正する必要があります。 全体として、Vibetest Useは直接的に特に役に立つとは思えないが、さまざまなビジネスプロセス内の特定のタスクに基づいて類似するツールを構築することができる。 ブラウザ使用に基づくもう一つのソリューションは、「MCP経由でウェブアプリケーションをvibeテストできるブラウザエージェント」です。 . 操作 WEB エヴァル・エージェント 名前付けは一般にAIツールの最も強力な部分ではなく、 オペレティブの主な製品は、既存の内部組織APIに基づいてアプリケーションを生成することに焦点を当てたLovableのようなソフトウェアであるが、驚くべきことに、彼らはテストツールを最初に使用し、最終的に主な使用ケースの一部となった。 WEB エヴァル・エージェント Web Eval Agent は、MCP を通じて利用可能であり、ブラウザの使用に加えていくつかの機能を提供します。 まず、Operator のように、テストエージェントと相互作用するための便利な UI が付属します。 次に、テストタスクをオーケストラし、配布します。 しかし、パラレル化は使用しませんので、リクエストごとに 1 つのエージェント / ブラウザで終了します。 ツールはその後、タスクを実行し、スクリーンショット、ネットワークおよびコンソールのログおよびエラーを収集し、最後にテキストレポートですべてをまとめます。アイデアは、あなたがすぐにこれらのエラーをあなたのコード生成エージェントに戻し、ループを閉じることができることです。Vibetest Useとは異なり、Web Eval Agentは、テストエージェントに指示し、テスト結果から結論を出すために使用するプロンプトを提供することができます。 いくつかの欠点もあります - ツールはオペレーティブの内部クレジットのみで動作します. すべてのチャットの完了は1クレジットを消費し、基本的なテストでさえ簡単に20〜30のリクエストを取ることができます。 しかし、主な制限は、機能性において非常に基本的なものであり、追加のQAツールなしでブラウザ使用の上に薄い層を提供するだけです。 Vibetest Useと同様に、このツールは効果的な使用のために重要な調整を必要とする:ベンダーのロックインを排除し、必要なビジネス論理で文脈を豊かにし、出力を公式化し、構造化する。 AI-QAスタートアップ 上記のツールのいずれも、創造者のサイドプロジェクトの一種であり、テクノロジーを展示するための二次的な努力として開発されたため、上記のツールのいずれも実際には箱から抜け出すことはありません。 
 
 
 
 
 
 
 スパイ 瞬間 ドッグ テスト Thunderコード ...and many many many more これらのツールのほとんどは、単純なMCPサーバーをはるかに超えており、BrowserStackやSauceLabsと同様にフル機能のテストプラットフォームです。基本的なテストジェネレーターとは異なり、これらのプラットフォームはテストのライフサイクル全体を処理します:自動テストを生成、ストレージ、および実行します。 
 
 
 
 
 
 
  from prompts and product requirements documents (PRDs) Auto-generation of tests 
 
 , where all logic is described with natural language AI-powered test steps 
 
  that simulate different user behaviors and scenarios Auto-healing tests that adapt and fix themselves when applications change Testing personas 
 
  that adapt and fix themselves when applications change Auto-healing tests 典型的なワークフローは、製品要件のAIによる分析から始まり、プラットフォームのインターフェイスを通じてテストケースを作成し、自動的に生成されるか、ユーザーによって手動で構築されるかに関わらず始まります。 得られたテストは、生成されたコード(TestSpriteのように)またはUIベースのテストステップ(Thunder Code)を通じて抽象化される2つの異なる形式で提供されます。コードベースのアプローチでは、ユーザーはプラットフォームの組み込みコードエディターを通じてテストステップを直接編集します。 これらのプラットフォームの価値は、主にLLMをQAのニーズに適応させることにあります. 彼らはすでに自動テストの開発と維持に費やされた時間を確実に減らすことができます. しかし、彼らの問題も明らかです - ベンダーのロックイン、高コスト、および開発ワークフローとAIアシスタントのコーディングへの統合の困難。 結論 AIによる品質保証ソリューションの明確な需要にもかかわらず、現在のツールは4つの要件を満たすものではありません。OpenAIのテストエージェントはあまりにも基本的で柔軟性がない一方で、Vibetest Us and Web Eval Agent built on Browser Useのようなオープンソースのツールは、生産ワークフローに必要な安定性と制御を欠いている。 Browser Useのテキストベースのプロトコルはうまく機能し、特定の要件を満たすためにこれらのツールの上にカスタムソリューションを構築することはすでに可能である。

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

Vibe-Codingの欠けている部分はVibe-Testingです

About Author

コメント

ラベル

この記事は

Related Stories

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Telegram: クリプト島と本土を結ぶ橋

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Telegram: クリプト島と本土を結ぶ橋

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

デジタルノマドの皆さん、タイの新しい DTV ビザについて知っておくべきこと

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps