アプリの機能の検証

アプリケーションをビルドしたら、期待どおりに機能することを検証します。

単体テスト

単体/ストーリーテストでは、ストーリーをクローズする前に、ストーリーで指定された要件が検証されていることを確認します。ストーリー/単体は、システムまたはアプリケーションのテスト可能な最小部分であり、構成して実行することができる部分です。

ストーリーの構成が完了したら、開発者はその特定のストーリーのコンテキストだけでなく、現在のストーリーとコンポーネントを共有する他の関連ストーリーでも機能を単体テストする必要があります。

ストーリーをクローズする前に、開発者はストーリーをプロセスオーナーまたは指定されたステークホルダーにアサインして、ストーリーの構成が期待される結果を満たしていることを検証することをお勧めします。

ServiceNow の自動テストフレームワーク (ATF) は、主にアプリケーションの機能テストを自動化することを目的としていますが、スクリプトインクルードとビジネスルールを含む構成の単体テストを自動化するために使用できることはあまりありません。

システムテスト

システムテストは、開発が完了したときに完全なシステムで実行されます。コンポーネントの全体的なインタラクションと、スコープ内の他のアプリケーションとの統合をテストします。システムテストは QA/テストチームによって実行されますが、開発者は QA チームおよびプロセスオーナーと協力して、テストケースがすべてをカバーしていることを確認する必要があります。開発者は、システムテスト中に見つかった問題の修正に対して責任を負います。

自動テストフレームワーク (ATF)

自動テストフレームワーク (ATF) を活用して ServiceNow アプリケーションの機能システムテストを自動化し、テストの時間とコストを削減して、UI に依存しない再現可能なテストにする必要があります。テストケースを作成するときは、次のガイドラインに従ってください。

テストを作成するとき：

• パラメーター化されたテストを使用して、テストケースの重複を回避します。
• テストの命名基準に従います。
  • <アプリのイニシャル>：<テストされている機能>
  • CSM：ケースの解決
• 説明に各テストのユースケースを記述します。例：ユースケースをテストするサンプル。
• 開発インスタンスでテストを開発し、テストインスタンスでテストを昇格/実行します。
• クローンするとテストはワイプされます。テストを保持するには、次のいずれかのオプションを使用します。
  • スコープ対象のアプリにテストをバンドルし、アプリを GIT にアップロードします。
  • クローンの前にテストを保存します。
  • テストを本番インスタンスに昇格させますが、本番環境ではテストを実行しないでください。
• 自己完結型のテストを作成します。
• テストステップが欠落している新しいサーバーサイドテストステップまたは REST テストステップを作成します。例：メール本文の検証。
• スクリーンショットが重要でない場合は、可能な限りサーバーサイドテストステップを使用します。
• 代理操作ステップから開始します。
• ブラウザースロットリングに注意してください。
• テストログとテストトランザクションを使用して、テストエラーのトラブルシューティングを行います。

テストスイートを作成するとき：

• テストスイートの命名基準に従います。例：ITSM INT：ユースケース。
• スイートについて説明します。
  • テストスイートの説明：「これは、プラグイン/アプリケーションをテストするためのサンプルテストスイートです」。
  • 説明に使用可能な追加情報を入力します。
• テストスイートを機能領域別に整理します。

ユーザー受け入れテスト

ユーザー受け入れテスト (UAT) は、アプリケーションのビジネス要件へのコンプライアンスを評価し、アプリケーションが提供可能かどうかを評価するために実施されるテストです。ユーザー、顧客、またはその他の権限を持つステークホルダーが受け入れテストを実行します。開発者は、システムテスト中に見つかった問題の修正に対して責任を負います。