こんにちは！オープンロジでQAエンジニアをしています。honamin です。
2024年12月、オーティファイ株式会社でQuality Evangelistをされている末村拓也さんに弊社オープンロジで凱旋講演を行っていただきました。（末村さんは2017年〜2019年にオープンロジに在籍されていました。）本記事ではその内容と様子について紹介いたします。

開催のきっかけ

末村さんと直接お会いしたことはなかったものの、Qiitaの「我が名は神龍……どんなテストもひとつだけ自動化してやろう」 他、数々のご登壇や記事を日々拝見しており、オーティファイ社でのご活躍も存じ上げていました。私がオープンロジに入社して少し経った時に「テスト自動化実践ガイド」 をご出版され、是非オープンロジでの凱旋講演をお願いしたい！と思い、お声がけしたのが今回の凱旋講演をご依頼したきっかけです。社内でE2Eテスト自動化を再スタートさせようとしているタイミングでしたので、基本に立ち返る場としても最適だと考えていました。

当日のスライド

講演の内容

テスト自動化実践ガイドの第一部「自動テストに取り組む前に」についてのご講演をお願いしました。
ここからは末村さんにお話頂いた内容を一部ピックアップして記載していきます。

【思い出と略歴】
本編に入る前に、まずは末村さんのご経歴とテスト自動化に至ったご経験、オープンロジでの活動からAutifyへのご転職までお話いただきました。「お客様にとってはバグがある状態が一番つらい。”バグがあるから品質保証をしましょう”はストレートフォワードではない」（場合によってはバグの修正を行うことを優先した方がいい）という言葉が印象に残っています。

どのテストを自動化したいのか

「テスト」と一言で言ってもいろんなテストがある。どんなテストを自動で行い、どんなテストを手動で行うかを明確にすることが大事。何を達成するためにテストをやるのか目的ベースで考えると良い。

自動リグレッションテストの重要性

継続的な開発の中では何度もテストを行うことになる。影響範囲が確実に定められればいいが、それが難しい場合の方が多い（開発フレームワークのメジャーバージョンアップなど）。

新規機能開発を行いリリースをする際には既存機能の検証も必要となるため、開発とテストの労力は必ず不均衡になる。手動テストでは使える時間と人的リソースに限界がある場合がほとんどであり、リソースを上限とした範囲を検証することになりがち。しかし、自動テストではリソースは最小限に、自信を持ってリリースをするためのテストが実行できる上、プロダクトの変更容易性を保つまたは向上させることもできる。

手動テストと自動テストのギャップ

手動テストをそのまま自動化するとうまくいかないことが多々あるのはなぜか。それは、

• 手動テストは柔軟で発見的

  • テストケースに書いていなくても、テスト実行中の違和感に気づくことができる

• 自動テスト（従来型の）は厳密で保証的

  • 決められた実行手順で、決められたアサーションのみを確認する

という違いがあるから。
ただ、書籍執筆時点では生成AIの進化を考慮していなかった。今では生成AIによって自動テストでも発見的に不具合を発見できるようになる日も近いかもしれないと感じている。

リグレッションテストをリリース前だけで実行しているとそこで不具合が発生した時に手戻りが発生してしまう。 理想的には開発サイクルの中で不具合を発見し、修正まで終了し、開発者に自分が開発した機能の品質に自信を持ってマージしてもらいたい。 

E2Eテストとは

ユーザーと一番近い環境で実行するテストになるため、ユーザーに価値を届けられているかどうかの検証を主な目的にする。そのためエッジケースの不具合の発見などは別のテストレベルで発見するのが望ましい。

• E2Eテストの良い点

  • 幅広い用途に利用できる

  • ユーザーにとっての価値をそのままテストできる

  • 様々なレベルのテストベースが扱える

• E2Eテストの辛い点

  • 難易度が高めである

  • ブラウザ、ブラウザ自動操作、テストフレームワーク、いろんなところに不具合が発生する可能性があり、テスト対象システム自体に問題がなくても偽陽性の不具合が発生しやすい

  • 単体テストなどに比べてテスタビリティの向上に限界がある

  • テストコードが長くなりがち＝認知負荷が高くなる

Q&A

スライドに記載のある事前質問以外に当日Slidoを利用した質問を行ったため、その中から抜粋して記載します。

Q：本の出版後、表記や書き直したい点はありますか。
A：生成AI。LLMやAIのテストについての話も入れたかった。

Q：Web APIプロダクトをE2Eテストしたい場合、ブラウザテストとの相違点があれば教えてください。実装についてはAPIの方が簡単そうですが、逆に難しくなる観点などはありますか？
A：難しくなる観点はないと思っている。考え方が違う点としては、APIなので仕様はきっちり決まっているはず。APIの定義がしっかりしていないと誰も使ってくれない（実際に試さないと使えない）プロダクトになってしまう。定義とリクエスト例（リクエストはそのままテストにできるもの）を公開すること。

Q：プロダクトが対象とする業種・ドメインによってE2Eテストの考え方や実装方法に違いがでたりしますか。
A：違いはかなりある。例えばECサイトはユーザーの通る導線がとても多く、難しい。GoogleのAdから入ったり、関連する商品から入ってきたりと、リグレッションテストしなければいけない箇所が多い。

Q：脆弱性診断の自動テストツールもありますが、これはQAの範疇に入るでしょうか。それともセキュリティ専門の部署などで扱うべきでしょうか。
A：どちらでもいいと思う。脆弱性（セキュリティ）自体は品質特性の一つなので、会社の誰かが責務を持ち、かつお客様に迷惑をかけていない状況を担保するのが大事。ただし、それぞれの品質特性を狩野モデルのどこに当てはめ、会社にとって重要なものなのかどうかを考えるのは間違いなくQAの仕事。

開催してみて

末村さんのテスト自動化についての知見の深さもさることながら、品質保証を通して常にユーザーと向き合っている実直さも参加した皆さんに伝わる会になったと思います。QAチームメンバーだけではなく、エンジニア、SREのメンバーも参加してくれたり、数年ぶりに末村さんと再会するQAチームの同僚や社内メンバーもいたりと、皆さんが楽しそうにお話している姿をみて、私もとてもハッピーな気持ちになりました。またいつでも遊びに来ていただきたいです！末村さん、ありがとうございました！

We're Hiring!

一緒にテスト自動化を推進してくださる方をお待ちしています！これから2、3年かけてテスト自動化の運用体制を構築したり、ガツガツテスト実装していきます！間違いなく今が一番楽しい時期です！

herp.careers QA（テスト自動化）

株式会社オープンロジ

募集要項をみる