.svg)
みなさんは、製品やサービスを購入する時、何を基準に選択しますか？
インターネットの普及やグローバル化により、消費者は多くの選択肢から製品やサービスを選択できるようになりました。
そして、その選択基準は「量」や「値段」から、「品質」や製品やサービスの背景にある「ストーリー」などに移り変わり、システム開発においても、「品質」はとても重要なポイントとなっています。
そして、システムの品質を保証するために重要な役割を果たすのが、「ソフトウェアテスト」です。
今回は、ソフトウェアテストについて、基本的な知識からソフトウェアテストの歴史、得られる効果やメリット、現状の課題と今後の展望まで解説していきます。ぜひ最後までご覧ください！
▼ 関連記事 ▼
ソフトウェアテストとは、ソフトウェア（アプリケーション含む）製品が想定通りに実装され、機能するのかを評価・検証するプロセスを指します。
ソフトウェアテストを行うことで、ソフトウェアの故障や欠陥を早い段階で修正し、本番環境運用中のそれらのリスクを抑えることができるため、「品質と信頼性の確保」を目的に行われます。
もちろん開発の理想としては、欠陥や故障のないソフトウェアを作ることですが、人が作る以上、それらを0にするのは不可能に等しいと言えます。そこで、ソフトウェアテストを実施することで、リリース後の大きなトラブルに発展するのを防げるということで、その重要性が年々高まっています。
ちなみに、品質管理の重要性に初めて触れられたのは、TＱＭ（総合的品質管理）の第一人者とも言われるジョセフ・ジュラン氏の著書『品質管理ハンドブック』（1951年）です。
ソフトウェアテストは、開発手法や各時代のニーズに合わせて、アプローチ方法やツールを変えながら進化してきました。
【1950年代初頭：デバック重視の時代】
ソフトウェアテストが誕生したばかりのこの時代には、形式化された標準的なテストプロセスはなく、プログラマーが手動でコードを確認し、バグの特定・修正を行っていました。そのため、それぞれのプログラマーのスキルに依存したテストが行われていました。
【1957年〜1978年：デモ指向の時代】
ソフトウェアテストが、ユーザニーズを満たしているかの確認のするための体系的なアプローチになり、テストの組織化・構造化が進みました。テスト内容は要件定義をもとに作成され、デバック作業と明確に区別されていました。また、この時期にテスト自動化の種が蒔かれ、時代に対応したソフトウェアテストへと進化していきました。
【1979年〜1982年：破壊指向の時代】
ソフトウェアを意図的に破壊することで、耐久性や安定性をテストするアプローチ方法が誕生しました。しかし、この手法では1つのバグの修正が別のバグに繋がってしまう可能性があり、あまり広まることはありませんでした。
【1983年〜1987年：評価重視の時代】
テストが品質の評価・測定に重点を置くようになり、「効果や品質を定量的に評価」する時代になりました。この時期には品質保証のためのテスト基準が確立され、テストを実施したソフトウェアの信頼性も向上しました。
【1988年〜2000年：予防指向の時代】
開発初期段階から品質向上を目指すため、「バグを未然に防ぐ」という予防のプロセスが重要視されるようになりました。
【現在】
現在のソフトウェアテストでは、自動化テストツールの誕生により、より効率的なソフトウェアテストに注目が集まっています。また、アジャイルやDevOpsといった開発手法や思考の普及により、ソフトウェアテストの役割と重要性がさらに高まっています。
ソフトウェアテストを実施する上で、理解しておくべき7つの要素が、『ISTQBテスト技術者資格制度「Foundation Level」シラバス』に記載されています。高品質なソフトウェアというのは、欠陥がないというだけでなく、セキュリティ対策や使いやすさなどの非機能要件といった要素も含まれてきます。
1. テストは欠陥があることは示せるが、欠陥がないことは示せない
テストにおいて欠陥が見つからない場合でも、「テストをしていない範囲」に欠陥がある可能性が否定できません。そのため、ソフトウェアテストを実施しても「欠陥がない」ことは証明できないのです。
2. 全数テストは不可能
ソフトウェアに入力する可能性のある全情報の組み合わせをテストするのは、よほどシンプルなソフトウェアでなければ、不可能に近いと言えます。そのため、ソフトウェアの性質やリスクを踏まえた実施可能な範囲に絞ったテストを実行する必要があります。
3. 早い段階でテストを実施する
不具合に気付かないまま開発を進めてしまうと、他の箇所に影響が出る可能性もあります。人が作っている以上、欠陥のない完璧なソフトウェアはを作ることは不可能に近いです。そのため、修正コストや時間をできるだけ抑えれるよう、早期発見が鍵になります。テストの順番も加味しながら、できるだけ早い段階でソフトウェアの実施が必要です。
4. 欠陥の偏在
ソフトウェアの欠陥は、ソフトウェア全体に均等に存在するわけではなく、一説によると発見される欠陥の8割は、ソフトウェア全体の2割に集中しているとも言われています。そのため、テスト箇所を決める際に、過去の欠陥分析などをもとに、テストの焦点をある程度絞るのが良いとされています。
5. 殺虫剤のパラドックス
害虫駆除で同じ殺虫剤を繰り返し使用していくうちに、薬剤に対する耐性がついてしまうように、ソフトウェアテストも同じテストを繰り返し行うと、新しい欠陥を発見できない可能性が高まります。そのため、欠陥の修正後は新しいテストケースやテストデータを使用したテストを実施する必要があります。
6. テストは条件次第
すべてのソフトウェアに共通で使えるテストは存在しないため、状況や目的に応じてテスト内容を決めていく必要があります。
7. 「バグゼロ」の落とし穴
「バグがない＝高品質」ではないということは、常に念頭に置いておきたいポイントです。見つけた欠陥を修正したことで、新たな欠陥が発生する可能性や、機能性が損なわれてしまったり、新たにセキュリティ対策をとる必要が出てくる可能性もあります。
ソフトウェアテストを行うことで、以下のような効果やメリットが期待できることから、開発において重要な工程と言えます。
・バグの修正による品質保証とユーザー満足度
ソフトウェアテストを実施することで、開発の様々な段階で混入してしまったバグを特定し、本番環境での運用までに修正することが可能です。また、体系的なアプローチでテストすることで、機能要件で定義したように意図した動作をするかや、ユーザーニーズを満たしているかの確認も行えるため、多角的にソフトウェアの品質の保証をすることが可能です。
・バグ対応へのコストと時間の削減
ソフトウェアの開発が進めば進むほど、欠陥の修正には時間とコストがかかります。早い段階でソフトウェアテストを実施することで、修正にかかる時間とコストを抑えるだけでなく、リリース前であればユーザーへの不信感を与えることなく済みます。
・法や規則、基準に準拠した開発が実現
ソフトウェアには、セキュリティやアクセシビリティなど準拠すべき規則や基準があります。要件定義の段階でこれらを考慮すべきなのはもちろんですが、ソフトウェアテストを実施することで、より規則等に準拠した開発を行うことができます。また、これらに反することで生じる問題やリスクを回避することができます。
ソフトウェアテストの種類は、「手動」と「自動」の2つがあり、そこから様々なテストへ枝分かれしていきます。
【手動テスト】
手動テストは自動化ツールを使用せずに、テストケースを手動で実行していきます。テスターはエンドユーザーの使用を想像して、ソフトウェアが期待通りに動作するか確認します。
・ホワイトボックステスト
クリア（またはガラス）ボックステストや構造化テストとも呼ばれる、ソフトウェアの内部構造や動作を確認するテストです。コードが期待通りに機能し、全ての内部コンポーネントが正しく動作していることを確認することを目的とし、コード記述やロジックをしっかりと理解している、開発者やテスターによって実施されます。
・グレーボックステスト
ホワイトボックステストの内部の技術面に焦点を当てたテストと、ブラックボックステストのソフトウェアの機能を客観的に評価するという2つの要素を組み合わせた、バランスの取れたテストを目的とするソフトウェアテストです。
・ブラックボックテスト
ブラックボックステストは、コードやロジックといった技術的な知識に基づくテストではなく、「ソフトウェアの機能を客観的に評価」することに焦点を当てたテストです。ソフトウェアが指定された要件に従い、期待した動作を行うか確認することを目的とします。テスターがソフトウェアの内部の仕組みを見ず「ブラックボックス」として扱うことから、この名が付きました。ブラックボックステストはさらに、「機能テスト」と「非機能テスト」の2つに分類することができます。
- 機能テスト
ソフトウェアの機能が要件定義通りに実装され、期待していた動作をするかのテストです。
例：単体テスト、システムテスト、結合テスト、ユーザー受け入れテスト、スモークテスト、回帰テスト など
- 非機能テスト
特定機能や動作以外の、操作性やパフォーマンス、セキュリティ、スケーラビリティといった側面に焦点を当てたテストです。
例：性能テスト、ストレステスト、負荷テスト、スケーラビリティテスト など
【自動テスト】
あらかじめ定義されたテストケースを、専用のツールを使ってテストします。テスト作業は反復で時間がかかる作業のため、自動化することで効率性を向上するだけでなく、ヒューマンエラーを減らし、精度を向上することができます。代表的なツールを以下で挙げていきます。
・Selenium
主にWebアプリのテスト自動化のために使われている、オープンソースのフレームワークです。様々なプラットフォームやプログラミング言語で動作するツールやライブラリが提供されています。
・appium
主にモバイルアプリのテスト自動化のために使われているオープンソースのフレームワークです。iOSとAndroidの両方のプラットフォームで、ネイティブとハイブリッド問わずテストを自動化できます。
・JUnit
プログラミング言語であるJava用のテストフレームワークで、Javaを使用した開発では広く使用されている自動化テストです。ソフトウェアの部分ごとに単体テストを作成し、テストの実行、アサーションの作成、テストの結果の検証など、テストスイートの構築に役立つ多くの機能を提供しています。
ここでは、現状の課題と、今後の展望についてまとめていきます。
【現状の課題】
現状の課題の多くは、自動化テストを有効的に組み込むことで解消へと近づけることができます。
・開発サイクルの高速化
アジャイル開発やMVP開発といったスピード感を重視した開発手法が主流となり、十分なテスト時間の確保や、テストケースを最新の状態に保つことが難しくなっています。そのため、自動化テストを有効的に活用することで、スピーディーな開発を行いながら、しっかりとテストを実施することができます。
・複雑化するアーキテクチャによる不完全なテスト
昨今のソフトウェアには、複雑なアーキテクチャが含まれることが多く、APIやマイクロサービス、サードパーティなど、様々な要素が組み合わさって構築されています。そのため、全ての統合ポイントを徹底的にテストするのが難しくなっています。また、多くの機能が実装されたソフトウェアのテストにおいて、想定できるシナリオや組み合わせ全てのテスト範囲をカバーするというのは実現不可能に等しいです。そこで、重要な機能や潜在的リスクに基づいたテストケースに優先順位をつけ、各テストを自動化し、繰り返し行なっていくことで、複雑化するアーキテクチャや広範囲のテストに対応することができます。
・限られたリソースと予算
リソースと予算の問題は長く課題として挙げられています。これらが制限されることにより、テストの時間も限られ、テスト範囲が狭まる可能性もあります。そして、従分なテストを行えないことは、重大なバグや脆弱性が見落とされてしまう可能性が出てきます。そのため、重要な機能を中心にリソースを効率的に割り当て、可能な箇所は自動化テストを導入することで、限られたリソースや予算を有効的に活用することができます。
【今後の展望】
進化するテクノロジーとソフトウェアテストが組み合わさることで、ますます効率的かつ精度の高いソフトウェアテストが実現できると予測できます。
・AI（人工知能）とML（機械学習）の台頭
AIやMLとのコラボは、ソフトウェアテストの自動化に大きな影響を与えています。これらを活用することで誤探知を減らし、テスト全体の精度の向上や、レポートの自動生成などに役立ちます。
・シフトレフトテスト
開発の早い段階でテストプロセスを推進する方法です。リリース前にコードをテストすることで、開発プロセスの早い段階で欠陥を発見でき、問題に対処するために必要な時間と労力を最小限に抑え、テストがより効率的、迅速かつコスト効率よく行われます。これは、アジャイル開発や DevOpsではとても重要といえます。
ここまで、基本的なソフトウェアの知識から、歴史、得られる効果やメリット、現状の課題と今後の展望まで解説してきました。
ソフトウェアテストは、時代の流れとともに変化する開発手法やニーズによって、デバック重視の時代から、予防志向へとその焦点が変化してきました。
また、テストの自動化も進み、新たなテクノロジーとのコラボで、効率的かつ高精度なソフトウェアテストを実現し、ますます高品質なソフトウェア開発が可能となっています。
JIITAKでは、ソフトウェアテストにおいて、AWS Code BuildやSeleniumなどを活用したテストプロセスの自動化を行い、生産的な価値創出をしていきます。また、迅速なバグの特定や改修対応、機能の強化など、開発するソフトウェアの要件と品質基準を満たし、品質を担保した包括的なソフトウェアテストを提供します。お困りごとのある方は、ぜひ一度、JIITAKまでご相談ください！
