Studyplus Engineering Blog

スタディプラスの開発者が発信するブログ

JaSST’23 Tokyoに参加しました

こんにちは。QAエンジニアの森長です。

前回のブログ執筆時点ではサーバーサイドエンジニアでしたが、最近QAエンジニアにジョブチェンジしました。

3月9日(木)~10日(金)で開催されたJaSST’23 Tokyoに視聴者として参加しました。

弊社QAチームは立ち上がったばかりなこと、私自身QAエンジニアになったばかりなことから、他社での取り組みを知りたく視聴しました。

JaSST’23 Tokyoとは?

JaSST Tokyoは、ソフトウェアテスト分野のシンポジウムです。ソフトウェアテストやソフトウェアの品質に関心を持つ人々が情報を発信したり学びを得たり、参加者同士で交流ができる場となっています。

今年はオンラインで、2023年3月9日(木)~10日(金)の2日間、開催されました。

公式HP:https://jasst.jp/symposium/jasst23tokyo.html

感想

2日間で9セッション視聴した中で特に印象に残ったセッションを4つご紹介します。

Chaos Engineering to Continuous Verification

Netflixのカオスエンジニアリングチームのエンジニアリングマネージャーを務めていたCasey Rosenthal氏による基調講演でした。複雑なシステムに対してどのように安全性を担保していくべきかといった内容が話されました。

特に講演の最後に話された”Don’t fight complexity. Navigate it.”という言葉が非常に印象に残っています。

直訳すると「複雑性と闘うな、複雑性を操縦しろ」ですが、複雑なシステムを無理に簡素化したりシステムの全てを把握したりするのは不可能なので、抗うのではなくうまく対応しろということかなと解釈しました。

想定できないことに気づくために、Chaos Engineeringのような手段で意図的に障害を発生させる検証を継続的に行うことが重要なのだと改めて感じました。

弊社もいくつかのマイクロサービスで構成されており、ある箇所で障害が起きた際の影響を全ては予測できていないので、実験的に障害を起こすことで新しい気づきを得られるようにしていきたいなと思いました。

「テストプロセス、プロダクト品質評価のための実用的なODC分析とCATによる管理方法」

本セッションは品質評価に関するセッションで、ODC分析という欠陥分析手法の説明と実際に現場で活用していく際に使えるツールの説明が行われました。テストプロセスやプロダクト品質の分析をしていきたいという話を弊社QAチーム内でしていたので参考になる部分があるかと思い参加しました。

ODC分析は、RCA分析と統計分析のいいとこ取りをしたもので、障害を属性ごとに分類することで効率よく原因や傾向を分析できる手法です。属性は、例えば、発生トリガー(=どんなテストで発生したのか)や障害タイプ(どのようにバグが実装されたのか)などがあります。

弊社では障害を品質特性で分類し分析していこうとしており、ラベリングして分析する点ではODC分析と似ている部分があります。 様々な分析手法がある中で分類による分析のメリットを知れ、自分達の取り組みの方向性に自信が持てたのでよかったです。

弊社での分析作業の流れは、Qaseというツールでテスト実行結果を記録→障害があればmondayというプロジェクト管理ツールでチケットを切って報告→スプレッドシートに障害を一覧化し分類・分析、という流れで行ってます。現状3つのツールを使っているので、今後管理方法をシンプルにしていきたいなと本講演を聞いて思いました。

「ローカル環境を用いたアジャイルテスティングの実践事例~より高速なフィードバックを目指して~」

アジャイル開発におけるテストに関するセッションでした。弊社はアジャイル開発をおこなっておりその中でQAのプロセスをどう取り入れるか課題に感じていたので参加しました。

講演を行ったfreeeさんでは、開発がキリがいいところまで実装できたらQAがローカル環境に自ら反映して、検証環境での通しテストの前にこまめにテストをおこなっているそうです。 これによって、通しテストの前に全体の50%のバグが見つけられたそうです。

弊社では全ての開発が完了した後にまとめてテストをしています。freeeさんのような取り組みができれば開発してから日が経つ前にバグ報告可能になり、開発者の記憶が新しいうちに修正ができ良さそうです。

一方で、開発エンジニア的に都合がいい開発順序とQAエンジニア的に都合がいい開発順序が異なるのでは?と思うところもあります。 ローカル環境でのテストを本格的に導入したいとなった場合、この辺りの認識を開発エンジニアとすり合わせていくことが重要だなと感じました。

「テストの設計意図を届けよう2023~テストしたいことを、よりスマートに伝えるための第一歩テスト設計コンテストU-30セッション -」

テスト設計に関するセッションでした。日々テスト設計レビューで大量の指摘をいただいてる状態なので、少しでも良いテスト設計をしたいと思い参加しました。

テスト観点の広げ方として、テスト対象の構図を見せる(=特定の着眼点に基づいて、状態遷移図、画面遷移図、IPOなどで図として表す)などすぐにでも使える様々なテクニックが紹介されました。仕様書をなぞっただけのテスト設計をしがちなので、こういった小さなテクニックから始めて観点を広げていきたいと思いました。

まとめ

初めての参加でしたが非常に濃い時間を過ごせました。

どのセッションでも登壇者が一方的に話すのではなく、視聴者がリアルタイムでDiscordに感想や疑問を書いていく形式だったので、理解が深まったりお祭り的な雰囲気で楽しかったです。

テスト観点の広げ方や分析の手法など、今日から使えるテクニックを学べたので早速日々の業務で活用していきたいと思いました。

一方で手法を学んだり観点を広げるだけでなく、互いの違いを理解し周囲(開発者やPOなど)をうまく巻き込んでいくことが品質向上のために重要であることを、全セッションを通して改めて感じました。

今後は社内でのQA啓蒙活動にも力を入れ、チームのプロセス改善に全員が前向きに参加できる環境を作ってきたいです。改善をおこなっていく中で、最終的に皆の仕事が少しでも楽になる手助けをしていきたいと思いました。

以上、JaSST’23 Tokyoの感想でした。