こんにちは。Sansan 事業部プロダクト開発部の奥野です。
私は中途採用で昨年11月に入社して4ヶ月ほどになる、関西支店で勤務するエンジニアです。MAIDO という開発チーム*1 に所属しています。
今回の記事では、1月に私が主催した Selenium のチーム内勉強会を起点にして始まった、E2E テスト導入に向けた動きについてレポートします。なお、E2E テスト（End to End テスト、詳細は後述）の技術的側面については深掘りせず、新しい文化の導入に主題を置きます。
Seleniumとは
まず、勉強会の題材とした Selenium について簡単に紹介します。
Selenium とは、ブラウザを使用する E2E テストを自動化するテストフレームワークです。その歴史は2004年から始まっているため*2、ご存知の方も多いかと思います。
E2E テストは、システム全体を一通り動作させて行うテストであり、機能テストや結合テストといったテストフェーズで行われます。 Web アプリケーションの場合、ユーザがブラウザ操作を起点にして、クライアント処理・サーバ処理を通して画面再描画に至る過程を最初から最後までテストします。
E2E テストはユニットテストに比べると、ビジネスや要件の観点からのテストが可能であり効果的です。
一方で、E2E テストはシステム全体を動作させるため、テストの事前条件としてDBデータを揃えておく必要があるなどのセットアップが大変、テストに時間がかかるというデメリットがあります。
なぜ E2E テストをチームに導入しようと思ったか
Sansan はリリースしてから10年以上経過しているプロダクトであり、いわゆるレガシーシステムです。
仕様や設計が複雑化しており、仕様を把握するのも、テストをするのも大変です。少なからず技術的負債も蓄積しており、どのように向き合っていくかは常に問題になっています。また、大規模なリファクタリング、新しいアーキテクチャへの移行についても議論が盛んです。
一方で、MAIDO チームで開発している管理者向け機能では、テストコードによる保護、テスト自動化が積極的に行われていませんでした。個々のビジネスロジックに対するユニットテストはテストコード化されていましたが、機能テストレベルのテストコードは存在していませんでした。つまり、UI制御やDBアクセスを含めた機能仕様観点からテスト仕様は過去のテスト設計書から掘り起こさなければならず、テスト自動化されていませんでした。
そのような中で入社数ヶ月の身としては、プロダクト知識が不足しており、ソースコードを変更した際にそれがデグレを起こしていないか、不安で仕方がありませんでした。リグレッションテストをしようにも、何をテストしていいのかすら分からない始末でした。
「ここにテストコードがあれば、ある程度のリグレッションテストを行うことができるのに…」
私は前職で、Selenium を活用した E2E テストの自動化に取り組んでいました。それを主たる業務としていたわけではないですが、それなりに思い入れがあり、その導入効果も把握していたので、E2E テスト自動化の導入に向けて声を上げようと思った次第です。
Selenium 勉強会を主催する
手始めに、Sansan の Web アプリケーションを Selenium で 自動的にテストする簡単なプロトタイプを作ってみました。
それをチームメンバーにデモしたところ、「Selenium で何ができるかを考えてみたい」という声が出ました。それならばまず Selenium を知る必要があるということで勉強会を開催することにしました。
ちなみにですが Sansan では、各所で勉強会や読書会が定期的に行われています。MAIDO チームでは、技術系に限ってみても直近で Go, Selenium, Kubernetes, React についての勉強会を実施しています。 昨年12月に実施した Go 言語の勉強会はハンズオン形式で全3回で行い、実際に運用業務で使用するツールを Go 言語で試作開発するといった動きにつながっています。
Selenium 勉強会のゴールとして 「今やってる開発のテストとして、1本くらい Selenium でテストコードを書いてみようと思えるようになる（自分の大切な時間の一部をテストコードに割いてもいいと思えるようになる）」 ということを設定しました。
Selenium を使ったことがあるメンバーもいましたが、大半が触ったことがない、チュートリアルをやった程度ということでしたので、基本的な機能や使い方の紹介を始めとして、便利機能や導入体験談なども共有しました。
また、チームで担当している管理者向け機能のうち、こういった機能や画面でテストを作ってみたいという要望も集めて、実際にプロトタイプを作ってデモするといったこともしました。
1回で終わらせるつもりでしたが、1時間30分の講義を勉強会として2回実施しました。
勉強会をやってみた感触
勉強会の終わりで感想を聞いてみたところ、苦労の甲斐あってか、メンバーの包容力のおかげか、好意的な反応が多かったです。
それでも、E2E テスト導入の壁としてよく言われる「コストが高い、費用対効果が低い、メンテナンスが大変」という感触は強く存在しているようでした。確かにそれらは否定できません。実体験として重荷となったことも少なくありません。
が、それを上回るメリットも確かにあります。
自動化したテストでコードの振る舞いを確認できればコードを変更するときに、少なくとも変更していない部分の振る舞いが変化していないことをすぐに確認できます。
こうしてコードを保護して変更しやすくすることができれば、機能改善やリファクタリングに意欲的なチームメンバーが安心してコードを変更できます。これは MAIDO チームにおける大きなメリットであると思っています。
とはいえ、まだまだ第一歩も踏み出せていない状態です。
ユニットテスト等に比べると、立ち上げ時のハードルが高いため、二の足を踏み、なかなか実践に至らないことが多いです。
ですので、まずは触ってみたい気持ちになってもらえただけも良かったと思っています。
勉強会後の動き
- はやく1本書きたい。はやく開発環境整備してほしい。
- ちょうどいまやっているテストがめんどくさいので書きたいと思った。
そういった声をさっそくいただきました。
まずは私がサンプルや共通部品をとりいそぎで用意しておき、それを使い、労力をかけない形で「書いてみる」「動かしてみる」ということをやってもらいました。
Selenium のテストコードは様々なプログラミング言語で実装することができます。
Sansan 事業部で扱う主要プログラミング言語は C# ですが、あえて Python を選択しています。
軽量言語で簡単に導入や動作確認できること、また新たな言語を触ってみたいという声があったのが選択理由になります。（私はもともと Java プログラマなので、Java や Groovy で書きたかったのはさておき…）
言い出した私が当分は書き揃えていくことになるかと思っていましたが、勉強会直後には早くも、チームメンバーに簡単なテストコードを書いてもらうことになりました。
さらに、通常の開発業務で追加した機能に対してテストコードを書くということも、きちんとユーザストーリーとして定義して、タスクを設定して実施しました。つまり、プラスアルファなものではなく、スプリントプランニングの対象に加えて、立派な開発タスクとして組み込まれたということになります。
チームに生まれた文化
とはいえ、MAIDO チームでは、開発サイクルを1週間で行うスプリントを回しています。従来からタイトなスケジュールだったこともあり、なかなか E2E テストまで書くことが定例化するところまで至っていません。
ただ、E2E テスト自動化の機運を止めたくないという思いを持ったメンバーも多く、機会があればテストコードを書きたいという意欲はあります。
E2E テスト自動化があることを前提に話が出てきたりします。たとえば、既存機能がパフォーマンス劣化していないかを検知するために、E2Eテストを利用するといったようなものです。こういったアイデアは着手には至っていませんが、チームのバックログに積まれています。
E2E テスト自動化の今後
主要なテストケース、効果の有りそうなテストケースから優先して作成していく予定です。品質保証の手段というよりも、まずは自分たちが安心して開発できる、コードを変更できるようにする仕組みとしてテスト自動化を進めていこうと考えています。
次の大きなステップとしては、作ったテストコードを自動実行するための、E2E テスト用の継続的インテグレーション環境の構築を進めています（Kubernetes 勉強会に参加したこともあり、Kubernetes で構築がんばっています）。
おわりに
前述したとおり、私のチームではテスト自動化に対して積極的ではなかったです。たまたま前職でテスト自動化に取り組んでいたとはいえ、組織でやっていなかった新しいことをやるにあたっての苦労はありました。
最初はこっそり一人でやって、ある程度形になってきたらお披露目しようかと思っていましたが、新しいことを受け入れる、挑戦するチームだったので、機会があって見せることができました。
また、比較的好意的に反応してくれるメンバーがいて、次のステップ（チームへの展開）にすんなり移ることができました。
変化を恐れず、挑戦していく文化のもとで、新たな挑戦の助けになるテスト自動化を早く実現できればいいと思っています。
*1:私が所属する関西支店の開発チーム MAIDO については、チームメンバーの加藤が紹介している記事がありますのでそちらをご覧ください。
*2:https://www.seleniumhq.org/docs/01_introducing_selenium.jsp#selenium-history
