テスト自動化失敗談を共有しよう！ by T-DASH Advent Calendar 2022の24日目の記事です。
はじめに
自分はBrooklynにあるRobotics Startupでデスクトップアプリと新規ハードウェア用のアプリの開発を行っています。すべてのコードはOpenSourceとして、GitHubで公開されています。
利用しているメインテックスタックはElectron、Reactjs、TypeScriptでテストはJestとreact-testing-libraryを使っています。CIはGitHub Actionsを利用していて、PRが更新されるごとに全ワークフローのチェックが行われるようになっています。software teamには自分たちの担当するfrontendとは別にbackendのrobot-service teamとembed teamが居ます。2つのteamはpythonをメインに使っています。
自分が入社した時は各frontend, backendに各々1人テストを専従にしているエンジニアがいて、アプリケーション開発しているメンバーは単体テストを書けばよくて、残りのテストはテストエンジニアがフレームワークを使って、書いてくれていて自動化されていました。
ちなみに、テストエンジニアが居た当時はチームのStandupが毎朝あって、Retroが2週間ごとにありました。
違和感を覚える
入社する前に、デスクトップアプリのメジャーアップデートするんでその作業が君の最初の仕事になりますとか言われ、出来上がったデザインをReact使って実装してみたいなことをやり始めて1カ月くらいたったくらいに、普段あんまり接点のないテストエンジニアからSlackのDMが届きました。
内容は担当した箇所がが想定と違った動きをしているという事でした。「分かった、すぐ確認して折り返します。」と返して、コードを確認したところ、こちらのミスだったので、すぐ修正のPRを上げて、他のメンバーにレビューを依頼しました。そして、テストエンジニアに原因と修正のPRについての連絡を入れました。
翌日、メールボックスを見たら、GitHub経由でテストエンジニアからテストコードのreviewの依頼が来てました。まぁ、自分が担当した部分なので、そうなるのかと思いながら、リンクを開きました。
リンク開いた表示されて、GitHubのレビュー画面を見た瞬間、「Oh my goodness, seriously?」と口に出してました。
e2eのテストコードなので、てっきりcypressとか使っていると思い込んでいたので、TypeScriptが表示されるとばっかり思っていたんですが、目の前のコードはpythonでしたｗ
個人的に、data scrapingとかをpython + beautiful soup + selenium とかでやっているので、コード自体は馴染みがあるので、読むこと自体は問題ないんですが、正直強烈な違和感を覚えました。
チームメンバーはts + reactjsがメインといえど、コンピューターサイエンス出ている人がばかりなので、Reviewするくらいは問題は全くないんでしょうが、コードベースをJSからTSにフル換装して、アプリの土台もElectron使っているJavaScriptエコシステム万歳状態なのに、なぜテストだけpython。しかも、専従でやっている1人はドキュメントらしいドキュメントも書いていない。
「これ、この人いなくなったらヤバいよねと」と思いましたが、入社直後でいろいろと自分のタスクで忙しかったので、あとでいいかとその時はなにもしませんでした。
晴天の霹靂 layoffs
入社して、3ヶ月くらいたった6月の最後の週にCEO名義のメールが届いてました。基本的にコミュニケーションはSlackなので、珍しいなぁとメールを読んでみたら、「マクロ経済の動向やコロナの影響等々でファイナンスの状況が良くないため、人員の整理をします。」とありました。
リストに名前がある人は本日の昼前までにマネージャーから連絡があるので、確認してくださいということでした。その直後に、VPoEからSoftware engineer全員がいるプライベートチャンネルに投稿があって、昼にエンジニアだけでMeetingするので、参加できる人は参加するようにという事でした。（後で知ったんですが、この時点で対象になっている人たちは会社のアクセス全部deactivateされていたみたいです。）
結果は、タイトルからも分かる通り、チームのテストエンジニアがリストに入っていました。。。
ただ、自分たちデスクトップアプリ担当のチームはリリースを2週間後に控えて、QAteamからのFeedbackやバグレポートに対応している最中でとてもテストエンジニアから業務内容を引き継ぐ時間的な余裕がなくタイミング的には最悪でした。
個人的な興味でテストエンジニアが書いていたテストコードを見に行ったんですが、テスト自体の進行も思っていたほどではなくて、エラーが出やすいとされている場所や、Testの開始が行われる予定が少し遅れたところに関しては、ほぼ手付かずという感じでした。
自動化道半ばで終わる
その後、７月のメジャーアップデートが終わって、チーム全体が落ち着いたころにStandupで恐る恐る、「今後、e2e testの部分どうするの？」とtech leadや他のエンジニアたちに聞いてみました。
そうしたら、沈黙があって、「Good question」とTech leadが言った直後全力の苦笑い。そして、チームメンバーも同じ。（恐らくみんな、おまえそれ聞く？聞いちゃうのかよみたいな感じだったのかもしれません。）
結論としては、現状e2eでdetectされるようなバグもユーザーから報告も上がってきていないこと、e2e testがpythonで書かれていてメンテナンスにコストが掛かることを踏まえて、一時e2e testに関してはpending 事項にするということになりました。そして、これを書いている12月24日 (east time)まで、もう誰もテストの話はしなくなりましたｗ
夏に、１人プロジェクトみたいな感じで、取った夏休みを使って75％切っていたアプリのtestカバレッジを3％ほど引き上げた後にtech leadとの1on1でそれとなく、e2e testの話を聞いてみました。
もちろん絶対テストがあった方が良いとは思っているが、タスク量と人員を考えると、今そこには手を付けている余裕はないので、新しく人が入るまでは現状維持で行くことになると言われました。そして、残念なことにメンバーは増えるどころか、コロナの後遺症が回復せず1人去り、Amazonに行きますと1人去りと減り続けています。
問題点と今後
自分が入社した時点では結構チーム分けがきっちりされていたのですが、コード見ていると、テストエンジニアが入社したころはbackendやembedにいるメンバーもデスクトップアプリのコードを触っていたようで、その関係でpythonの方が得意というメンバーの数がts/jsより多かったので、python + seleniumでのe2e testにGoサインが出たのかもしれません。
ただ、個人的にはfrontendのmeetingと新規ハードウェアのmeetingに出たり、Confluenceにあるドキュメントを見ると、明確にJavaScriptのEcosystemを活用していきましょうという雰囲気なので、テスト環境についてデスクトップアプリのメジャーアップデートの話が上がった時点で議題に上げられなかったのはSofware engineer teamとして失敗だったと思います。
そして、個人としては危なそうと感じた時点でテストエンジニアに連絡を取って、最低限のドキュメント作成の依頼をしておくべきだったかなぁと思っています。
現状、デスクトップアプリには機能が追加され続けている点、メンバーの数とタスクの分量を考えると、e2eのテストのために時間を割くのは現実的に無理だろうなぁという気がしています。
その一方で、自分がメインでやっている新規ハードウェアに搭載するアプリに関しては専従で作業しているのは自分だけで、implementationガイドも自分の方で作っているので、自動化のための道筋づくりみたいなのは自分がLeadを取っていけば、実施はできるのかなぁとも思っています。
ただし、実際のところそこまで手が回っていないので、お正月にリサーチして、フレームワークの絞り込みをしたいなぁと思っています。
そして、リサーチの前提条件は自分が居なくなっても、他の人が問題なく引き継いでイケるになると思います。