こんにちは！開発本部でQAエンジニアとしてインターンをしている嵩原（@BkNkbot）です。PR TIMESで初めてのQAエンジニアインターン生として3ヶ月半の間お世話になったので、今回は実際にどんなことに取り組んだのかお話ししていきます！
インターンまで
これまで私は複数の企業でQAとして業務していた経験があり、その際に執筆した技術記事などを読んだ社員さんから「弊社のインターンに興味ないですか？」と声を掛けられました。その後、QAチームのリーダーと1度だけ軽く面談を行いインターンを行うことが決定しました。
私が入社する前のQAチームはまさに”これからテストの自動化を進めていきたい！”という状態で、実際に面談でも「Playwrightでテストを書いてほしい」「先頭に立ってテスト自動化を進めてほしい」と強く依頼されました。
実際の業務
テストシナリオ整理
…と言っても、もちろん自動化を行っていないわけではありません！PR TIMESではAutifyを使って既に一部のテストが自動化されていました。
しかし、蓋を開けてみると「命名がバラバラで新規参入者に伝わらない」「既に使われていない」「失敗し続けているのにそのまま放置されている（保守されていない）」テストが数百個近くありました。
そのため、Playwrightを使う気満々で入社したのですが、QAチームやエンジニアと話していると ”実装されているのに有効活用されず、捨てられているテスト” が多く存在することが問題なのではないかと感じ、Autifyの整理から始めることにしました。
テストの大掃除
Autifyには「シナリオテスト」、複数の異なるシナリオで再利用できる「ステップグループ」、複数のシナリオを指定したルールに従って実行する「テストプラン」があります。
これらの必要・不要を判断するために、実際に中身を見て「他と重複していないか」「最近実行されているのか」を確認し、残すかどうかを決めます。不必要だと思ったものはQAチームや作成者などに話を通して、問題なければ削除していました。
結果として、削除後はシナリオテストを162件→80件、ステップグループを52件→40件、テストプランを51件→20件と大幅な削減を行うことができました！
これにより、未着手であるテストの範囲もわかるようになり、無駄に回されていたテストの実行も止めることもできました。この整理を行っていたのが旧エディタから新エディタへの転換期だったこともあり、このまま放置されていたら無駄なシナリオテストが多くなっていたと思うので、このタイミングで残すテスト・消すテストの意思決定を行えたのはよかったです！
命名変更 / 帳簿作成
まだここでは終われません。次に、どうしても名前がバラバラなのが気になりました。今までは命名に関して規則は決められていなかったようで、テストケース名の頭に【実行禁止】と付いているものもありかなり怖かったです。
せっかく整理をしたので、命名についてもこのタイミングである程度統一性を持たせるために全てのテストケース名を再検討し、変更しました。
命名についてはかなり迷いましたが、QAチーム / 開発チームに定期的に意見を聞いたり、実際に使って修正を加えたりすることで最終案を確定させました（一部のテストは外部委託しているので、社外の人とも定期的に新命名の認識合わせを行いました。インターンという立場で自分が主導権を持って社外の人と話を進められたのは間違いなく貴重な経験でした）。
また、旧命名 / 新命名で既存のメンバーが混乱する可能性があったので、あわせてGoogle スプレッドシートで「テストケース一覧が確認できる帳簿」を作成しました。私が入社したときは「どういうテストがあって、どういうテストが存在しないのか」をサッと確認することが難しかったので、今回の帳簿作成でその課題も解決出来た気がします。
実際に帳簿を作成したことで「PR TIMES内と外部委託企業のどちらが責任を持ってメンテナンスしているのか分からない状態のテスト」が浮き彫りになり、お互いに積極的なコミュニケーションを取っていこう！という流れが生まれました。
PlaywrightによるE2Eテストの実装
さて、これで社内の既存テストの整理はひと段落です。整理をしたことで、実行に時間がかかっているテストが何となくわかるようになってきました。本題はここからです！
PR TIMESでは、毎日深夜に実施しているAutifyのテストプランがあります。しかし、最長で7時間もかかっているものがあり、みんな頭を悩ませていました。理由も特に不明で、複雑な手順を踏んでいるわけでもありませんでした。
ちなみに、本記事にAutifyを下げる意図は全くありません。ノーコードにはノーコードのメリットがあると思いますし、私はAutify整理編でその恩恵を強く受けています。
このままAutifyで全てのテストケースを頑張るのではなく、すごく時間がかかっているテストプランに関してはPlaywrightで実装することにしました。QAチームが使っていくため、実装するにあたって「Windows/Macのどちらでも動作すること」「誰が読んでも理解出来るようにコメントを詳細に書くこと」ことが求められました。
それを踏まえた上でガリガリと実装し、結果としてAutifyで7時間かかっているテストを簡易的なチェックだけなら15秒に短縮することができました！
実はQAチームが新規実装することになってもいいように、基本的にはPlaywrightの機能の中でも直感的に触れる「Pick locater」を利用しながら実装していました。最近trace画面上でも使えるようになったので、とても簡単にテストが書けるようになりました。
今まではcodegenコマンドやVSCodeの拡張機能経由でしか利用できなかったので、かなり嬉しいアップデートなんです！関連しているページはこちら。
今までは要素の特定をしたい場合に要素内に入っているテキストなどを参考にアサーションを実装していました。しかし、「何度やってもその要素を取得するコードが書けず、フロントエンドのコードを読む」ということを何度もやったことがあります。原因としては、半角空白が入っているなどで若干テキストが違っていたり、button要素かと思ったら実は違った、ということが多いです。
検証モードで毎回要素を確認して実装するようなことは現実的ではありませんが、traceページから「Pick locater」タブを選んで要素をクリックすると、その要素がどのようなlocaterであるのかすぐにわかります。
こちらのページから実際に試してみてください！取得されたlocaterをコピーしてexpect文の中に貼り付けるだけで、誰でも簡単にアサーションテストを実装することが可能です。
また、VSCodeの拡張機能である「Playwright Test for VSCode」を使ったデバッグも行いました。こちらはVSCode上で任意の場所にブレークポイントをつけて実際に手元で動かしてみることで、エラーの原因を手元で特定するために利用します。今回のインターンがなければ触ることもなかったと思うので、デバッグについても知見を深められる良い機会になりました！
最後には、利用にあたってのドキュメント整理や仕組み化が残っています。誰が読んでもわかるように、ドキュメントに関してはGitの入れ方からGitHubのアカウントの作り方、Playwrightの実行方法や実行結果の読み方など、かなり丁寧に記載しました。Readmeを分かりやすく書く難しさと、こだわり始めたら終わりがないことを実感しました。
そして作ったテストを「サクッと回せる仕組み」が大切というわけで、クリックしただけでテストの起動から実行まで良い感じにやってくれるバッチファイルの作成も今後行う予定です。せっかく作ったのに使われないと悲しいですからね！自分も含め「人間はなかなかテストを回さない」ということを強く実感したので、テスト実装では終わらず、手軽に実行できる仕組みを作るところまでが重要です。
色々書き連ねましたが、他にも沢山の業務に挑戦させていただきました！PR TIMESとしては初のQAインターンということもあるので、こちらにも少し触れておきたいと思います。
リファクタリングデー / 定期リリースQA
PR TIMESでは、月に一度「リファクタリングデー」という「リファクタリング作業を定期的に実施する日」が存在しています。開発チームと協力しながら、普段の開発の中で後回しになりがちな部分のリファクタリングを1日かけて行うドキドキなイベントです！
QAチームは、そのリファクタリングが適応された環境を次の日に1日2回テストします。ステージング環境で問題がなければ、本番環境にデプロイして再度テスト。分担しているとはいえ、もの凄く体力を使う一日なので、毎月取り組んでいる開発本部の方々に尊敬の念を抱きました…。入社して3日目でこのQAに入ることになり、とても刺激的だったことを覚えています。
もちろん定期的なリリースQAにも取り組みました。今まで触ったことのない部分を確認するQAが多かったので、毎回ドキドキしていたことは内緒です！このインターンではないと触れない箇所も多かったので、とても勉強になりました。
デザインQA
PR TIMESのQAは上流から関わることができるのが強みという話も聞いていたので、現在は新規プロジェクトのメンバーとしてデザインQAも行っています。
デザインQA以前の話にはなるのですが、複数のデザイン案が上がってきたときに「思っていることを上手く言語化できないな」と本当に強く実感しました。言語化する力が足りないというのはもちろんあるのですが、デザインの知識が全くなかったため代替案を考えることができず、会議であまり意見を出すことが出来ませんでした。余談にはなりますが、本当に悔しかったのでデザインの勉強を始めました。
デザインQAに至るまでは他の方が話している内容を聞いているだけになってしまいましたが、さまざまな視点から意見が出ていて大きな学びになりました…！
おわりに
怒涛の3ヶ月半でしたが、とても学びが多い期間になりました。特にPR TIMESに入って一番驚いたのは、”社内の透明性が本当に高いこと”です。DMを基本的に利用しない運用にしているとのことで、「#room_yurume」という雑談専用のチャンネルがあります。個人宛のちょっとした連絡は大体ここに流れているイメージ。自分が気になったプレスリリースを他の人に共有していたり、個人的なランチのお誘いなども見ることが出来ます。
そのおかげもありエンジニアとQAの距離が近く、仲も良いので非常に仕事が進めやすかったです！DMを利用している社員さんがいないため、ちょっとした確認や雑談の様子も見ることが出来ます。
「ちょっとハドルしてもいいですか？」「ちょっとMeetしたいです！」という社員さん同士の会話を普段から目にする機会が多かったので、インターンとしても”こんなに小さなことでも聞いていいんだ”という気持ちになり、心理的安全性が高い環境の中で多くのことに挑戦することが出来ましたし、恐れず社内でも発言することができました。
以下は、社内で障害が起きてしまった際のスレッドの様子です。インターンという立場でありながら、開発本部長に対して自分の意見を話せたことが心理的安全性が高いことの何よりの証拠です。
最後になりましたが、QAインターン受け入れの前例がない中で貴重な機会を作ってくださった開発本部のみなさん、本当にありがとうございました。最後までやり切ることができたのは、QAチームをはじめとした多くの社員さんのご協力があったからだと思います。短い間でしたが、本当にお世話になりました！
