JaSST’25 Tohoku 参加レポート｜テ。ーテストの設計についてー

皆様こんにちは、ハヤシです。

2025年5月30日(金)に開催された、JaSST2025東北に参加してきました。

初めての仙台、JaSST、新幹線などでいろんな経験ができました！

それでは基調講演とワークショップで行った活動をもとに参加レポートを作成いたします。

JaSST東北とは

JaSST東北とは、NPO法人ASTER (ソフトウェアテスト技術振興協会) が主催する「Japan Symposium on Software Testing (JaSST)」の東北地方での開催を指します。

JaSSTは、ソフトウェアテストに関する最新の情報やノウハウを共有し、ソフトウェア業界全体のテスト技術向上を目指したシンポジウムです。（JaSST公式サイトより）

JaSSTの開催地

JaSST東北の流れ

以下は今年のJaSST東北の正式名称とテーマ、テーマ概要、プログラム概要です。

正式名称：JaSST’25 Tohoku　ソフトウェアテストシンポジウム2025東北
【やってみよう！テスト開発 〜チームで育てるテスト観点〜】

テーマ：「テスト設計」

テーマ概要：

JaSST東北、本年のテーマは「テスト設計」です。

シンポジウム後半には、テスト設計を体験できるワークも用意されています。そこで本セッションでは（主にテストの）「設計技術」について、お話します。

ご参加のみなさまの理解をより深めていただくために、背景となるテスト設計のモチベーションや、技術の世界観全体感をつかむためのテスト設計プロセスの話題も盛込んで、設計の話を展開します。また設計技術を学んでいくためのヒントも提供できればと思います。

JaSST’25 Tohoku公式サイトより

プログラム概要：基調講演→ワークショップ（全体説明）→ワークショップ１→ワークショップ2

※参加前に心掛けていたこと

僕自身去年の4月に新卒で入社後、今までの案件でテスト設計を一からからやったことはなかったので（1回は以前あった設計を元にアップデートされた内容を追加して修正するだけでした。）将来担当することになるテスト設計のために、「実践で使えるテスト設計インサイト」を確実に自分のものにして帰ろう、という気持ちで参加いたしました。

基調講演「テ。ーテストの設計についてー」

今回の基調講演に登壇された方は近美克行さん（シーイーシー／ディペンダビリティ技術推進協会／ASTERテスト設計コンテスト）でした。セッションが始まる前からテストに関するすごい情熱が伝わってきて本当にプロフェッショナルな方だと感じました。

基調講演では全部話しきれない分量のプレゼンテーション資料でしたが、テスト設計における重要なポイントを中心に講演してくださいました。（テストに関する愛を感じました！）

講演の流れ

　講演の流れは以下のような流れでした。

1. PART1. なぜ、わざわざ（テストの）設計を行うのか？
   設計の目的（ゴール）を知る
2. PART2. 設計技術を構成する技術要素や原則を知る
   そして設計のご利益を知る
3. PART3. 設計技術を磨くアイデアを考える

PART1.なぜ、わざわざ（テストの）設計を行うのか？（テスト）設計の目的（ゴール）を知る

テスト設計を行う理由を理解するために本講演のPART1ではまず、ソフトウェア開発で設計が行われなかった時にどのような困りが生じるかについて考えることから始めました。

以下は本講演で述べられた設計を行わなかった時の困りごとです。

1. 事前検証機会の喪失（作ってからじゃないと設計の良し悪しが判断できないため）
2. 知識共有機会の喪失（設計レビューの形で有職者の支援が受けられない）
3. コミュニケーション機会の喪失（設計書というドキュメントの形で情報を残さないことにより、未来の自分、他の設計者、実装者、テスト担当、保守担当者に設計知見や意図が伝達できない）

たしかに…と考えました。設計をしてドキュメントの形で保存すると上記全てをある程度未然に防ぐことができるかと。なんとなくわかってはいたものの、確実にまとめて説明して頂いてきれいな形で頭の中に整理される感じでした。

では、設計をすることによって得られる利益は以下となります。

1. 事前検証機会確保によるフィードバックループの短縮→速度向上
2. 知識共有機会確保による「既知・確実」情報の共有
3. コミュニケーション機会確保による合意形成達成・説明責任の達成

困りごとと連携される利益でとてもわかりやすく、設計を行うことによるメリットとデメリットが確実に理解できました。

そこからテスト設計の場合どのようになるかをみると…

1. 事前検証機会の確保
   • 製品出荷以前にテストの有効性を判明し、致命的な有効性不足を判明できる
2. 知識共有機会の確保
   • 最近のソフトウェアは一人で作成、実施、検証するには規模が大きすぎるため、知識共有機会の確保により、多数人でプロジェクトを行える
3. コミュニケーション機会の確保
   • もし、テストを一人でできたとしても、利害関係者への説明は必要となる

このように、テスト設計は絶対的に必要なプロセスだということがわかりました。

PART2.設計技術を構成する技術要素や原則を知る。そして設計のご利益を知る

PART2ではテスト開発プロセスを重点に講演が進みました。以下星マークがついてる部分がこの講演で重点的に扱われた部分です。

テスト開発プロセスにおける、

• ☆テストの目的は？
• テストのINPUTは？　 テストベース
• テストのOUTPUTは？　テストケース
• ☆テストの構成要素（情報要素は？）
• ☆構成要素間の相互作用は？

のうち、星マークがついてる部分を講演の内容を元に解説していきます。

1. テストの目的は？

欠陥の修正（QC）への貢献と品質保証（QA）への貢献

• 欠陥の修正（QC）への貢献
  • いかに少ないコスト （人的リソース、時間、スキルニーズ、精神力など）で、是正に      つながる 欠陥を発見できるか？
  • NGが発生する条件を絞り込めるような十分な情報提供ができるか？
  • 欠陥であることが正しく判断しやすいか？
• 品質保証（QA）への貢献
  • 開発とテストプロセスがどの程度うまくいっているか？ についてのフィードバックに使う
  • すべての利用者、利用状況、ユースケースの組み合わせは現実的に検証不可能であるため、品質保証目的、目標のモチベーション（テスト結果を証拠として、検証したい内容）を定義し、それにあわっせて適切な品質保証戦略（論証戦略＝説明ロジック）を構築する

2. テストの構成要素（情報要素は？）

テスト要求とテスト条件の集合

• テスト目的に関する情報要素：テスト要求 
  （品質論証の論証ゴールと論証の有効範囲を表現したもの）
  →テストの目的のパートで解説したもの
• テストケース実装に関る情報要素： テスト対象とテスト対象の持つI/Fに関連する情報

3. 構成要素間の相互作用は？

テストフレームやテストコンテナで表現されるテストケースやテスト条件の依存関係

テスト同士に依存関係がある場合、複数のテストケースをまとめて管理/実行する必要　があります。そのため、テストコンテナやテストフレームといった単位で整理します。
こうした単位でまとめる際に、「どのような目的・利益を得たいか」を明確にすることも、テスト活動において重要なポイントです。

PART3.設計技術を磨くアイデアを考える

　PART3では、設計技術を磨くポイントとしていくつかをご紹介くださいました。

　各ポイントは以下になります。

1. 夢は大きく！
2. 設計を学ぶ際のポイント
3. 続けるのは楽しさ（そして達成感）

ひとつずつ述べて自分の感想を加えていきます。

1. 夢は大きく！

• 目指すは全自動！
  • すごく共感しました。全自動を目指していたら、もし全自動にならなかったとしても、テストの全体的なプロセスのうち大多数が自動化できるのは可能かと考えました。

• 自然言語や図のコンピューター解析技術も進歩している
  • 最近のAI技術の成長から見て私も近未来では人でしか対応できなかったテストをAIに任せられる日が来るのではないかと考えました。

2. 設計を学ぶポイント

• 設計の目的を意識する
  • 一番大事かと思います。常に目的を意識してると必要なことに早く気が付き、自ら学ぶのではないかと考えました。

• ゼロから考えることは大変なためパターンやベストプラクティスを学ぶ
  • パターンやベストプラクティスを学ぶことによって一番正解に近い設計になると考えました。加えてその数が多ければ多いほど精度はより高くなるのではないかと考えました。
    しかし、真似するだけでは成長できないのでそれらはあくまでも一例として、現場、コンテキストに合わせて使う必要があることも伝えてくれました。

3. 続けるのは楽しさ（そして達成感）

• 仲間を持つ
  • 一人ではできないことも多数では行けるので大切だと考えました。仲間自体がモチベーションになることは自分も経験したことがあり、すごく共感しました。

• 継続は力
  • 継続することにより、習慣になり、携わっていた絶対的時間が増えることで結果も残り、続けられる力になると考えました。

ワークショップ

VSTePとは？

VSTeP（Viewpoint-based Software Test Engineering Process）とはテスト技法の一つで簡単に説明すると「テストケースをざっくり考えてから具体化する方法」になります。

いきなり細かいところから考えると大きな抜け漏れが発生しやすいので、一例としてブレインストーミングのような形で出来るだけ多くの観点を出し、UMLっぽい図を用いて（わかりやすくするため）どんどん具体化していく形です。

以下はVSTePの簡単な流れとなります。

テスト要求分析（テスト観点を出す）→テストアーキテクチャ設計（テストコンテナ設計）→テストアーキテクチャ設計（テストフレーム設計）→テスト詳細設計（テストケース作成）→テスト実装 （テストスクリプト作成）

今回のワークショップでは上記の流れのうち「テスト要求分析（テスト観点を出す）」と「テストアーキテクチャ設計（テストコンテナ設計）」の部分を実際やってみました。

各ワークショップで行った活動については下で詳しく説明いたします。

ワークショップ１（テスト観点図作成）

ワークショップは4人一組で行うグループ作業でした。（私のチームは3人でした…）各チームごとにファイルボックスがあり、その中に今回行うワークショップの資料が入っていました。（ワークで使用するターゲットユーザの情報、機能設計書等）今回の対象プログラムは「アラームアプリケーション」でした。

運営の方々から「機能設計書はまず詳しく見ずに、アラームアプリケーションで必要だと考える観点をだし、後から機能設計書に合わせて対象外判定など行ってください〜」と言われました。

そこで私達のチームでは「まず各自でできるだけ観点を出して発表し合い、議論して追加すべきと考えられる観点を追加」する方法で行いました。

私は一人で考える時は「アラームアプリケーションで抜けてはいけない」点を中心に観点を作成いたしました。
（作成した観点一例：レイアウト・表示、ボタン挙動、状態遷移、画面遷移、アラーム正常起動、編集機能等）

個人作成の時間が終わり、他のチーム員と作成した観点をすり合わせてみたら…なんと重なる部分と重ならない部分で 5:5 くらいの割合でした。

ある程度自分が考えていなかった観点も出てくることも想定していましたが、自分一人では長く考えても思い浮かばなさそうな観点もあり、集合知性の力を感じました。

その後はお互いの観点とその観点を選んだ理由などを聞き、議論して追加の観点を引き出す作業をおこないました。議論することで、より多くの観点を見つけることができ、自分の視野もどんどん広くなっていくことを感じました。

最後には今まで出した観点を大きな項目で分け、対象外の観点はステッカーで表示し、ツリー構造でまとめることでワークショップ１の作業は終わりました。大きな項目で分ける時は作成した観点を最大限同じカテゴリーの観点とまとめること、大項目の考え方に注意しながら作成しました。

以下は私たちのチームで作成したワークショップ１の成果物です！

作成が終わった後5分ほどで他のチームの成果物を見ることができました。見てから考えたのは「どのチームも同じではないが納得できる、私たちのチームで出なかった観点だけど必要な観点だ」等私たちのチームの改善点、良かった点、悪かった点等をもう一度考えられる良い機会でした。

　ワークショップ２（テストコンテナ図作成）

ワークショップ２ではワークショップ１で作ったテスト観点図をもとにテストコンテナ図の作成を行いました。

テストコンテナとは？

• テストコンテナとは、テストタイプやテストサイクル、テストレベルをまとめたもの
• うまくまとめると全体像を把握しやすくなる

JaSST2015東京より

上記の説明をもとにテストコンテナ図とは、テスト観点を「テストタイプ」「テストサイクル」「テストレベル」などの分類で整理し、図として可視化したものと考えられます。

私たちのチームはワークショップ１で作成した観点をもとにテスト実行手順に沿ってテストコンテナ図を作ることにしました。「どの観点をどのタイミングで実施するか」の判断がとても難しく、議論にも大きな時間がかかりましたが、結果的にはよくまとまってるテストコンテナ図になったのではないかなーと思います。

以下は作成したテストコンテナ図です！

※テストコンテナ図で表現したテストの順序は以下です

「UI、基本機能チェック」→「アラーム作成（基本動作確認）」→「アラーム動作（アラームがなる時の動作）」→「アラーム削除→アラーム動作（アラーム削除後の動作）」→「アラーム編集、詳細設定」→「アラーム動作（詳細設定されたアラームの動作）」→「性能（アプリの性能）」→「異常系」→「アプリ外要因」→「アラーム動作（アプリ外要因によるもの）」

今回もまた他のチームの成果物を拝見できる機会があり、見させていただきました。感想は以下になります。

• 意外とコンテナが少ないチームもある
• 私たちのチームは機能的な面を中心に作成したが、非機能のテスト観点を含んでいるチームもあった
• やっぱりチームによって分類の仕方が大きく異なる。でも全部納得できる。

気づいた点、今後活かせると考えられるポイント

気づいた点

今回のJaSST2025東北を通じて気づいた点は大きく分けて3点あります。

1. テスト設計が必要な理由の明確化
2. 複数人でテスト設計を行う時の利点、コミュニケーションの重要性
3. 私が属しているチーム以外の成果物から得た気づき

まずは１の「テスト設計が必要な理由の明確化」です。いままで漠然と「テスト設計は必要」だと考えていましたが、それがなぜ必要なのか、しなかった時にどのようなことが起きるのかに関して深く考えていませんでした。

しかし、今回その理由とそれにより得られる利点を明確化したことで、今後行うテスト設計の理解を深めることができました。

2の「複数人でテスト設計を行う時の利点、コミュニケーションの重要性」はワークショップでチーム活動を行い、お互いの観点、フィードバックによりどんどん成果物の完成度が上がることを目にしました。

そこで複数人の観点、良いコミュニケーションが合わさったことにより、上がる成果物の完成度は「たし算ではなく掛け算に近い」と感じました。それにより「私の観点を増やす」、「コミュニケーション能力を増やす」ことの重要性にもう一度気づきました。

3の「私が属しているテスト設計チーム以外のチームの成果物をみる利点」は成果物作成後、他のチームの成果物を見ることにより、観点の拡大を感じました。

自分の成果物を見ることが大事なのはもちろんのこと、時には他のチームの成果物を見ることもエンジニアとして成長するために大切な行動であるということにも気づきました。

今後業務で活かせると考えられるポイント

　数多くのポイントがありますが、基調講演とワークショップでいくつかを選別して説明します。

基調講演

「テスト設計の方向性、情報の位置付けと関連性」

• テスト設計の方向性
  • 設計するテストの目標をしっかり把握し、その目標にたどり着けるテストを設計することでテストの抜け漏れが発生しないようにする

• 情報の位置付けと関連性
  • 情報同士の位置付けと関連性を考えることにより、テストの網羅性を向上し、設計の一貫性と論理性の向上を得られる。

ワークショップ

「設計時のコミュニケーション、VSTePのやり方」

• 設計時のコミュニケーション
  • 自分の意見の出し方、他チーム員の意見を受容する姿勢、議論を通じた意見のすり合わせ
• VSTePのやり方
  • テスト観点の出し方、出したテスト観点の整理、テストコンテナの設定（どのような形で分けるか）

このような点を今後の業務で活かせると考えました。

おわりに

今回JaSST2025東北に参加することにより、参加されえた多数の方たちからたくさんのインサイトを得ることができ、エンジニアとして一歩成長することができたと思います。これを読まれてる皆さんもぜひ機会があれば参加してみると成長につながると思います。

長文を読んでいただき、ありがとうございました。