こちらの記事は、アソビュー！ Advent Calendar 2024の7日目（裏面）です。
はじめに
アソビューでQAエンジニアとして働いている丸山と申します。一般顧客向け自社サイトを中心にQA業務を行っています。現在、日々の業務では主にテスト設計やテスト実施を担当しています。
ソフトウェア開発の現場でテストを設計する際、機能を参考にして単純にテスト項目を作成していくと、スケジュールに収まりきらないテスト量になる事態がしばしば発生すると思います。機能について詳しく調査すればするほど考慮すべき要素が多くなり項目数が膨らみますが、納期を後ろ倒しにすることはできず、「テスト項目を絞る必要がある」という判断を求められる場面が出てきます。
このとき、どのようにテスト項目を削減するかについて悩むことはないでしょうか？
今回は、テスト項目の削減に関する一つのアプローチとして、直近で私が関わった開発案件における優先度を活用した事例をご紹介します。
実際の開発案件での事例
開発機能の概要と状況
今回ご紹介するのは、社内でメールマガジン配信機能を開発した際のお話です。従来は社外のシステムを利用してメールマガジンの作成・配信を行っていましたが、自社システムでこれを実現することを目的とした新規開発プロジェクトでした。
このプロジェクトでは、社内で同様の機能を開発した事例がなく、完全に新規の機能として進める必要がありました。また、運用開始時期は要件が決まる前に固定されており、変更が難しい状況からのスタートでした。
テスト計画・設計開始段階での調整
要件が固まる段階で、テスト項目をどのように取捨選択する必要性を感じました。今回のメールマガジン配信機能では、以下のような特徴があるからです。
- メール作成時の自由度が高く、画像やテキスト、リンクを自由に配置できる
- 配信設定に関する項目も多く、組み合わせまで考慮するとテスト量が肥大化する
設定項目が多く自由度も高い＝組み合わせが膨大になる。テストの計画・設計を始める時点でこの点は明確だったので、初期時点で開発チームリーダーと協議し、以下のように調整しました。
- 複数要素の組み合わせテストは開発部門内では最小限の確認とする
- 並行して運営チームに本番を想定した記事作成を依頼し、実地テストを行う
こうした調整で開発部門内のテスト量をある程度減らしましたが、それでもテスト項目数は多すぎる状態でした。そこで使用したのが「優先度」の考え方です。テスト要素に対して優先度づけをして、テスト項目の絞り込みや粒度の調整を行います。
テスト効率化のための優先度付け
テスト項目に優先度をつける際の視点はさまざまあります。以下に代表的なものを挙げます。
- リスクベース：バグ発生の可能性や影響の大きさを基準に設定
- 履歴ベース：過去のテスト結果に基づいて優先度を設定
- 技術的複雑性ベース：新技術や複雑な機能に注目して設定
- 顧客優先度ベース：顧客が重視する機能を優先する
- ビジネス価値ベース：システムや機能のビジネス価値を考慮して設定
- コスト（時間）ベース：テストに必要な工数を基準に設定
- 頻度ベース：利用頻度が高い機能を優先
- 変更点ベース：修正や追加部分を優先
- カバレッジベース：仕様やコードのカバレッジを重視して設定
ざっと挙げただけでも結構な種類がありますが、重要なのは「何を重視するか」を明確にすることです。基準が曖昧だと項目の絞り込みが不十分になりかねません。まず主とする基準を決め、その後必要に応じて複数の視点を組み合わせるのが効果的です。
今回の機能開発ではリスクベースを採用
上の優先度の視点の中からメールマガジン配信機能ではリスクベースを中心に採用しました。
リリース時期が確定していてマストとなる状態の為、全ての不具合を取り除くことは難しい状態であり、より重要な不具合を優先で取り除いていかないといけない状態でしたので、リスクベースの視点の中でもバグ発生時の影響の大きさを基準とした優先度で切り分けを行う必要があると判断しました。
不具合が発生した場合の影響の大きさについては顧客優先度ベース（顧客が何をしたいと思うか、どういった操作を行うことになるか）、ビジネス価値ベース（ビジネス面でどのような目的を持っているか）といった視点も考慮します。
メールマガジンの配信機能であればお得な情報や人気のプランに関してメールを見るお客様に魅力が正しく伝わる形で提示できること、お客様がメール内のリンクから正常にアソビューのプラン紹介ページへ進み、予約などが行えることが具体的な目的になります。
作成したメールが正しく表示されない、リンク等から正しく自社サービス内へ進めないといった不具合が出ると目的を達成できませんので優先度を高く設定。そもそも送信自体ができなければ意味がありませんし、誤送信をしてしまうとお客様へご迷惑をかけてしまいますので、そうした基本的な送信機能や安全対策についても優先度を高めに設定することにしました。
優先度に基づくテスト項目の分類
方針が決まったら優先度を高・中・低の3段階に分け、以下のように項目を割り振りました。
優先度：高
- メール本文作成機能全般のテスト
- 受信メールの表示確認やリンク動作確認
- 正常系の送信テスト
- 送信時設定に関する各種設定値別のテスト
- 送信をしてはいけない場合の制御のテスト
優先度：中
- 配信設定の再編集のテスト
- 設定項目の部分的な組み合わせテスト
優先度：低
- 設定項目の順序違いによるテスト
- 送信時設定項目で想定外の異常値に対する動作確認
優先度が高い項目は条件分け等を精緻に行い、振る舞いを確認。低い項目は主要な条件分けだけを確認するような方針です。この結果、想定工数を2〜3割削減できました（感覚値）。
テスト進行中の調整
実際にテストを進めると進捗が想定より遅れ、折り返し時点で進捗率は4割前後にとどまりました。優先度：高の項目の消化率は問題ありませんでしたし不具合も発見・修正できていましたが、優先度：中の項目については進捗が思わしくないという状態でした。
最重要としていた部分は期間内に確認できる見通し。優先度：中としていた部分についても、不具合が出た場合にお客様に対して不利益を与えるような要素についてはテストして問題ないことが確認できていたため、開発チーム内で相談して、「優先度：高の項目を最優先で完了させる」「時間が許せば優先度：中の残項目を確認をできる限り進める」「優先度：低は確認は省略」という形で対応を調整しました。
こうした取捨選択についても事前に優先度づけをしておくことで判断を素早く行えます。
最終的な結果
最終的にメールマガジン配信機能はテスト期間内に優先度：高の項目は100％、優先度：中は約80％のテストを消化してリリースを迎えました。リリース後2か月で致命的な不具合は発生せず、この結果からも優先度設定の有効性を確認できました。
終わりに
テスト項目の絞り込みや削減の方法については様々ありますが、優先度に関しては比較的すぐに取り入れやすく、効果も出やすいと思います。また、優先度についてより詳しく調べていくと、基準によっては定量的に数値で算出する手法などもいくつかあったりしますので、ご興味のある方は調べてみても面白いと思います。
ソフトウェアテストで全ての要素をテスト仕切ることは現実的に不可能です。テスト項目が多すぎて困っているという方は、一度優先度づけで整理してみてはいかがでしょうか。
