QAエンジニアがSoutherを使ってみたの〜10分でわかるSouther〜

JaSST nano vol.56（https://jasst-nano.connpass.com/event/406998/）で発表したSoutherの紹介資料です。

Transcript

1. QAエンジニアが Southerを触ってみたの 10分でわかるSouther リリカル
2. Southerとは？ JVM 上で動く、Java と組み合わせて使えるプログラミング言語 小さな言語 Java から使える 作者: kawasima さん 業務のデータと、業務上の振る舞い 書いたモデルから Java の型が生成 OSS として GitHub で公開 を書くことに特化 され、既存の Java と一緒に動く （souther-lang/souther） では、なぜ QA やテスターのいるところで プログラミング言語の話をするのか？ JaSST nano · 2 / 8
3. Southerが問題にしていること 一般的なテスト設計の流れ 仕様書などのテストベース 作者 kawasima さんの問題提起（※ 私の理解です） 本来、設計者が行うべきモデリングを、QA や テスターに代行してもらっているのではないか テスト分析 テスト設計モデルを作る 状態遷移表 ・ デシジョンテーブル ・ その他 • 状態遷移表やデシジョンテーブルは、仕様を整理したモデル • それを後工程の QA が作って初めて「未定義の遷移」や「抜けて いる条件」が見つかる、という状態は、設計の段階でモデルが ↑ここは、業務の「モデリング」そのもの 無かったということでは？ → 後から QA がモデルを作るのではなく、開発側が最初から きちんとモデルを作るところから始めるべきではないか テストケース ※ kawasima さんの発言を私の理解で要約したものであり、原文の引用ではありません • これが Souther の出発点 JaSST nano · 3 / 8
4. Souther の基本的な考え方 よくある順番 Souther の順番 仕様書を書く モデルを作る 業務のデータ・条件・振る舞いを言語で書く compile 実装する 書き方の矛盾は、ここで止まる 問題があれば モデルを直す example で検証する 具体例で、モデルの答えを確かめる 後からテストする そのモデルをもとに実装する 問題は、実装した後に見つかる ここまで、実装前 まずモデルを作り、そのモデルが正しいかを検証してから実装する JaSST nano · 4 / 8
5. モデルが正しいかどうかをどう確認するのか モデル全体に対して 具体例に対して 「このモデル全体は正しいですか？」 「10 万円なら承認される？」 「10 万 1 円なら却下される？」 → 判断が難しい → 判断しやすい 業務の人に聞いても、設計者に聞いても、 入力と期待結果の組なら、業務の人も即答できる。 「たぶん合ってる」以上の答えは出にくい テスターが普段やっている確認と同じ Souther では、この具体例を example としてモデルに添えて、モデルを検証する 期待と違う答えが出る場合、コンパイルが通らない ※ 実例マッピング（Example Mapping）に少し近い感覚かなと思います。同じものではありませんが JaSST nano · 5 / 8
6. Southerを使ったシフトレフト 一般的なイメージ Souther モデル 実装 compile / example テスト 問題発見 コンパイルエラーは、実行より前の検証 • コードを書いたとき、型の誤りが コンパイル時に見つかる • 検証が実行より前にある Souther は、その検証対象を業務モデル まで前に持ってくる • 型の誤りだけでなく「10 万 1 円は 却下」のような業務上の答えまで、 コンパイル時に確かめることができる 問題発見 実装 問題発見は、実装の後 問題発見は、実装の前 モデルを作り、モデルを検証し、問題があれば実装前にモデルを直す JaSST nano · 6 / 8
7. テスト設計もモデルから導ける Model に書いてあることを読む • 型の場合分け、guard の比較、invariant の境界を読む • 何も書いていない位置（条件のない Int など）は分割せずに「導出できない」と報告する 同値クラス・境界・分岐に分解する 「10 万円以下なら受理」→ 10 万円 / 10 万 1 円と、内側・外側の代表値の計 4 つを確認対象にする examples が足りない場所を報告する 「上限を超えた側のexampleがない」「却下になるパターンがない」のように、どの観点が未確認かを一覧 にする QA の目で見ると やっていることは、境界値分析（ON / OFF / IN / OUT ）・同値分割・分岐網羅・2 クラスの組合せ • QAやテスターが仕様書から手で起こしている 観点を、モデルから機械的に出している （Southerがテスト設計技法を内蔵している） 「全部が Souther で完結する」わけではない • 導けるのは、モデルに書いてある範囲だけ • 書いていない位置は「導出できない」と返す • 業務知識、非機能、画面や連携の観点は、 今まで通り人が設計する example が足りない場所は雛形だけ作る • 入力値だけが入った行を出し、期待結果は空欄のまま。 期待結果は人間が埋める • Southerで答えを創作しない テスト設計漏れや実装誤りを後工程で人が補うのではなく、そもそもモデルをきちんと作る Source: souther-lang/souther の souther-compiler（partition/*, Adequacy, GeneratedRows）と souther-cli の実装を読んで要約（2026-10-20） JaSST nano · 7 / 8
8. QAとして実際に使ってみた 3 通りの使い方を試してみた △ テスト設計 あまり差がなかった 人が設計するのと Souther を使うので、そこまで大きな差は感じなかった △ コードレビュー 微妙だった Souther ならではの追加発見は、あまりなかった ◎ 設計レビュー 一番良かった 設計を Souther でモデル化しようとすると、曖昧さや未定義が表面化した。 「仕様書から状態遷移表を書いてみたら未定義の遷移が見つかる」のと同じ効果 結論: 誰に使ってほしいか 第一候補 開発エンジニアに使ってほしい 最初から Souther でモデルを作り、実装前に検証できるから ぜひ使ってみてください ※ 私が実際に試した範囲での所感です 第二候補 QA・テスターが設計レビューで使う 設計をモデルに落とすことで、曖昧さや不整合を見つけやすい 興味があれば “Souther” で検索 GitHub: souther-lang/souther JaSST nano · 8 / 8