こんにちは。bun913と申します。
みなさんは Tokyo Test Festというイベントをご存知でしょうか？
テスト関連のイベントといえば、JaSSTというシンポジウムが有名ですが、 Tokyo Test Fest は昨年度から始まった年に1回の大規模なテストカンファレンスです。
こちらは同時通訳がついており、日本語・英語の両方で楽しめるのですが、私は昨年参加した際に「来年は絶対に英語で聞けるようにするぞ」という目標を密かに立てていました。
結論から言えば英語でほとんどの講演を聞くことができたのですが、内容も AI・アクセシビリティ・自動運転周りのテスト自動化の実践など多岐に渡り、非常に有意義な時間を過ごすことができました。
個人的にはQAエンジニアに限らず、開発者の方も非常に楽しめる内容だと感じたのですが、その中でも特に印象に残った講演について、簡単に紹介したいと思います。
Tokyo Test Fest の素敵な配慮
ここまでのお話や Tokyo Test Fest のウェブサイトを見て、「英語での参加がメインなのかな？」と感じた方もいるかもしれません。
確かに国外からの出席者やスピーカーも多いのですが、以下の参加者カードの写真をご覧ください。
それぞれ赤と緑のシールが貼られていますが、どちらかの色が「日本語で話します」「英語で話します」という意思表示になっていたと思います。（私は両方で話す気持ちなので、両方のシールを貼っていました）
冒頭に記載したように同時通訳のためのトランシーバーも貸し出されており、英語が苦手な方でも安心して参加できるように配慮されています。
「国籍や言語に関係なく、Tokyoでテストについて語ってみんなで楽しもう！」というようなメッセージを強く感じました。
基調講演 森崎 修司 さん テストや文化の多様性での気づきをうまく使ったQAの効率化とプロダクト価値向上
森崎さんから「誰に、いつ、どこでQA的な洞察を提供するか？」というテーマでお話しいただきました。
講演内容
ユーザーエクスペリエンスはコンテキストによっても変わってきます。例えばスマホアプリの天気予報機能で音声認識を使う場合、満員電車の中で実行されるのと静かな場所で実行されるのでは正確性に影響が出てきます。車の運転中では指で操作できないので、より音声認識の精度が重要になってきます。
開発だけ・要件だけではユーザーの体験や受け取る価値が決まるわけではなく、そのようなコンテキストも含めたQA的な洞察をどこで、いつ、誰に提供するかが重要になってきます。
バグが埋め込まれる前に見つけるのが prevention（シフトレフト）、埋め込まれた後に見つけるのが detection（シフトライト）とのことでした。
- prevention
- 仕様やコードの曖昧さを事前にレビューで見つける
- detection
- テストケースにそれを入れて、境界値を試す
本来2つ以上のアプローチを選べますが、全部はできません。何を基準にQAアプローチを選択するかが重要になってくるとのことでした。
感想
私自身もSDETとして、APIレイヤーでのリグレッションテストの自動化などに取り組んでいますし、極力コードレビューなども取り入れていますが、全部はできません。結局、組織の今の課題に合っている、一番役に立つだろうと考える中で、自分にできることを選択しています。できないことは仲間に任せるようお願いしたりしています。
SDETとして色々な情報を知りながら、適切な選択をできるように選択肢を広げないといけないなと思いました。
ノーコードAIテスト自動化のはずが、結局たくさんコードを書くハメに
講演内容
AIはどうやって答えを知っているのか。学習データで鍛えられているため、トレーニングしていないことはわかりませんよね。アプリのアサーションの仕方や、アプリ特有の知識などは当然わからないわけです。
プロンプト一つにもコンテキストが必要ですが、当然コンテキストが大きいほど待ち時間も、コストもかかってきます。コンテキストが少ないジョブは当然早いし、向いています。
良いコメントを書いておくのは自分のためだけでなく、開発、そしてAIのためにもなるとのことでした。見なきゃいけないコンテキストが減るからです。
Augmented Code Generation という考え方があり、お手本になるコードを用意しておいて、それを参照させて良いコードを生成させるそうです。シンプルなタスク、かつコンテキストが少なくて済むようにタスクを与えることが重要とのことでした。
AI Code レビューにも具体的かつシンプルに知らせることが大切で、例えば data-test-id を使うなどのルールを明確にするとのことです。AIを Replicator として使うには、最初に良いコードをちゃんと書けないといけないとのことでした。
感想
AIに全てを任せることは逆にコストがかかります。小さく、適切に最小限のコンテキストを渡してシンプルな形で作業をさせることが結局重要だと受け取りました。難しい形や大きい形で渡すことで逆に手戻りが大きくなります。
これは実践でも感じていることで、MCPなどを使って単にコンテキストを渡すだけでなく小さくドキュメントを与えたり、コードのコメントで済むところはそれだけで済むような作りにした方がいいなと思っていたので、まさにその通りだと思って頷きながら聞いていました。
テストをチームスポーツに：バグバッシュで実現する高品質ソフトウェア開発
講演内容
品質にはいろんな側面があり、一人一人が違う品質の観点を持っていますよね。要求を満たしているか、使いやすさ、信頼性などです。
バグバッシュとは、たくさんのバグを限られた時間でみんなで協力して見つけるイベントとのことです。メジャーリリースの前によく実行されるそうで、たくさんのバグを見つけられるだけでなく、いろんな人の観点からのフィードバックを得られるとのことでした。
バグバッシュは3つのフェーズで構成されるそうです。
Pre bug bash では、モデレーター、環境を作る Stager、参加者などの役割を定義するとのことです。事前ミーティングでモデレーターが機能の説明をしたり、期待値を揃えたり、範囲を決めたりするそうです。JIRAなどのバグマネジメントツールもセットアップしておくとのことでした。
Bug bash では、Briefing 10分でスコープを説明し、60分間参加者にバグを見つけてもらうことに集中してもらい、Debrief 20分でそれぞれの参加者に見つけたバグを共有してもらうそうです。
Post bug bash では、フィードバックを参加者からもらい、バグの優先付けを行うとのことです。Bug Hunter、The Best Bug、Hawk Eye、Oracle などの優勝者を決めるそうです。
Gamification の手法として、実際に使えるポイントなどを用意してゲーム化することも紹介されていました。
感想
今私は、どのタイミングでどのサイズのリリースに対してバグバッシュを行うといった定義をできていません。ですが、多くのステークホルダーを集めて1時間程度で行い、いろんな観点で行うバグバッシュは教育やバグ出しの観点でも効率も良いと言えるかもしれません。個人的にいろんな人の観点を見れるので、自分の成長にも良さそうです。
また、この発表の中ではバグバッシュで出たバグに応じて賞を決めたりして、本当に実際の買い物に使えるような形でゲーミング化する手法を紹介されていて、シンプルにみんなを巻き込むにあたって「楽しい」は重要なので非常に参考になりました。AWSのゲームデーなどもそうですが、遊んで競って学ぶって楽しいですよね。
LT: Creating a Comprehensive Accessibility Test Plan
講演内容
A11y（アクセシビリティ）は単にコンプライアンスの問題ではなく、誰にでも使いやすくするためのものとのことです。アクセシビリティはチェックリストではなく実際の人に向けられるものとのことでした。
（私などは静的解析でまずはチェックから始めようという考え方をしていたので、非常にハッとさせられました）
スピーカーは繰り返し、アクセシビリティは単に非機能の面ではなく機能面を含むと言っていました。この点について、ぜひ資料が公開された際に見ていただきたいです（まだ見つけられていません）。
講演後の質問と感想
講演終了後に「アクセシビリティについて知識がない場合、どこから始めたら良いか」とお聞きすると、WCAG について紹介されました。
また、ステークホルダーのジョブロールによる役割などが定義されているので、そこから理解すると良いとアドバイスをいただけました。
私はつい、非機能と言い訳してしまいがちですが、そもそもその前提も違うかもしれないと見直して、理解が必要だと思い直しました。
E2E Tests For Autonomous driving software with AWS
講演内容
Autoware Open Source Software を提供するチーム側の取り組みについてのお話でした。
自動運転に関わるソフトウェアに関するもので、確かにそこを聞くだけでもテストの重要性や難しさが伝わってきます。
おそらくこのあたりのOSSの話になるかと思います。
課題としては、基本となるOSSと、そこからフォークされた（たとえば）バス用のOSSなど、複雑に絡み合ったものをどのようにテストするかという点だったそうです。手動でテストをするのが大変で、環境を作るのも当然大変という状況とのことでした。
解決策として、Evaluator を作り、EC2のゴールデンイメージ（コンテナイメージかもしれません）を作っておいて、それを GitHub Actions から呼び出して実行するというアプローチを取られていたそうです。
感想
スピーカーもおっしゃっていましたが、テスト自動化を構築するという意味だと、ついPlaywrightなどを利用してテストをするということを考えがちですが、業界やプロダクトによってテストのアプローチや作るべき基盤が違うと思います。
私も個人的にメールやSlack通知などのユーザーへのフィードバックを起点に、テストをする基盤の必要性を感じてテスト基盤を作成したことがあります。
SDET として開発だけでなく、AWSなどの基盤系の知識は引き続き仕入れて、色々な観点で自分も楽しみながらテストの自動化でも楽しめる領域がたくさんありそうだと改めて感じました。
バグを超えて：チャットボットを効果的にテストするには
講演内容
従来のテストが機能しない理由として、今までのテストは基本1つのインプットに対して、1つの正しい挙動があったという点が挙げられていました。
この講演では ChatGPT のようなチャットボットをテストするにあたって、どのように考え方を変えるべきかが紹介されていました。
QA mindset shift として、we test reasoning, not just rules という考え方が紹介されていました。単に機能性だけじゃなくて、真実を保証しないといけないとのことです。AI時代にもクオリティを引っ張る必要があるとのことでした。
感想
よく言われることですが、AIが関わらないようなソフトウェアだと一つの入力に対して決まったことが返ってくるということを検証していました。しかしAIであればそれが適用できないので、何を持って「OK」とするかも含めて、どのように決めていくかは重要ですよね。
その中でも「ルールを検証するのではなく」「（たとえば機能が満たしたい背景などに基づいて）こういう出力が出たが、このような理由なので良い」といった観点をより強く持つ必要があると感じました。
最後のキーノート Be a Better Test Friend（より良いテスト仲間になる）
こちらはすでに資料を公開してくださっているので、私の思う内容は読み飛ばしていただいても良いかもしれません。
講演内容
QAは Critic（批判者）ではなく、Editor（編集者）のように協力する立場であるべきとのことです。Friends don't use Jira to communicate という言葉が印象的でした。
QAはある意味孤独な仕事で、Goalkeeper（最後の砦）のように思われがちですが、Holistic Quality Mindset が重要とのことです。When the quality is shared, we share the burden as well as the success という考え方が紹介されていました。
全体でできることは色々ありますが、チームにいろんな人がいるから全部自分でする必要はないとのことでした。コードレビューは開発者がしているし、ユーザビリティを考えるデザイナーもいます。
Product Owners、UX、Developers、Operations といった友達のように協力することで、Build the right thing、Build the thing right、Proof といったQAのプロセス全体を支えることができるとのことでした。
それぞれのロールとの協力関係の詳細は資料をご覧ください。
感想
スピーカーはこの話は「私と友人のストーリーだ」とおっしゃっていました。
私自身のチーム内での協力関係を見ると、開発者に対しては同じような協力ができていると感じていますが、逆に距離の遠いロールもあります。SREやデザイナーなどの品質に関わる方と協力することはありますが、実際のオペレーションに関わる方やビジネス側との（個人的な）協力が弱い部分もあると思います。
そこに友人を増やすことで、もっとより良いプロダクトの力になれるなと改めて思いました。
個人的な感想
私は昨年よりグローバル化を推進中のマネーフォワードで働いているのですが、昨年 Tokyo Test Fest に参加した際には同時通訳を利用してほとんどの講演を聞いていました。
もちろんそれでも非常に有意義な時間を過ごすことができたのですが、どうせなら質問も気後れせずに英語でしたいし、アフターパーティーでも英語でもっと話せるようになりたいと思い、今年は英語でほとんどの講演を聞くことにチャレンジしました。
個人的なチャレンジとして、それは満足いくものでしたし、内容も非常に有意義でした。
今回は講演の内容の一部にとどまる形での紹介となりましたが、ぜひ来年以降も Tokyo Test Fest が続いていき、より多くの方に参加していただければと思います。そして私もまた参加したいと思いますし、発表の方にもチャレンジできればと思います。
以上、最後までお読みいただき、ありがとうございました。
Discussion