はじめに
みなさん、はじめまして！ SmartHRのQAグループ所属のshibachokuです。
本記事は、「SmartHRのQA（品質保証）」連載企画の第4弾です。 SmartHRのQAグループはソフトウェアテストを中心に、メンバーのスキルセットやプロダクトの状況によって、柔軟かつ多岐にわたるアプローチで品質保証活動を担っている組織です。
今回はプログラミング初心者だった私が、日常的にE2E自動テストを書くようになるまでのお話を紹介させていただきます！
自己紹介
前職で情報システム部門に約9年間在籍した後、2017年4月にカスタマーサポートとしてSmartHRに入社。2019年5月に志願してQAグループに異動し、QAエンジニアとしてのキャリアをスタート。複数のプロダクトを経て、2020年12月から「ラクラク分析レポート（以下、分析レポート）」専任で品質保証活動に従事しています。
E2E自動テストを書くきっかけ
分析レポートのQA担当になったことがきっかけで、E2E自動テストを本格的に書き始めました。 私が担当になるまでは、分析レポートチームには専任のQAが居なかったため、チームメンバーが手動でリリース前の受け入れテストをしていました。 この頃、一方、他の開発チームではE2E自動テストが実装されており、E2E自動テスト起因で不具合を発見したり、リグレッションテストとして定時実行していました。その様子を見て、「分析レポートにもE2E自動テストを実装して、予期せぬ不具合やデグレを検知できるようにしたい！」という気持ちが高まり、第一歩を踏み出しました。
最初にやったこと
現在、SmartHRではCapybaraでE2E自動テストを書いています。 E2E自動テストの環境構築を牽引してくれているメンバーが作成してくれた、以下の E2E自動テストを書くために最低限必要な知識の習熟度を測定するチェックリスト で「現時点での自分ができること・できないこと」を明確にし、できないものに関しては、自身で調べたり、手が空いている分かる人に突撃質問して解消していきました。
最低限の知識が身についたところで、次にガイドラインや既存のE2E自動テストのコードを読み「どのように作られているのか」を学習し、ペアプロを通じて「小さくPull Requestを出す」ことに取り組み始めました。
つまずきポイントと乗り越えた方法は？
正直、ポイントというより、全部につまずいていました。学習した時点では理解したつもりが、実際にE2E自動テスト書き始めると、何から書いて良いかわからずに手が止まってしまいました。
具体的には「PageObjectというものを作成しないといけないことは分かったけど、そもそもPageObjectが何のために必要なの？どう書けばいいの？」、「section と sections、element と elements ってどう使い分ければいいんだ……」、「xpath取得して書いてみたけど本当に欲しいxpathなのかも一意のxpathなのかも分からん！」などなど、PageObject関連だけでもこれだけのつまずきがありました。 そして、これはほんの一部で、列挙し始めたら寝ずに3日くらいお話できるほどのネタがあります。
上記の状態を脱するために「Slackでの非同期コミュニケーション」や、すぐに解決が難しい場合は「zoomでのペアプロや生配信」を行ない解消していきました。
Slackで質問した際はすぐに反応があり、複数から「こうすると良さそう」といった意見やドキュメント、参考コードなどが集まってきて「すぐに解決できた！」といった機会が多く、成功体験を積み重ねることができました。
「zoomでのペアプロや生配信」ではコードに対するアドバイスだけでなく、エディタの拡張機能やコマンド、ショートカットの便利な知見もいただき、勉強になることだらけでした。 それだけでなく、コミュニケーションの機会にもなり、この生配信を通じて徐々に開発メンバーとも打ち解けられたと感じています。
また、これらの取り組みを行なっていくなかで「用語がわからない」というつまずきもありました。
恥ずかしながらE2E自動テストを書いていくうえでの基礎を習得しないまま実践に入ってしまったため、ドキュメントに書いてある用語や、会話の中で出てくる言葉を理解できない……といった状態に陥っていました。 それを解決するために、E2E自動テストの実装と並行してProgateでRubyの学習をはじめました。 基本的な文法から学べたため、用語はもちろんコードの意味も理解できる実感を得られ、実装のスピードも向上しました。 それだけでなく、始業前に15分〜30分程で取り組んでいたので、頭がスッキリした状態で業務ができましたし、実装中も「あ！ここ今日やったところだ！」といった小さな喜びや楽しみもできました。
どのくらいの頻度(毎日コツコツ)で取り組んだの？
毎日触る時間を作るために「1日1Pull Requestを出す」を目標に取り組みました。 E2E自動テストをマスターするために必要なこととして、以下の2点の仮説を立て、この目標を設定しました。
- 数をこなして経験値をあげていくこと
- 細かいフィードバックをもらうこと
▼ ほぼ毎日コツコツしてきた記録
半年くらいたった頃から、1日で1つのテストを書けるようになったり、自力でエラーの解消までできるようになり、少しずつ「書けているかも」という実感を得られるようになりました。
なぜできるようになったか？
「周囲の協力があったから」だと思っています。 QAグループのメンバーだけでなく、プロダクトエンジニアからの協力もあり、「絶対に書けるようになってやる！」という気持ちも持てましたし、モチベーションを維持し続けられていると感じています。 ひとりでやっていたら、きっと早くに挫折したり、プログラミングへの苦手意識が強くなっていたと思います……。
今はどういう変化が起きたの？
「書く」だけに集中していた状態から「全体を見て最適な方法はなんだろう？」ということを考えるようになってきたと感じています。
具体的には「他の人が見ても理解しやすい書き方」や「コメントの書き方」等を気にするようになったり、「実行時間が長いから短縮できる方法はないか？」という視点で考え、相談できるようになりました。
一番の変化は「プログラミングって難しい……」という苦手意識がなくなり、「もっと色んなテストを書いてみたい」と思うようになったことかもしれません！
▼ 1年前の自分では想像もできない発言をしています
今後はどういうことをしていくの？
QAだけでなく、開発チーム全員が日常的にE2E自動テストを書いている状態にしていきたいと考えています。 すでに取り組みも始めていて、3名のプロダクトエンジニアがコミットしてくれています！ また、現在は開発サイクルとE2E自動テストは独立していることと、GitHub上のリポジトリ自体も別れているため、リリースフローに組み込んだり、よりプロダクトの品質向上に繋がる活動にしていきたいです。
欲張りですが、E2Eテストだけでなく、ゆくゆくはフロントエンドやバックエンドのテストも書けるようになりたいという野望も抱いています。
まとめ
このように、未経験……むしろプログラミングに苦手意識を持っていた私でも約半年で最低限のE2E自動テストが書けるようになりました。 未経験でもやりたい気持ちがあれば、チャレンジする機会があり、惜しみない応援や協力もいただけるとても恵まれた環境だと実感＆感謝しかありません。 今後の取り組みなどもいつかブログでご報告していきたいです！
We are Hiring !
最後まで記事を読んでいただき、ありがとうございました。 SmartHRのQAに興味を持っていただけましたら、下記の採用サイトからエントリーいただけますと幸いです。 カジュアル面談も実施しておりますので、選考に進む前に気になることがありましたらぜひ、気軽に聞きにきていただけたら嬉しいです。 みなさまのご応募お待ちしております！
