テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践 に対する速報感想 #長崎QDG

本日はこちらの8th長崎QDGに参加しています。この記事ではその中の「テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践」というセッションについての考え方について自分なりの速報感想を書いています！

少なくともこの記事発表時点では、発表資料の公表を確認できなかったのでもし公開を確認できたら、そちらへのリンクも貼りたいと思います。

(追記) 資料を公開いただいたので、リンクを追記します！

https://speakerdeck.com/ropqa/test-architecture-design-in-practice

「実践」という名のとおり、思ったよりソフトウェア設計よりの話が多い！すごい！

私は長崎QDGというものに初めて参加するのですが、勝手に「どちらかというソフトウェアテスト技術」に関する内容やQAエンジニアの方向けのトピックが多いのかなと勝手に思っていたのですが、こちらのセッションはかなりソフトウェア設計に近い人に刺さる内容でした。

この発表のテーマとしてもっとも大事なキーワードが「重篤度」と「テストサイズ」の分類を利用して、テストの優先度（リグレッションテストの優先度）を構造的に整理していくという内容でした。

ここからは私の拙い理解のもとで（迷惑にならないであろう）内容を書いております。

• まず前提として、発表者のチーム（組織？）ではクリーンアーキテクチャなどを利用されている
  • モジュールによって、ドメイン層、アプリケーション層などが分けられているというくらいのざっくりとした認識をしています
• その中でテスト対象のシステムを
  • ドメインに分けて考える
  • ユーザー視点で観測可能な振る舞いで考えてフィーチャーを特定
  • さらにフィーチャーを分解して論理的な機能構造アイテムを特定
  • というように、木構造でブレイクダウンをしながらテスト対象を考えていく
• その過程で重篤度分類により効果的なテストスイートを導出する
  • 組織によって、マーケットで見つけたバグの影響度などをレベル別に定義されていることがありますよね
    • Critical: サービスが全面的に利用できなくなるレベル
    • Major: サービスの根幹に値する重要サービスが利用できなくなるレベル
    • Minor: 機能には影響しないが画面の崩れなどユーザーの操作性に微細な影響を与えるレベル
• テストサイズ分類による効率的なテストスイートを導出する
  • 以下のような書籍で紹介されているテストサイズの分類とほぼ合致している考えだと思います
  • 機能サイズにしたがって、例えばユニットテストで何をどのようにテストするのが責務かということも整理できる考え方だと思います（その他サイズごとの比率をどうするかなどの議論も活発ですよね）
    • 本筋とはそれますが、t-wadaさんもよく言及されていますよね
    • 例: https://logmi.jp/main/technology/330972
• 取り組みの結果も数値もつけて示してくださいました

というようにかなりロジカルかつ、組織課題にフィットしたテストアーキテクチャ設計の実践をされていると感じました。

https://bookplus.nikkei.com/atcl/catalog/13/P85120/

感想のまとめ

• 発表者に対する感想
  • 非常にロジカルながらも、丁寧にゆっくり説明してくださり、普段から丁寧に言語化されている方なんだろうなぁと感じました
  • 論理的な話って眠気を感じることもあるのですが、論理構造が「抽象→具体」や「上位→下位」となっているので、とても聞きやすかったです
  • ブログ記事も書かれているのをよく観測するので、もっと見ます(強い決意)
    • https://developers.freee.co.jp/entry/freee-qa-advent-calendar2024-day23
• 発表に対する感想
  • 私は職種上 Software Development Engineer in Test という立場なので、QAEと開発者の両方の立場からの視点をもってビジネス（開発組織）に貢献していく必要があります
  • そもそも、ドメインごとにコードをきっちり分けられていて、クリーンアーキテクチャをやられていることがとてもすごいと思うんですよね
    • さらっと前提で話されていましたが、あらためてすごいということを伝えたい
  • その上で「公開している機能は全てリグレッションテストを書くのが望ましい」ということは承知の上、どのように優先度づけてやっていくか
  • どこで何を責務として、何を守るべきかという視点がそもそも持っている上で、どうテストのアーキテクチャ設計をしていくかというバックグラウンドを感じました
• 一言で言うと
  • あらゆることをなんとなくではなく、論理立ててやってる。言語化すごい。

以上、自分なりの感想となってしまいますが、とても勉強になるセッションでしたし、発表者の方の試行錯誤をここに還元してくれて本当にありがたかったです。

以上、bun913でした。