# テスト テスト状況を確認する画面です（サイドバーの「テスト・フィードバック」）。「**シナリオタスク**」と「**単発タスク**」の2つのタブに分かれています。 ![PM on Railsのテスト結果。シナリオごとの合否と証拠が見える。導入前は『動いた』が口頭だった。導入後は完成条件に対する結果が残る。](https://pmonrails.com/docs-img/test-results.png) ## シナリオタスク（受入シナリオの合否） 受入シナリオ（[ユーザーストーリー・シナリオ](https://pmonrails.com/docs/stories.md)）が、実際のテストで**通ったか・落ちたか**を記録・集約するタブです。 - 左のツリーで**ストーリー → シナリオ**を選ぶと、そのシナリオの結果（**合格 / 不合格 / スキップ / 未実行**）が見られます。 - 上部の**カバレッジ（テスト済みの割合）と合格件数は、画面を開いた時点でプロジェクト全体**を集計します（左のツリーを展開しなくても数字が入ります）。個別シナリオの詳細はツリーで選んで確認します。 - 状態（すべて / 合格 / 不合格 / 未実行）で絞り込めます。 - 結果は手で記録（「合格 / 不合格 / スキップ」）したり、開発側（CIなど）から取り込んだりできます。実行履歴も残ります。MCPでは、シナリオ作成時に自動生成されたscenario taskの `task_id` へ `create_test_result` で記録します。 - **CIから自動で記録する** — GitHub Appを連携したリポジトリのworkflowがシナリオ別の合否レポートをartifactとして残すと、PM on Railsが読み取ってシナリオタスクに記録します。リポジトリ側にPM on Railsのトークンやsecretは要りません。設定手順は下の「CIから自動で記録する」を見てください。 - 実行履歴には**出自**（CI自動テスト / 手動記録 / エージェント）が付き、出自で絞り込めます。CI由来の行にはworkflow名とrunへのリンクが出ます。「テストは通っている」と「人が動作を確認した」を区別して読めます。CI由来の行の出自は後から書き換えられず、手動の記録をCI由来に変えることもできません。 - **「検証済み」に数えるのは現行版での合格だけ**です。シナリオを直して版が進んだ後の旧版の合格や、版の記録が無い合格は、プロジェクトの健康状態などで未検証として扱います。 - **証拠の画像・動画** — 手動記録ではファイル選択に加え、**クリップボードから貼り付け**（Cmd/Ctrl+V）でも添付できます（[Macデスクトップアプリ](https://pmonrails.com/docs/desktop.md) でも同じ）。別の入力欄にフォーカスがあるときは、貼り付けを奪いません。 - 不合格のシナリオから、その場で「**バグを起票**」して、カンバンで対応へ回せます。 > シナリオ定義そのものの編集は[ユーザーストーリー](https://pmonrails.com/docs/stories.md)画面で行います（このタブは結果の記録に専念します）。`create_scenario` はTestResult行を事前作成しません。 ## CIから自動で記録する GitHub Actionsの実行結果を、シナリオごとの合否として自動で記録できます。人が「合格」を押さなくても、テストが通っているシナリオと落ちているシナリオがテスト画面に並びます。 ### 前提 1. **GitHub Appでプロジェクトとリポジトリを連携**しておく（[GitHub連携](https://pmonrails.com/docs/github.md)。ワークスペース設定 > 連携 > GitHubで「GitHubに追加」し、プロジェクト設定 > 連携 > GitHubでリポジトリを選ぶ）。 2. GitHub Appの権限に **Actions: Read** が付いていること（artifactの一覧とダウンロードに使います）。付いていないと、取り込みが「artifactを取得できない（権限不足）」として同期イベント履歴に残ります。 ### 手順 **1. テスト名にシナリオのidを書く** 紐付け先はSDLCScenarioのidです（シナリオタスクのidではありません）。idはストーリー画面のシナリオにある「Scenario IDコピー」か、MCPの `list_scenarios` / `read_scenario` で確認できます。そのidを、テストの名前に `[pmr:]` の形で含めます（例: `it('ログインできる [pmr:3f2a9c1e-…]')`）。テスト名に書けないランナーではJUnit XMLの `` でも構いません。 紐付けてよいのは、**テストのassertがシナリオのThenをそのまま検証しているもの**だけです。一部しか検証しないテストに付けると「検証済み」が嘘になります。 シナリオ名やGherkin、版をリポジトリへ写す必要はありません。シナリオは版ごとに別のidを持つので、idだけで「どの版を検証したか」が決まります。 **2. テストランナーのJUnit XMLを出す** 専用のレポート形式や変換ツールはありません。pytestの `--junitxml`、PHPUnit / Pestの `--log-junit`、Jest / Vitestの `jest-junit`、goの `gotestsum --junitfile` など、ランナーが出すJUnit XMLをそのまま使います。 同じシナリオに複数テストがあるときは、1件でも失敗なら不合格、失敗が無く合格があれば合格、スキップだけならスキップとして畳みます。 **3. workflowでJUnit XMLをartifactとしてuploadする** artifactの名前は **`pmr-scenario-report` で始める**必要があります。unit / integrationのようにジョブが分かれるときは `pmr-scenario-report-unit` のように後ろで区別します。 ```yaml - name: Run tests run: vendor/bin/pest --log-junit /tmp/junit.xml - name: Upload scenario report if: always() uses: actions/upload-artifact@v4 with: name: pmr-scenario-report path: /tmp/junit.xml if-no-files-found: ignore ``` `if: always()` を付けておくと、テストが落ちたrunでも「不合格」が記録されます。 **4. 結果を確認する** - workflowが完了すると、PM on Railsがバックグラウンドでartifactを読み、シナリオタスクに結果を記録します。テスト画面の実行履歴に出自「CI自動テスト」とworkflow名・runへのリンク付きで並びます。 - 取り込みの経過と理由は「設定 > GitHub連携」の**同期イベント履歴**に出ます。artifactが無い、権限が無い、レポートの形が違う、といった場合もここに理由が残ります。 ### 記録されないシナリオ 記録されるのは **合意済み（承認済み / 有効）の版**だけです。次の場合は、間違った「検証済み」を作らないため記録せず、理由を同期イベント履歴に残します。 - テストが報告したidの版がまだ下書き / レビュー中（合意してから再実行します） - テストが報告したidが旧版（合意済みシナリオを直して新版になったなど）。履歴に**現行版のScenario ID** が出るので、テストのidを貼り替えます。新版がまだ下書きなら「合意待ち」と出ます - 却下 / 廃止 / アーカイブ済みの版 - フォークリポジトリからのPRで実行されたrun（外部から任意のシナリオに「合格」を積めないようにするため） - 同じrunが二重に届いた（同じrunの結果は1回しか記録しません） - そのrunの `pmr-scenario-report*` artifactのうち1つでも取り込み上限（32 MB）を超えていた（読めた分の合格だけを記録しないよう、run全体を記録しません。超過したartifact名が履歴に出ます） 合意済みのシナリオを編集すると、旧版は旧版・新版は下書きになるため、**新版が承認されるまでCIからの記録は止まります**。正本を直した後は、テストを新版の仕様に合わせてidを貼り替え、再実行すれば次のrunから記録されます。 ### 取り込み直す 権限を付け直した後や、webhookを取りこぼしたときは、同じrunを `POST /api/github/workflow-runs/{run_id}/scenario-report?project_id=<プロジェクト ID>`（editor以上）で取り込み直せます。取り込み済みのrunは二重に記録しません。この再取り込みはwebhookのフォーク判定を通らないので、フォーク由来のrunを再取り込みしないのは呼び出し側の責任です。 ## 単発タスク（ストーリーに紐づかないタスクの確認） ユーザーストーリーに紐づかないタスクを一覧し、確認した結果を見るタブです。 - 「合否」と「自分の確認状態」で絞り込めます。 - タスクを選ぶと、そのタスクの内容と確認結果が開きます。 ## 関連バグ シナリオを選ぶと、右側に「関連バグ」が出ます。 - 「バグを起票」から、そのシナリオに紐づく不具合を起票します。 - 未解決の件数と、各バグの重大度・状態・報告者が分かります。 - 各バグの「修正提案」から、修正案の提案・承認・適用へ進めます（[バグと変更管理](https://pmonrails.com/docs/bugs-changes.md)）。 ## 開発とのつながり 「完成の基準（受入シナリオ）」「実際のテスト結果」「見つかった不具合」が同じ場所で結びつくので、**どこまでが本当に完成したか**を、要求から実装まで一続きで把握できます。 --- https://pmonrails.com/docs/test-results