IBM Rational Test Workbenchとは？詳しく解説します

TOP
コラム
IBM Rational Test

IBM Rational Test Workbenchの概要について

ここでは、IBM Rational Test Workbenchについて説明させていただきます。
IBM Rational Test WorkbenchはAPIテスト、機能UIテスト、パフォーマンステスト、サービス仮想化を活用するためのプラットフォームとして機能します。 IBMでは、より高品質なソフトウェアと迅速なデリバリーへの取り組みを積極に行っております。これにより、ソフトウェア開発、テスト、および運用の各チームは、手戻り作業などに無駄な時間やコストを使わずに、イノベーションに時間を費やすことができます。特にソフトウェアテストにおいては無駄が発生しやすい分野であり、効率化が何よりも重要視されます。ソフトウェアテストは、ボトルネックになりプロジェクトの妨げになる可能性がある一方で、スムーズに実行することで、競争上の優位性になることもあります。 IBMは継続的なテストを実現するために、適切な機能とベストプラクティスを導入しており、多くの高品質なサービスを提供していることで知られております。具体的には適切な機能とベストプラクティスを採用し、DevOpsの変革をサポートする継続的なテストを実現しており、その結果としてスピードと品質の確実な向上が見られます。

IBMとDevOps

中でも最も重要な役割を果たすのがDevOpsであり、IBMでは非常に重要な役割を担っております。
IBMにおけるDevOpsアプローチの目標は、ソフトウェア・デリバリーを加速させると同時に、スピード、コスト、品質、リスクのバランスをとること、また、リスクのバランスを取りながら、クライアント・エクスペリエンスを向上させることです。この作業は決して簡単ではなく、日々の改善や高いテクノロジーが求められることは言うまでもありません。IBMではこれらを実現するためにテストツールを多くリリースしており、IBM Rational Test Workbenchはそのサービスの一つと言えます。
DevOpsを理解することがIBM Rational Test Workbenchに繋がるため、もう少し詳しくについて説明させていただきます。 DevOpsの中でも特に関連するのが継続的テストです。これらは継続的インテグレーションや継続的デプロイのようにデリバリーパイプラインのボトルネックを解消するために採用されています。プロジェクトチームは、有効なソフトウェアビルドが利用可能になったときに、それぞれをテストする能力を向上させる必要があります。継続的なテストは、ソフトウェアが現実的なテスト環境で検証される展開プロセスの一部として統合されたテスト自動化に依存し、サービス仮想化を追加することで、チームはシフトレフトを実行することができます。つまり、ライフサイクルの早い段階でソフトウェアの品質チェックを開始することができます。これらは依存性がありながら利用できないソフトウェアやシステムをシミュレートすることで、ソフトウェアの品質をライフサイクルの早い段階でチェックすることができます。
サービス仮想化についても説明させていただきます。サービス仮想化では、アプリケーション内の選択したコンポーネントの動作をシミュレートすることができます。企業はテスト環境において、実際のサービスやシステムの代わりに仮想サービスを使用することができます。テスト環境では、実際のサービスやシステムの代わりに仮想サービスを使用して、開発プロセスの早い段階で統合テストを実施することができます。IBM Rational Test Workbenchにおいては、テスト自動化とサービス仮想化を組み合わせることでチームはアプリケーションをエンドツーエンドでテストし、品質に関するフィードバックを即座に得ることができます。サービス仮想化によって、ソリューションの品質に関するこのような即時のフィードバックを獲得することで企業はその品質を予測することができます。また、高品質の革新的なソリューションを迅速に市場に提供することで企業としての競争力を高めることができます。

継続的テストは、プロジェクトチームが可能なときではなく、必要なときにテストを常に実行する準備を行うことができます。DevOpsを構成するプラクティスは、ソフトウェアデリバリーライフサイクルにまたがる幅広い能力セットであり、継続的なテストも含まれます。ソフトウェアデリバリーライフサイクルにまたがる一連の機能であり、継続的テストはその一つです。 DevOpsは、リーンとアジャイルの原則に基づくアプローチです。これらはアジャイル原則に基づくアプローチである原則に則りビジネスオーナーと開発、運用、品質保証の各部門が協力しながらプロジェクトが推進されていくと理解しておくとわかりやすいでしょう。ソフトウェアを継続的に提供することで、ビジネスが市場機会により迅速に対応できることが可能となります。また、市場機会により迅速に対応し、顧客からのフィードバックを得るまでの時間を短縮することができます。 DevOpsとは何か、DevOpsをどのように活用するかについては、専門家によっても意見が若干異なります。 DevOpsは実務者だけのものだと言い、クラウドを中心に展開するという人もいます。 IBMは、DevOpsをビジネス主導のソフトウェアデリバリーアプローチと捉えており、様々なサービスをリリースしております。 IBM Rational Test Workbenchもその一つと言えるでしょう。
このアプローチでは、新しいまたは強化されたビジネス機能をアイデアから生産に至るまで、効率的な方法で顧客に価値を提供し、その価値を獲得することができます。そのためには、開発チームと運用チーム以外のステークホルダーの参加が必要です。 DevOpsアプローチには、ビジネスライン、実務担当者、経営者、パートナー、サプライヤーなどが含まれます。 IBMを含むいくつかのソリューションプロバイダーは、この原則を独自に発展させたものを開発し、多くのサービスがリリースされております。今日のエンドユーザーは最終的なテスターであり、アプリケーションの経済的な成功を決定するための要因を構成します。このような要求から、企業は今日の消費者のニーズを満たすソフトウェアを、迅速に提供する必要があります。開発ライフサイクル全体を通してソフトウェアの品質に関するフィードバックを得ることができれば、ビジネスリーダーはより正確な予測を立てることができます。以上が簡単ではありますがIBM Rational Test WorkbenchとDevOpsに関する説明とさせていただきます。

IBM以外の取り組み

DevOpsに取り組んでいるのはIBMだけではありません。
クラウドコンピューを扱うクラウドベンダーはDevOpsの概念を重要視し、高い品質のサービスを提供していることで知られております。クラウドベンダーとはその名の通りクラウド技術を利用して様々なサービスを展開する事業会社を指します。最も有名なクラウドベンダーであるAmazon Web Services（AWS）を始めとして、 Microsoft（Microsoft Azure）やGoogle（Google Cloud Platform）など世界的なIT企業がそれらに該当します。また、IBMやOracleといった老舗ベンダー企業も独自のサービスを展開しクラウドサービス市場において上位企業を追従しております。
AzureはMicrosoftの提供するクラウドコンピューティングサービスとして世界トップクラスのシェアを誇っております。これらのサービスはコンピューティング、ID、モバイル、Web、ネットワーク、モバイル、セキュリティなど多くの領域において導入されており、Azureの特徴はそのテクノロジーの高さにあると言えます。
Azureではエキスパートのチームが支える徹底的なセキュリティと、エンタープライズ、政府機関、スタートアップから信頼されるプロアクティブなコンプライアンスを提供し、世界最高水準のテクノロジーを提供します。ハイブリッドクラウド向けに設計されたツールとサービスによって、オンプレミスでもクラウドでもあらゆる環境に対応することが可能です。また、クラウドベースのデスクトップとアプリの仮想化により、従業員がどこからでも、どんなデバイスからでも仕事を行うことが可能となります。

では、Azureのサービスについて簡単に紹介させていただきます。
Azureの「Azure Pipelines」では任意のクラウドまたはオンプレミスにデプロイし、 Linux、macOS、Windows 向けのクラウドでホストされるパイプラインを取得することが可能です。これらはWeb、デスクトップ、モバイルのアプリケーションをビルドを実行します。ビルドとデプロイを自動化すると、開発者は基本的な作業にかかる時間の削減を実現し効率的に重要かつクリエイティブな作業に時間をかけることができますのでDevOpsにとって非常に効果的なプラットフォームと言えるでしょう。
「Azure Pipelines」の特徴をいくつか紹介させていただきます。 Node.js、Python、Java、PHP、Ruby、C/C++、.NET、Android、および iOS アプリなどあらゆる言語やプラットフォームをビルド、テスト、デプロイすることが可能となり、Azure、AWS、GCP など、任意のクラウドへのソフトウェアの継続的デリバリー (CD) を実装することも可能で、相互に依存する任意の数のステージへのデプロイを視覚化します。また、Linux、macOS、および Windows で並列実行することができプラットフォームに関係なく効率的なDevOpsの支援を実行します。さらにコミュニティが構築したさまざまなビルド、テスト、デプロイタスクのほか、Slack からSonarCloud までの数百の拡張機能を探し、実装することが可能です。
次に、「Azure Repos」について説明させていただきます。
これはプロジェクトにクラウドでホストされた容量無制限のプライベートGitリポジトリを実現します。機能としては、スレッドのディスカッションと継続的インテグレーションにより、各変更に対するGitのコードレビューをより効果的に実行しフォークを使用して、インナーソースワークフローとのコラボレーションを促進します。また、継続的インテグレーション/継続的デリバリー (CI/CD) をセットアップして、完成したすべてのpull requestでビルド、テスト、デプロイを自動的にトリガーします。 pull requestをマージする前に、コードレビュー担当者のサインオフ、ビルドの成功、テストの合格を求めることで、コードの品質を高く維持します。さらにブランチのポリシーをカスタマイズして、チームの高い基準を維持するなどの機能を提供します。
次に「Azure Monitor」について説明させていただきます。ここではアプリケーション、インフラストラクチャ、およびネットワークに対する最新の監視機能でビジネスを変革することが可能で、Azureとオンプレミス環境からテレメトリデータを収集、分析し、データに基づいて行動を起こすことができます。また、アプリケーションのパフォーマンスと可用性を最大限に高め問題を特定することが可能で、アプリケーションの監視ではWeb アプリケーションの可用性、パフォーマンス、使用状況を監視するための機能を全て搭載しており一般的な言語とフレームワークがサポートされています。もちろんAzure DevOps、Jira、PagerDuty などの DevOps プロセスおよびツールとの統合が可能であるため、それらを組み合わせて利用することで高機能なイベントの監視を実行します。さらに、インフラテクノチャの監視も重要な機能となります。「Azure Monitor」では仮想マシン (VM)、Azure Kubernetes Service (AKS)、Azure Storage、データベースなど、インフラストラクチャのパフォーマンスを分析し、最適化します。 Linux VMとWindows VM、およびそれらの正常性と依存関係をすべて1つのマップ上で表示しそれらを監視することが可能です。もちろんネットワークの監視も実行します。
次に「Azure Artifacts」についても説明させていただきます。 DevOpsにおいて継続的インテグレーションと継続的デリバリーが重要なことについてはすでに本文で説明させていただきました。「Azure Artifacts」ではパブリックおよびプライベートのソースの Maven、npm、NuGet、Pythonパッケージのフィードを作成、共有可能することが可能となります。パッケージを共有し、組み込みの CI/CD、バージョン管理、テストを使用することができる点が大きな特徴です。

AWSとDevOps

AWSとDevOpsについて紹介させていただきます。
AWSはAmazon.comにより提供されているクラウドコンピューティングサービスであり、クラウド分野において世界トップシェアを誇るサービスとしても有名です。AWSではDevOpsを積極的に推奨していることは他社と同様です。そもそもDevOpsは一つの文化やルールであり、それらを共通理解としてもっておかなくては、DevOpsのスムーズな運営を実行することができないという点についてはしっかり理解しておく必要があります。
その文化はCALMSと呼ばれ、DevOpsプロセスにおけるフレームワークであり、 Culture、Lean、Automation、Measurement、Sharingの頭文字をとった言葉です。

CALMSの一点目はCultureです。CultureはDevOpsを実行するうえで最も重要な内容の一つです。 DevOpsは開発チームと運用チームの協力によって成立するため、単に各工程が効率的に開発を実行することが必要なだけではなりません。つまりCALMSの文化を理解せずにプロジェクトを推進するだけでなく、文化に対する共通認識が必要となるということです。例えば優秀なエンジニアを投入して開発を行い、便利な自動化ツールを導入したとしても、この文化についての共通認識がないとチームとしてのパフォーマンスは下がってしまう可能性すらあります。そのため、チームやマネージメントの担当者はDevOpsの文化の徹底を行いプロジェクトを推進する必要があります。
DevOpsのCultureにおける主な特徴は、開発と運用の役割間のコラボレーションの強化が最も重要な内容の一つと言えるでしょう。また、責任を共有する姿勢は、より緊密なコラボレーションを促進するDevOps文化の側面です。システムを別のチームに引き渡した後に、開発チームがシステムの運用と保守も継続して関係します。システムの存続期間にわたってシステムの世話をする責任を共有する場合、開発チームは運用スタッフの苦痛を共有できるため、展開と保守を簡素化する方法を特定できます。追加の Observed Requirementsを取得する場合がありますが、本番環境でのシステムの監視から運用スタッフがシステムのビジネス目標の責任を共有すると、開発者とより緊密に連携して、システムの運用上のニーズをよりよく理解し、それらのニーズを満たすことができます。実際には、コラボレーションは多くの場合、運用上の懸念事項（展開や監視など）に対する開発者の認識の高まりと、運用スタッフによる新しい自動化ツールとプラクティスの採用から始まります。これらの責任を共有する文化をサポートするには、組織のシフトが必要です。企業内に情報サイロが発生することを回避し、開発と運用の間における引き継ぎ期間とドキュメントは、最初からソリューションに一緒に取り組む必要があります。これらは運用スタッフがチームに早期に関与できるように、リソース構造を調整すると便利です。開発者と運用スタッフを同じ場所に配置すると、共同作業に役立ちます。引き継ぎとサインオフは、人々が責任を共有することを思いとどまらせ、非難の文化に貢献します。代わりに、開発者と運用スタッフの両方がシステムの成功と失敗に責任を持つ必要があります。これらのDevOpsのCultureは開発者と運用スタッフの役割の境界線を曖昧にし、最終的にはその区別をなくすという大きなメリットがあります。また、組織にDevOpsを導入する際の一般的なアンチパターンの1つは、誰かに「DevOps」またはチームを「DevOpsチーム」と呼びます。そうすることで、DevOpsが破壊しようとしている種類のサイロが永続化し、DevOpsの文化と慣習がより広い組織に広まり採用されるのを防ぎます。
もう1つの価値ある組織の変化は、自律的なチームをサポートすることです。効果的にコラボレーションするには、開発者と運用スタッフが、複雑な意思決定プロセスなしで意思決定を行い、変更を適用できる必要があります。これには、チームの信頼、リスクの管理方法の変更、失敗の恐れのない環境の作成が含まれます。たとえば、テスト環境に展開するためにサインオフの変更のリストを作成する必要があるチームは、頻繁に遅延する可能性があります。このような手動チェックを必要とする代わりに、完全に監査可能なバージョン管理に依存することができます。バージョン管理の変更は、チームのプロジェクト管理ツールのチケットにリンクすることもできます。
手動でサインオフしなくても、チームは展開を自動化し、テストサイクルをスピードアップできます。 DevOpsのCultureへの移行の効果の1つは、新しいコードを本番環境に導入することが容易になることです。これには、さらに文化的な変化が必要です。生産の変化が健全であることを保証するために、チームは開発プロセスに建物の品質を評価する必要があります。これには、パフォーマンスやセキュリティなどの部門の枠を超えた懸念が含まれます。SelfTestingCodeを含む ContinuousDeliveryの手法は、定期的な低リスクの展開を可能にする基盤を形成します。また、開発者と運用スタッフの連携方法やシステム自体を継続的に改善するために、チームがフィードバックを重視することも重要です。生産監視は、問題を診断し、潜在的な改善点を見つけるための有用なフィードバックループです。これらが高品質なサービスを実現し、顧客の満足度を高めるということがDevOpsの本質的な目的の一つとなります。

CALMSの二点目はLeanです。Leanとは、DevOpsプロセスにおいて無駄を回避し、効率的に開発を行うことを意味します。あらゆるプロジェクトやソフトウェア開発やテストにおいて失敗や間違いは避けることができません。重要なことは失敗そのものを回避するよりも、チームとしてそれらを受け入れ、吸収し改善を実行することです。 DevOpsプロセスにおいては失敗そのものが責められる文化ではなく、それよりも失敗の個所を特定し改善するというプロセスを重視します。これにより結果としてチームが活性化し高いパフォーマンスを維持することが可能となります。これらの考え方は従来のソフトウェア開発における考え方と異なる部分もありますが、DevOpsを理解するうえで重要な内容であることは間違いありません。

CALMSの三点目はAutomationです。自動化の重要性においてはいうまでもありません。現在多くのソフトウェア開発において自動化のためのツールやプロセスが導入されておりますがDevOpsにおいてはよりそれらを重視し効率的な開発を実現します。具体的にはDevOpsプロセスにおいて反復的な手作業を排除し、反復可能なプロセスを生み出し、信頼性の高いシステムを構築するという過程がとられます。また、これらを実現されるためのキーワードが本文でも紹介させていただきました継続的インテグレーションおよび継続的デリバリーです。継続的デリバリーではコード変更が発生した際に自動的に構築、テスト、および実稼働環境へのリリース準備が実行されるという特徴をもつ開発手法の一つです。継続的インテグレーションを拡張した継続的デリバリーによりコード変更が、ビルド段階の後にテスト環境や本番環境にデプロイされます。継続的デリバリーを適切に実装することで標準化されたテストプロセスに合格し、デプロイ準備の整ったビルドの成果物を常に確認し作業を行うことが可能となります。

CALMSの四点目はMeasurementです。 DevOpsプロセスにおいて継続的な改善をしっかりと計測し分析することは非常に大切です。開発から展開までの速度やバグ頻度、システム障害後の回復や、ユーザー数などサービスに関わるあらゆる数字を把握し計測し改善を実行していくことが重要となります。また、このような計測データを多くの部署と共有し分析を行うことでより顧客満足をを高めることが可能になります。

では、AWSとDevOpsについてさらに詳しく解説させていただきます。 AWSはDevOpsを導入し多くのサービスをリリースしていますが、これらについてのメリットをいくつか紹介させていただきます。
DevOps導入のメリットの一点が迅速にサービスを開始することが可能という点となります。 Amazonのアカウントを保有しているユーザーであれば特別な手続きが必要なく、簡単にサービスを利用することが可能です。これによりビジネスにおいて非常に重要なポイントであるサービスの立ち上げの速度と市場への投入という点を担保することができます。
二点めがフルマネージドサービスであるということです。そのためユーザーはサーバの管理や障害対応などの心配なく開発に集中することができるというメリットがあります。世界最高水準のAWSの環境やサービスを安心して利用することができます。また、拡張性が高いということも大きなポイントになります。
AWSを利用することで単一のインスタンスを管理したり、数千単位までスケーリングすることが可能です。現在の急激に変化するビジネスにおいて柔軟に拡張することはサービス提供側としては非常に柔軟なポイントであることは間違いなく、それにより無駄なコストを削減することにも繋がります。 AWSではプロビジョニング、設定、スケーリングを単純化し、柔軟なコンピューティングリソースを行うことが実現できるというメリットがあります。オートメーションを使用して構築の高速化と効率化を達成することが可能である点も忘れてはいけません。 AWSで提供されているサービスを利用することでデプロイ、開発とテストのワークフロー、コンテナ管理、設定管理などの、手動で実行するタスクやプロセスを自動化できます。

次にDevOpsに関連するAWSの具体的なサービスを紹介させていただきます。
「AWS CodeStar」ではアプリケーションを迅速に開発および構築してデプロイすることが可能です。AWS CodeStarは統合されたユーザーインターフェイスを備えているため、ソフトウェア開発アクティビティを1つの場所で簡単に管理できます。 AWSでの開発を数分で開始できるため開発者にとって非常に便利なツールと言えるでしょう。また、ソフトウェアデリバリーを1つの場所で管理できることや、チーム全体でセキュアに作業できることや、さまざまなプロジェクトテンプレートから選択可能できるなど多くのメリットを提供することができるプラットフォームと言えます。
「AWS CodeBuild」ではソースコードをコンパイルし、テストを実行し、デプロイ可能なソフトウェアパッケージを作成できる完全マネージド型のビルドサービスを提供しております。 AWS CodeBuildではDevOpsにおいて必要不可欠である継続的インテグレーションと継続的デリバリーを実現することが可能です。また、完全マネージド型ビルドサービスであり拡張であること、従量課金制であることなどがAWS CodeBuildの特徴となります。多くの企業やチームのDevOpsの支援を実行することが可能です。
「AWS CodeDeploy」ではAmazon EC2、AWS Fargate、AWS Lambda、オンプレミスで実行されるサーバーなど、さまざまなコンピューティングサービスへのソフトウェアのデプロイを自動化することが可能です。これらのフルマネージド型のサービスではDevOpsにおいて必要な自動デプロイを可能としミスが起こりやすい手動操作を不要とします。また、アプリケーションのデプロイ時のダウンタイムを回避し、アプリケーションの複雑なアップデート処理にも対応します。
「AWS CodeDeploy」では、デプロイのニーズに応じてスケールすることが可能であるサービスとなります。
「AWS Lambda」では、サーバーレスでイベント駆動型のコンピューティングサービスを提供しサーバーのプロビジョニングや管理をすることなく、あらゆるタイプのアプリケーションやバックエンドサービスのコードを実行することができます。大規模なデータ処理、インタラクティブなウェブおよびモバイルバックエンドの実行、強力な機械学習インサイトを実現、イベント駆動型アプリケーションの作成することができる点がその特徴となります。
また、テストに関連するサービスとしてLambdaTestというサービスも提供しております。 LambdaTestは3000以上のブラウザとオペレーティングシステムで自動化されたライブインタラクティブクロスブラウザテストをオンラインで実行するテストツールです。クロスブラウザテストというのは、Web開発者がWebサイトでブラウザの互換性テストを実行するのに役立つソフトウェアツールで、特にモバイルアプリのテストを実施する際やWebサイト開発プロジェクトのテストにおいては不可欠なツールと言えるでしょう。クロスブラウザテストソフトウェアを開発者のワークフローに統合して、迅速な結果を提供し、Webサイトのテストに費やす時間を短縮することが可能です。複数のブラウザでサイトをテストする場合、さまざまな方法でテストできますが、クロスブラウザテストツールを導入することが一般的です。現在多くのクロスブラウザテストツールがリリースされておりますが、メリットデメリットが存在するため、プロジェクトや担当者のスキルや予算にあったものを選定することをおすすめします。
「AWS OpsWorks」ではChefやPuppetのマネージド型インスタンスを利用できるようになる構成管理サービスであり、DevOpsによって必要なオートメーションプラットフォームを提供します。
以上が簡単ではありますがAWSとDevOpsについての説明とさせていただきます。

シフトレフト

IBM Rational Test Workbenchを理解するうえで重要なポイントとしてシフトレフトがあげられます。
シフトレフトとは、ソフトウェア開発における慣行の一つで非常に重要な考え方の一つです。ソフトウェア開発およびソフトウェアテストの工程において問題の検出だけでなく問題の予防に努め、これまでよりも早い段階でソフトウエアのテストを開始ことやそれに関する考え方をシフトレフトと呼びます。その目的は、品質を向上させ、長いテストサイクルを短縮し、無駄な作業やそれに伴うコストや負荷が発生する可能性を低減することです。開発サイクルの終わりに多くのミスや見落としていた問題によって、手戻りや重大な欠陥が生まれることがあります。
現在のIT業界においてそれらは多くのリスクをもたらし、あらゆるプロジェクトにおいて監視すべき課題と言えるでしょう。テスト開始前にすべてのアプリケーションコンポーネントが利用可能になるのを待つことは、しばしば遅延の原因となり、プロジェクトのリスクを増大させ、欠陥やアーキテクチャ上の重要な課題が欠陥することに繋がると言えるでしょう。シフトレフトプラクティスは、これらを回避しプロジェクトがスムーズに推進されるために重要な考え方です。シフトレフトを実行することでテストサイクルの後半に重大な欠陥が発見された場合に発生する手戻り、遅延、解約を回避することができます。テストサイクルの後半に重大な欠陥が発見された場合、すべての統合および製品コンポーネントが最終的に複合アプリケーションとして組み合わされているためすでに完了した工程に対して調査、修正などを実行することが必要となります。これらを回避するために統合テストも重要です。統合テストは、コードが現実的なテストラボにデプロイされると同時に実行され、これらの問題を回避することを目的としています。これらはテストラボで実施します。依存するアプリケーション・コンポーネントがテストに利用できない場合は、仮想サービスによって実際のコンポーネントの動作を模倣することができます。仮想サービスは、その準備が整うまで実際のコンポーネントの挙動を模倣します。例えばIBM Rational Test Virtualization Serverと IBM UrbanCode Deploymentを組み合わせることでシフトレフトのソリューションを実現することが可能となります。 IBM UrbanCode Deployを組み合わせて連携させ、プロビジョニングを行うことが可能となります。
以上が簡単ですがシフトレフトについての説明となります。

テストコスト削減

IBM Rational Test Workbenchを理解するうえで重要なポイントとして、テストコスト削減です。
ソフトウェア開発のライフサイクルにおいてテスト工程が非常で重要な役割を占めることはいうまでもありません。その一方でテスト工程においては多くのコストが投入され、企業においてそれらが無駄になるケースは決して少なくありません。これらは企業のコストを奪うだけでなく、ソフトウェアの市場投入を遅らせる原因となることもあるため企業の競争力を低下され、様々な影響を与え、ソフトウェアを開発あらゆる企業にとって大きな課題の一つと言えます。
なぜテストはそんなにコストがかかるのかというと、アプリケーション開発の新しいアプローチとクラウド技術の採用がその背景にあります。これらはレガシーシステムで維持されている記録システムの安全性を確保しながら、新しい革新的なアプリケーションのフロントエンドの両方を検証し運用する必要があり、これらがプロジェクトに混乱な無駄を発生させているためです。ソフトウェア開発とデリバリーは、複雑なモノリシック・アプリケーションから進化しており、その多くの依存関係はビルド時に解決されます。ソフトウェア開発とその提供は、従来型のビルド時に多くの依存関係を解決する複雑なモノリシック・アプリケーションから、実行時に依存関係を解決できるより分散したサービス中心アーキテクチャへと進化しています。ほとんどのエンタープライズ・アプリケーションは、もともとクラウド以前の環境向けに設計された既存のアプリケーション（Systems of Recordとも呼ばれる）と、新しいSystems of Recordの組み合わせによって構成されておりこれらを統合し最適な形で運用することが大きなポイントと言えるでしょう。ただしこれらのアプリケーションのアーキテクチャは、多くの依存関係があるため、複雑化する傾向にあります。これらを解決するのがAPIです。APIを使用して、新しいシステム・オブ・エンゲージメントと既存のシステム・オブ・レコードの間の橋渡しをします。
API管理とクラウド統合技術を活用することで組織のセキュリティ要件に対応しながら、統合を可能にします。これらのワークロードは複数の環境にわたって実行することができます。

クラウド

次にテストとクラウドについて説明させていただきます。
現在の企業においてはオンプレミス、プライベートクラウド、パブリッククラウドというように環境が多様化しており、これらの組み合わせは、ハイブリッドクラウドとも呼ばれます。ハイブリッドクラウドアーキテクチャは、クラウド対応アプリケーションとクラウドネイティブアプリケーションの両方において、標準となりつつあります。 IBMが2016年に発表したホワイトペーパーでは、ハイブリッドクラウドは展開に柔軟性をもたらし、組織が適切なワークロードを実行するためのプラットフォームを選択することを可能にするとしております。また、IDC（International Data Corporation）は、多くのIT企業がハイブリッドクラウドアーキテクチャに取り組むと予測しています。テストコストを削減するために、組織はテスト自動化の導入やフレームワークの開発に取り組み、テスト効率を高めています。現在多くのソフトウェア開発におけるテストはフレームワークを開発し、テストの効率化を図っています。もちろん全てのクラウドがテストコストやテクノロジーの問題を解決するとは限りません。ただし多くの場合においてソフトウェアの機能検証のスピードが向上し多くのユーザーにとって満足度を高めることを可能にするでしょう。クラウドによるサービス向上でソフトウェアの機能を検証し、顧客の手に届けることで、市場シェアを拡大することも可能であると言えるでしょう。IBMでは多くのサービスによりこれらを実現しております。

その代表例がIBM Cloudで、最大の特徴の一つが堅牢性となります。 IBMは長い歴史の中で基幹系システム実績が豊富であり、その実績と性能については業界でトップクラスです。また、金融系などのシステムにおいてはセキュリティの高さや堅牢性は最も重要な機能の一つです。
IBM Cloudの強みと言える点がオンプレミスであり、オンプレ上の既存のアプリケーションをIBM Cloudに移行することが可能な「VMware on IBM Cloud」というサービスをリリースしております。多くのユーザーが導入するVMwareですが、オンプレミスからクラウドへの移行、連携はアプリケーションの構成変更など技術的に検討する内容が多岐に渡り不安を抱えている企業も少なくありません。「VMware on IBM Cloud」はVMwareのミドルウェアを購入してオンプレミス環境で動作させる操作と同様に、クラウド上に用意したVMwareのミドルウェアを、自由に操作することが可能となります。バックアップ機能・可用性の確保、ジョブ制御といった非機能要件がポイントとなりますが、これらをオンプレミス環境からそのまま利用できる点がこれらを実現します。 IBMの培ったオンプレミスの実績とIBM Cloudのテクノロジーでユーザーを協力に支援することが可能となります。特にハイブリッドクラウドで運用する企業が増加しつつある昨今において、オンプレミス環境からの移行やVMwareの移行、などに課題や不安を抱えているケースにおいてはIBM Cloudを利用するメリットは非常に大きいと言えるでしょう。従来型のオンプレミス環境からの移行やマルチクラウドはこれからのIT企業において必須となってきますので、そのあたりに実績を誇るIBM Cloudを利用することは大きなメリットと言えるでしょう。

では、さらにクラウドについて詳しく解説させていただきます。ビジネス上の利害関係者は、プロジェクトチームに対して、新しいアプリケーション、統合、移行、および変更をできるだけ早く提供するよう要求します。それに対して、プロジェクトチームは、テスターに技術環境が要求通りに動作すること、ビジネスプロセスとトランザクションが期待通りに実行されること、ソリューションが想定される使用量に対応すること、アプリケーションは安全で、ユーザーデータは保護されること、というような検証を依頼します。
これらを高い水準で実行するためのプラットフォームをIBMは提供します。ソフトウェアやシステムのプログラマーはミスをしないように最善を尽くしますが、ヒューマンエラーを避けることは難しいため、慎重なテストを実施する必要があります。これらのテストをしないことで発生するリスクは、たとえわずかなテストでも実施するコストを大きく上回ります。 Application Development Trendsが実施した最近の調査では本番環境へのデプロイを遅らせる理由において最も大きな理由は圧倒的にテストであることが判明しました。 IBMは、アナリティクスとテストに関する洞察を用いてテスト作業と関連するデプロイメント作業を最適化することに重点を置いています。これはより多くのリソースをイノベーションに利用できるようにするためです。アジャイルやDevOpsの採用が進む中、繰り返し行うたびに手動テストを再実行することは、持続可能なパターンではありません。これらの課題を解決するのがテスト自動化です。テスト自動化ツールの代表例はSeleniumです。
Seleniumとは画面のテストを自動化し実行することを可能にするツールで、習得のための難易度が比較的低いことや、テスト作業を簡単に効率化できるためITエンジニアが利用するテストツールとして人気です。テストを実行うする際の方法として、WebブラウザにおいてITエンジニアが入力を行い検証するテスト方法と、プログラミング言語やスクリプト言語を利用しテストを実行させる方法があり、Seleniumは後者に該当します。
Apache JMeterもテスト自動化における有名なツールです。 Apache JMeterはクライアントサーバシステムのパフォーマンス測定および負荷テストを行うJavaアプリケーションです。HTTPレスポンスの内容の妥当性を判定することもできるため、パフォーマンステストのみならず、機能テストに使用することも可能な幅広いソフトウェアとなります。 Apache JMeterはオープンソースソフトウェアであり、機能動作のテストとパフォーマンスの測定をロードするように設計されていることが大きな特徴の一つと言えます。 Apache JMeterはページの閲覧、リンクのクリック、メニューへのアクセスなどのユーザー操作をシミュレートすることにより、Webアプリケーションの機能をテストするために使用できます。 Apache JMeterでは高速テストプランの記録、構築、およびデバッグなどテスト実行に必要な機能を揃えたIDEとして活躍しております。これらのIDEは、開発者がコードを整理し、他のユーザーと共有し、Webサイトまたはアプリケーションの作成プロセスをより効率的にするのに役立つように設計されているパッケージです。コードエディタやコンパイラ、リンカ、デバッガ、テストツール、バージョン管理ソフトなどがパッケージングされていることが多いです。テストIDEはテストを効率的に実施できるように機能が搭載されたIDEであり、最も有名なものの一つがSelenium IDEとなります。 Seleniumは2004年にThoughtWorks社により開発が行われ歴史が始まりました。その目的はテストにおける自動化の実現であり、ツールは同年にオープンソース化されております。 2007年にはWebDriverと称されるブラウザ自動化ツールを開発しリリースされ、「Selenium WebDriver」「Selenium 2.0」プロジェクトが開始されております。その後「Selenium Grid」と呼ばれる複数のSelenium テストを複数同時に実行できる機能の実装などを経て現在に至って、現在でも多くのエンジニアにSeleniumは利用されているテストツールの一つです。Apache JMeterは2001年にリリースされましたので、最も歴史の長いテストIDEの一つと言えるでしょう。また、Apache JMeterの特徴として環境を問わず動作するという点もメリットと言えるでしょう。ソフトウェアテストを実施するうえで多くの環境やツールに対応することができるという点は大きな意味を持ちます。 ApacheJMeterでは多くの異なるアプリケーション/サーバー/プロトコルタイプをロードしてパフォーマンステストする機能を搭載しており、開発者がテスト実行するための環境を選びません。具体的には、 Web-HTTP、HTTPS（Java、NodeJS、PHP、ASP.NET、その他の言語）、SOAP /RESTWebサービス、FTP、JDBCを介したデータベース、LDAP 、JMSを介したメッセージ指向ミドルウェア（MOM）、メール-SMTP（S）、POP3（S）、IMAP（S）、ネイティブコマンドまたはシェルスクリプト、TCPJavaオブジェクトなどです。本文でお伝えしたように、当初はWebアプリケーションをテストするために設計されましたが、その後拡張され、現在では複数のプログラミング言語や環境においてテストを実行することが可能となっております。
以上が簡単ではありますがクラウドとテストに関する説明とさせていただきます。

継続的テスト

IBM Rational Test Workbenchを理解するうえで重要なポイントとして、継続的テストがあげられます。
継続的テストは大きなトレンドの一つといってもよく、IBMでもそれらを実現するための取り組みを行っております。継続的なテスト文化を構築するには、人、プラクティス、ツール、そして時間が必要となります。実現するためには、すべてのテストプラクティスにおいて、適切な努力のバランスを見つけることが重要です。しかし、テスト用にコードをデプロイし始める前に、見落とされがちな活動の1つがコードレビューとなります。ビルドに含まれ、環境 (テストまたは本番) へのデプロイ時に使用されるすべてのものは、この目的のために集められた専門家のチームによってレビューされるべきです。コードレビューは、効率的に実行され、効果的であるとみなされる必要があります。そうでなければ、チームはそれを時間の無駄と見なすかもしれません。レビュープロセスにおいても注意が必要です。
レビュープロセスでは、新しいソフトウェアや変更されたソフトウェアが組織のコーディング標準に従っており、組織のベストプラクティスを遵守していることを確認する必要があります。また、それはベストプラクティスを遵守していることを確認する必要があります。テストを実施する際の注意についても説明させていただきます。従来のテスト手法を適用した場合、不具合はテスターとプログラマーとの最初のコミュニケーショテスターとプログラマー間の最初のコミュニケーション不足によって生まれるケースは少なくありません。多くの場合、欠陥はコードそのものではなく、要件や設計、あるいはテストに問題があります。時には、問題はアプリケーションの外に原因があるケースもあります。
具体的にはテスト環境、テストデータ、テストスクリプトそのもの、あるいはこれらの組み合わせなどです。これらの問題を正確に把握するためには慎重に調査し、関係者のコミュニケーションをスムーズに実行することが重要です。

ソフトウェア開発ライフサイクル

これらを実行するために重要なことがソフトウェア開発ライフサイクルの理解でしょう。
ライフサイクルのどの個所に問題が発生しているかなどを的確に把握することが問題解決の初期段階です。不具合を記録し、追跡するための協調的な環境を持つことは、どのようなソフトウェア開発ライフサイクルにおいても不可欠です。しかし、欠陥の管理は、正しい手法を採用するための氷山の一角に過ぎないとも言えます。欠陥の管理に費やす労力のレベルを分析するときは、次の内容が重要となります。欠陥の記録、トリアージ、分析に多くの時間を費やしていないか、あるいは本質的でない欠陥について時間を費やしていないかという点です。具体例を出しながら説明させていただきます。
例えば、テストとコードの間に誤解があるような、本質的な欠陥ではない場合においても多くの時間を費やすケースはプロジェクトによく見られます。このようなテストとコードの間の誤解などを回避することでできれば、多くのプロジェクトはスムーズに実行することができると言えます。また、それらを実現するためには何が欠陥とみなされ、何が要求とみなされるかを定義し、理解することが大切と言えるでしょう。そして何が不具合で、何が改善要求（RFE、変更要求、強化要求などとも呼ばれる）であるかの定義や理解を、デリバリーチーム全体で共有することが重要です。プロジェクトを運営する際、多くの開発メンバーやテストエンジニアや利害関係者が存在します。そして個人的な意見や好みが不具合として表面化することがよくありますが、あくまでも機能をベースにコミュニケーションを実行し、問題解決にあたる必要があります。例えば不具合だけを提出し、機能拡張を提出しないのであれば、プログラマーとテスターの間に軋轢が生じる可能性があります。こういったチームメンバー間のコミュニケーションコストを抑え、RFEを提供する最良の方法について協力することで、より良いチームワークを築くことができます。
IBMでは、不具合と機能拡張を以下のように区別しています。不具合はテスト対象のソフトウェアがアプリケーションの要件と一致しない問題であり、アプリケーション要件と一致しない問題です。一方で機能拡張はテスト対象のソフトウェアが期待通りに機能せずテスト対象のソフトウェアが期待通りに機能せず、期待される動作を捉えたアプリケーション要件がない場合に実行します。テスト自動化の実践は、これらのテスト管理の後に来るものであるため、まず自動化ありきでなく問題を正しく理解することが重要です。すべてのテストを手動で実行することは、非効率的であり、必ずしも正しくないと言えるでしょう。堅牢で保守性の高いテスト自動化フレームワークを作成することは多くのリソースや高いテクノロジーが必要となりますので、それらをIBMではカバーします。
また、そのためにはビジョン、要件、アーキテクチャ、デザイン、コーディング、そして場合によっては自動化が意図したとおりに実行されるかどうかの検証など多くの手間がかかることは間違いありません。
テスト自動化フレームワークは、非常に便利な一方で壊れやすく、脆く、保守が困難で、リファクタリングにコストがかかるケースもありますので、すでに準備された高いテクノロジーやパッケージを導入することでそれらを回避することができるでしょう。 IBMでは、アプリケーションのすべての層でテストを自動化することを提唱しています。コンポーネント層、サービス層、およびユーザーインターフェース層を含む、アプリケーションのすべての層でテストを自動化することを提唱しています。これらの層にまたがるテストの適切なバランスを見つけることが重要です。

単体テスト

IBMでは単体テストの重要性を理解し、それらを強力に支援します。
単体テストはユニットテストと呼ばれることもあり、ユニット単位で検証を行い、モジュールやコンポーネント単位でのテストを実施することになります。単体テストのメリットとしては、モジュールやコンポーネント単位でテストを実施するため原因の特定と修正が容易があるということがあげられます。また、単体テストの段階で不具合を見つけることで、結合テスト以降の工程においてテストの手戻りを少なくすることなどが可能となり、テストの安定性を担保するという意味もあります。開発者がテストに関するドキュメントを参考にすることで、そのユニットの正常動作に必要不可欠な特性を理解することができるという点もメリットとしてあげておきます。単体テストにおいては、単体ストのユニットのAPIのドキュメントを確認することで効率よくシステムを把握できるという一面もあります。また、単体テストにおいては、コードが設計通りであることや意図したとおりに動作できているかとう点を確認するため、ソフトウェア開発者の手により実行されるケースも多いです。そのため、単体テストにおけるデメリットや注意点としては開発者が単体テストを実施することが多いため、工数がかかりやすいということがあげられるケースも少なくありません。最近では単体テストは自動化するケースが増えているため、開発者およびテスターが単体テストを実施する際にテスト自動化ツールなどの知識や経験が必要になることも少なくありません。いずれにせよ単体テストの品質がプロジェクト全体に及ぼす影響は大きいため、専門的な知識と配慮をもって単体テストを実施することは必須と言えるでしょう。
プログラマーのコードが彼らの開発環境で正しく動作することを確認するためのユニットテストを実行することは、デリバリーチーム全体の信頼を構築する上で大きな役割を果たすでしょう。ソフトウェア開発ライフサイクルのもっと早い段階で提供できるベストプラクティスを実行することで、後の段階で不必要な遅延あるいはコストの増加を回避することが可能です。プログラマーを含むすべてのチームメンバーは、そのソフトウェアの品質に貢献する責任を共有し行動することが重要と言えるでしょう。
また、単体テストにおいてテスト自動化と並行して、テスト分析と洞察のプラクティスも重要な点です。貴重なテストの労力をどこに費やすべきかをチームが知るために、テスト分析および洞察を提供します。もちろんテスト工程において重要な点は単体テストのみではありません。結合テスト、システムテスト、ユーザーテストといった各工程を経て実行されますのでそれらに対する正しい知識は必要となります。また、自動化ツールや様々なテクノロジーを導入する際にも、それぞれの工程を理解し、正しい形で利用することが重要であることはいうまでもありませんので、簡単に紹介させていただきます。

まず、結合テストでは、単体テストの次の工程としてモジュールを結合させた状態でのテストを実施します。この工程ではモジュール間のインターフェース構造や結合についての動作の確認を実施し、プログラムやモジュール間の構造やデータの受け渡しなどについて問題がないか確認、検証を実行します。単体テストではあくまでもモジュールやコーポネントの確認であり、それぞれの結合についてのテストは結合テストで受け持つという形になります。
結合テストにはいくつか手法がありますが、その代表的な例であるトップダウンテストとボトムアップテストについて説明させていただきます。トップダウンテストは上位のモジュールからテストを実施していく方法となります。上位モジュールがテストを通過することで、該当モジュールから呼び出される下位モジュールのスタブを用意して検証を行います。上位のモジュールからテストを実施するため、プログラム機能の漏れを発見するのが容易であることがトップダウンテストのメリットとなります。ボトムアップテストは下位のモジュールからテストを実施し上位モジュールに対してテストを行っていく方法となり、トップダウンテストとは逆のアプローチとなります。理解していくポイントとして、開発と同時にテストを実施できるというメリットがある一方で不具合があった際の影響も多いのがボトムアップテストであるということです。そのためどちらのテスト手法を選択するのかについてはシステム開発全体の特性や機能や規模など様々な要素を考慮し決定するといいでしょう。また、自動化ツールなどもプロジェクトの目的や環境にあわせて決定する必要があります。

次の工程がシステムテストです。システムテストは単体テスト、結合テストの次の工程となり全ての機能が揃った状態で様々なテストを実施します。テスト工程におけるV字モデルにおけるシステムテストは要件定義の工程とリンクしております。 V字モデルはシステム開発として一般的かつオーソドックスな手法として使われており、基礎的な知識となります。Vモデルの概念図において、図の左側には「要件分析」「要件定義」「基本設計」「詳細設計」が表記されます。図の右側には「単体テスト」「結合テスト」「システムテスト」「ユーザーテスト」が表記されます。これらのそれぞれの工程がリンクすることがV字モデルの根幹です。「要件分析」は「ユーザーテスト」とリンクしており、ユーザーが要件通りにシステムが作成されているかを確認するテストとなります。つまりシステムテストでは要件定義で決定した要件の内容に沿っているかという点について確認していくことになり、要件定義書に記述した機能要件・非機能要件などをテストしていきます。システムテストのテストの種類は何通りかありますので、プロジェクトやテスト内容に応じてそれらを選定していきます。機能テストでは、要件定義書に記述した機能について本番環境と同等の状態でシステム要件を満たしていることを検証します。システムが機能要件通りに稼働することや、その他の機能が正しく動作するかという点について確認を実施するテストです。
構成テストでは、サポートされる各ソフトウェア構成とハードウェア構成に関するシステムのテストを行います。これらの工程を経て最終的にユーザーユーザーテストが実施されます。ユーザーテストは受け入れテストとも呼ばれ、システムテストを実施した後のテスト工程となります。運用環境やそれに近しい環境においてはユーザーが動作や品質などをチェックし、確認するテストとなります。ユーザーテストはテスト工程における最終段階となります。クライアント（発注者）の希望した機能が搭載されていても、実際の運用環境でしっかりと稼働しなければ意味がありません。また、ユーザーテストでは思いもよらないトラブルやクライアント（発注者）が利用できるかなど様々な観点でサポートを行う必要があります。開発したシステムがクライアント（発注者）のニーズを満たせているかという点が最も重要となり、リリース後の安定した運用にも影響してくる部分となりますので、ユーザーテストは非常に重要な工程であると理解しておく必要があります。
以上が簡単ですが単体テストの説明とさせていただきます。

IBM Rational Test Workbenchの機能

IBM Rational Test Workbenchの機能について説明させていただきます。
すでに本文で伝えたようにIBM Rational Test Workbenchは、APIテスト、機能UIテスト、パフォーマンステスト、サービス仮想化など、DevOpsアプローチをサポートするソフトウェアテストツールを提供します。これらはテストをより早く、より頻繁に自動化して実行し、修正にかかる費用が少ないときにエラーを特定します。
IBM Rational Test Workbenchのメリットの一点目がエラーが発生しやすい手動テストを減らすことです。従来型の手動テストにおいてはエラーや人為的なミスを避けることができません。もちろん全てのテストを手動化することが難しい場合もありますが、効率的な自動テストを導入することはプロジェクトに大きな意味を与えます。従来のプロジェクトで利用していた機能を失うことなく、モバイルおよび統合テクノロジーなど、すべてのテストを自動化することが可能となります。
二点目がユーザーエクスペリエンスを簡素化することです。ユーザーエクスペリエンスデザインは、製品とのやり取りで提供される使いやすさ、アクセシビリティ、および喜びを向上させることにより、ユーザーの満足度を高めるプロセスです。 UXデザインとは、誰にとっても使いやすく満足のいく製品をデザインすることで、優れたカスタマーエクスペリエンスを生み出すことです。これらは製品に関するすべてが可能な限り直感的で簡単になるように設計されていることを確認する責任があります。 IBM Rational Test Workbenchでは完全に統合されたオーサリング環境を使用して、さまざまなドメインで一貫したユーザーエクスペリエンスを実現します。
三点目が欠陥を早期に見つけることができる点です。テストを開始するための時間を削減し、スムーズなテストを実行することができます。
四点目がツールの統合です。 IBM Rational Test Workbenchでは他のツールと統合して、モバイル、ウェブ、従来のデスクトップアプリなどのテストシナリオを作成します。これによって従来のツールの利便性を生かしたままテスト工程を実行することが可能となり、プロジェクトに影響を与えずにテストを行うことが可能となります。
五点目が品質を向上させることができる点です。 IBM Rational Quality Managerと統合して、テスト作業の回収率を向上させます。 IBM Rational Quality Managerは、開発ライフサイクルの全体にわたって総合的なテスト計画、テスト構成、およびテスト成果物管理の機能を提供する、コラボレーティブなWeb ベース・ツールで、あらゆるサイズのテスト・チーム用であり、テスト・マネージャー、テスト・アーキテクト、テスト・リーダー、テスト担当者、および Labマネージャーなどのさまざまなユーザー役割をサポートしています。これらのアプリケーションはテスト組織外の役割もサポートしています。

IBM Rational Test Workbenchの特徴

IBM Rational Test Workbenchの特徴について説明させていただきます。
一点目がコードフリーのオーサリングです。 IBM Rational Test Workbenchではストーリーボードテストを使用して、自然言語テストの説明とビジュアル編集を組み合わせて、機能テストと回帰テストの作成を簡素化します。機能テストは、ソフトウェアが要件を満たしていることを確認するために使用されるソフトウェアテストの一種です。回帰テストは、同じテストケースを繰り返し実行するプロセスです。アイデアは、ソフトウェアに加えられた変更の結果として、欠陥が導入または発見されたかどうかを確認することで、Cucumber、Selenium、FitNesseなどの自動ツールを使用して手動または自動で作成できます。これにより高度なテストを簡単に実行することが可能となり、開発者やテストエンジニアの負担を減らし、スムーズなプロジェクト推進を行うことを可能とします。
二点目がスクリプトレスの視覚的なパフォーマンステストとワークロードモデルです。
パフォーマンステストは、特定のアプリケーションのパフォーマンスを測定するプロセスです。これにより、アプリケーションがパフォーマンス要件を満たし、特定の数のユーザーを問題なく処理できるようになります。 IBM Rational Test Workbenchでは動的サーバー応答の自動管理により、大規模なパフォーマンステストスイートの提供を加速します。
三点目が継続的インテグレーションテストです。継続的インテグレーションテストは、開発者がコードの問題を検出し、問題が発生する前に修正するために使用できるソフトウェア開発ライフサイクルテスト手法です。継続的インテグレーションテストは、多くの場合、Jenkins、Travis CI、TeamCity、Bambooなどのツールまたはフレームワークを使用して実行されます。これらのツールを使用すると、開発者はコードに対して継続的テストを実行し、本番環境にプッシュする前にコード内のエラーを特定できます。 IBM Rational Test Workbenchではビジネスプロセス実行言語モデルまたはビジュアルテストデザイナを使用して、既存のシステム動作を記録することにより、サービスレベルのテストを開発し実行することが可能となります。
四点目が正確なワークロードエミュレーションを実現する点です。 IBM Rational Test Workbenchでは、グラフィカルなワークロードスケジューラを使用して、さまざまなユーザーグループと負荷条件のモデリングを簡素化します。五点目が標準とプロトコルの拡張性を担保している点です。 IBM Rational Test WorkbenchではJavaコードの挿入、カスタムデータ変換などの拡張機能を使用して、既存のサービスまたはカスタムサービスを適応させます。
六点目が柔軟な価格設定となります。独自のビジネスニーズに応じて購入および割り当てることができるため、無駄なコストを発生せずに企業によって最適な料金で運用することが可能となります。
以上が簡単ではありますがIBM Rational Test Workbenchの特徴に関する説明とさせていただきます。

まとめ

いかがでしたでしょうか？ IBM Rational Test Workbenchについて詳しく解説させていただきましたので、参考にしてみてください。