はじめに
こんにちは！システム開発部 横断開発課でQAエンジニアをしている@two_packです。SEN Advent Calendar 2025の9日目になります！
弊社では横断組織としてQAチームがあり、各プロダクトのQA活動を行っています。 今回は私の関わっているプロダクトで最近一区切りついたとあるプロジェクト（以降PJ）でのテストを基に、どんな感じでテストしているのかを書いてみます。
体制・開発プロセス
PJはPdM、PL、エンジニアを中心としたメンバー構成で、週1回の定例ミーティングで進捗確認や仕様の調整などを行っていました。QAチームもこの段階から参加し、品質・テストの観点から仕様検討に加わっています。 また、定例に出ているメンバー以外にも、デザイナーやSREが適宜支援してくれる体制です。
今回のQAチームは、私のほかにテスト設計以降を行うメンバーが1名、テスト実行からさらに1名という形で対応しました。2人（以降、QAメンバー）は時短勤務で、かつ勤務時間も重複しておらず、フルリモートかつ非同期なコミュニケーションが中心となるため、情報をうまく共有して非効率にならない工夫が必要な環境でした。
PJの開発プロセスはウォーターフォールに近い形式で、QAチームにはシステムテスト以降の役割を強く期待されている状況でしたが、前述の通り可能な限り上流から関わるスタイルで進めました。
テストプロセス
テストプロセスは、以下の4段階で進めています。
- テスト分析
- テスト設計
- テスト実装
- テスト実行
テスト分析
「何をテストするのか」を決めるプロセスです。ここは定例に参加してメンバーと密にコミュニケーションが取れる私が担当しました。テスト対象を整理しながら、テストレベルやテストタイプをQAメンバーと検討し、全体の方針をまとめました。
テスト設計
「どうテストするのか」を決めるプロセスです。ここはQAメンバー主体で実施してもらいました。 Figmaを使って対象機能や仕様を可視化しながら整理していきました。 QAメンバーは全員フルリモートですが、Figma上のボードを共有、Slackのハドルなどで密にすり合わせていくことで、膝を突き合わせているかのような感覚で認識を合わせることができました。
また、探索的テストのチャーターについてもこの段階で作成し、後の工程でブラッシュアップしています。
テスト実装
テスト設計をテストケースに落とし込むプロセスです。ここもQAメンバー主体です。 限られた工数と期間の中で、クリティカルな機能のリグレッション（回帰）テストをいかに効率的に行うかが課題でした。 今回は途中から1名が合流する予定だったため、「誰が見ても迷わず実行できるか」という観点と「効率性」のバランスを考慮し、 テストケースの粒度や記載レベルを入念に調整しました。
テスト実行
作成したテストを実行するプロセスです。進捗はスプレッドシート、不具合管理はGitHubで行っています。 単に消化するだけでなく、ある程度進んだ段階で「検出した不具合の傾向分析」を行いました。分析結果をチームへフィードバックし、作り込みの弱点への対策や、手厚くすべきテスト観点の追加など、プロセスの途中でも柔軟に軌道修正を行っています。
最終的に、テスト終了判定として得られた情報をまとめ、PdMやPLへ共有してリリース判断の材料としてもらっています。実際には日々の進捗報告や段階的な分析共有を行っているため、チーム全体での品質確認の総括という意味合いが強いです。
最後に
つらつらと書いてきましたが、行っていること自体は標準的なテストプロセスを地道に回しているに過ぎません。 しかし、「当たり前のことを、当たり前にやる」ことが品質保証の第一歩だと考えています。この土台をベースに、より効率的で価値あるQA活動を目指して、引き続き改善を積み重ねていきます！
SEN Advent Calendar 2025 10日目となる明日は たにおりさん です！お楽しみに！
そして！
私たちと一緒に、幼保業界や写真業界のDXを進めていく仲間を募集中です！
QAエンジニアの募集も行っていますので、ご興味がある方はご覧になってみてください！
📋 採用情報
