IBMニュースレター
The DX Leaders
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
ニュースレターは日本語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。
Functional Testingは、指定された要件に基づいてアプリケーションの主要な機能が期待どおりに動作するかどうかをVerifyするソフトウェア・テスト・アプローチです。
ソフトウェア開発には、さまざまな種類のソフトウェア・テストがあります。それぞれ、少しずつ異なるアプローチでタスクに取り組みます。Functional Testingは、ユーザー体験の概念に最も近いものであり、1つの重要な質問に焦点を当てます。ソフトウェアの主要な機能が、指定された要件に従って、期待通りに動作するかということです。
ソフトウェアの品質は、多くの場合、ソフトウェア開発ライフサイクルの一部としてさまざまな角度から評価されます。Functional Testingに関する限り、テスターは基本機能を検証し、ソフトウェア機能がビジネス要件を十分にサポートできることを確認する必要があります。テスト実行により、DevOpsは実際の成果と期待される成果を比較できます。
テストは開発プロセスの重要な部分であり、Functional TestingはQAチームが事前の品質保証を行うことを可能にすることで、実際にワークフローをリリースする際にどのように動作するかを明確に把握できます。
IBMニュースレター
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。
ニュースレターは日本語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。
全体的なストラテジーの一環として採用されるソフトウェア・テストの種類に応じて、さまざまな運用要素にスポットライトが当てられます。Functional Testingは、さまざまなソフトウェア・モジュール間の全体的な互換性を評価します。これは、期待されるユーザー・インタラクションやユーザー・インターフェースの実現可能性など、他の関連側面に直接影響します。
Functional Testingで提供されるテスト環境は、ブラックボックスの一例と考えられており、テスターは（ホワイトボックス・テストに見られるような）システムの内部構造に関する洞察を得ることはなく、その代わりに、システムとそのパイプラインが希望通りに機能するかどうかに関する「合格/不合格」のレポートを渡されます。
通常、Functional Testingは、次の6つのステップを必要とするテスト・プロセスに従って行われます。
ソフトウェア・テスト・モデルにさまざまな種類があるのと同様に、Functional Testingにもさまざまな種類があります。その数は膨大であり、これはそのうちのほんの一部に過ぎません。Functional Testingの種類には幅広いニュアンスが含まれており、ここではアルファベット順に記載されています。
ソフトウェア・テストでは、テスターは、正式なテスト・プロセスに従って、アドホック・テストを行うことがよくあります。この非公式な形式の探索テストは、テスターのスキルと直感に基づいて行われます。定義された構造はありません。代わりに、テスターの直感が、使用されるテスト手法を推進します。
例：開発者とテスターが協力してモジュールやアプリの改善に取り組む「バディ・テスト」。この形式のアドホック・テストでは、通常、テスターは修正プログラムが必要なバグやその他の要素を見つけますが、開発者はその修正プログラムに集中します。
アプリケーション・プログラミング・インターフェース（API）は、ソフトウェア開発を可能にし、異なるアプリやシステムの接続を可能にします。APIテストにより、API接続ポイントが必要に応じて動作できるようになります。また、ユーザーの権限やAPIを介したデータの管理方法に関する監視も可能です。
例：「ヘッドレス・テスト」は、ユーザー・インターフェースまたはユーザー・インターフェースのインプットフィールドが欠落している場合に行われます。このような状況では、多くの場合、インターフェース・サービスまたはアプリと共有されるインプット・データは、APIテストを通じてテストするのが最適です。
多くの組織は、テスト・プロセスに実際のユーザーの実際のエクスペリエンスを真に反映させたいと考えています。このような企業の場合、複雑なテスト・シナリオは望ましいレベルの精度を提供しますが、複雑さが増すと、実行するための事前の作業が増えてしまうということを指摘しなければなりません。
例：オンライン注文処理はシームレスなオペレーションのように見えます。その舞台裏では、買い物客のオンラインカートにどれだけ簡単に商品を追加できるか、割引の適用などの機能がどれだけ迅速に統合されるか、そのような購入がどれだけスムーズに行われるかなど、テストすべきプロセスがたくさんあります。
完璧な世界では、Functional Testingに合格すれば、必ず合格します。しかし、現実ではそうではありません。ソフトウェアは、新しいコードの変更で、知らないうちにエラーを引き起こす可能性のある開発者から、ソフトウェアに影響を受けることがよくあります。回帰テストは、安定したベースラインが維持されていることを確認します。
例：コードが変更されるたびに、いずれかの形式または別の形式の回帰テストが使用されます。これには、バグの修正プログラムや新機能の導入後、またはソフトウェアの更新後に行われる関連する更新が含まれます。
健全性テストは、比較的小さな変更や修正プログラムの追加によって既存の機能が損なわれていることを確認する迅速かつアジャイルな方法です。健全性テストは、新しい機能がシステムの他の機能を損なわないことを確認する簡単な方法として使用される傾向があります。
例：回帰テストと同様、健全性テストでは、性能の改善を検証し、基本的なオペレーションを確認し、システムが期待どおりに動作していることを確認するために、システムを以前の機能に「巻き戻す」ことができます。コードが変更されるたびに、いずれかの形式または別の形式の回帰テストが使用されます。これには、バグの修正プログラムや新機能の導入後、またはソフトウェアの更新後に行われる関連する更新が含まれます。
「煙があるところに火がある」という古いことわざがあります。この格言が「Smokeテスト」という名前にインスピレーションを与えたようです。Smokeテストは開発プロセスの早い段階で実施され、実行されると、エンド・ツー・エンドの機能を判断します。機能に障害が発生した場合、QAチームは必要な修正を行います。
例：スモークテストは、継続的統合と継続的パイプラインを検証するために、新しいソフトウェアビルド（または大規模なコード変更）をデプロイする前の最終チェックとして使用できます。
エンド・ツー・エンド・テストとも呼ばれるシステム・テストは、ソフトウェア・システム全体のソフトウェアがどのように連携して動作するかを評価する目的で機能します。システム・テストでは、多くの場合、特定のソフトウェア・システム内で連携して動作する場合とそうでない複数の個別のソフトウェア・システムの分析が含まれます。
例：エンド・ツー・エンドのシナリオでは、テスト実施者は完全なワークフローを評価することができます。オンライン小売オペレーションの場合、これは、元の注文書から全体の履行プロセスまで、利用者が体験する小売エクスペリエンスを意味する可能性があります。
単体テストは、小宇宙におけるテストの一形態です。ここでは、システム全体をテストするのではなく、限られたコードのみをテストしますコードのセクションは分離されたテスト環境で評価され、単体テストが失敗した場合は（テスト・データと機能目標との比較に基づいて）、システム全体のレベルで追加のテストを実行できます。
例：かなり基本的な計算要素は、単体テストによって適切にテストされます。摂氏温度を華氏温度に変換する単純な関数を考えてみましょう。テスト環境には、問題のコードと関連するテスト・ケースが含まれます。
ソフトウェア・テストの後半段階として、ユーザー受け入れテストでは、作成されるソフトウェアの対象とする層を代表する人々によって実施される性能テストを組み込み、そこから学習することを目指します。これらのエンド・ユーザーは、テスト・プロセスにさらなる現実性をもたらします。
例：ソフトウェア・プランのユーザーは、次のサービス層にアップグレードし、全ての新しい機能を解き放つことができるようになります。ユーザー受け入れテストでは、ユーザーが主要な機能へのアクセスを予想どおり増加させることができることをVerifyします。
その名前が示すように、Non-Functional Testingは、通常は機能を確認するために重要とは見なされないアプリケーションの動作を評価します。それでも、よく整理された愉快なユーザー体験を提供することは、現在ではソフトウェア開発の不可欠な部分と考えられています。Non-Functional Testingでは、特にソフトウェアがより優れた拡張性を実証するために最大化されている場合に、潜在的なシステムの問題が明らかになります。
負荷テストは、Non-Functional Testingの主要な形式の1つです。理論的には、システムは単一のシステム・リクエストを送信するのと同じ緊急性で、何千ものシステム・リクエストを処理できなければなりません。しかし、その論理は現実的な経験によって裏付けられていません。負荷テストは、システムがピーク負荷や極端なワークロードの急増に対応できるかどうかを確認するために機能します。
別の形式のNon-Functional Testingでは、性能に特に注意を払います。性能を向上させるには、システムがリクエストにスムーズかつ迅速に応答することが重要です。性能テストのテスト計画では、ユーザーがリクエストが処理されるまでの待ち時間を評価します。性能テストを慎重に作成すると、早い段階でレイテンシーを最小限に抑えることができます。
データ・セキュリティーの重要性を考えると、ある形式のテストがこの現代の目的に的確に対応することは驚くべきことではありません。動的アプリケーション・セキュリティー・テスト（DAST）や静的アプリケーション・セキュリティー・テスト（SAST）などのセキュリティー・テスト手法は、テスターがセキュリティーの脆弱性をチェックするのに役立ちます。企業のセキュリティー・テストの方法は、潜在的な脅威に応じて選択されます。
Non-Functional Testing・タイプの1つは、ユーザー体験（UX）の品質を重視するものです。ユーザビリティー・テストは、小規模での使用に最適な手動テスト・プロセスです。ただし、特にアプリケーションのローカライズなどの動きを実行する場合には、可能な限り適用する必要があります。人為的ミスの原因となる複雑性が伴う場合は危険が伴うことがあります。
ほとんどのツールは異なるプラットフォームや種類のアプリケーションをサポートしているため、さまざまなFunctional Testingをすべて正確に追跡し続けるには作業がかかります。この急成長するマーケットプレイスに追いつく方法はありませんが（数百、場合によっては数千ものFunctional Testingが容易に製造されていると推定されています）、実績のある人気と認められたユーティリティーにおいて際立った存在となるツールをいくつかご紹介します。
Javaアプリケーションを開発および配信するためのフルマネージドのシングルテナント・サービス。
DevOpsソフトウェアとツールを使用して、複数のデバイスや環境でクラウドネイティブ・アプリケーションを構築、デプロイ、管理します。
クラウド・アプリケーション開発は、一度構築すれば、迅速に反復し、どこにでもデプロイできます。