QAEが新規プロジェクトで、はじめにやったこと

こんにちは、hacomonoQA部のたっきー（滝田）とゆう（田中）です。
2024年8月より新規機能開発のプロジェクトが立ち上がり、QAE（QAエンジニア）として参画しました。
プロジェクト初期段階にQAEとして取り組んだ事柄を紹介します。

プロジェクト参画前に

QA部として、アジャイルテストを取り入れていくという目標を立てていました。
このタイミングで新規プロジェクトに参画することになったため、従来のやり方に捉われず、テストおよび開発フローの改善にアプローチすることにしました。

開発フロー改善

開発フローの改善については要素が多いため、今回は「テスト」に焦点を当てます。
以前の開発フローはこちらです。

課題には下記などがあります。

テストはrelease branchで実行される
不具合修正が発生すると他チケットに影響を及ぼしかねない
テストは大別して「受け入れテスト」と「リグレッションテスト」の2つになるため、受け入れテストの比重がとても大きい
不具合検出が開発フローの後半に密集するため、修正・テスト実行の負荷が大きい
release branchから取り除いた際の影響も大きい

これらの課題を解消し、プロダクト品質向上を図るために取り入れた開発フローはこちらです。

新しい開発フローの目的は下記になります。

develop branchまたはfeature branchでテストされるため、他チケットの影響を受けにくい
APIテストはフロント実装を待たずに実行できる
E2EテストとAPIテストは継続的なテストに活用
自動テストでカバーできない領域のみをマニュアルテストで検証する
release branchにマージされる前に多くのテストが実行される
リグレッションテストの軽量化、リリースまでの速度向上を狙うことができる

プロジェクト管理、ポータル作成

開発フローの変化にあわせてプロジェクト管理も改めて整理しました。
タスク管理はJira、テストドキュメントはNotionで行なっています。
Notionにはナレッジや議事録などもまとめて、ポータルとして活用しています。
各工程・ドキュメントのトレーサビリティも取れるようにしています。

受入条件の設定

開発フロー、プロジェクト管理ツールの準備ができました。
この時点で開発設計も進んでおり、ユーザーストーリーが作成されていました。
ユーザーストーリー単位で受入条件を設定しました。

受入条件は対象のユーザーストーリーが完了になっているかのチェックに使用します。
ユーザーストーリーが大きいサイズになっているものについては小さく分解します。
分解の目的はユーザーストーリー、開発、テストの複雑化を避けることです。

テスト分析

受入条件が決まったらQAはテスト分析を始めます。
テスト分析の種類と概要は下記です。

パターンテスト
- システムが取りうる値を入力した際の挙動をみる
- 組み合わせテスト
APIテスト
- ユーザー操作では入力されない値を送信した際の挙動をみる
E2Eテスト
- ユーザー視点の操作を行い対象機能が期待通りの挙動をするかをテストする
マニュアルテスト
- 上記を実行しない場合、同じテストを繰り返し実行しない場合にマニュアルテストを実行する

高頻度なマージを想定しているため、繰り返しテストが実行されるように基本的にはパターンテスト、APIテスト、E2Eテストで対応し、自動テストとして実装していきます。

課題、大変なところ

既存の開発フローからいくつか変更点があるため、チームメンバーと目的や認識をあわせる必要があります。
懸念点などは小さくても無視せずコミュニケーションをとって解消している最中です。

APIテスト、E2Eテストについてはスキル不足もあるため学習しながら進めています。
チームで相談して決めたリリーススケジュールを守れるようにスキルアップを目指さなければいけません。