YT.dev

このPJは - 詳細を[自社テックブログで公開](https://www.lifull.blog/entry/2024/06/11/070000) - 全社MVP受賞 しています。 ## 概要 E2Eテストをシフトレフトし、PR上でテスト実行できるようにした。 またテストのメンテナンスもPR作成者が担当できるように運用フローも作成した。 これにより - リリース時にかかっていたe2eテスト実行時間を2.5→0に短縮した - featureブランチ→本番環境へ直接反映するフローが選択できるようになった ## 課題と解決法 ### 課題 全社横断でE2Eテスト(回帰テスト)をGitflowにおけるdevelopブランチマージ後に実施していたが、以下の課題があった。 1. developブランチマージから本番環境反映まで8.5時間かかっていた 2. QAチームの工数が1~4時間/日かかっていた 2-1.基本的に朝9時からdevelopブランチに対して自動テストを実行 2-2.実行後の結果を確認、バグが検知されれば開発チームに仕様確認 2-3.14時に本番環境反映 3. E2Eテストでバグを検知した時の手戻りの多さ 3-1.Revert対応率は3年連続で50%を超えていた 4. QAGと開発チームのコミュニケーションに時間がかかる 4-1.弊社QAGは横断組織で、機能開発チームに常駐しているわけではありません。そのためE2Eテストが失敗した際に、E2Eテストのメンテナンスが必要なのか、バグなのかがすぐに判断できませんでした。都度開発チームに調査依頼を投げていたので、両チームの負担となっていました。 ### 解決法 E2EテストをPR上で実行できるようにし、以下のフローへ改善した 1. featureブランチで開発 2. featureブランチでpushするたびにE2Eテスト実施 3. 必要があればプロダクトコード or テストコードの修正 4. developブランチへマージ ※developブランチではE2Eテスト実施 **しない** ## PJ詳細 ### 大まかなタスク 1. PJ全体のWBS作成 2. MTGの頻度や内容の決定 3. 現状の課題の洗い出し 4. E2Eテストの再設計 4-1.テスト実行時間が長く、開発者体験悪化を防ぐためテストの実行時間を短縮する必要があった。不要なテストの削除、テストのリファクタを実施。 これにより合計400ケースから3割削減した 5. 運用フロー作成 コードのpush→自動テストの実行→通知先の選定→自動テスト/プロダクトの修正の流れ 6. テスト実行基盤となるk8sの構築 6-1.インフラチームが環境は作ってくれていた(後述のKEEL)ので、job, pod, containerの構成 7. 運用開始 8. 運用課題(後述)を開発チームと協力しながら解決 ### 工夫した点 #### GitHub ActionsでのAWS認証をOIDCで実装 このPJではAWS認証をIAMユーザー認証からOIDCによるIAMロール認証に切り替えました。 IAMユーザー認証の場合、GitHub Actionsのシークレット変数にAWS_ACCESS_KEYやAWS_SECRET_ACCESS_KEYなどの機密情報を保存する必要があります。万が一これらが漏洩してしまうと、AWSのリソースが不正に操作されてしまいます。 OIDCによるIAMロール認証を導入することで、GitHub Actionsのシークレット変数に機密情報を保存する必要がなくなり、セキュリティを向上させることができました。 ### 運用課題とその解消法 #### テスト結果通知のコメントが量産されPRが見づらくなる テスト結果はPRにコメントする形で表示しています。 開発している時には気づけなかったのですが、コミット数が多くなってくるとコメントがその分量産されPRの見渡しが悪くなるとのFBをもらいました。 #### 解決法 以下の処理に変更しました。 PR内に存在する過去のE2E結果コメントを削除 新規のテスト結果コメントを投稿 #### マージ要件を満たせない このE2EテストはCIとしてPushの度に実行されます。またリグレッションテストとしての役割も持っているので、当然全てのテストが成功してからdevelopブランチに反映されるべきです。 そのため導入時はテストが100%成功していないとマージができないようにしていました。 しかし、このルールでは開発者体験が悪化してしまいました。原因は以下です。 - E2Eテストは他のテストレベルと比較して不安定さが高い ネットワークの問題等で1個でも失敗してしまうとマージができない 後述の「テストの再実行がやりづらい」問題のため、テストの再実行に10〜17分かかってしまう。 - ABテストが多い LIFULL HOME'Sでは多くのプロジェクトが並行して進んでおり、それに比例してABテストも数多く存在します。 基本的にはE2Eテストシナリオではメインに採用されている方を期待していますが、自動テスト時に期待していない方を引いてしまった場合、UIやロケーターが変わるので失敗してしまいます。 開発者も他チームのABテスト事情を全て把握しているわけではない #### 解決法 マージ要件に閾値を設ける手段を取りました。 具体的には自動テストのpass率が90%を超えている場合にはマージ可能としました。 チーム内で話し合った結果、避けたかったこととしては以下が列挙されました。 - バグの流出 自動テストで検知されているバグを無視してマージした結果本番で障害が出る - E2Eテストの形骸化 テストが失敗してもマージ可能なため自動テストのメンテナンスをせずに放置される可能性がある。 自動テストのメンテナンス不足で失敗が増え、テスト結果が信頼できなくなる等が起こる傾向にある - 開発者体験が悪くなる プロダクトコードに問題が無く、flakyテストによってマージが阻まれる事 他チームで実施されているABテストによってテストが失敗し、マージが阻まれる事 テスト成功率100%を求め続けることで開発者のストレスになる 最悪の場合QAと開発者で対立が生まれる 上記の「バグの流出」と「E2Eテストの形骸化」は自動テスト成功率を100%を強いることで解決できますが、3つ目に関しては自動テスト成功率を100%を強いると起こり得てしまう問題です。 過去の自動テストの結果を見て、flakyテストとABテストで期待していないパターンを引いた場合でも90%は下回らないということが分かりました。 そのためマージ要件をE2Eテストのpass率100%→90%に変更しました。 #### テストの再実行がやりづらい テストの再実行を行いたい場合、以下の手順を踏む必要がありました。 1. EEの再起動 2. E2Eテストの実行 3. E2Eテストの結果 特にコードの修正をしていない場合の再実行では、E2Eを再実行したいだけのためにEEの再構築も行わなければなりません。 EE再構築からテスト完了まで17分かかることもあり、これはユーザーにとってストレスでした。 #### 解決法 GitHub Actionsの[workflow_dispatch](https://docs.github.com/ja/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)を使い、E2Eテストの再実行を楽にしました。 以下の流れでテストの再実行が実施されます。 1. workflow_dispatchでPR番号を入力する 2. 入力されたPR番号から再実行すべきテストケースを取得 3. 入力されたPR番号から再実行対象のFQDNを取得 4. WorkflowでE2Eテストの再実行用スクリプトを実行 これによってコードの変更をしていない場合でのE2Eテスト再実行の手間が軽減され、時間としては17分→7分ほどにまで削減できました。 ## 使用技術 - 弊社のアプリケーション実行基盤を利用。 - AWS ECS - 内製テストフレームワークである[bucky](https://qiita.com/rueyjye/items/570ce17d698819f99091) - shell E2Eテストの実行フローは以下の通りです。 1. PR作成後に一時的な検証環境であるEphemeralEnvironment起動 2. EphemeralEnvironmentの起動後にdockerコンテナが起動 3. dockerコンテナからECSを実行 4. ECSに定義されているタスクからE2Eテスト実行 5. テストの実行結果がをshell scriptで処理しPRにコメントで通知 6. 基本的にはテストが全成功がマージの必須要件 ## 結果 - リリースの速度が向上。 - リグレッションによるrevertの回数が減少。 ##### 多重実行防止 テスト実行時に同じテストが複数回実行されることを防ぐため、テスト実行中にテストの実行を操作する仕組みを導入しました。 ###### 起こっていた問題 「pushされるたびに自動テストが走る」仕組みになっているので、連続でpushされた場合に同じテストが複数回実行されることになります。 これでは余計なコストがかかるだけでなく、アプリケーションに余計な負荷がかかっていました。 ###### 解決策 新規でテストが実行される際に、実行中のテストを停止する仕組みを導入しました。 具体的には以下の流れです。 1. コードがpushされた際に、同じPRに対して実行中のテストがあるかを確認 2. 実行中のテストがある場合、そのテストを[stop-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/stop-task.html)を使って停止 3. 新規でテストを実行 ##### 結果 同じテストが複数回実行されることを防ぐことができ、テストの実行回数を減らすことができました。 またECSのコストも削減でき、アプリケーションにかかる負荷も軽減できました。 ##### data-test-idの推進 E2Eテストのlocatorを記述する際に、data-test-idを利用することで、テストの安定性を向上させました。 ###### 起こっていた問題 シフトレフトによりテストの実行回数が増えたことで、flakyテストの存在が顕在化しました。 またPR作成者がテスト結果を確認する手間が増えてしまいます。 ###### 解決策 QAグループで議論した結果data-test-idの導入を決定しました。横断プロダクトでの導入になるため他部署との調整が必要で以下の流れで進めました。 1. プロダクトエンジニアで興味ある方を巻き込み、E2Eテスト安定化チームを立ち上げた 1. フロントエンドに手を加えることになるためその領域のスペシャリストにも参加してもらいました 2. そのチームでdata-test-idの導入について共有し、チームメンバーの所属部署に種まき＆懸念がないかの確認を依頼 1. ここで皆さんが早めに動いてくださってとてもとても助かりました 3. QAグループでdata-test-idの命名規則の決定し導入リポジトリのgithub Discussionsにて共有 1. 命名規則や運用フロー等に関してすり合わせを行い導入決定 ##### 結果 少しずつですが導入され、導入されたプロダクトコードでのテストは安定性が向上しました。 ある程度導入された段階で、flakyテストをモニタリングし数字も出していこうと思います。

## 概要 qiitaにも投稿しています https://qiita.com/Yamashita-Taiki/items/10aebf3a54c2b4d6665f 社内で自動テストの課題についての相談を募っていた際、とあるタグマネージャーツールを使用している部署から「意図したタグが正しく埋め込まれているか確認するための工数が膨大である」との意見があった。 ## 課題 タグ確認作業は手動で行われており多くの工数が必要になっていた。 そこで、意図したタグの埋め込みを確認するためのE2Eテストを導入することで、今後の業務効率向上が期待できると考えプロジェクトを開始した。 ## 使用技術 Playwright TypeScript - タグマネージャーツールの特定のイベントで埋め込みたいタグを期待値とし、該当のPathでE2Eテストを実行した。 - 運用に関しては以下の対応を取った。 - ローカルでE2Eテストを実施する→PRのラベルに[E2E_test_passed]のラベルを自分で付与する→ラベルがついていればマージができるようになるactionsを作成 ## 結果 今までタグが問題なく埋め込めているかを確かめるために2〜3日かかっていた工数が、E2Eテストによって5分/日に減少した

## 概要 開発チームのエンジニアに対して探索的テストの講習を実施した ## 講習の目的 開発チームのソフトウェアテストスキルの向上 開発チームの課題として以下があった - どうすれば効果的に探索的テストを実施すれば良いかわからない - 過去に開発者のみで実施した時 - 不要な箇所を見てしまう - テスト成果物を上手く残すことができず、トレーサビルティの悪化にも繋がってしまった。 - その結果探索的テストに自信が持てなくなってしまっていた ## 講習の内容 - 上記の開発者の悩みを解消するため、新規PJのリリースのタイミングで実施 - 探索的テストの1サイクルのみ 1. 新機能を分解 2. 各機能で起こって欲しくないことを考える(リスクベースド) 3. 2で上がったリスクはどのように操作すれば発生するか？の検討 4. 実行 - 講習ではインプットをメインで開発者には参加してもらい、後日開発チームのみで実施 - 自分が探索的テストを実施 - 新機能の詳細、仕様は講習内で自分→開発者へ質問という形をとった ## 参加者の反応 事後アンケートの結果(一部) - 探索的テストの効果的な実施方法が理解できてよかった - いきなり開発者自身で実施せずに、慣れている人の思考を得ながら受講できたのがありがたい - テスト成果物の残し方がわかった

## 概要 大学4年目〜就職後は副業として教育系スタートアップに参画 教育系のサービスを展開しており、その社内システムの開発を主に担当していた。 サービスの内容としては、学校教員と外部人材とマッチングを図り学生に新たな視点を持つことを目指すサービス。 担当した主な業務は以下 - 別サービスのdbにクライアントとユーザーの情報が格納されており、その情報を社内システムで抽出し、表示。 - 外部人材としての登録があった際に審査ができる機能（審査の合格、不合格によりメールを送信し、フィードバックを送れる機能） - 登録希望の学校の審査機能 ## 経験したこと - 1つのDBを共有する構成 - テーブル数が10程度の規模のRailsアプリケーションの初期段階の開発経験 - docker fileの作成 - 基本的なトランザクション処理 ## 使用技術 - docker - PostgreSQL - minitestでのunit test - Ruby on Rails(フロントもerb)

## 概要 友人の趣味である麻雀の学習アプリの開発に携わった。 ## 詳細 友人の企画の元、麻雀のモバイルアプリを作成した。 ### アプリの想定ユーザーは - 麻雀を始めて少し慣れてきた - 点数計算はできない - 雀荘に行くことにはハードルを感じている - 周りに教えてくれる人がいない 上記を解消するため麻雀に関する知識の習得、実践問題を通じて点数計算ができるようになることサポートする ## 使用技術 - Dart, flutter - clean architecture - デザイン: flutter flow - テスト: flutter_test ## 担当範囲 - ドメイン層のコーディング - クイズ一覧画面（当アプリでは麻雀に関する問題を解く機能がある） - domain層のユニットテスト - top画面の - クイズ一覧画面のwidgetテスト

# タイトル RSpecでのユニットテストの保守改善とGitHub Actionsへの移行 ## プロジェクトの概要 私は弊社のAPIサーバーにおいて、以下の業務を担当しました。 - RSpecを用いたFlakyなテストの改善 - CIツールをGitHub Actionsへ移行 - シフトレフトの実施 ## 課題とアプローチ 弊社のAPIサーバーはGitFlowを採用し、featureブランチからdevelopブランチへのマージ後にユニットテストを実行していた。しかし、このプロセスにはいくつかの課題が存在していた。 - テスト結果のフィードバックが遅く、開発サイクルが遅くなっていた。 - 古いテストコードのメンテナンスが追いつかず、不安定なテストが多い。 - CIツールがJenkinsとcircleCIで、Pull Requestから結果確認までのステップが多く開発者体験が悪かった。 ## 採用したアプローチと技術 - メンテナンス性を確保するため、社内の単体テスト方針を「単体テストの考え方/使い方(マイナビブックス)」に統一した。 - テストコードは引き続きRSpecを使用。 - CIツールをGitHub Actionsに変更。 - featureブランチのPull Request作成時にCIをトリガーする設定を導入。 ## 成果 - Flakyなテストの改善により、不安定だった20件以上のユニットテストを改善した - "required"指定されていたテストがFlakyだった。そのためrequiredを外す業務があったがその業務がなくなった。 - GitHub Actionsへの移行により、開発者の体験が向上した。 上記の改善により、より品質の高いプロダクトを迅速にリリースできるようになった。

副業先で1人目のQAエンジニアとして以下の活動を実施しています。 - リグレッションテストの導入 - 探索的テストの支援、普及 - ソフトウェアテストの普及活動 ## リグレッションテストの導入 ### 状況 - 私が参画した時点でプロダクトが3年目に突入していた。 - プロダクトの規模も大きくなり仕様が複雑化&初期メンバーの退職も重なり、新機能開発やリファクタの際の影響範囲の特定に疲弊していた。 - 今までは本番でバグが出ても直せばOKな状態だったが、ユーザも増えてきており、その対応では信用低下につながる - エンジニアの数が少なく毎回同じテスト手動で確認するのは工数的に難しい ### やったこと 1. CTOとエンジニアから現状の課題をヒアリングした 1-1.プロダクトの規模 1-2.リリースフロー 1-3. 現状のテスト 等 2. リグレッションテストを導入し、繰り返し実施されるテストの計画、設計、実装、実行のコストを削減した（テスト自動化はコストの削減をメインと考えるべきではない。という説明も実施） 導入するまでの流れは 2-1 過去バグの収集(開発チームに協力していただいた) 2-2 実行環境の選定 2-3 テストデータの問題と対策を考える 2-4 導入する機能をランキングにした 2-4-1 一気に導入するべきではないと考えたため 2-5 導入する機能に対してリスクベースド分析を実施 2-6 リスクに対して適切なテストレベルの列挙 2-7 テストの設計 2-8 実装(テストコードの実装は開発エンジニアの方が得意だと考え、協力していただいた) ## 探索的テストの支援、普及 私は特に探索的テストはエンジニア以外でも実施すべきと考えている。 しかし - 「テストってエンジニアの業務」だという無意識の壁 - 「そもそもテストって何かわからない」 - 「探索的テストって？」 があると考えたため、エンジニア以外の職種の方に参加してもらい、「モブ探索的テスト会」を開催し、エンジニア以外にもテストのい意味とメリットを感じてもらうようにした