ノーコードテスト自動化・効率化ツールのTricentisについて、なんでも投稿してみよう！ by Tricentis Advent Calendar 2025

Tricentis Testim で実現する、CI 統合前の継続的テスト運用

Last updated at 2025-12-17Posted at 2025-12-17

はじめに

Tricentis Testim（以下、Testim）は、CI/CD パイプラインに組み込むことが簡単で、DevOps を支援するための強力なテスト自動化ツールです。

一方で、「いきなり CI に統合するところまでは準備が整っていない。社内調整が必要で CI に載せるのは時間がかかりそう...」など、「CI に載せる前に、まずはツール単体で継続的に回せる運用を作りたい」というケースも多いのではないでしょうか。

筆者は、CI 統合の前段階として単体運用の「土台」を固めることには大きなメリットがあると考えています。まずテスト自体の信頼性（安定したテスト）を担保しておくことで、いざ CI を導入した際に「テストが頻繁に落ちてパイプラインを止めてしまう」といった混乱を防ぐことができるからです。

本記事では、そんな状態からスタートして、Testim の機能を活用し、将来の CI（継続的インテグレーション）連携も見据えた、Testim 単体での継続的テスト運用を始める方法をご紹介します。

記事の構成は、大きく以下の 2 つに分けて紹介していきます。

テストシナリオの作成とメンテナンス運用

Testim 上のブランチ運用とレビューの仕組みを整え、「安全にテストを育てる」方法

テスト実行運用とフィードバックループ

スケジュール実行と失敗ラベル付けにより、「失敗の原因を可視化し、継続的に改善するテスト運用」の方法

この 2 つを整えることで、「CI に統合せず、 E2E テストのフィードバックループを回す」基盤が準備できると思います。運用設計時の参考として、ご活用いただければ幸いです。

Tricentis Testim 公式サイト

1. テストシナリオ作成とメンテナンス運用

テストシナリオをどの様に作成し、メンテナンスしていくかは、継続的テスト運用の重要なポイントになります。本パートでは、Testim のブランチ機能で、テストシナリオのバージョン管理を活用して運用する方法を説明します。

Testim のブランチ機能とは

Testim のブランチ機能は、GitHubやGitLabなどのバージョン管理システムと同じように、テストシナリオのバージョンを管理できる機能です。ブランチを活用することで、複数のチームメンバーが同時に作業でき、安全にテストシナリオの作成やメンテナンスを行うことができます。

また、ブランチプロテクションの設定も可能なため、重要なブランチを保護し、プルリクエスト（PR）を通じて変更していくことで、意図しない変更を防止することもできます。

ブランチは任意のブランチから派生させることができ、ブランチ設定はプロジェクト単位で行えます。これにより、プロジェクトごとに適した運用ルールを柔軟に設計できます。

Testim のブランチ機能の注意点

ブランチ名の再利用不可: 削除済みであっても、過去に使用したブランチ名は再利用できません。
全体設定の影響: プロジェクト設定などの「全体に関わる設定」はブランチを跨いで共有されるため、変更すると全てのブランチに即時反映されます。

参考: Branch Management

1.1 ブランチ戦略と権限設計

継続的テスト運用を始めるにあたり、まずはブランチ戦略と権限設計を行います。
小さく始めることを念頭に置き、まずはシンプルな GitHub フローを参考にしたブランチ戦略からはじめることをおすすめします。
シンプルなルールからスタートすることで、運用の負荷を抑えつつチームに習慣として根付かせやすくなります。

イメージしやすくするために、GitHub Flowの画像は AI に生成してもらいました。

ブランチの種類と役割

masterブランチ: 本番環境で実行される安定版のテストシナリオを配置します。直接変更は行わず、PR を通じて変更を加えます。
featureブランチ: 新しいテストシナリオの作成や既存のテストシナリオの修正を行うためのブランチです。作業が完了したら、masterブランチへの PR を作成します。
fixブランチ: 本番環境で実行されるテストシナリオに修正が必要な場合に使用します。修正が完了したら、masterブランチへの PR を作成します。

運用イメージは、「master から feature（fix）ブランチ作成 → テスト追加・修正 → PR → レビュー → master にマージ」の流れです。

1.2 Testim のブランチ機能の設定

Testim のブランチ機能を有効化するには、設定メニューから「Project Settings」の「PROJECT」タブを選択し、「PULL REQUESTS」セクションで設定を行います。ここで、ブランチプロテクションルールの設定も可能です。
「Protect branches from changes」のトグルスイッチをオンにして、必要なルールを設定してください。今回は、ブランチ戦略に基づき、masterブランチに対して直接編集を行わない read-only とし、 PR を必須とする設定を行います。

ブランチプロテクション・ PR 設定項目について

設定項目	説明
Protect branches from changes	直接変更から保護する `read-only` ブランチを設定
Require approving reviewer	PR の承認を必須にする設定
Branches	PR の承認を必須にするブランチを指定
REVIEWERS	PR 承認者の指定
ALLOW SELF APPROVAL	自分自身で作成した PR 承認の許可指定

ブランチ運用のポイント

PR の承認権限: 品質を担保するために、リーダー・シニア層に限定して運用を開始し、段階的に拡大していくことをおすすめします。
ALLOW SELF APPROVAL: 運用開始初期の迅速な対応に限り、対象者を絞って有効化するのが有効です。ただし、安定稼働後は無効化を推奨します。

1.3 ブランチ運用によるテストシナリオの作成・メンテナンス

ブランチ戦略と権限設計、Testim のブランチ機能の設定が完了したら、実際にブランチ運用を開始します。以下の流れでテストシナリオの作成・メンテナンスを行います。

1.3.1 プロジェクトの選択

複数のプロジェクトがある場合は、画面上部プロジェクトメニューから、対象のプロジェクトを選択します。

1.3.2 `master`ブランチから`feature`または`fix`ブランチを作成

Testim の画面上部にあるブランチメニューから、masterブランチを基点に新しいfeatureまたはfixブランチを作成します。

ブランチ名は、以下の例のように、チームで統一された命名規則を用いることをおすすめします。{}の部分は適宜置き換えてください。

新規作成の場合: feat/{YYYY-MM-DD}-{testcase-name}-{username}
既存修正の場合: fix/{YYYY-MM-DD}-{testcase-name}-{username}

1.3.3 作成ブランチに切り替えてテストシナリオの作成・修正

作成したfeatureまたはfixブランチに切り替え、テストシナリオの作成や修正を行います。
テストシナリオの作成や修正の操作方法については、Tricentis Japan 様の以下の Qiita 記事が分かりやすく解説されていますので、ご覧ください。

Shared steps の作成・修正時のポイント
Testim には複数のテストシナリオで共通利用できる Shared steps 機能があります。Shared steps の修正は、影響範囲が広いため、以下の運用ルールを設けることをおすすめします。

Shared steps の新規作成前: プロジェクトメンバーに「用途・責務・想定再利用範囲」を共有し、合意を取る。
Shared steps の修正前: 利用しているテストシナリオを確認し、「いつ / どう変えるか」を事前に共有する。
安易に Shared steps を増やさない: 本当に共通化すべき箇所か？を検討する

こうすることで、「共通ステップを直したら、関係ないテストまで大量に落ちた」という事故を防ぐことができます。

Shared steps の影響範囲確認方法は、Shared Steps Library 画面で、各 Shared step のプルダウンをクリックすると、利用しているテストシナリオ一覧を確認できます。

参考: Shared Steps Library

1.3.4 テストの動作確認

テストシナリオを作成・修正した後は、必ずローカルとクラウド環境の両方で動作確認をします。ローカルではテストが成功するが、クラウドでは失敗する場合もあるため、両環境での確認が重要です。

ローカル実行

手元のブラウザでテストを実行し、期待どおりに動作するか確認

クラウド実行（Grid）

ツールが提供するクラウド環境（Grid）でテストを実行し、クラウド環境で安定して動作するか確認

参考: Running Tests Overview

1.3.5 PR の作成とレビュー

テストシナリオの作成・修正と動作確認が完了したら、masterブランチへの PR を作成します。
PR には、変更内容の説明や関連するチケット番号などを記載し、レビュー担当者に通知します。レビュー担当者は、変更内容を確認し、必要に応じてコメントや修正依頼を行います。
以下のような PR テンプレートを用意しておくと、 PR コメントの作成やレビューがスムーズに進むと思います。

PRテンプレートsample

PR Title: {テストシナリオ名}の新規追加・修正

## 作成・修正内容
- テストシナリオの新規追加・修正内容の説明

## チケット番号
- ZZZZ-1234

## 対応背景・目的
- 対応経緯の説明

## 補足情報
- 特記事項や注意点など

作成後、 PR を作成したことをチャット（Slackなど）で共有し、レビューを依頼します。レビュアーは上部メニューのマージアイコンから確認をします。

新規テストの場合と既存テスト修正の場合で、レビュー時の確認方法が異なりますので、以下で説明します。

新規テストの場合

新規テストの PR は、ツールの仕様上、差分ビューが出ないため、PR 画面の「View source」リンクから作業ブランチへ移動し実際のテストシナリオを開いて内容を確認します。

確認ポイント
- シナリオ設計・テスト設計に沿った内容になっているか
- PR コメントに書かれた背景・目的から見て、テストシナリオの流れに違和感がないか
- 不要なステップや冗長な操作が含まれていないか
- 失敗しやすい実装（タイミング依存、DOM 依存が強すぎるセレクタなど）がないか

既存テスト修正の場合

既存テスト修正の PR では、PR 画面の「Compare」や差分ビューから変更内容を確認できます。

確認ポイント
- チームで事前に合意した修正内容に沿っているか
- 関係ないステップまで変更していないか（レコーダー誤録など）
- Shared steps の修正が入っている場合、その影響範囲は妥当か

1.3.6 Approved & Merge

ここまでで作成した PR を、2 名体制でレビュー・承認し、master に取り込むフェーズです。レビュー体制は、1 次レビュー担当者・2 次レビュー担当者（Approve + Merge 実行者）の 2 名体制を推奨します。

1 次レビュー担当者

PR 全体を確認し、内容に問題がなければ 2 次レビュー担当者にエスカレーション

2 次レビュー担当者

最終確認を行い、問題がなければ PR を Approve、master への Merge を実行

Testim の PR Approve について

PR の承認は、いずれか 1 名のみしか行えません。
2 名以上の承認を必須とする設定はできませんので、2 名体制でのレビュー運用を行う場合は、上記のような運用ルールを設けて対応してください。

フィードバックがある場合

PR コメント欄に指摘内容を記載
「Request Changes」を選択して PR を差し戻し
チャットで作成者に差し戻しを連絡

問題なく承認できる場合

1 次レビュー担当：PR を確認し、チャットで「LGTM」を連絡
2 次レビュー担当：PR を Approve
master に merge を実行
このとき「ブランチ削除」のチェックボックスにチェックしておく
もしチェックし忘れても、後から master 画面からブランチ削除可能
最後に、merge 完了をチャットで作成者とチームに共有して終了

2. テスト実行運用とフィードバックループ

ここからは、どのようにして継続的にテストを実行し、フィードバックループを回していくかについて説明します。Testim のスケジュール実行を活用し、定期的にテストを実行する方法をご紹介します。

ポイントは、次の 4 つです。

定期実行（または手動実行）の設計
失敗テストへのラベル付け
ドキュメントとの連携
失敗傾向の分析と改善

2.1 定期実行の設計

継続的テスト運用を実現するためには、定期的にテストを実行する仕組みが必要です。Testim のスケジュール実行機能を活用し、適切な頻度でテストを実行するように設定します。ここでは、以下のような運用パターンサンプルを紹介します。

ブランチ：master ブランチ

実行対象：

重要度の高いテストスイート（スモークテスト）
リリース前に必ず通したいテストプラン（シナリオテスト）

実行頻度は、システムの重要度や変更頻度に応じて決定します。

運用パターンサンプル

日次：主要フローのスモークテスト
リリース候補ブランチ作成時：広めのリグレッションテスト

具体的なスケジュール設定例は、次のとおりです。

日次実行をしたい場合
- 「Specific time」を選択し、実行する曜日と時間を指定します。
一定間隔でポーリングしたい場合
- 「Monitor」を選択し、実行間隔を指定します（5 分〜 12 時間の範囲で設定可能）。

スケジュール実行の注意点

日次実行時に指定する時間は、デフォルトでは LOCAL または GMT（協定世界時）からの選択となります。日本時間に合わせる場合は、UTC+9 時間を考慮して設定してください。
Monitor 実行は、指定した間隔で継続的に実行されますが、実行時間が長いテストシナリオがある場合は、次の実行が開始されるまでに前の実行が完了しない可能性があります。テストシナリオの実行時間を考慮して、適切な間隔を設定してください。

参考: Scheduler-web / Scheduler-mobile

2.2 失敗テストへのラベル付け

テスト実行後、失敗したテストシナリオにはラベルを付けて管理します。
これにより、各テストの失敗原因や、その原因が属するカテゴリを継続的に蓄積していくことが可能になります。そのために実施するのが、失敗テストへのラベル付け運用です。

蓄積したラベル情報をもとに、ダッシュボードレポートから失敗傾向を分析します。これにより、「テストが落ちている」という抽象的な状態から、どこに改善リソースを割くべきか、チームとしてどのタイプの問題が多いのかが判断しやすくなり、改善活動に役立てることができます。

Testim の失敗ラベルの種類と定義サンプル

ラベル名	定義サンプル	参考事例
Bug in App	不具合・デグレ	リリースでボタンが動かなくなった API が 500 を返すようになった
Environment Issue	検証環境の問題	テスト環境にアクセス不可レスポンス遅延タイムアウト
Invalid test data	テストデータの問題	テストユーザが削除されていたテストデータの期限切れ
Test design	テストシナリオ設計の問題	UI の要素取得が不安定タイミング依存によるフレーキー
New UI change	UI 変更 / 仕様変更	ボタンのテキストが変更項目追加や画面遷移フローの変更
Other	上記以外のケース	再現性が低い突発的なエラー原因究明途中

ラベル付けの手順
- ツールのダッシュボードから「Runs」メニューを開く
- 失敗したテストの実行結果を選択（詳細画面へ）
- 「Tag test failure」などのメニューから、該当ラベルを選択
- Description に、原因を簡潔に記入

2.3 テストシナリオドキュメントとの連携

テストシナリオの意図をドキュメントに残す運用も重要です。
以下のようなポイントを押さえたドキュメントを用意しておくと、テストシナリオの理解が深まり、メンテナンス性が向上します。

テストシナリオドキュメントの項目例

テストシナリオ ID / 名称
Testim のテストシナリオリンク
テストシナリオの概要
テストの目的
検証範囲
前提条件（必要なテストデータ、環境設定）
シナリオの流れ
期待結果

ドキュメント管理のポイント

Confluence、Notion など、チームで共有できるツールを活用して管理
テストシナリオの変更時は、ドキュメントも更新し、常に最新の情報を保つ

2.4 継続的な改善サイクル

ここまでを組み合わせると、次のようなサイクルになります。

テストシナリオを作成 / 修正し、レビューを経て master へ
master 上のテストを定期実行
失敗にラベルを付与し、原因を可視化
必要に応じてテストシナリオやテストシナリオドキュメントを更新

チームとしては、例えば週次や月次の振り返りミーティングの冒頭5〜10分で、ラベル別の失敗件数を確認するだけでも効果的です。

ラベル別の失敗件数
テストシナリオ別の失敗頻度
特定ラベル（例：Test design）が多いテストの一覧

といった観点で確認することで、以下のような「改善の焦点」をチームで合わせることができるのではないでしょうか。

アプリ側の品質問題が多いのか
テスト設計の見直しが必要なのか
テストデータ運用に課題があるのか

さいごに

本記事では、Testim を活用して「CI 統合前の土台」を作るための運用フローをご紹介しました。

重要なポイントは、**「ブランチ・レビュー」でテストの信頼性を高め、「定期実行・ラベル付け」**で改善のサイクルを回すことです。

CI 統合していない段階であっても、この運用を整えておけば、将来的に「どのテストを CI に載せるか」といった判断がしやすくなります。

まずは、次の 4 ステップだけでも試してみると、感覚がつかめるはずです。

ブランチ保護: master を read-only とするブランチ保護と、簡単な PR テンプレートを用意する
代表的なテストシナリオの作成: 主要なシナリオを 1〜2 本作成し、master にマージする
スケジュールの登録: 作成・修正したテストシナリオを「日次実行」に設定する
失敗の可視化: 失敗時には必ずラベルを付与し、原因を 1 行だけメモする

これだけでも、「CI に統合される前から、テストが価値を出し続ける状態」を作ることができます。

Testim を活用した継続的テスト運用の第一歩として、本記事の内容を参考にしていただけたら幸いです。ここまで読んでいただき、ありがとうございました。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up