ソフトウェアテストのよくあるアンチパターン3選(過剰、不明瞭、属人化)の改善例

1. はじめに

この記事は、アソビュー! Advent Calendar 2024 の4日目(表面)です。
こんにちは、アソビュー株式会社でQAエンジニアをしております空です。
アソビューではQAが各プロダクトに配置されています。
僕は今年の5月から現在のプロダクトにジョインし、テストの課題に取り組んできました。
その中で遭遇したプロダクト品質に関するソフトウェアテストの課題と対応についてご紹介いたします。
すべてのプロジェクトに当てはまるわけではないと思いますが、何かしらのヒントになりましたら幸いです。

2. 遭遇したアンチパターンとその課題

2.1 過剰なテストケース

発生した状況の説明

エンハンス開発(機能拡張や改善を目的とした開発)の個別案件で作成したテストケースを、リグレッションテスト(改修が既存機能への影響が無いことを確認するテスト)で使い回した結果、テストケースが必要以上に増えることにつながっていました。

課題の詳細

具体的には、案件ごとに同じサービスや機能を改修しており重複したテストケースが点在している状況になっている箇所もありました。
また、案件によっては単体テスト粒度のテストケースの構成となっており、ケース数が多いが実りが少ないテストケースとなっている箇所もありました。
その結果、テストの管理も煩雑になり、テスト実行に時間がかかる状態に陥っていました。
この過剰さが原因で、毎回テストに大きな工数が必要となり、他タスクに割ける時間が不足するという弊害が発生していました。

2.2 不明瞭なテストケース

発生した状況の説明

テストケースの内容が抽象的で、何を検証するためのものなのかが一目で理解できないものが多くありました。

課題の詳細

具体的には、テスト仕様書にテスト対象のサービス・機能・画面項目が分類として記載されていました。
しかし、どういった内容でどこまで検証しているかといった検証内容を、1ケースずつ記載された手順や期待値を読み解かないと理解できない状態でした。
また、過去に利用していたテスト管理ツールに特化した記載となっていた箇所もあり、その記載に慣れていないメンバーが見た時に内容を把握しにくい状態でした。
その結果、分析時に余分な時間がかかる場面が頻発しました。
この不明瞭さによって、エンハンス開発時にテストを効率良く回していくことが難しくなっていました。

2.3 属人化

発生した状況の説明

テスト実行に関する知識が特定のメンバーに集中しており、他のメンバーがテストをスムーズに行えない状態でした。

課題の詳細

具体的には、テストケース実行に関する情報が適切に管理されず、次回の担当者が前回の担当者に聞いて実行するということが頻発しておりました。
また、実行時に気付いた内容を実行結果にメモ書きされている箇所もありましたが、その場限りで次回以降に活かされていないこともありました。
結果として知識が共有されていないため、担当者の不在時に進行が滞るという弊害もありました。

3. 実施した対策

3.1 過剰なテストケースへの対策(改善と成果)

具体的なアプローチ

リスクベーステスト(例:購入などバックエンドでの重要な処理を行う機能をクリティカルパスとして重視するテスト)を採用して、重要な機能に集中できるよう優先順位を明確化しました。
また、リリース案件に応じて機能の重み付けをしてテストケースの比重を動的に変更するようにしました。
機能一覧のテストカバレッジを明確化して、重複箇所の省略やテストしていない機能が発生しないようにしました。

得られた結果

一定の品質を保ちながら、リグレッションテスト実行時間が半分以下(1か月を2週間弱になるなど)に短縮しました。

3.2 不明瞭なテストケースへの対策(改善と成果)

具体的なアプローチ

テストケース記述の標準フォーマットを導入し、全体的な視点から、何を担保するのかを明確に記載するようにしました。
各ケースの意図や期待する結果を明確に記載するガイドラインを作成しました。

得られた結果

テストケースの読みやすさが向上し、テスト観点の抜け漏れを減らすことに繋がりました。
結果として、レビュー時間の効率化も行えました。

3.3 属人化への対策(改善と成果)

具体的なアプローチ

テスト実行時に気付いた内容を、マスターとなるテスト仕様書に集約して、前回の担当者に聞かなくてもスムーズに実行できるようにしました。
また、Confluenceを用いてテスト実行時に使用したマスタデータなどを一元管理しました。誰でも参照可能な状態を維持しました。

得られた結果

作業が記録として残ることで、他者が担当範囲を引き継ぐ際の負担が軽減しました。プロジェクト全体の継続性が向上しました。
また、ドキュメント化に際し、チームメンバー間でのコミュニケーションや連携が向上し、ワンチームで進められるようになりました。

4. まとめ

  • 過剰なテストケースを整理することで、実行時間や管理コストを大幅に削減できることを実感しました。
  • リスクベーステストの導入によりリグレッションテスト工数を軽減して、重要な部分にリソースを集中させることが可能になりました。
  • 不明瞭なテストケースを明確化することで、キャッチアップとレビューが容易になりました。
  • 属人化の対策として、実行結果を適切に記録することで、チーム全体での作業効率化や継続性を確保できました。
  • 全体的な効率化により捻出できた時間を、他のタスク対応に充てられるようになりました

5. 終わりに

プロジェクトごとに状況や優先度は異なるものの、今回の改善を通じて品質向上と効率化の両立に手応えを得ました。
今後は、自動化やリソースの最適化を進め、引き続き改善を進めていく予定です。

アソビューでは、「生きるに、遊びを。」を実現するための良いプロダクトを担う様々なエンジニアを募集しています。
カジュアル面談のご希望も随時お受けしておりますので、お気軽にエントリーください!
お待ちしております。

www.asoview.com