マネージドQA

検証を任せても、記録は残る。

テスト計画レビューから探索的QA、結果分類、再検証、リリースメモまで。IXCの専門家がQoretix上で合意した範囲のQA業務を実施し、結果はお客様のチームと同じワークスペースに残します。

実行証跡と判定はプラットフォームが記録し、判断が必要な業務は専門家が担当します。

2つの利用方法

必要な範囲だけ、任せる。

プラットフォームは同じです。違うのは、誰がどの業務を担うか。

A

お客様のチームで運用

QA責任者とテスターがプロジェクトを準備し、ケースを承認して、実行結果と判定を直接確認します。

チームが担当すること

  • リポジトリ接続、対象URL、テストアカウント登録
  • 文書・コード・画面から作成したケース案を承認
  • push・PRに合わせた自動実行ルールの設定
  • 判定と証跡を見てリリースを決定

こんなチームに自社QA担当者がおり、検証基準を自分たちで定めたいチーム

B

専門家がQoretix上で実施

IXCの専門家が同じワークスペースで合意したQA業務を実施します。レビューコメント、探索結果、再検証記録、リリースメモがプロジェクトに残ります。

専門家が担当すること

  • 導入・検証体制の設定とテスト計画レビュー
  • リリース前の探索的QAとUXレビュー
  • 失敗結果の分類と再検証
  • リリースメモ作成

ケース生成と実行はチームが、リリース前の探索的QAとリリースメモは専門家が担当することもできます。

こんなチームにQA担当者がいないチームや、リリース前の集中検証が必要なチーム

両方を組み合わせることができ、範囲は相談のうえ決定します。

導入の流れ

相談から、最初のリリースメモまで。

初回実行までの設定は通常5分。その前後の人による業務は、次のように進めます。

  1. 範囲のご相談

    対象プロジェクト、リリース周期、任せる業務を決めます。相互NDAの締結後、書面の業務委託契約に範囲を記載します。

    顧客担当者・IXC

  2. 検証体制の設定

    専門家がリポジトリ接続、対象URL、テストアカウント、要件文書の登録を支援し、画面を収集します。自動実行ルールと承認フローもこの段階で設定します。

    専門家・QA責任者

  3. 計画レビューとケース承認

    専門家がプラットフォームの生成した計画とケース案をレビューし、要件にない仮定を取り除き、不足する経路を追加します。

    専門家

  4. 実行と結果分類

    push・PRごとに自動実行し、失敗を専門家が分類します。再現する不具合には重大度を付けてJiraに記録し、再現しない失敗は理由を記載して判定を保留します。

    自動実行・専門家

  5. 探索的QAとUXレビュー

    リリース前に、自動実行が開いていない画面や操作フローを専門家が確認します。レビューノートは画面ごとにプロジェクトへ残します。

    専門家

  6. 再検証とリリースメモ

    修正コミットを再実行して判定を確認し、検証した内容と残る事項をリリースメモにまとめます。リリースの最終決定は顧客担当者が行います。

    専門家・顧客担当者

実行、結果分類、探索的QA、再検証をリリース周期ごとに繰り返します。

専門家の業務

人が担う、8つの業務。

自動実行ではできない判断を専門家が担い、すべての結果をプラットフォームに記録します。

導入・検証体制の設定

チームの状況に合わせて、プロジェクト準備、自動実行ルール、役割、承認フローを設定します。

テスト計画レビュー

計画の根拠と選択ケースを要件と照合し、不足や過剰な範囲を修正します。

探索的QA

ケースにない経路を人が確認し、検出内容を再現手順とともに記録します。

テスト保守

画面やAPIの変更で壊れたケースを修正し、PR提案を承認・却下してテストを最新に保ちます。

結果分類

失敗が不具合、環境問題、不安定な動作のどれに当たるかを判断します。重大度を付け、分類理由をJiraに記録します。

UXレビュー

3つのブラウザエンジンの画面を人の目で確認し、動作は正しくても使いにくい箇所を記録します。

再検証

修正コミットで失敗ケースを再実行し、判定がPASSになったかを確認します。

リリースメモ作成

判定、検証範囲、残存リスク、推奨事項を1枚にまとめ、リリース決定の根拠にします。

記録

専門家の判断も、記録に残す。

チャットやメールに分散させず、プロジェクト内に残します。計画のレビューコメント、探索的QAの結果、分類理由、リリースメモを実行履歴と同じ場所で確認できます。

  • 計画レビューのコメントを計画書のバージョンとともに
  • 探索的QAの検出を画面・再現手順とともに
  • 分類理由を失敗結果とJira課題に紐付けて
  • リリースメモを判定カードの隣に
テストレポート・証跡を見る

よくあるご質問

任せる前に、確認したいこと。

どのようなプロジェクトから始められますか?
ステージングURLとテストアカウントがあり、GitHubリポジトリを接続できるWeb案件が最もスムーズです。サーバー・API案件は画面収集を省略し、API検証から始めます。
専門家はコードやデータにどこまでアクセスしますか?
リポジトリはGitHub Appの権限で読み取り、登録されたステージングURLとテストアカウントでのみ検証を実行します。アクセス範囲と保管期間は相互NDAおよび書面の業務委託契約に記載します。
私たちのチームは何をする必要がありますか?
顧客担当者が要件文書を提供し、ケースの承認とリリース決定を行います。その他は合意した範囲に応じて分担します。
すでにQAチームがあっても利用する意味はありますか?
はい。リリース前の探索的QAだけ、結果分類だけといった形で範囲を絞れます。同じワークスペースで一緒に確認します。
リリース判定は誰が出しますか?
判定はプラットフォームがルールに従って出します。専門家は判定を書き換えず、その上にリリースメモを加えます。リリースの最終決定は顧客担当者が行います。
現在の課題管理ツールや文書はそのまま使えますか?
Jiraを接続すると失敗結果が課題として起票され、結果と紐付きます。要件文書はDOCX・XLSX・PPTX・PDF・画像・Markdownで添付できます。

マネージドQAのお問い合わせ

どの業務から任せるか、一緒に決めましょう。

プロジェクト、リリース周期、チーム構成をお知らせください。必要な検証業務と対応範囲を一緒に決めます。

マネージドQAのお問い合わせ

ご希望の日程と依頼したい業務を簡単にご記入ください。