はじめに
株式会社ビットキー Software QAアドベントカレンダーの2024年12月9日の記事は、2023年3月に入社しましたSoftware QAチーム所属 takumi_sakao が担当します。
私は、弊社が提供するworkhubやhomehubといったサービスのソフトウェアテストに従事し、テスト計画〜テスト完了までを担当しています。
対象読者
本記事のテーマは「テスト分析」です。
テスト分析は、テスト活動の中でプロダクトの品質担保の根幹となるプロセスです。
本記事の対象読者は以下のような方が対象です。
- テスト分析をしたことがない方
- テスト分析の有用性がわからない方
- テスト分析に興味がある方
テストプロセス
テスト分析について述べる前に、弊社のテスト活動全の説明から入ります。
テスト活動は以下の図のようなテストプロセスを辿ります。
各テストプロセスの解説
- テスト計画：テストの目的を定義し制約下で最も効果的なアプローチを選択します。検証期間の設定や工数の調整など実施します。
- テスト分析：仕様書、設計書、ユーザーストーリーなどのテストベースを確認し、テスト範囲やテスト条件を識別して、テストの方針を立てます。このプロセスでは、何をテストするかを決定します。
- テスト設計：テスト技法を用いてテスト条件をテストケースに落とし込みます。カバレッジアイテムを識別し、テストデータや環境の設計も行います。このプロセスではどのようにテストするかを決定します。
- テスト実装：テストウェア（テストデータなど）の作成や取得、テストプロシジャーの編成を行います。手動および自動テストスクリプトの作成、テスト環境の構築も含みます。
- テスト実行：テストスケジュールに従ってテストケースを実行します。テスト実行中に不具合を検知した場合、不具合内容を精査した上でステークホルダーへ報告をします。
- テスト完了：プロジェクトのマイルストーンで未解決の欠陥や変更要求を整理し、テストウェアを保管または引き渡します。テスト環境を適切にシャットダウンし、教訓や改善点を分析してテスト完了レポートを作成します。
- テストのモニタリングとコントロール：テスト活動を継続的にチェックし、進捗を計画と比較して、遅延があれば検証期間の延長やリリース日のリスケを打診するなど、品質担保のために必要な行動を取るプロセスです。
テスト分析とは
テスト分析とは、ソフトウェアテストにおいて何をテストすべきかを明確にするためのプロセスです。
この過程では、テスト対象となるシステムの仕様や要件を綿密に調査し、深く理解することが求められます。さらに、テストすべき範囲やテスト条件、影響範囲などの洗い出しを行なっていくプロセスです。
このプロセスを通じて、プロダクトの潜在的な問題点や重要な機能を特定し、テストの優先順位を決定することができます。テスト分析によって得られた情報は、テストの設計や実行の効率を大幅に向上させ、結果としてプロダクトの品質担保に大きく貢献します。
そのため、テスト分析は単なるテストプロセスの一部ではなく、高品質なプロダクトを実現するための戦略的なアプローチであり、テスト活動において非常に重要なプロセスとなります。
テスト分析はなぜ重要なのか？
テスト分析が重要な理由は、主に3点あります。
-
品質を左右する
前述の通り、テスト分析は何をテストすべきかを明確にするプロセスです。テスト対象となるシステムの仕様や要件を深く理解し、テスト範囲や他機能への影響を把握することで抜け漏れのないテスト項目を洗い出すことができます。これによりテスト実行時に不具合を見逃さない状態を構築することができ、プロダクトの品質担保に繋がります。 -
テストの効率化
テスト分析によりテストすべき範囲やテスト条件を明確にすることで、修正による影響がない機能に対するテスト実装やテスト実行を減らし、効率的にテスト実装やテスト実行ができることを実現します。不要なテスト条件によるテスト設計を避けることができ、テストの効率化を図ることができます。 -
リスクの低減
テスト分析では、機能の追加や修正によってどんなリスクが発生するかを考慮します。そのリスクを見据えた上で、テスト範囲やテスト条件などの洗い出しを実施します。ここでリスクを顕在化させておくことで、システムの不具合の発見に繋がり、リリースする前に修正を促すことでリリース後のトラブルを未然に防ぎ、リスクの低減に寄与します。
テスト分析が疎かになるとどうなるか？
テスト分析が疎かになった場合、以下のような問題が発生する可能性があります。
-
不完全なテストカバレッジ
テスト観点の抜け漏れが発生し、テスト実行においてテストすべき観点の網羅性が担保できておらず、テストカバレッジが不完全となります。これにより、重要な機能や要件がテストされないままリリースされ重大な不具合が見逃されることになります。 -
テスト実行工数の圧迫
テストすべき範囲や要件の認識齟齬が発生することで、無駄なテスト実行が発生する場合があります。要件に基づかないテストケースが増え、実際には重要でない部分にリソースを割いてしまうことが発生します。また、期待値ミスやテスト条件の設定ミスなどによりテストの再実施を行う必要が生じ、テスト実行工数の圧迫に繋がります。 -
プロジェクトの遅延
テスト分析を怠ってしまうことによってテストの観点漏れや期待値の誤りなどの問題が発覚し、再度大規模なテストを行う必要が生じることとなり、リリーススケジュールの遅延に繋がってしまいます。また、仕様の矛盾や実装の考慮漏れなど要件の見直しから実施する可能性が生じ、開発の手戻りにも発展してリリースに大きなリードタイムが発生する場合もあります。 -
プロダクトの品質低下
要件を満たすテストが実施できていない、もしくはテスト範囲に抜け漏れがあった場合、不具合の多いソフトウェアをリリースすることとなり、本来提供したい価値をユーザーへ提供することができず、ユーザーの信頼を損ね、企業の評判やブランドイメージに悪影響を及ぼします。ユーザーの信頼を失い、ユーザー数が低下することは、会社の売上にも影響を及ぼす可能性があります。
テスト分析で押さえたいポイント
テスト分析に着手する際に押さえたいポイントを4点紹介します。
1.仕様の把握
まず押さえるべきポイントは、テスト対象の仕様を正確に把握することです。
テスト分析は「何をテストすべきか」を考えるプロセスのため、テスト対象となるプロダクトの仕様がどういったものか、そこに対してどんな変更が加わるのか仕様を把握することが必要です。
例えば、新規機能が5つあるソフトウェアに対して新規機能は4つまでと認識していた場合、仕様を十分に把握できていないことになり、検証時にテスト観点の漏れが発生します。
そのため、テストベースの徹底的な分析が必要であり、仕様書、設計書、ユーザーストーリーなどの資料を精査してテスト観点の抜け漏れや仕様の矛盾がないかを確認します。
2.影響範囲の確認
次に押さえるべきポイントは影響範囲の確認です。
機能追加や不具合修正が既存機能のどこに影響しているかを確認するプロセスです。影響範囲の確認によって、テスト範囲を明確にすることができ、網羅性の判断を下す際に重要な指標となります。
また、影響範囲が明確になることで、テストすべき範囲をピンポイントで絞ることができ、無用なテストを実施する工数を削減することができます。
3.観点の抽出
テスト対象には、必ずテストすべき観点が存在します。
この観点とは、テスト条件やテスト環境などが該当します。
テスト条件：どんな値で検証するのか、文字は何を入力するのかなどテストデータを選択する際の指標になります。また、同値分割や境界値分析などの技法を活用し、効率的にテスト条件を洗い出すことが重要です。
テスト環境：どのデバイスで検証するのか、OSは何を選択するのかという観点です。デバイスであれば、PCで検証するのか、スマホで検証するのかという観点があり、OSであれば、WindowsとMacどちらで検証するのか、端末やOSで差分が潜んでいる可能性も考慮してテストすべき観点の抽出を行います。
この観点の抽出によってテストの質が左右するため、テスト分析において非常に重要な部分であると考えています。
前述した影響範囲の把握に加え、テストの観点を正確に抽出することで、抜け漏れのないテストを実施することができます。
4.網羅性の確保
テストの観点を抽出したのち、その観点の組み合わせでプロダクトがどんな動作をするのか、またユースケースとして考えられる観点の組み合わせや動作を考慮して、テストが網羅的であることが必要です。
ソフトウェアには複数の観点の掛け合わせによってのみ発生する不具合が潜んでいる場合があり、可能な限り観点の組み合わせを考慮し、プロダクトに不具合がないか網羅性を担保することが重要です。
また、正常系の観点だけでなく、準正常系や異常系の観点も含めることでより網羅性の高いテストを実施することができます。
さらに機能面の観点だけでなく、パフォーマンスや性能、セキュリティ、使いやすさなどの非機能要件も考慮することでプロダクトの品質担保により貢献できます。
弊社での実例
弊社SWQAチームでは、テスト分析を実施する際にマインドマップを活用しているチームがあります。
今回はマインドマップを活用したテスト分析の実例をご紹介いたします。
弊社プロダクトのworkhubを例に出します。
workhubには、ユーザーが会議室やワークブースといった空間をWeb上から予約できる機能があります。
その機能に対して以下のような修正が入ることになりました。
修正内容
- 予約機能において、予約取得の方法をFirestoreからGraphQLに切り替える
この予約機能の修正に対してフロアマップを活用したテスト分析がこちらになります。
このフロアマップから読み取れることは、テスト分析で押さえたいポイントの要素の抽出、網羅性の確保がしっかり含まれています。
仕様と影響範囲の確認
今回の例では、予約機能に関するもののうち、管理画面からの導線のみが影響範囲に該当することが、仕様書や開発とのコミュニケーションで判明したため、「エリア予約」をテスト対象としてテスト分析を進めていきます。
予約機能の種類
- エリア予約
今すぐ予約Pass予約
観点の抽出
テスト対象を明確にした後は、テスト対象から検証すべき観点の抽出を行っています。
「エリア予約」の機能に対して、以下3つの観点を抽出しています。
- ユーザー：予約をする人
- 対象スペース：予約する対象(空間)
- 予約の繰り返し：予約の設定
誰が、どの空間を、どんな予約設定で予約するのか、エリア予約に関する観点の抽出を実施しています。
テスト条件の洗い出しと網羅性の確保
テスト条件は観点ごとに存在し、仕様やユースケースと照らし合わせて、必要なテスト条件の洗い出しを行っています。
洗い出したテスト条件から、どんなテスト条件の組み合わせで検証を実施するのかについて検討する必要があり、そこからはテスト分析ではなくテスト設計になりますので、以後は割愛します。
なお、この例ですと36個の組み合わせが存在します。
例）一般ユーザー & 会議室 & 毎日
フロアマップを活用するメリットとして、テストすべき観点やテスト条件を図示することにより、視覚的にわかりやすいテスト方針書となり、テスト分析の状況を俯瞰的に捉えることができます。
また、QA以外のメンバーにとっても視覚的に理解しやすい構造になっており、開発とQAでの認識齟齬を減らすことができます。
フロアマップ余談
弊社のテスト活動では「Qase」というテスト管理ツールを使用しています。
このQaseには、階層構造でテストケースを蓄積することができ、さらにそのテストケースをマインドマップで表現することができます。
弊社でのcQase使用例を一部抜粋します。
テスト観点やテスト条件によって階層構造で分類分けを行い、テストケースの蓄積をしています。
テスト観点を徐々に狭めていくように大項目・中項目・小項目と枝分かれしており、最小単位がテストケースとなっています。
終わりに
テスト分析はプロダクトの品質担保の根幹となる重要なプロセスです。これまで述べてきた注意点や押さえるべきポイントを踏まえ、テスト活動を計画的かつ柔軟に進めることで、より高品質なプロダクトを提供できるようになると考えます。
本記事を通してテスト分析を実施する際のヒントになれば幸いです。
Discussion