SET, QAエンジニア2024年振り返り

T-Y.dev

はじめに

今年一年お疲れ様でした！
初めての試みですが、2024年の振り返りを書いてみました。
ここで書いた解決策や考えは当時の僕なりの物であって、絶対ではないですし、必ずしも正解ではないと思っています。
むしろ、サービスや自分が成長していく中で、もっといい方法が見つかると思っています。
その前提のもと、という一つの参考事例として読んでいただければ嬉しいです。

トピック

初めに、個人的トピックを2つ書きます。

SETだけでなくQAも専門領域になった

入社から2年間はSETとして働いていましたが今年からQAも専門領域になりました。SETとQAの両方を経験することで、より幅広い視野・手段を持つことができました。
チームとしてはSETとQAの役割を統合することで、これまで以上に効果的な開発者支援を行うことができるようになりました。
SET時にJSTQB FLを取得し基礎は知っていましたが、実際にQAの業務を行うことで実践的な知識を得ることができると同時に難易度の高さも感じました。
SETとの違いを感じたのは以下の4点です。

  1. ユーザー視点の重要性:

    • SET時は技術的観点から品質・開発者体験向上を実施する機会が多かったのですが、QAではユーザーの観点から製品を評価することが求められると感じました。これによりUXの重要性を改めて認識することになりました。

  2. リスクと優先順位の管理:

    • QAでは様々なテストケースやバグの中で、どの問題がよりリスクがあり優先すべきかを判断する能力が求められます。これはSETでの業務とは少し異なるスキルセットだと感じました。

  3. コミュニケーションの増加:

    • QAは多くのチームと連携して品質向上させる役割があるため、開発者やデザイナー、プロジェクトマネージャーとのコミュニケーションが増えました。

    • コミュニケーションを取りながらの業務は向いており、高い成果を上げることもできたため、今後も積極的にコミュニケーションを取りながら業務を進めていきたいと考えています。

  4. テスト戦略の多様性:

    • これまでは手札に自動テストだけだったのが、自動化テストだけでなく、手動テスト・探索的テストなど様々なテスト手法を組み合わせて行う必要があるため、より複雑で噛み応えがありました。
      SETのスキルに加えQAが増え、オーナーシップをもって様々な手段を検討し他職種と連携ながら進める経験ができました。

副業で1人目QAとしてジョインした


同じ会社で働いていた先輩がCTOを務める会社から、副業でQAエンジニアとしてジョインする話を頂きました。
自分のスキルが課題解決に役立つと感じたため、1人目QAエンジニア（業務委託）としてジョインしました。
現時点では主に以下の業務を行っています。

  • リグレッションテストの自動化

  • 野良探索的テストの実施

稼働時間の問題で手を出せていない部分もありますが、初期フェーズから参加できることは非常に貴重な経験だと感じており、今後も継続して開発者体験と品質向上に貢献していきたいと考えています。

2024年にやったこと

今年やったことを書いていきます。前述の通りSETとQAの両方が専門になったため、幅広い業務を行うことができました。
前提として、ドメイン知識が多いタスクは省いてます。
あと書いてて気づいたんですが、QAとしてのPJはドメイン知識が多くて書きにくかったので、SETのPJが多いです。

E2Eテストのシフトレフト


今年のメインPJであり初めてのPJリーダーを経験しました。このPJのお陰で全社MVPも獲得でき、社内での自分の顔も広まりました。

このPJの振り返りはテックブログにも書いています(ブログの内容は2024年6月の状態)。

このPJではE2Eテストのシフトレフトを推進し、統合ブランチでのテスト実行時間を80%短縮する取り組みを主導しました(現在は全てシフトレフト済み)。このプロジェクトでは、開発プロセスの初期段階でテストを実施することで、品質向上と開発効率の改善を目指しました。

プロジェクトの背景と課題

当初、developブランチへのマージ後にE2Eテストを実行しており以下の課題がありました。

  • リリースまでの時間: developブランチへのマージから本番環境への反映までに約8.5時間を要していました。

  • QAチームの負担:日々1～4時間の工数がかかり、手動での確認作業が必要でした。

  • 手戻りの多さ:E2Eテストでバグを検知した際の手戻りが多く、リリースの遅延や品質低下のリスクがありました。

取り組みと成果

これらの課題を解決するため、以下の施策を実施しました。

  • テストのシフトレフト:E2EテストをPull Request上で実行可能にし、コードのpushからテスト完了までを5～8分に短縮。

    • テスト実行〜完了の流れ:

      1. 開発者がリモートにPush

      2. CIによってECSコマンドを実行

      3. ECS taskが起動し、テストを実行

      4. テスト結果をPull Requestに表示

      5. テスト結果に従い、Github Status APIを利用してマージ可否を判断

    • テストケースの削減と最適化:テストケースを再評価して削除・リファクタリングを行い、30%を削減。これによりテストの実行時間とメンテナンスコストを削減しました。

    • 自動化の推進:インフラチームと協力しPRごとに一時的な検証環境を構築。これにより、開発者が迅速にフィードバックを得られる体制を整備しました。

  • 運用課題の発見・改善

    • リリースしたら終わりではなく、ユーザーと定期的なコミュニケーションを通じて運用課題の発見・改善を実施しました。

工夫した点

GitHub ActionsでのAWS認証をOIDCで実装

このPJではAWS認証をIAMユーザー認証からOIDCによるIAMロール認証に切り替えました。
IAMユーザー認証の場合、GitHub Actionsのシークレット変数にAWS_ACCESS_KEYやAWS_SECRET_ACCESS_KEYなどの機密情報を保存する必要があります。万が一これらが漏洩してしまうと、AWSのリソースが不正に操作されてしまいます。
OIDCによるIAMロール認証を導入することで、GitHub Actionsのシークレット変数に機密情報を保存する必要がなくなり、セキュリティを向上させることができました。

6月以降にやったこと

上記は6月までの成果ですが、その後も以下の改善活動を実施しました。

多重実行防止

テスト実行時に同じテストが複数回実行されることを防ぐため、テスト実行中にテストの実行を操作する仕組みを導入しました。

起こっていた問題

「pushされるたびに自動テストが走る」仕組みになっているので、連続でpushされた場合に同じテストが複数回実行されることになります。
これでは余計なコストがかかるだけでなく、アプリケーションに余計な負荷がかかっていました。

解決策

新規でテストが実行される際に、実行中のテストを停止する仕組みを導入しました。
具体的には以下の流れです。

  1. コードがpushされた際に、同じPRに対して実行中のテストがあるかを確認

  2. 実行中のテストがある場合、そのテストをstop-taskを使って停止

  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テストをモニタリングし数字も出していこうと思います。

QAグループ所有のソフトウェアのRubyバージョンアップデート


このプロジェクトで「落ちているボールを自ら拾いに行く」を体現できたと感じています。
ライブラリや依存関係のアップデートのタスクは腰が重い場合もあるかと思いますが、自ら進んで取り組むことで、パフォーマンスやセキュリティの向上に貢献できると感じました。

対象はQAグループが作成したOSSのBucky-coreのRubyバージョンを2.6→3.2アップデートを行いました。
リリースタグはこれです

手順

特に特別なことは行っていないと思いますが、手順を書いておきます。
こういったアップデートは初めての経験なのでかなり大変でした。

  1. 全体の手順作成

    1. 初めての経験だったので、リリースまでの手順をまとめました。

  2. 新バージョンの情報収集:

    1. リリースノートの確認: Rubyの公式サイトでリリースノートを確認し、新バージョンでの変更点、新機能、非互換のアップデート、バグフィックスなどを把握します。

    2. 互換性の確認: 利用しているGemやライブラリにおいて、サポートされているRubyバージョンを確認します

    3. 今回は裏でSeleniumを使っているため、Seleniumのサポートバージョンも確認しました。

  3. 実装:　

    1. バージョンアップの実装: Rubyと依存ライブラリのバージョンをアップデートし、コードの修正や変更が必要な箇所を修正

    2. テスト:(QAエンジニアなのでこの部分はかなり自信を持って取り組めました)

      1. ユニットテスト: ユニットテストを実行し、アップデート後のコードが正常に動作することを確認。

      2. 結合テスト: 結合テストを実行し、他コンポーネントと連携して正常に動作することを確認。

      3. システムテスト: batsによるシステムテストを実行し、アップデート後のコードがユーザーの操作に対して正常に動作することを確認します。

      4. 受け入れテスト:実運用を想定したテストを実施し、アップデート後のコードがユーザーの要求を満たすことを確認

  4. 本番環境へのデプロイとモニタリング:

    • 監視: 本番環境へのデプロイ後、アプリケーションの動作をモニタリングし、エラー発生時の対応を迅速に行えるよう監視体制を整えました

自動テスト導入支援


SETとして自動テスト導入支援を行いました。
具体的には以下のような業務を行いました。

  1. ヒアリング:

    • チームの現状やプロダクトの詳細、割ける工数をヒアリングしました。

    • 頂いた情報を踏まえてリグレッションテストの自動化が最適であることを提案しました。

  2. 役割の決定:

    • プロダクトチームへの教育も兼ねて、テスト計画と設計はQAグループが担当し、テストスクリプトの実装はプロダクトチームが担当することになりました。

      • 実装されたコードがテスト設計書に沿っているかを確認するため、QAグループがレビュー担当になりました。

  3. テスト計画:

    • 5W1Hを明確にするため、テスト計画を策定しました。

    • 計画書をプロダクトチームに共有し、テスト範囲やスケジュールを確認しました。

  4. テスト設計:

    • テスト計画を踏まえて具体的なテストケースを設計します。

  5. テスト実装:

    • すでにプロダクトに導入されていたテストフレームワークを利用し、テストスクリプトをプロダクトチームに実装して頂きました。

  6. 導入　

    • テストスクリプトの実装が完了したら、CI/CDパイプラインに組み込み、運用を開始しました。

  7. プロダクトチームへ移譲:

    • slackでプロダクトチームとの連絡用チャンネルで質問を受け付け、運用後の課題を解決するサポートを行いながらプロダクトチームへ移譲しました。

工夫した点

最初のヒアリングの時点で自分がSET,QAであるという意識をあえて持たないようにしました。なぜなら「自分の持っている専門性で解決しよう」と思ってしまうからです。
あくまでもプロダクトチームの課題を解決するために、支援を行うという意識を持ちました。今回は自動テストの導入が一番だと判断しましたが、場合によってはプロダクトチームへの教育などを提案していたかもしれません。

自分の強み・弱み


上司や同僚からの以下のようなフィードバックを踏まえて、自分の強みと弱みを書いていきます。

強み

  1. プロジェクト推進力: E2Eテストのシフトレフトをはじめとして、自ら考えて課題を解決し、チームの原動力となった。

  2. 越境力とコミュニケーション: 他チームや他部署との積極的なコミュニケーションを通じて越境力が発揮できていた。

  3. 迅速な対応力: 他部署からの質問に即座に対応できる力を発揮。

    1. 平均を出してみたら、最初の返事1分1秒で返信していました

  4. チームへの良い影響: タスクをこなす姿勢がチーム全体に良い影響を与えていました。

  5. プロフェッショナルとしての成長: 上位等級者の支援を受けずに、他部署とプロフェッショナルなやり取りを行えました。

弱み

  • 成果物の質をさらに高める

    • タイポやデバッグlogの消し忘れが散見され、正確性を高めるための工夫が必要

2025年に向けて

2025年に向けての目標や、やりたいことを書いていきます。

ネイティブアプリの品質向上に貢献したい

今まではWebアプリの品質向上に貢献してきましたが、ネイティブアプリの品質向上にも貢献したいと考えています。
理由は以下の通りです。

  1. ユーザー体験の向上: ネイティブアプリはWebアプリに比べて一般的に高速で、よりスムーズなユーザー体験を提供できると考えています。

    1. ユーザーの満足度を高め、日常の効率や満足感を向上させることができます。

  2. アクセシビリティの向上: ネイティブアプリはデバイスのハードウェア機能にアクセスしやすく、より包括的で有意義な機能をユーザーに提供できると考えています。

  3. よりパーソナライズなユーザー体験: ネイティブアプリは、デバイス上のデータや設定に基づいて、より最適化された体験を提供することが可能です。QAエンジニアとして、これらのパーソナライズ機能の品質に貢献したいと考えています。

第二言語のスキルを向上させ、海外チームとの協業したい

英語を使って海外チームとの協業も行いたいと考えています。理由は以下の通りです。

  1. グローバルなチームとの協力
    異なる国や文化を背景とする同僚と円滑にコミュニケーションをとることができ、より広範なチームワークが可能になり得ると考えています。

  2. 学習機会の拡大
    最新の技術トレンドやベストプラクティスに関する情報にアクセスしやすくなり、これをローカルチームやコミュニティと共有することで、全体の技術力向上に還元できるためです。

いいなと思ったら応援しよう！