こんにちは！QAエンジニアのetoとshibachokuです。本記事は品質保証部連載第11弾です。今回はプログラミング初心者である私たちがPlaywrightにチャレンジし、実施してきた取り組みについて語った内容をブログにしました。初心者あるあるな話が結構出たのではないかと思います。
インタビューアーは品質保証部マネージャーのtarappoさんです。
※tarappoさんについては以下の記事をぜひご覧ください。
自己紹介
tarappo：品質保証部のtarappoです。今回は労務ユニットBのメンバーが最近すすめていたPlaywight周りのことについてお二人と話せればと思います。
eto：品質保証部労務ユニットBに所属しているetoです。よろしくお願いします。
shibachoku：同じく労務ユニットBに所属しているshibachokuです。よろしくお願いします。
tarappo：よろしくお願いします。お二人は普段どういう活動をされているのでしょうか？
eto：私は勤怠管理プロダクトにQAEとして専属で入っていて、チームの中で品質保証活動をしています。
shibachoku：私はプロダクトチームに専属で入らず、労務ユニットBが管掌するプロダクトを全体的に見ています。
tarappo：お二人は最近Playwright周りをすすめていたということですが、具体的にどのような活動をしていたのでしょうか？
eto：勤怠管理プロダクトで E2E 自動テストをPlaywrightで実装していました。ちなみに、Playwrightでの実装は勤怠管理プロダクトの前に関わっていたプロダクトチームでも少し経験していました。Playwright歴は浅めの1年くらいですね。
shibachoku：従業員サーベイのE2E 自動テストをPlaywrightへ移行する支援をしてました。昨年の後半からガッツリやりはじめたので、Playwright歴は半年くらいです。
※ われわれの所属する労務ユニットBについては以下の記事をご覧ください tech.smarthr.jp
Playwrightを使ったE2E自動テストの活動を始めたきっかけ
tarappo：Playwrightを使った自動テストの取り組みと経験がまだそこまで長くないというところが、2人に共通していそうですね。その取り組みを始めたきっかけって何かありますか？
shibachoku：もともとSelenium + Capybaraで E2Eの自動テストが運用されていたのですが、Flakyなテストが多かったりしたため、運用コストがある程度かかってしまうという課題がありました。その課題を解消したいと思ったことがきっかけです。現行のフレームワークで Flakyなテストを修正したり、運用を続けることはコストが高いと判断し、社内での利用が多くノウハウが一定存在しているPlaywrightを選択しました。
eto：私は、担当しているプロダクトにおいてユニットテストなどは一定存在していたのですが、E2Eの自動テストについてはテストケースが少なく、まだ足りていない状態でした。なので、よりデグレ検知などができるように、テストケースの追加をチームとして決めました。
E2E自動テスト実装時に大変だったこと
tarappo：Playwrightを使ってE2E自動テストを実装するにしても、すぐにできたわけではないと思いますがどのような点が大変でしたか？
shibachoku：プログラミングにそこまで慣れていないのでTypeScriptやPlaywrightを触ることに不安がありました。Playwrightを例にすると「要素を特定するための getByRole で何を指定すればいいのかも分からない状態」からのスタートでした。
また、以前Selenium +CapybaraでE2E自動テストを実装している時はXPathを指定していたことが多かったこともあり、getByRoleでうまく動かなかったら「XPathでどうにかしよう！」みたいな思考になっていました。DOMの構造に依存しないロケーターを使う方法に順応するまでは苦労しました。
eto：私はTypeScriptについての理解が浅かったので、適切なコードがなかなか一発で書けなかったのが大変でした。書いていて遠回りだなと思うような書き方をしていました。 例えば、ある要素のON/OFFの状態を判定するコードを書きたかったのに、その要素の数を数えて状態を判定するようなコードを書いていました。
tarappo：そういったまだ経験が浅い状況の中で、どのようにして解決していったんですか？
eto：Playwrightで書いたコードはユニットのチーフにレビューをしてもらい、修正の方向性を示してもらいました。その方向性をもとにやり方を自分で調べたり、調べて分からなかったところはレビュワーに直接聞きに行ったりしました。
shibachoku：私も同じくレビュー時に指摘してもらったり、モブプロ・ペアプロしてもらったり、Slackで非同期で質問したりして解決していきました。また、他プロダクトのE2E自動テストのコードと公式ドキュメントにもかなり助けられました。
実装面以外で大変だったこと
tarappo：お話されたように実装するにあたって大変だったことは一つ一つ学びながら進めていったんですね。それ以外に大変だったことって何かありますか？
shibachoku：移行対象のプロダクトに深く携わったことがなかったので、プロダクトのドメインや仕様を理解するのが大変でした。ドメインをすべて理解するのはきびしいため、既存のE2E自動テストの内容を確認し、テストケースがどのようなシナリオをカバーしているのか、どの機能を重点的にテストしているのかを把握することからはじめました。次に、実際にテスト対象の画面を操作して、各機能の動作や必要なデータ等を確認しました。そのうえで、コードを書いていき、テストを実行しながら修正していく、というプロセスで進めていきました。
良かったこと
tarappo：大変だったことばかりではなく、良かったこともありましたか？
eto：そうですね、E2E自動テストを実装したことで、リリース時の手動テストの負担が減りました。また、自分のプログラミングスキルも向上したように思います。E2E自動テストの実装がきっかけで学べた書き方がたくさんありました。
shibachoku：移行が完了したことに対して、プロダクトチームから喜びの声をいただけたのは嬉しかったです。PlaywrightやTypeScriptへの理解が深まったのも良かったです。何もわからないところから、一緒に悩みながら…ではありますがペアプロのドライバーもできるようになりました。
今後について
tarappo：Playwrightを経験しE2E自動テストを実装してきたわけですが、これからどうしたいかとかありますか？
eto：実装当初はうまくいっても開発が進んで別の機能が追加されたりするとFlakyになったりするところが出てきているので、今後はもっとテストを安定させられると良いかなと思っています。
shibachoku：移行することに重点を置きすぎてしまった点が反省点です。今後は移行や実装だけでなく、なぜこのテストが必要なのか？、本当にE2E自動テストで担保すべきなのか？、といった視点を持って対応していきたいです。
tarappo：素晴らしいですね。守るべきところで守れるようになっていくと品質保証の選択肢が増えていくと思います。そうして、増やした手札を使ってプロダクトの品質をさらに向上していきたいですね。
We Are Hiring !
本記事を読んで、SmartHRの品質保証部の目指す姿に共感して興味を持っていただけましたら、カジュアル面談をぜひご検討ください。 私たちと一緒に新たなSmartHRの品質保証部を築いていきましょう！ youtrust.jp
