課金基盤の長期開発プロジェクトにおける総合テストの実践と学び

こんにちは！品質保証部のプロダクト基盤ユニット所属、QAエンジニア（以下、QAE）のchokichiです。

今回は、「雇用形態別課金」プロジェクトの総合テストについて振り返ってみたので、設計思想から実際の結果分析まで、包み隠さずご紹介します。
※本記事でいう「総合テスト」は、外部システムとの連携や運用フローの確認も含めたリリース前の総合的なテストという意味です。

「雇用形態別課金」プロジェクトは、課金基盤チームが約11ヶ月という長期間をかけて開発した大規模プロジェクトです。そのうち、総合テストは約3ヶ月かけて実施しました。
同じように長期開発プロジェクトに取り組んでいる開発チームの皆さんや、基盤での大改修プロジェクトを担当するQAEの皆さんに、少しでも参考にしていただけたら嬉しいです。

これまでに課金基盤チームで私が行なった取り組みについては、以前書いた「複雑な課金基盤の内部仕様にまで踏み込んだQAエンジニアの取り組み」を読んでいただけたら幸いです。

総合テストを行なった経緯

今回のプロジェクトは、課金基盤という慎重な取り扱いが必要なプロダクトに対する長期間の改修でした。
また、他部署も関わる運用フローを変更する必要があるため、新機能と新運用フローが意図通りに動作するかを確認する必要がありました。

特に運用フローは普段のスプリント毎のテストでは確認できないため、他部署と協働して総合テストを実施することにしました。

総合テストの目的

総合テストではスプリント毎のテストで確認できていない以下を確認するのを目的としました。

• 長期開発によるリスク検証
  • 11ヶ月という長期開発の中で仕様変更も発生したため、全体を通して一貫性のある仕様になっているかを確認したいため
• エンドツーエンドでの動作検証
  • 個別機能テストでは検証しきれない外部システム連携を含む統合動作を確認したいため
• 運用フローが適切であるかの検証
  • 機能提供と決済に関する既存の運用フローを変更する必要があり、新しい運用フローがプロダクトに適合するかを確認したいため

スプリント毎のテストとの違い

普段のスプリント毎のテストと、総合テストの違いを表にまとめました。

観点	スプリント毎のテスト	総合テスト
テスト範囲	個別機能・ストーリー単位	外部システムを含むシステム全体の統合動作
テスト期間	1週間のスプリント内	約3ヶ月間の専用期間
テスト環境	基本的には開発環境	ステージング環境に専用企業アカウントを複数準備
参加者	開発チーム	開発チーム + 運用チーム
テスト観点	機能要件の動作確認 ストーリー単位の価値提供 既存機能への影響確認	外部システム連携時の機能提供 ビジネスシナリオ 運用フロー
データ準備	最小限のテストデータ	実運用に近い複雑なデータパターン
テスト実施方法	自動テスト 手動テスト	手動テスト

4つのテスト区分による多角的検証

上記の「テスト観点」に記載した通り、総合テストで保証したい観点が多岐に渡るため、目的別に以下の4つのテストを実施することにしました。
「総合テスト振り返り」の項でも触れますが、各テストがそれぞれの目的に合った成果をあげられたため、いずれも守りたい品質を守るために必要なテストでした。

連携時機能テスト

• 目的
  • 外部システム連携時のストーリーベースでの機能動作検証
• 特徴
  • ストーリーチケットを再整理してテスト観点を作成
  • 外部システム連携時に各機能が要求通りに動作するかの確認として、ストーリーに対してテスト観点を作成しパターン化
  • パターンをテストケースに落とし込みテスト実施
  • プロダクト側の機能に関するテストはこちらに集約
• 参加者
  • テスト設計
    • QAE + プロダクトマネージャ
  • テスト実施
    • 開発チーム（QAEを含む）

シナリオテスト

• 目的
  • 主要な契約パターンでの請求処理検証
• 特徴
  • 運用チームと協働で、請求に至るパターンのシナリオを作成・実施
  • 外部システムとの連携による請求データの正確性を重点確認
• 参加者
  • テスト設計・実施
    • 運用チーム + QAE

通しテスト

• 目的
  • 実運用に沿った複雑な契約変更パターンでの動作検証
• 特徴
  • 外部システムで「年度更新」「部分解約」「契約期間変更」等のさまざまな契約パターンを行なった場合を想定
  • 実際の運用中に発生しうる正常系と、設定ミスなどの非正常系の確認を実施
  • 外部システムの挙動に関するテストはこちらに集約
• 参加者
  • テスト設計・実施
    • 運用チーム + QAE

不安/リスクベースドテスト

• 目的
  • チーム全体で洗い出した不安要素やリスクの検証
• 特徴
  • 開発メンバー全員 + 運用チーム参加でのリスク洗い出し会を実施
  • 洗い出し会で出た不安やリスクを「影響度」と「発生確率」の四象限で分類し、優先度の高いものを対象にテスト設計を行なった
  • 普段使っているOSとブラウザの組み合わせ以外のテストや、公開APIへの影響確認を実施
• 参加者
  • リスク洗い出し会
    • 開発チーム + 運用チーム
  • テスト設計
    • QAE
  • テスト実施
    • 開発チーム

テストスケジュール

以下の図は実際のテストスケジュールです。

まず始めに全体のテスト計画から始めました。ここでテスト戦略としてテスト区分の作成と各テストのスコープを定義し、開発の進捗状況や運用チームとの連携タイミングを考慮した計画を立てました。
その後、一番最初にテスト実施する連携時機能テストからテスト設計を開始し、並行して運用チームと協働でシナリオテスト設計を行ないました。

開発の状況を見ながら連携時機能テストの実施を開発チームに始めてもらいつつ、QAEは引き続き運用チームと協働で通しテストの設計をしたり、不安/リスクベースドテストに向けた会議の準備を進めました。

このように、QAEが自身でタスクを進めながら計画に対して必要な人を巻き込んでいくことで並行して複数のタスクを進められ、大規模ながらも効率的にテスト設計・実施ができました。

不具合分析の結果と学び

不具合分析では以下の4つの分類で分析を行ないました。

分類	概要	結果
検出タイミング別	どのテストで検出されたか	連携時機能テストでの検出が最多
機能カテゴリ別	どの機能で検出されたか	基本機能に新しく追加した画面での検出が最多
原因別	何が原因で不具合が発生したか	影響範囲考慮漏れが最多
検知漏れタイミング別	どのタイミングで検知できていれば防止できたか	仕様策定やプロダクトバックログリファインメント（PBR）時の考慮漏れが最多

以下は上記結果を深堀りしてまとめたものです。

検出された不具合数

• 総件数
  • 21件
• 検出タイミング
  • 総合テストのうち、最初に実施する連携時機能テストで不具合を14件発見

主要な不具合の分類

• 特定の状態での発生
  • プランが1つの場合や雇用形態削除時など、特定の状態でのみ発生する不具合
• 仕様の不透明性
  • もともとどういう仕様にするか定かでなかったが、総合テストで期待値を明文化したことで不具合であることが明らかになったもの
• 影響範囲の確認不足
  • 同じ仕様で動く他の箇所への影響見落としや、前処理・後続処理に影響がないかの確認不足によって検出された不具合

原因別分析

• 影響範囲や受け入れ条件での考慮漏れ
  • 最多で発生。改修対象に対してどういったパターンが存在するかの認識と、どこまで改修・テストが必要かを考慮しきれていない部分があった
• UI関連の認識のズレ
  • デザイン案と実装後のデザインやテキストに認識のズレが発生した
• 仕様策定・設計時の検知漏れ
  • 改修が必要な箇所の洗い出し不足や、設計工程で実運用を想定しきれていない部分があった

主要な学び

• 仕様策定段階での詰めの重要性
  • 実装前のプロセスでの考慮漏れが不具合の主因となっているため、PBRや設計段階でよりシステムを俯瞰して捉え、実運用を想定したパターンの洗い出しが必要
• 運用パターンの体系化の必要性
  • 運用に外部システムが絡んでいて複雑なため、運用時にどういったパターンが発生するかの認識にバラつきがあるため、考慮すべきパターンをドキュメントにまとめるなどの体系化が必要
• 仕様の不透明性への対処
  • チケットに記載された対応内容や受け入れ条件だけでなく、認知範囲外への思考と問いかけを行なっていけるようにする。また、仕様が不透明な部分については曖昧なままにせず決めきる力が重要

総合テスト振り返り：効果的だった点 / のびしろ

総合テストと不具合の分析結果を踏まえて、「効果的だった点」と「のびしろ」をまとめました。

効果的だった点

• 運用チームとの協働
  • 運用フローとプロダクトの整合性確認により技術的な検証だけでは見落とす観点を補完し、ビジネス観点での検証が実現
• 4つのテスト区分によるテスト設計
  • それぞれのテストが補完し合う構造で多角的な検証が実現
  • 最初に実施した連携時機能テストで多くの不具合を潰すことができ、後続テスト時に同じ不具合を踏まないように進められた
  • 通しテストにより、個別機能テストでは検出困難な重大な不具合を発見

のびしろ

• 総合テストに準備を含めて約3ヶ月という長い時間がかかった
  • ストーリーの整理を総合テスト前に済ませ、いつでもテスト設計が開始できる状態にしておけると良い
  • 開発スコープについてもなるべく細分化し、段階的に検証できると良い
• 外部システム仕様のインプット不足により、外部システムと課金基盤の不具合切り分けに時間を要した
  • 外部システム仕様をドキュメント化し、コミュニケーションコストを削減するなどの工夫が必要
• 実装より前の工程で考慮漏れが多く発生したため、受け入れ条件の網羅性などの仕様策定時に課題があった
  • 運用パターンを含むPBR時の考慮点を標準化できると良い

最後に

以上が約11ヶ月という長期間をかけて開発した「雇用形態別課金」という大規模プロジェクトの総合テストについての計画・設計・実施・分析の全容です。
これだけの長期間をかけ、影響箇所が多岐に渡る開発はSmartHRに入社してから初めての経験だったので、私自身学びが多いものでした。
特に、テスト毎の目的を強く意識したテスト設計や、日常的に関わっていないチームとの連携方法について、苦労しながら学びを得られました。

こうした貴重な体験ができるのはプロダクト基盤ユニットならではなので、一緒に良いプロダクトを早くお客様に届ける仲間が増えたら幸いです。

We are Hiring!

SmartHRでは一緒にSmartHRを作り上げていく仲間を募集中です！少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！

youtrust.jp

open.talentio.com

open.talentio.com