プラットフォーム

要件からリリース判定まで、ひとつながりに。

テスト計画・ケース生成・API/UI検証・セキュリティ検査・運用監視が、1つのプロジェクト内でつながります。実行後には証拠と、PASS・CONDITIONAL・FAILの判定が残ります。

デモを依頼マネージドQAを相談

リポジトリの接続から最初の実行まで、通常約5分。

機能

8つの機能を、1つのプロジェクトに。

機能は個別に有効化できます。結果は同じプロジェクト、同じ判定カードに集まります。

テスト計画

要件文書と有効なケースから、名前・説明・根拠・計画書・選択したケースを備えた計画を作ります。下書き・有効・保管の状態で管理します。

詳しく見る

テストケース生成

人・文書・コードの3つの作成元から、シナリオ・前提条件・入力値・期待結果を作成します。PR差分からケースの追加・変更・削除を提案します。

詳しく見る

API検証

サーバー/APIは画面収集を省略し、API契約を基準に実行します。応答構造やステータスコードが契約と異なる場合は、失敗として記録します。

詳しく見る

UI検証・専門家によるUXレビュー

Chromium・Firefox・WebKitで同じケースを実行します。自動化で見つけにくい導線の問題は、専門家がUXレビューノートに残します。

詳しく見る

セキュリティ検査・脆弱性管理

コード・シークレットのスキャン、依存関係の警告、サプライチェーン・悪意あるパッケージの発見を判定と同じ画面で確認します。致命的・重大な発見はFAILになります。

詳しく見る

監視・運用課題 プレビュー

運用エラーをコミット単位で受け取り、再現用の検証を作って回帰テストに追加します。デプロイ前の判定と、デプロイ後に起きたことをつなげて確認できます。

詳しく見る

テストレポート・証跡

各実行にHTMLレポート・失敗画面・再現動画・ログが残ります。失敗をJiraの課題として作成し、結果に関連付けられます。

詳しく見る

プロジェクト・顧客ワークスペース

組織別ワークスペースで、自組織のプロジェクトと結果だけを表示します。QA責任者・テスター・顧客の役割で、設定・承認・リリース署名の権限を分けます。

詳しく見る

プロジェクトの流れ

要件から再検証まで、途切れない。

1つのプロジェクトで6つの工程がつながります。前の工程の成果物が、次の工程の材料になります。

  1. プロジェクトの準備

    GitHubを接続し、ステージングURLとテストアカウントを登録します。最大90秒で画面を収集し、機能一覧・要件・ワイヤーフレーム・権限マトリクスを添付します。

    リポジトリ · 対象URL · テストアカウント · 画面収集 · 文書

  2. テスト計画

    文書と有効なケースから計画を作成し、何をなぜ検証するのか、その根拠を残します。

    計画書 · 根拠 · 選択したケース

  3. ケース生成

    画面と文書から下書きを作成し、検証できないものは除外します。優先度と自動化レベルを設定し、韓国語・英語・日本語に翻訳します。

    文書 · コード · 人 · PR提案

  4. API・UI実行

    リポジトリ・ブランチ・変更パスの条件に合わせて、pushやPRで自動実行します。失敗したケースには、スクリーンショット・再現動画・ログが残ります。

    3つのブラウザエンジン · API契約 · 自動実行ルール

  5. セキュリティと運用の問題

    リポジトリのセキュリティ警告とlockfileに基づくサプライチェーンの結果を、同じ実行にまとめます。デプロイ後のエラーを回帰検証に戻す運用監視は、プレビューです。

    依存関係の警告 · サプライチェーン · デプロイ後のエラー

  6. 判定・レポート・再検証

    1つの実行に1つの判定が残ります。修正後に同じケースを再実行し、再検証の結果を前の判定につなげます。

    PASS · CONDITIONAL · FAIL · Jira

再検証は、同じプロジェクトの次の実行です。

リリース判定

リリースできるか、
ひと目で。

実行後の答えは3つです。軽微な失敗・隔離された検証・要件カバレッジ不足はCONDITIONALとし、人の確認が必要な状態を通過と区別します。

  • FAIL — 安定した検証で致命的・重大な失敗、または致命的・重大なセキュリティの発見がある場合
  • CONDITIONAL — 軽微・低影響の失敗、不安定・隔離・判定保留の検証、または要件カバレッジが目標80%未満の場合
  • PASS — 実行したすべての検証が初回で通過した場合
  • 判定カードに通過・失敗・隔離・スキップの件数、セキュリティの発見、検証範囲をまとめます
テストレポート・証跡を見る

プラットフォームと専門家

使うプラットフォームは同じ。
任せる範囲を選べます。

お客様のチームで運用することも、合意した検証業務をIXCの専門家に任せることもできます。専門家が作った計画・ケース・結果の分類は、お客様のワークスペースに残ります。

  • 導入・検証体制の設定とテスト計画レビュー
  • 探索的QA・UXレビュー・失敗の分類・再検証
  • リリースメモ作成
  • 必要な業務だけを任せ、残りはチームで運用
マネージドQAを相談

よくあるご質問

導入前に確認したいこと。

導入には何を準備すればよいですか？
GitHubリポジトリ・ステージングURL・テストアカウントの3つがあれば、最初の実行に進めます。要件はDOCX・XLSX・PPTX・PDF・画像・Markdownで添付でき、文書がなければ画面とコードから始められます。
どの種類のアプリケーションを検証できますか？
準備時にWeb・Android・iOS・macOS・Windows・サーバー/APIを自動判別します。Webは3つのブラウザエンジンでUIを実行し、サーバー/APIは画面収集を省略してAPI検証へ進みます。
既存のCIパイプラインや課題管理ツールはどうなりますか？
既存のパイプラインをそのまま使えます。GitHub Actionsのpush・PRイベントで実行し、失敗を結果にリンクしたJiraの課題にできます。他のリポジトリ・課題管理ツール・PRによるリリースゲートはプレビューです。
プレビュー機能は、どう確認できますか？
運用監視・クラウド点検・メール/チャット/Webhook通知・API仕様の連携・SSOログイン検証はプレビューです。デモでは、現在動作する範囲を実際のプロジェクトで確認できます。
自動化できない業務は、誰が担当しますか？
計画の確認・探索的QA・UXレビュー・失敗の分類・リリースメモは人が担当します。お客様のQA責任者やテスターが行うことも、マネージドQAでIXCの専門家に任せることもできます。
データと結果は、どのように分離されますか？
組織別のワークスペースで、自組織のプロジェクトと結果だけを表示します。リポジトリはGitHub Appの権限で接続します。導入方式とデータの取り扱いは、次のページで確認できます： デプロイ・データの取り扱いで確認できます。

まずは、1つのプロジェクトから。

リポジトリ・ステージングURL・テストアカウントが1つずつあれば、最初の判定を確認できます。デモでプロジェクトの流れをご覧ください。

デモを依頼導入相談

sales@qoretix.com+82-33-242-0210平日 10:00–18:00 KST