こんにちは、QA部のまっちゃんこと松田です！
今回は私のチームで取り組んでいるテストプロセス改善について紹介します。

はじめに

これまで私の所属するチームで行っているテストでは手動によるブラックボックステストのみ行っていました。ひと通りの機能実装の後にテスト実施に着手する流れとなっていました。

具体的な流れは、以下のようになっていました。

機能実装が完成
画面上で対象機能のテストを行う
また、複数の機能を同時開発している場合は、下図の流れで開発とテスト実施していました。

以下の課題を感じていました。

機能実装の完成を待つことによるテスト着手のリードタイムが長くなっている
テスト対象が大きくなることによる、不具合リスクの増加

改善のための取り組み方針を以下のように決めました。

前提として、不具合の早期発見は修正コストの低減につながる。という考え方を取り入れ、下図のようにプロセス改善に取り組みました。

具体的に以下のような活動をしました。

テストリードタイムの短縮化

テスト可能な最小単位で開発チケットを作成する。
これを実現するには、担当の開発メンバーとの連携が必須です。
- 必要があれば既存の開発チケットを分割してもらうなどQAからも働きかけを行います。
APIテストの導入
- 最小単位のテスト実施を行うためには必然的にAPI単位のテスト実施が可能でなければなりません。
- APIをリクエストした際の挙動をテストするAPIテストを取り入れました。
  - APIテストはPostmanを使用して実施しています。
実装状況のモニタリング
- テストリードタイム短縮のために開発完了をいち早くキャッチアップする必要があります。
- プルリクエストのマージ時にメッセージを投稿するbotを用意しチャンネルに自動投稿することで、テスト着手のタイミングを明確化しました。
- テスト実施開始の際にもチャンネルに自動投稿を行い、開発完了からテスト実施完了までの状況をチーム全員がSlackのみで把握できるようにしました。

テスト対象の細分化

開発チケットの切り分け
- チケット単位でテストを実施する準備のために以下の取り組みを行いました。
  - チケット単位でテスト可能な最小単位に切り分ける。
  - 複数の機能開発が含まれないようにチームで調整
探索的テストの導入
- 細分化したチケットごとに探索的テストを導入しました。
- テスト設計を最小限に収めることでテスト実施着手までの時間を短縮しました。

ここまでは、当初の想定と大きなズレはなく、タスクを小さくすることや早く動くことで、関心事の範囲が狭まり、チーム全体として、コミュニケーションが取りやすくなったと感じています。

以下は改善した後に感じた内容です。

実施してみて感じたメリット

テスト対象の明確化
- チケットをテスト可能な最小単位にしたことで、テストすべき機能・画面も小さくなりました。
- 探索的テストで十分テスト可能と判断できるチケットが増え、結果としてテスト設計にかかる工数の削減ができました。
不具合の原因特定の容易さ
- 最小単位のテストのため、不具合の原因特定が容易になりました。
- 不具合チケットの起票スピードが向上しました。
- 改善前のプロセスでは、不具合の原因特定が難しく、不具合チケットを誰にアサインするか？など不具合検出後の情報整理に時間をかけていましたが、この時間をなくすことができました。
テスト実施の負荷分散
- テスト実施を常に行い続ける性質上、テスト実施期間が集中しないため極端に稼働が上がるタイミングが無くなりました。
- 短期間で不具合発見が集中することもなくなりエンジニアの負担も軽減されました。
テスト実施の可視化
- テスト完了時にチケットをクローズすることで、テスト実施中のチケットが可視化されるため開発メンバーを含めたテスト進捗の共有がこれまでより容易になりました。
- Slackにbot通知を設定したことにより、自動投稿を起点に開発メンバーとQAメンバーのコミュニケーションが生まれるようになりました。

やってみて感じた課題

プロセスの改善から間もないためまだまだ課題に感じていることもあります。

最小化したチケット単位の実施のみでは品質に懸念がある
- 最小の機能のみにフォーカスしたテストでは当然ながら機能全体を通したシナリオテストや複数機能の因子を絡めたパターンのテストは行えません。
- 最小単位のテスト以外に以下のテストを実施して品質を担保することを目標としています。自動テストを含めたアプローチはまだまだ完璧ではないため今後の課題となっています。
  - PRDに定義されたストーリー単位のテスト
    - マニュアルテストと並行してE2Eテストを実装する
  - 全機能が実装された段階で全体のリグレッションテストの実施
    - 合わせてストーリー単位でのテスト時に作成した自動テストの実行
テスト対象の細分化ができていないと悲惨
- まだまだプロセスに慣れていないため複数の機能を内包したチケットを見逃してしまうことがあります。
- テスト可能な状態になってから気がつくと軌道修正が大変です。
- チーム内での認識の共有とコミュニケーションの活発化でチケットの切り分けを実現する必要があります。