testRigor Software Testing

testRigor Software Testing

testRigor, Inc. · コーディング

testRigorは、平易な英語の指示をWeb・モバイル・デスクトップ・API向けのE2Eテストに変換するAIテスト自動化プラットフォームであり、要素認識は自己修復型で動作する。

testRigor Software Testing の画面プレビュー

testRigor Software Testing について

About

testRigorとは

testRigorはクラウド型のテスト自動化プラットフォームだ。根底にある考え方はひとつ、テストは同僚に渡す指示文のように読めるべきだというもの。例えば「ログインして商品を検索し、カートに入れて購入まで進む」と書けば、AIがその文の裏にあるクリック、入力、待機を組み立てる。ページオブジェクトもXPathもCSSセレクタも要らない。

狙いは自動化プロジェクトの大半を潰すメンテナンス問題にある。従来のフレームワークはテストを実装の詳細に結びつけるため、ボタン名の変更やページの再構成で、利用者から見れば正常なのにスイートが落ちる。testRigorは人が画面で見るもの、つまり表示テキスト、入力欄、ボタンのラベルを見て、変更後も正しい要素を探し直す。ベンダーはセレクタ依存のフレームワークに比べてメンテナンス時間が約200分の1になると説明する。これは提供元の数字であり、独立した検証ではない。

向くのは受け入れレベルの業務フロー回帰テストだ。会員登録、決済、申し込み、初回設定などが該当する。ゲーム、リアルタイムグラフ、動画品質の確認には向かない。コマンドは英語で書くため、対象アプリが日本語でもチームには一定の英語力が要る。

はじめかた

  1. testRigorのサイトでアカウントを作る。14日間のトライアルではUbuntu、Windows、Mac、Android、iOS、WindowsネイティブアプリをAI機能込みで試せる。
  2. テストスイートを作り、実行先を選ぶ。ブラウザ、モバイル端末ファーム、デスクトップアプリ、APIエンドポイントのいずれかだ。
  3. 最初のテストを平易な英語で書くか、Chrome拡張を入れて手動操作を録画する。
  4. テストを実行し、ステップごとのレポートを見て、AIが取り違えた箇所の言い回しを直す。
  5. 用意されたスクリプトかAPIでJenkins、CircleCI、GitHub ActionsなどのCIに接続し、ビルドごとに流す。

AIツール情報

testRigor Software Testingの料金、対応プラットフォーム、性能を簡単に確認できます。

無料プランいいえ
有料プランCustom quote based on AI agents; 14-day trial
プラットフォームWeb, iOS, Android, Windows, macOS, Linux
開発元testRigor, Inc.
カテゴリコーディング
リリース日Jan 2015
最終更新Oct 2026
サイト訪問数122.3K
サイト世界ランキング343.7K
API提供状況はい

こんな人におすすめ

このツールが最も力を発揮するユーザー、タスク、シーン。

ユーザー

  • 手動QAテスター:プログラミングを学ばずに既存のテストケースを実行可能な検査に変えられる。自動化エンジニアのいないチームがカバレッジを確保する最短ルートだ。
  • プロダクトマネージャーやビジネスアナリスト:開発が終わる前に受け入れ条件を英語で書けるため、仕様書とテストが同じ文書になる。
  • 成長中のSaaS企業のQAリード:ユーザー数もテストケース数も無制限なので、専門家ひとりに集めずチーム全体でテストを書ける。
  • 自動化担当のいない小規模チーム:QA2人でもSDETを雇わずにWebとモバイルのフローをカバーできる。

タスク

  • 主要業務フローの回帰テスト:決済、会員登録、パスワード再設定、アカウント変更をビルドごとに再確認する。セレクタの修正は不要だ。
  • 手動テスト資産の移行:ブラウザ拡張が操作中のクリックを記録し、実行できる英語スクリプトを生成する。あとは文言を調整するだけ。
  • クロスプラットフォームのスモークテスト:同じテストをChrome、Safari、iPhone、Androidエミュレータに向けられるため、似たスイートの重複が減る。
  • 複数ユーザー・複数チャネルの導線:メールで同僚を招待し、SMSでコードを確認し、電話認証を挟み、最後にデータベースで結果を確かめる。

シーン

  • UIの更新が頻繁なアプリ:自己修復型テストはレイアウト変更や要素の改名に耐える。週次リリースが丸一週間のテスト修正に変わらない。
  • 規制やセキュリティ要件の厳しい配備:SOC 2 Type II準拠とオンプレミス選択肢があり、テスト通信を共有クラウドに出せないチームでも使える。
  • ツールを一本化したい組織:Jira、TestRail、Zephyr、CIとの連携により、結果は既存の報告先ツールの中に残る。

主な機能

平易な英語でテストを書く

各ステップは普通の英語の一文だ。「click 'Add to cart'」や「check that the page contains 'Order confirmed'」のように書く。プラットフォームが指示を解釈し、一致する要素を判断して実行する。これは英語記述テストであり、文字どおりのノーコードテストでもある、技術背景のない人でも読み、見直し、修正できる。自動化コードを触れるのがエンジニア1人だけというボトルネックも消える。

自己修復型の要素認識

testRigorはXPath式もCSSセレクタも保存しない。人が行うように、表示テキスト、ラベル、入力欄の種類、ページ上の位置から要素を特定し、実行のたびに解決し直す。開発者がIDを変えたり、ボタンを新しいコンテナで包んだりしてもテストは動き続ける。代償として、曖昧なラベルはAIを迷わせるため、ステップの言い回しが重要になる。

生成AIによるテスト作成

短い説明からテストを起草し、本番環境の分析で見えたフローに対してカバレッジ案を出す。新機能を指定してスクリプト案を受け取ることもできる。新しいスイートを作るときの「白紙問題」を短縮する仕組みだ。ただし生成されたステップは人の確認が要る。テストは検証した内容しか保証しない。

Web・モバイル・デスクトップ・APIを1つのスイートで

同じ英語構文が、ブラウザ、iOSとAndroidのネイティブアプリ、iframeやshadow DOMを含むハイブリッドアプリ、Windowsデスクトップアプリ、RESTエンドポイントで動く。決済テストをWebセッションから確認メール、データベース照会まで1本のスクリプトでつなげられる。複数ツールを統合するチームは、この広さを乗り換えの理由に挙げることが多い。

複数ユーザー・複数チャネルのフロー

実際の業務は複数の人と複数の経路にまたがる。testRigorはテストの一部としてメール、SMS、インスタントメッセージを送受信し、電話を発信・受信し、データベースを照会できる。招待、二要素ログイン、サポートへの引き継ぎを、単体チェックと手作業に分解せず通しで検証できる。

CI/CDとテスト管理の連携

Jenkins、CircleCIなどのパイプライン向けに既製スクリプトがあり、テストが失敗すればビルドも失敗する。ネイティブ連携は結果と不具合をJira、TestRail、Zephyrへ送る。TestRailは双方向で、TestRail内に実行可能な仕様を書ける。REST APIは独自レポートと定期実行を担う。

メリットとデメリット

メリット

  • 手動テスターが数日で戦力になる。平易な英語のテストがプログラミングの壁を取り払い、多くのQAチームが低いカバレッジで止まる原因を消す。
  • メンテナンスが大きく減る。自己修復型テストはセレクタの変動を無視する。E2Eテスト最大の隠れコストがここだ。
  • 1つのプラットフォームでWeb、ネイティブモバイル、デスクトップ、APIをカバーできるため、機能の重なるツールを整理できる。
  • 課金は並列実行するAIエージェント単位で、席数でも実行回数でもない。ユーザーも実行も無制限だ。
  • SOC 2 Type II準拠、オンプレミス配備、Slackサポートが、大企業の購買要件に合う。

デメリット

  • 公開価格表がない。どのプランも商談から始まるため、今日カードで買いたい小規模チームには不利だ。
  • 費用は並列エージェント数に連動する。大きなスイートで最速のフィードバックを得る構成が、同時に最も高くつく。
  • ゲーム、ライブダッシュボード、動画再生には向かず、製品のその部分は別のテスト手法が必要になる。
  • テストもコマンドも英語で書くため、別の言語を主に使うチームには摩擦が残る。

よくある質問

利用者が通るフローのE2E回帰テストを自動化する。QAチームはリリースごとに、会員登録、決済、初回設定、アカウント変更がWeb、モバイル、デスクトップ、APIで正常に動くかを確認する。