2026-10-12訂正：壊れない保証/従来ツールの単一ID比較を修正しました。未確認のWebhook操作手順とpayloadを設計例へ戻し、placeholder画像を外しました。
こんにちは😊
株式会社プロドウガの@YushiYamamotoです！
ITPRODX.comを運営しながら、React.js・Next.js専門のフリーランスエンジニアとしても活動しています❗️
この記事は ノーコードテスト自動化・効率化ツールのTricentisについて、なんでも投稿してみよう！ by Tricentis Advent Calendar 2025 の参加記事です🎄
Webアプリ開発において、E2E（End-to-End）テストは「安心」を買うための重要な投資です。
しかし、UI実装の細部に強く依存したlocatorを使うと、変更時の保守が増えることがあります。
UIの意味と実装詳細のどちらをlocatorにするか です。
- CSSのクラス名が変わっただけで
Element not found💀 - ボタンの位置がズレただけでクリックできない 💀
- テストのメンテナンスに時間を取られ、本末転倒になる 💀
今回は、保守を減らす候補として Smart Locators を備えるツール 「Tricentis Testim」 を紹介します。
さらに、テスト結果を n8n で受け取り、Slack通知へつなぐ未実施の運用案を検討します。この記事の訂正では連携・送信をしていません。
TestimのSmart Locatorsと保証できない範囲
Testim は、AIを活用したSaaS型のテスト自動化プラットフォームです。
最大の特徴は、要素を特定する 「Smart Locators」 という技術です。
Testimの公式説明では、複数属性と要素の関係を使って特定し、過去の実行に基づきlocatorを更新します。ただし任意の変更で壊れない保証ではありません。
Playwrightのlocatorもrole・accessible name・text・test ID等や絞り込みを使え、単一ID/CSSしか使わないわけではありません。class/id変更で確実に失敗するという比較を訂正します。
自己修復で別の要素を操作したり、製品の意図しない変更を見逃したりしないか、locator変化と操作後の業務assertionを確認します。「locatorで見つかった」と「機能が正しい」を分けます。
🏗️ アーキテクチャ：テストから通知まで
今回は、Testimでテストを実行し、その結果（特に失敗時）をn8n経由でSlackに通知する設計案を示します。下のWebhook経路は利用版の連携仕様確認が前提です。
検証案1：UI変更に対するlocatorとassertionを比べる
必要なplan/権限・対象の公開/機密範囲と操作の承認を確認します。Testimのtrial条件/機能は対象契約で確認し、登録・導入は今回実行していません。
1. レコーディング（Record）
「Create New Test」を押し、対象のWebサイト（今回は自社サイト）で操作を行います。
ポチポチとクリックしていくだけで、操作がステップとして記録されます。ここまでは普通のツールと同じです。
2. AIの凄さを体感する（Locators）
記録されたステップのプロパティを見てみましょう。「Locators」タブを開くと、AIがどのように要素を認識しているかが可視化されています。
元の画像URLは説明用placeholderで、実画面/実験の証拠ではないため外しました。画面名・locator確認方法は対象版の公式ドキュメントで確認してください。
検証するなら、同じ画面/操作/業務assertionでclass/id変更、同名ボタン、対象削除、別要素への誤一致を試し、実行log/locator変化/結果を保存します。元記事の「削除しても成功した」という実験は今回記録未確認で、成功した本人実績やPlaywrightとの比較結果として確定しません。
設計案2：確認済みのテスト結果を通知へつなぐ
Testimは素晴らしいですが、テストが落ちた時にメール通知だけでは見逃してしまいます。
そこで、n8n を使ってSlackに通知します。
1. 受信の信頼境界を決める
Webhook方式が利用できる場合に、HTTPS・提供側に対応する認証/署名・payload検証を設計します。runId/eventTypeで再配信を識別し、受信済/通知pending/sent/結果不明を分け、timeout後は送信結果を照合して重複を防ぎます。受信URLを知っているだけで正規eventとは扱いません。未対応ならCI等の確認済み結果経路を検討します。
2. Testim側の連携経路を確認する
元記事の Settings > Integrations > Webhooks / Test run failed という画面・eventは公式仕様を確認できていないため操作手順から取り下げます。利用版で対応する連携/API/CI結果を確認し、実payloadをサニタイズして受信contractに合わせます。以下のschemaがTestimからそのまま届くとは保証しません。
3. n8nで通知を整形する
以下は架空の受信contract例です。実際の公式payloadではありません。runId/eventType/時刻・許可したURLを検証し、必要な項目だけ通知下書きへ渡します。
通知基盤の架空contract例（Testim仕様未確認）
{
"eventType": "TEST_RUN_FAILED",
"projectId": "p_12345",
"runId": "r_67890",
"testName": "お問い合わせフォーム送信テスト",
"executionDate": "2025-12-01T10:00:00.000Z",
"failedStep": {
"description": "Click 'Submit'",
"screenshotUrl": "https://testim.io/screenshots/..."
},
"link": "https://app.testim.io/#/project/..."
}
確認/承認したcontractからn8nのSlack通知を構成する案として、以下のようなメッセージを作成します。
🚨 E2Eテスト失敗アラート
テスト名: お問い合わせフォーム送信テスト
失敗箇所: Click 'Submit'
リンク: 詳細レポートを見るスクリーンショットを確認してください👇
[画像URL]
通知/詳細画面の権限とrun照合で原因調査を支援します。即時検知・原因の確定を保証しません。
💡 応用：AI × AI の相乗効果
さらに発展させて、n8nの途中に OpenAI (ChatGPT) を挟むことも可能です。
- Testimから失敗ログ（テキスト）を受け取る。
- 承認済みのAI処理環境で、credentials/個人情報/顧客log/署名URL・画面情報を除去し、必要最小限の公開/架空データだけ渡し、「このエラーの原因と、修正すべきコードの当たりをつけて」と指示する。
- Slackに「AIによる分析結果」も合わせて通知する。
「TestimのAI」がテストを守り、「生成AI」が修正をサポートする。
AIの原因候補は未確認の推測で、log・再現・testsで照合します。失敗logやスクリーンショットを未承認の外部AIへ送る設計にはしません。
まとめ
- Testim を使えば、locator保守を減らす可能性がある。機能assertion/誤一致と総保守時間を測る。
- Smart Locators の自己修復機能は、locatorの変更と業務結果を人が確認する。
- n8n と連携すれば、確認済みの結果contractと認証/再配信・通知照合を設計できる。
「テスト自動化に挑戦したけど、メンテが辛くて挫折した…」という方にこそ、Tricentis Testimは触ってほしいツールです。
trial/plan条件と対象機能は最新の契約で確認します。効果の保証ではありません。
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。
訂正の確認範囲
公式のSmart Locators説明とPlaywright docsを照合し、schema例のJSON構文を確認しました。実画面・class/id変更実験・Testim→n8n contract/認証・workflow・Slack送信・LLM分析と効果測定は未実施です。