ソフトウェアテストとは？必要性・実施内容・プロセスを解説

高品質なソフトウェアとは、さまざまな視点からの要件を満たしている状態を指します。動作するだけではなく、以下のような項目についてもきちんと評価する必要があります。

● 安全性
● 快適さ
● 効率性

バグが残ったまま公開されてしまうと、金銭的な損失につながるでしょう。場合によっては、信頼の低下や人命への影響さえ及ぼすおそれがあります。

そこで、品質の判断基準として広く用いられているのが「ISO/IEC 25010」という国際的な評価指標です。この規格では、以下8つの品質特性からソフトウェアを評価します。

● 性能効率性
● 互換性
● 使用性
● 信頼性
● セキュリティ
● 保守性
● 移植性
● 機能適合性

こうした複数の特性をどれだけ満たしているかによって、ソフトウェアの総合的な品質が決まります。

■ISO/IEC 25010の品質特性
評価する際には、国際規格「ISO/IEC 25010」で定義された8つの品質特性が基準となります。まず、処理速度、応答時間、スループットなどを確認する「性能効率性」は、使いやすさだけでなく業務の生産性にも関わります。

次に、異なる環境や機器で正常に動作する「互換性」は、柔軟な運用の実現に役立ちます。また、誰にとっても扱いやすい設計であることを示す「使用性」も重要です。

さらに、予期せぬトラブルが起きた際にも動作を維持できる「信頼性」は、長期的な安心感につながります。加えて、情報漏洩や不正アクセスを防ぐ「セキュリティ」は、現代のソフトウェアには欠かせません。

更新や改修を行いやすい「保守性」や異なる端末やOSへスムーズに展開できる「移植性」、要求された機能が過不足なく備わっているか確認する「機能適合性」も含めて、品質を判断します。

■情報処理推進機構（IPA）の品質特性
情報システムの信頼性と持続性を確保するためには、IPAが定める非機能の品質特性を踏まえることが重要です。まず、常時安定して稼働する状態を保つ「可用性」は、業務継続に直結する基盤となります。

加えて、業務量の増加に耐えうる「処理性能と拡張性」も、長期的な運用を支えるうえで欠かせません。日常的な運用や保守作業を効率的に行える「操作性・保守性」に加え、異なるシステム環境への適応力を示す「移行性」も、変化に強いシステムには必要です。

また、情報を外部の脅威から守る「セキュリティ」対策も重要な取り組みとなります。さらに、環境負荷の低減や省電力といった視点から評価される「環境配慮」も近年では無視できない要素となっています。

ソフトウェアに不備があると、修正作業や検証のやり直しにかかる費用だけでなく、ユーザー側の被害に対する補償まで求められる場合があります。とくに公共性の高いシステムや金融、医療に関連する分野では、損害の影響範囲が大きくなります。

バグの修正には、金銭面だけでなく多くの時間も費やされます。作業に要する時間は、本来ほかの開発や改善に充てるべきリソースを奪うことになるでしょう。

修正対応に開発者が割かれることで、別の案件に遅れが出るリスクも生じます。結果として、本来得られるはずの成果や機会を逃してしまうおそれがあります。

バグが発覚すると、製品の評価だけでなく提供元の企業全体に対する信頼も損なわれます。とくに知名度の高い企業では、社会的な影響も大きく、ブランド価値の低下に直結する可能性があります。

バグは金銭的な損失にとどまらず、人命を脅かす深刻な事態を引き起こす可能性があります。たとえば、自動車や列車の制御に用いられるシステムに誤作動があれば、重大な事故を招きかねません。

安全性を守るうえで、欠陥の早期発見は欠かせません。

アプリやWebサービスを公開する前に、十分な検証を求める声は非常に多いです。実際のアンケート調査では、リリース前のソフトウェアテストに対する重要性を利用者740人の91％が感じており、なかでも「強くそう思う」との意見が7割近くを占めていました。

利用者の信頼を得るためにも、事前のテストは不可欠といえるでしょう。

調査データの引用元：アプリやwebサイトのバグに関する調査

ソフトウェアテストでは、仕様どおりに動作しているかを確認する「検証」だけに注力するのは適切ではありません。開発されたシステムが、実際に利用者の期待や目的に応えているかという「妥当性の確認」も同じくらい重要です。

この2つは「V＆V」と呼ばれ、それぞれVerificationとValidationに該当します。Verificationでは設計や仕様のとおりに作られているかを確認し、Validationではユーザーの視点からソフトウェアに価値があるかを判断します。

たとえ正しく動いていたとしても、ユーザーの課題を解決できなければ本来の意味をなしません。使いやすさや実用性といった観点も含めて検証する姿勢が、現場では求められています。

ソフトウェアテストは、バグを発見する手段であり、完全に問題がないことを証明するものではありません。テストで異常が見つからなかった場合でも、特定の条件下で問題が現れなかったに過ぎません。

別の状況ではバグが発生する可能性が残ります。そのため、どれほど丁寧にテストしても、本番運用でのトラブルが完全に防げるとは限りません。

テストはバグを発見する手段であり、完全に問題がないことを証明するものではありません。テストでは異常が見つからなかった場合でも、別の状況ではバグが発生する可能性があります。

つまり、どれほど丁寧にテストしても、本番運用でのトラブルが完全に防げるとは断言できません。したがって、関係者にはどのような条件下において問題がなかったのかを正確に伝える必要があります。

あらゆる入力や操作パターンを網羅する「全数テスト」は、実際のソフトウェア開発では現実的に行えません。複雑なシステムでは、条件の組み合わせが膨大になり、すべてを検証するには途方もない時間と労力が必要になるためです。

そのため、実務ではテスト範囲を絞り込み、効果的に欠陥を発見できる方法を選ぶ必要があります。

開発の初期段階からテストを始めることで、あとの工程で発生する手戻りを減らせます。要件定義や設計の時点で不備を見つけて修正すれば、修正にかかる労力やコストを最小限に抑えられるでしょう。

とくに外部委託の場合は工程が分断されやすく、初期のミスが後になって発覚するリスクが高まります。早い段階でレビューや静的テストを実施することによって無駄な工数を削減できるため、全体スケジュールの遅延も防ぎやすくなります。

ソフトウェアの欠陥は、すべての機能に均等に発生するわけではなく、特定の部分に集中しやすい傾向があります。とくに、設計が複雑で実装が難しい箇所や開発経験の少ない機能は欠陥が生じやすくなります。

そのため、過去のバグ履歴や技術的な難易度をもとに重点的なテスト領域を見極めることが大切です。

同じテストを繰り返し実施していると、新たなバグを見つける力が徐々に低下します。確認観点が固定化され、視点が狭まってしまうことが原因です。過去の経験に依存するあまり、想定外の動作や新たなリスクに気づけなくなる場合もあります。

こうした事態を避けるには、テスト観点や手順を定期的に見直して、第三者の視点を取り入れるとよいでしょう。

ソフトウェアテストは、対象となるシステムの性質や開発環境によって最適な方法が異なります。たとえば、厳格な精度が求められる医療機器とエンタメ向けアプリでは、注視すべき観点も実施すべき手法もまったく異なります。

さらに、アジャイル開発かウォーターフォール型かによってもテストの進め方は変わります。状況に応じた柔軟なテスト設計と運用は、不可欠といえるでしょう。

欠陥が見つからない状態を目指すあまり、開発の本質を見失ってしまう危険があります。たとえバグが検出されなくても、使いやすさや信頼性の保証には直結しません。むしろ、過度な修正が新たなバグを招くこともあるでしょう。

大切なのは、欠陥の数を減らすことではなく、ユーザーが求める価値を確実に提供できているかを見極める姿勢です。

レベル別にすると、以下の5種類のテストがあります。

● コンポーネントテスト
● コンポーネント統合テスト（結合テスト）
● システムテスト
● システム統合テスト（結合テスト）
● 受け入れテスト

各テストについて解説します。

■コンポーネントテスト
プログラムの最小単位である部品ごとに、仕様どおりの動作を確認する検証作業です。主に開発者が実施し、外部の影響を排除して機能や構造を個別に確認します。

仕様どおりに処理が行われるかを確認すると同時に、バグの早期発見やほかの工程への影響防止も目的とされます。

■コンポーネント統合テスト
複数の構成要素を組み合わせた際の動作や連携が設計意図に沿っているかを検証する工程です。単体で確認された機能同士が連携する場面で発生するバグのほか、データの受け渡しにおける齟齬などを早期に発見することが目的です。

個々の機能が正しく動作していても、連携によって問題が生じる可能性があるため、丁寧な確認が求められます。

■システムテスト
すべての構成要素を統合した状態で、要求どおりの機能と性能が備わっているかを確認する最終検証のひとつです。機能面だけでなく、動作速度や安定性など非機能面も含め、エンドユーザー視点での完成度を見極めます。

実環境に近い条件下で実施することで、実運用に耐える品質かどうかを確認するのがねらいです。

■システム統合テスト
自社のシステムと外部サービスやほかのシステムとの連携が正しく行われるかを確認する工程です。APIやデータ連携、外部システムとの通信処理など、システム間の結びつきに着目します。

誤作動や情報の齟齬を未然に防ぐためにも、できる限り本番環境に近いテスト環境で実施することが求められます。

■受け入れテスト
システムが求められた処理を正しく実行できるかを検証する工程です。ユーザーストーリーや業務要件に基づき、機能が仕様通りに動作するかを確認します。

業種特有の知識が求められる場合もあるため、業務への理解に基づいたテスト設計が必要です。

品質別では、以下2つのテストに分類されます。

● 機能テスト
● 非機能テスト

それぞれのテストについて解説します。

■機能テスト
システムが求められた処理を正しく実行できるかを検証する工程です。ユーザーストーリーや業務要件に基づき、機能が仕様どおりに動作するかを確認します。

業種特有の知識が求められる場合もあるため、業務への理解に基づいたテスト設計が必要です。

■非機能テスト
システムの性能やセキュリティなどの特性に着目して、動作の滑らかさや安全性を評価するためのテストです。「どう動くか」ではなく「どのように振る舞うか」を確認するものであり、全テスト工程で実施可能です。

評価対象に応じて、設計技法や専門知識が求められます。

技法別では、以下2つのテストに分けられます。

● ブラックボックステスト
● ホワイトボックステスト

■ブラックボックステスト
ソフトウェアの外部仕様に基づいて動作を確認する手法です。内部の構造や処理内容には踏み込まず、入力に対する出力結果が期待どおりであるかを検証します。

ユーザーの視点で実施するため、機能の使いやすさや正確性を評価するのに適しています。

■ホワイトボックステスト
コードやデータフローなど内部構造に基づいてテストケースを設計する手法です。実行した処理の割合を可視化できるため、テストの網羅度を定量的に把握できます。

たとえば、条件分岐のすべてを確認することでロジックの漏れを防ぐなど、設計の精度を高める効果が期待できます。

まずは、テスト計画から始めます。この段階ではテストの目的を設定しますが、ほかにも重要になるのが、テスト対象の定義と実行範囲です。

開発後のリスクを想定し、実施するテストで保証されるべき部分と、優先順位や重要度をもとに、何のために、どのようにテストを行うか決めます。

また、テストプロセス全体にわたって重要となるのが「モニタリング」と「コントロール」です。これらは、特定の工程に限定されるものではなく、計画、設計、実行、評価といった各フェーズで継続的に行われるべきプロセスです。

テスト活動の進捗状況、品質、リスク、欠陥などを継続的に監視し、記録する「モニタリング」と、テスト計画の進捗と実際の進捗を比較し、計画からの乖離を把握、必要に応じて調整する「コントロール」をします。

分析結果をもとに、実行すべき具体的なテストケースを策定します。仕様やインターフェースなどの情報を精査し、目的に応じたテスト条件を抽出したうえで、代表的な入力パターンや境界条件、異常系まで幅広く想定することが必要です。

あらかじめ準備した手順やデータに従い、実際にシステムを動かして動作を確認します。想定どおりの結果が得られているかを検証して、画面キャプチャやログなどの証跡を記録します。

期待と異なる動作を確認した場合は、詳細な記録とともにバグとして報告し、必要に応じて再検証や回帰テストを実施しなければなりません。

各ケースの結果を精査して、バグの有無や発見された問題の深刻度を評価します。発見内容は優先度や影響度に基づき分類し、修正対応の判断材料とします。

また、テスト計画に定めた終了基準に到達しているかどうかの確認も必要です。実施結果を関係者へ報告するとともに、得られた知見を改善に活かしましょう。