はじめに
開発本部所属の塚山です。普段は広告配信システムの開発やQAチームの立ち上げを行っています。テストの自動化が大好きで、熱心に取り組んでいます！最近はどんどんAI周りの技術革新が進んできて、ついていくので精一杯です(泣)、、、
3月末に開催されたJaSST'25 Tokyoに参加しました。開催から時間が経ってしまいましたが、録画を見返しながらいくつか気になったセッションについてまとめて感想を書きます。
JaSSTについて
NPO法人ASTER （ソフトウェアテスト技術振興協会）が運営しているボランティアベースのソフトウェアテストのシンポジウムです。JaSST Tokyoだけではなく、TohokuやKansai等の各地で開催されています。オンラインでの配信もあり、録画に関しては参加者に公開できる範囲で共有されます。事前申請が必要ですが、懇親会や初心者向けのワークショップもあったりします。
振り返り
チーム全員で品質課題の改善のために取り組んだことを振り返る
専属QAエンジニア不在の中、チーム一丸となって改善活動に取り組んだお話
- 品質ナラティブ
- 企業で品質について考えたり話したりしている「語られ方」そのもののこと
- 責任ナラティブ
- 誰が品質に責任を持つか考えられている
- テストナラティブ
- 品質向上につながるテスト技法は何か・どんなツールを使うべきか考えられている
- 価値ナラティブ
- 品質に投資した場合の利益（価値）に関して考えられている
- 取り組んだこと
- 品質ナラティブを用いて現状を把握する
- 自分たちのチームにあった方法を考える
- テスト分析・設計を用いて影響範囲の考慮漏れを無くす
- 大切にしたい価値観を完成の定義とする
こちらのセッションではLeading Qualityの品質ナラティブをしっかりチームの活動方針に落とし込んでいて、とても参考になりました。特に各ナラティブをそれぞれ言語化して、理由まで書いていて非常に理想的な例だと思いました。自分も本は読んだのですが、なかなか実務に活かせていませんでした、、、これを機に上記を参考にして、Leading Qualityの読書会を行なって活動方針を定めようと計画しています。また最後の「自分の考えを伝えることから始めよう」という言葉に心を打たれました。自分も熱意を持ってプロダクトをより良くするために、色々な人を巻き込んで改善していくつもりです！
なぜ人はE2E自動テストの継続に失敗するのか
ここ10年で出てきたサービス・ツールによってE2Eテストの導入障壁は下がったが、うまくいかないパターンもある。それらのパターンに関するお話
- 継続に失敗する要因
- 技術的な課題が解けない（現在ではサービス・ツールの充実によって、解消できそう）
- テストの目的が定まっていない
- 目指す方向性と手段のミスマッチ
- テストに対する「なぜ」が曖昧
- 継続に成功した要因
- E2Eテスト専属エンジニアのポジションを設ける
- 開発チームに責務を移譲する
- 開発者がテストケースの作成と実行の責任を負い、QAエンジニアは作成されたケースのレビューを行うという明確な役割分担をする
「テストの目的が定まっていない」というお話を聞いて、ギクッとしました。自分もしっかり目標を定めて定期的に振り返ることを習慣にしようと決心しました。E2Eテスト専属エンジニアポジションを設けることに関して、まさに自分が行なっていることと内容が似ていました。普段の開発と並行してテストの実行環境を整えるのはかなり難しいです。そのため専任者を用意することはテスト自動化を進める上で大切です。実体験ですが、こちらのセッションを参考に自分が専任者としてプロジェクトに入って自動化を進めた結果、自動テスト基盤を構築することができました。またシフトレフトをしっかり行うということも、バグの早期発見という観点から大切なことだと改めて思いました。
開発者主導の自動テスト導入によるバグ早期発見
受け入れ基準・受け入れテストの作成によって、シフトレフトを実現するお話
- 受け入れ基準を作ることで仕様を明確に把握する
- 受け入れ基準を受け入れテストとして自動テスト化する
- 受け入れテストを開発・テストフェーズで実行する
受け入れテストと言えばV字モデルの一番最後に行うものだと認識していたのですが、こちらの事例では開発フェーズよりも前に受け入れ基準・テストを作成し、開発・テストフェーズに実行しているようです。シフトレフトを実現する上でとても有効な手法だと思いました。またこちらのセッションでPlaywrightのBDDライブラリの存在を初めて知りました。Gherkin記法は以前から知ってはいたのですが、普段のテストに活かすことができていませんでした。その点を反省して、最近はテストコードのテスト名に下記のように書くことを意識しています。（自己流のやり方です）
// Given When Then
it("ある条件の場合、ボタンを押した時、特定の画面に遷移する", () => {});
他のセッションでも言及されていますが、意識しないとテストコードは可読性が低くなりがちなので、Given When Thenのような手法で読み手にできるだけ情報を与えるようにすると認知的負荷が下がって保守性が向上するのではないかと思います。特にテストコードをAIに生成させる場面が増えていく中で、コードを読むことやテスト結果を確認するという作業は残り続けるはずなので、より可読性を高める意義があると考えています。またテスト名に一貫性を持たせるためにチームで相談してルールを定める必要もありますね。
リーダブルテストコード 〜メンテナンスしやすいテストコードを作成する方法を考える〜
読みやすさやメンテナンスしやすいテストコードに関するお話
テストコードの認知的負荷
- アンチパターン
- 情報量が少なすぎるテスト
- 情報量が多すぎるテスト
- テストを理解するのに必要な情報を過不足なく含んだテストを書くべし
前述した通り自分もテストコードの情報量にこだわって作成しています。適切なテスト名をつけたり、よく使うケースを関数としてまとめたりしています。情報過多のケースではアサーションが複数並んでしまうことがあるので、注意しないといけないですね。その場合はそれらのアサーションを複数のテストコードに分割して書くと良くなるはずです。それでも不安な場合はチームで適切な情報量に関して議論するともっと良くなるかもしれませんね。
コンテキストを明示してテストコードを自己説明的にしよう
- テストコードの中に暗黙のコンテキストが存在すると認知的負荷が高くなってしまう
- Utilityの中にコンテキストを含めて、明示的に表現しよう
よく使うログインのUtilityを作成していたので内容を理解しやすかったです。Utilityの引数に残りの処理を渡してコンテキストを表現する手法は鮮やかだなと感じました。自分も今度からテストコードに取り入れます！
テストコードにはテストの意図を込めよう
- リーダブルなテストコードは変更容易性を高める
- 開発者にヒアリングして上手くテストの意図をテストコードに込める
- テストの意図をテストメソッド名に書くことの利点
- 特別な設定値がどれかわかる
- 仕様変更時に対応しやすい
テストの意図がしっかりと伝わるテスト名をテストコードに落とし込むことが必要だなと考えています。特に一度作成されたテストコードは長期間に渡って保守されるはずなので、テストの意図が適切に表現されていると、属人化せずに複数人で保守できるなと思いました。
まとめ
ここまで規模の大きなQAイベントはなかなか無いので、貴重な経験でした。
これらの知見を日々の業務やチームの活動に活かしていきたいと思います。
JaSST Tokyoは来年もっと大きな会場で開催されるようですね。
どんどんパワーアップしていくJaSSTにぜひ参加してみてください！
▼採用情報
レアゾン・ホールディングスは、「世界一の企業へ」というビジョンを掲げ、「新しい"当たり前"を作り続ける」というミッションを推進しています。
現在、エンジニア採用を積極的に行っておりますので、ご興味をお持ちいただけましたら、ぜひ下記リンクからご応募ください。