🔎

テスト管理システム SquashTMの調査 2025年版

に公開
Test
Playwright
tech

はじめに

このドキュメントではSquashTMというテスト管理ツールについての調査・実験結果をまとめます。

このドキュメントの対象読者はテスト計画、テストケースなどのドキュメントについて知見があり、テスト実行の管理ツールを探している人物を対象とします。

SquashTM

テスト管理ツールとして、JaSST Tokyo2017で導入事例が紹介されたツールです。

SquashTMはテストケースの管理を行うだけでなく、バグ管理システムやテスト実行メカニズムとの連携が行えます。

日本語自体の対応はされていないものの、直感的なGUIは使いやすく、また機能的にもドキュメントも十分揃っています。
Community版という無料で使用できるオープンソース版と、有料のPremium, Ultimate版が存在します。

Community版で使用できる主な機能は以下の通りです。

  • 要件項目の作成・管理
  • テストケースの作成・管理
  • テスト実行の割り当てと実施記録
  • 要求仕様・テストケースのExcelからのインポート
  • 要求仕様・テストケースのExcelへのエクスポート
  • ユーザーレベルの操作をするREST APIの実行
  • バグトラッキングシステムとの連携
  • Squash Orchestrator（テスト実行の標準メカニズム）との連携

有料版では有用な機能がさらに追加されます。

Community版の機能はデモサイトが設置されていますので、簡単に確認することができます。

その他機能については以下を参照してください。

実験環境のシステム構成

今回の実験ではローカルのDockerコンテナとしてテスト管理の実験が行えるようにします。その構成例については以下を参照してください。

https://github.com/mima3/research_tms/tree/main/squash-tm/

今回は以下のコンテナを作成します。

docker compose upを実施後しばらくするとブラウザからアクセス可能となる。

項目 値
URL http://localhost:8090/squash
user admin
password admin

なお、必要なマシンスペックについては以下を参照してください。
Minimum Configuration and Prerequisites

最小限の手動テストを実行する方法

以下の作業を行い実際にテストを実行するまで確認します。

  • ユーザーの追加
  • プロジェクトの作成
  • 要求仕様の作成
  • テストケースの作成
  • テスト実行の計画
  • テストの実行

ユーザーの追加

画面左下の Administrationメニューから Users を選択します。

Administration - Users 画面が表示されるので、 Add a user ボタンを押下します。

Add a user ダイアログが起動するので、Login, First Name, Last Name, passwordを入力して Add ボタンを押下します。

ユーザーの追加が確認できます。

プロジェクトの作成

要求仕様、テストケースなどはプロジェクトごとに管理されます。
テストを実施するには、まずプロジェクトを作成する必要があります。

画面左下のAdministrationメニューからProjectsを選択します。

Administration - Projectsの画面が起動します。

画面、右上の＋ボタンからコンテキストメニューを開き、「Add a project」を選択します

Nameを入力して「Add」ボタンを押下します。

これによりプロジェクトが追加されます。

ユーザーの紐付け

作成したプロジェクトにユーザーを紐づけることができます。

Clearance テーブルの Associate users を押下します。

Add clearance ダイアログにて Users と Profile　を選択して Add ボタンを押下します。

これでユーザーが追加できます。

Requirementsの作成

一般的なテスト管理ツールの一部では要件定義をした項目をテストケースと共に管理して、要件をどの程度網羅したテストであるかを管理することができます。
SquashTMも要件の管理機能を有していおり、「Requirements」と呼称します。詳細は「Requirements」のドキュメントを参照してください。
なお要求仕様がなくてもテストケースの作成とテストの実行は行えます。

以下に要件を追加する流れを説明します。
まず左のメニューからRequirementsを選択します。

プロジェクトごとの階層構造が表示されます。

要件項目を作成したいプロジェクトを選択します

＋ボタンを押すことで作成のコンテキストメニューが表示されます。

名称 説明
Add a requirement 要件の項目を追加する
Add a high-level requirement 複数の要件とリンクされたHigh level requirementsを追加する。
Community 版では使用できない。
Add a folder 要件をまとめるフォルダを作成する。フォルダはサブフォルダを有することができる

まず「Add a folder」を選択します。
Add a folder ダイアログが表示されるので NameとDescriptionを入力後に「Add」ボタンを押下します。

フォルダが追加されることを確認します。

フォルダを選択中にさらに「Add a folder」でサブフォルダを作成することが可能です。

次に任意のフォルダを選択して「Add a requirement」を選択します。

Add a requirement ダイアログが表示されます。

Name や Descriptionを入力して Add または　Add another ボタンを押下してください。

Add a requirement ダイアログの属性についての詳細は下記のページを参照してください。
Manage Standard Requirements

Requirementが作成されると以下のようになります。

Test casesの作成

SquashTMではテストケースを作成・管理できます。
詳細は以下を参照してください。
Test Cases in Squash

以下に要件を追加する流れを説明します。
まず左のメニューからTest casesを選択します。

テストケースを追加するプロジェクトを選択します。

＋ボタンを押すことで作成のコンテキストメニューが表示されます。

名称 説明
Add a test case テストケースを追加する
Add a folder テストケースをまとめるフォルダを作成する。フォルダはサブフォルダを有することができる

まず「Add a folder」を選択します。
Add a folder ダイアログが表示されるので NameとDescriptionを入力後に「Add」ボタンを押下します。

Requirements のfolderのようにフォルダの下にサブフォルダを作成することが可能です。

次に任意のフォルダを選択して「Add a test case」を選択します。
Add a test case ダイアログが起動するので Format を Classic にして Name と Description を入力して Add ボタンを押下します。

要件との関連付け

テストケースによってカバーできる要件を関連づけることができます。
テストケース中の Requirements verified by this test case のリストに、このテストで確認できる要件を追加します。

まず＋ボタンを押します。

Requirement 階層構造で表示されます。

関連づけたいRequirementを選択してドラッグ&ドロップで Requirements verified by this test case　に Requirement を追加します。

テストの前提条件とステップの記載

テストケースには、そのテストの前提条件と詳細の実行手順を記載する必要があります。

テストケースを選択後、「Prerequisites and test steps」 タブを押下します。

PREREQUISITES の項目に前提条件を入力して Confirm ボタンを押下します。

ACTION に手順を記載し、 Expected result に実行後にどうなるかの期待する動作を記載して Add ボタンを押下します。

ステップを追加または挿入する場合は、 Add a step ボタンを押下します。

同様の操作でテストケースをいくつか作成します。

なお、テストケースはCopy & Pasteが可能なのでコピーして一部を変更してテストケースを作成する
ことができます。

その他、テストケースの入力方法については下記を参照してください。
Conceiving the scenario of a Classic Test case

テスト実行の計画

Executions workspaceを使用して、テストの実行計画を作成できます。

画面左のメニューから　Executions を選択します。

テストの実行計画を行いたいプロジェクトを選択して＋ボタンを押下します。

メニュー 作成する項目 作成できる場所
Add a folder 構造整理用のフォルダ プロジェクト直下、folder、sprint group
Add a campaign ある目的・範囲でテスト実行をまとめるためのグループ プロジェクト直下、祖先がプロジェクトのみのフォルダ
Add an iteration campaign の下位の概念。iteration 単位でテストが実行できる campaign
Add a test suite 機能またはタイプごとにテストをグループ化するために作成する iteration
Add sprint group Scrum のスプリントのグループ プロジェクト直下、祖先がプロジェクトのみのフォルダ
Add sprint Scrum のスプリントを表す プロジェクト直下、sprint group、sprint groupまたはfolderのみが祖先のfolder

今回は campaign と iterationを作成するまでの手順を紹介します。
まず「Add a campaign」を実行します。

Add a campaign ダイアログが表示されるので、Name と Description を入力して Add ボタンを押下します。

作成した campaign を選択して Add an iteration を実行します。
Add an iteration ダイアログが表示されるので、Name と Description を入力して Add ボタンを押下します。

テスト計画にテストケースを紐づける

Execution Plan タブを選択します。

Associate test cases ボタンを押下します。

作成済みのテストケースが表示されます。

実行対象のテストを選択してExecution plan にドラッグ&ドロップを行いテスト計画とテストを紐づけます。

テスト実行者のアサイン

Execution Planを右にスクロールするとUSER列が表示されるので、そこをクリックします。

これによりテスターにテスト実行をわりあてることができます。

テスト実行

テストをアサインしたユーザーでログインしてExecutions workspaceを確認すると、自身にテストが割り当てられていることが確認できます。

Start ボタンを押下するとテストが開始します。

テスト実行用のダイアログが表示されます。画面右上のStartボタンで次のページが表示されます。

ステップが１つずつ表示されるので、ACTIONとEXPECTED RESULTが表示されます。期待値と一致するケースではPassという結果を押下します。

次のステップが表示されます。今回は失敗したものとしてFailedを押下します。必要に応じてCOMMENTSに追加情報を入力します。

以降のチェックは無駄なのでGo to the next test case を押下します。

この時点でテストのSTATUSが確定します。

割り当てられたテストケースを全て同じように実行します。

iterationのトップページを確認すると、テスト結果の統計情報が確認できます。

Squash Orchestratorとの連携によるテスト実行

Squash OrchestratorはOpenTestFactoryを拡張したテスト実行基盤です。
SquashTMで作成したテストケースからPEaC (Planned Execution as Code) を生成してオーケストラ経由で適切なAgentでテストを実行します。

ここではSquash Orchestratorでテストを実行させるための設定を記載します。

Squash Orchestratorの連携情報を設定

画面左下の Administrationメニューから Servers を選択します。

Test automation servers タブを選択します。

Add ボタンを押下します

Add a test automation server ダイアログが表示されたので、Name, Type, URL, Descriptionを入力して Add ボタンを押下します。

Test automation serverが追加されるのを確認します。

追加したサーバーの名前をダブルクリックすると詳細情報が表示されます。

Receptionist URL　〜 Killswitch URL にポート番号を付与する。

サーバーの種類 URL
Receptionist URL http://orchestrator:7774
Observer URL http://orchestrator:7775
Event bus URL http://orchestrator:38368
Killswitch URL http://orchestrator:7776

Authentication policy の Tokenを入力します。値はココを参照してください。

正しいTOKENを入力すると以下のようになります。

また、Environments項目にAgent情報が表示されます。

Squash public URL の設定

Squash public URLが未設定の場合は、Test automation serverの画面上部に以下のようなメッセージが表示されます。

Set the Public URL のリンクを押下すると以下に遷移します。

Squash public URLにhttp://squash-tm:8080/squashを入力します。

コンテナ内のorchestratorからアクセスできるようにコンテナ名とコンテナ中のポート番号を指定します。

Source code management serversの設定

SCM Gitを入れる

SquashTMが動作する環境の/opt/squash-tm/pluginsにGit connectorプラグインを配置する必要があります。
プラグインについては以下からダウンロードできます。

Download plugins

Source code management serversの設定

Administration - Servers を開きます。

Source code management service を開きます

Add ボタンを押下すると Add a source code management server が表示されます。

Name, Type, URLを入力して Add を押下します。

今回の入力値は以下の通りです。

プロパティ 値
Name GitHub
Type Git
URL https://github.com/mima3/

引き続き追加情報を入力します。
Authentication Policy にGitHubのアクセストークン情報を入力します。

アクセストークンはGitHubの以下のメニューから作成できます。
GitHubのSettings>Developer Settings>Personal access tokens

次に自動テスト対象のリポジトリを追加します。

今回は以下のような値にしました。

プロパティ 値
Name example_playwright
BRANCH main
WORKING DIRECTORY tests/example_playwright

プロジェクトに自動テスト用の設定を行う

Administration > Projectsを選択します。

自動テストを行いたいプロジェクトを選択し、Automationタブを選択します

Automationの設定を行います

  • SOURCE CODE MANAGEMENT SERVER
    • Server : GitHub (https://github.com/mima3/) を選択
    • Repository: example_playwright (main)　を選択
  • TEST AUTOMATION SERVER: orchestrator を選択
  • Test automation server

自動テストの実行方法

自動テスト用のテストケースの追加

Format：Classicのテストケースを追加します

Automation の Eligibility for automationにて Eligible を選択します

設定内容

  • Automated test technology: Playwright
  • URL of the Source code repository : https://github.com/mima3/example_playwright (main)
  • Automated test reference: tests/example.spec.ts

右上の Transmit を押下します

Automation status が Transmitted になることを確認します

テストケースのタイプをAutomatedにする

この状態ではテストケースの Automation status が Transmittedのままなので自動テストはまだ実行できません。
自動テストをするには Automation status をAutomated に変更する必要があります。

左側のメニューから Automation > Automation Workspace(Auto m.)を選択します

Global view タブを選択します

TEST CASE をクリックすることで行を選択します

右上のAutomatedボタンを押下します

AUTOM. STが Automatedに変換されます。

テスト実行

Executions 上の任意の iteration にAutomatedとなったテストケースを追加します。

Automated のテストケースを追加すると画面右上に Run automated testsがボタンが現れるので押下します。

Overview of the automated test execution ダイアログが表示されます。

Confirm ボタンを押下します。

しばらく待つとテストが完了します。

注意事項

REST APIの使用

Pluginとしてapi.rest.servicesが入っている場合、REST APIが使用できます。
REST APIのドキュメントは自身のSquashTMのエンドポイントで閲覧可能です。
今回の実験環境の場合、以下のURLになります。

http://localhost:8090/squash/api/rest/latest/docs/api-documentation.html

まず、REST API用のアクセストークを作成します。

そのため、My account　を選択します。

Personal API tokens を追加します。

任意の名前と有効期限を入力してAdd ボタンを押下します。

トークンが発行されるので、その値を保管します。

このトークンを使用して以下のようにREST APIを実行できます。

export API_TOKEN=上記で生成したトークン

# タスクの取得例
curl -v -X GET -H "Authorization: Bearer ${API_TOKEN}" \
     -H "Accept: application/json" \
     http://localhost:8090/squash/api/rest/latest/test-cases

# タスクの作成
curl -v -X POST -H "Authorization: Bearer ${API_TOKEN}" \
  -H 'Content-Type: application/json; charset=utf-8' \
  -H 'Accept: application/json' \
     http://localhost:8090/squash/api/rest/latest/test-cases \
  -d '{
  "_type": "test-case",
  "name": "ファーストネーム",
  "parent": { "_type": "project", "id": 1 },
  "importance": "MEDIUM",
  "status": "UNDER_REVIEW",
  "nature": { "code": "NAT_FUNCTIONAL_TESTING" },
  "type": { "code": "TYP_COMPLIANCE_TESTING" },
  "prerequisite": "Weather should be cold",
  "description": "詳細",
  "custom_fields": [
  ],
  "steps": [

  ],
  "datasets": [],
  "verified_requirements": []
}'

管理用のREST APIはCommunity版では使用できないので留意してください。
また、本番環境ではアクセストークンの取り扱いに十分注意してください。

まとめ

実験中に気づいた点について以下にポジティブな側面とネガティブな側面にわけて列挙します。

ポジティブな側面:

  • Community版の範囲でも、多くのテスト管理ツールと同等以上の機能を有する。
  • 直感的に使える。TestLinkなどのテスト管理ツール経験者であれば学習コストは低い
  • マニュアルが英語であるが豊富である
  • 探索的なテストの結果も管理できる
  • テストケースにパラメータを埋め込める。これにより、同じようなテストを別のパラメータで実行できる

ネガティブな側面:

  • ダイアログ画面でタイトルとかを入力する際に日本語変換の確定で決定がされてしまう
  • 日本語がサポートされていないので、機械翻訳が効かない環境や、人員によっては導入が厳しい
  • H2がなくなったので、お試し環境を構築する際のハードルが高くなった
  • Administration - Projectsでプロジェクトが選択できなくなる場合がある（更新で直る）
  • テストの自動実行については、他の CI/CD ツールに対する顕著な優位性は見いだせず、トラブル時の対応も難しい

いくつか、ネガティブな側面はありますが、テスト管理を始めてみる場合の有力な候補の一つになると思われます。

Discussion