テスト自動化
自動化を適用できるテストの分野には、以下の例が挙げられます。
開発者とテスターが完全にアクセスできない可能性があるサード・パーティー・システムとの統合テスト。 低負荷パフォーマンス・テスト。正式な負荷テストを実施するまでにまだ十分な時間的余裕がある段階で、ビルドごとにストレス、負荷、ボリューム、またはメモリー・リークに関する小規模なチェックを実行し、ビルド間でのパフォーマンスの低下を早期に識別します。 ユーザーがインストールするソフトウェアのインストールおよびアップグレードのテスト。消費者向けソフトウェアの場合、多数のプラットフォームとオペレーティング・システムをまたいでインストールおよびアップグレードをテストする必要があります。 特に、財務情報や個人情報をリスクにさらす場合に、セキュリティー上の脆弱性のスキャン。 自動化の実装には、以下の主要な例をはじめ、あらゆる形態と形式があります。
ユーザー・インターフェース (UI) 層での機能テスト
APIを使用した機能テスト
さらに、手作業で実施すると極めて有益なテストもあります。テスト自動化と並行して、これらのテストを継続的に行ってください。
探索的テスト。スクリプト化されていないテストで、最終的な結果を規定せずに、テスターがシステムのさまざまな側面を分析します。このようなテストは、自動化テストによってまだカバーされていない、欠陥を隠しているシナリオを新たに見つける上で役立ちます。 ユーザビリティー・テスト。エンド・ユーザーに、システムの特定の側面をテストしてもらい、操作しながら口頭でフィードバックしてもらいます。チームはこれにより、ユーザーが対象のシステムを操作しているときに、どう思っているのかをより深く理解できるようになります。 継続的テストを実現する
継続的テストの組織文化を築き上げるために必要なのは、人、プラクティス、ツール、時間です。以下の図に、継続的テスト・プロセスを確立する際の一般なプラクティスを示します。
従来のテスト手法を適用する場合、テスターと開発者の間で最初の意志疎通経路となるのは、欠陥です。テスターが「バグを見つけた！」と判断すると、開発者はコードに問題があることに同意または反対します。多くの場合、欠陥はコード自体の問題ではなく、要件や設計の問題であったり、さらにはテストの問題であったりすることさえあります。場合によっては、問題の原因はアプリケーションの外部にあります。例えば、テスト環境、テスト・データ、テスト・スクリプト自体、あるいはそれらの組み合わせが問題を引き起こしていることもあります。ソフトウェア開発ライフサイクル内では例外なく、コラボレーティブな環境を作って、欠陥をログに記録して追跡することが不可欠ですが、適切なプラクティス一式を導入するとなると、欠陥の追跡は取り組み全体のほんの一部でしかありません。
通常、テスト・チームが次に導入するプラクティスのうちの 1 つは、テスト管理です。テスト作業の計画、必要なテストの特定、手動テストの作成、既存のテストの収集、テストの実行、テストの進捗状況の追跡およびレポートは、すべてテスト管理に含まれます。テスト管理のプラクティスは、チームと経営陣の両方にとって、テストが合格したか、失敗したか、あるいはブロックされているかを簡単に理解するのに役立ちます。さらに、以下の質問にも答えを出すことになります。テスト作業がスケジュール通りに進んでいるか、遅れているか、あるいは予定よりも早く進んでいるか？ 通常、次にくるのはテスト自動化のプラクティスです。つまり、チームがテストを手作業で実行するのでは非効率的、非効果的、そして多くの場合は明らかに不可能であると理解した時点で、テスト自動化が検討されます。堅牢で保守しやすいテスト自動化フレームワークは、ソフトウェア開発プロジェクト自体と同じように取り組まなければ作成するのが困難です。自動化フレームワークを作成するには、共通のビジョン、要件、アーキテクチャー、設計、さらに場合によってはコーディングが必要になり、最終的には自動化が意図されたように機能することを検証しなければなりません。これらの側面を無視して作成されたテスト自動化フレームワークは、不安定で壊れやすく、保守するのが困難で、リファクタリングにコストがかかるものになりやすく、放棄されることも珍しくありません。 テスト自動化と併せ、テスト・アナリティクスおよびインサイトのプラクティスも、どのテストをいつ実行すべきか、なぜテストを実行しているのか、という質問の答えを出すようになってきています。コード変更の影響分析は、特に開発者たちがコードの変更セットに厳密に従い、一貫性を保っていなければ、難しいタスクになりがちです。前回のビルドから何が変更されたのかを把握していなければ、実行すべき適切なテスト・セットを選択することはできません。コード変更の影響分析を行わずに、すべてを包括的にテスト (再テスト) するという対処は心をそそるものの、コストのかかる答えです。 テスト環境の作成も、テストの重要な側面の 1 つです。テスト環境のプロビジョニングを自動化すると、非常に大きな見返りがあります。まず、新しいビルドのテストを開始するまでには数時間、数日、あるいは数週間かかることもありますが、テスト環境の作成と構成を自動化すれば、その時間を数分にまで短縮できます。この自動化は、テスト環境の問題、つまり従属ソフトウェアの不適切なインストールや、その他の手作業によるプロセスによってもたらされた問題による、誤ったエラーの数も減らします。IBM DevOps の筋書きでは、テスト自動化はデプロイ自動化と密接に関連しています。 テスト実行とテスト環境の自動化と併せて、サービスを仮想化 (つまり、スタブを作成) すると、テスト作業の有効性が大幅に高くなります。既知の合意したインターフェースに基づいて仮想サービスを作成することで、その従属システムがまだ利用できないとしても、開発者とテスターは同じインターフェースに対してコードを作成し、テストできるようになります。これらの既知のインターフェースに対してテストを実行できれば、遥かに早い段階でテストを始められるようになり、したがってビルドのたびに頻繁にテストを実行することができます。サービス仮想化は、ライブ・システムを使用して簡単にテストできないようなシナリオのテストも可能にします。例えば、以下のシナリオです。 例外とエラー
欠落データ
遅延応答時間
大量のデータまたはユーザー
簡単にテストできるシステムの部分をビルドしてテストするのではなく、サービス仮想化をテストの取り組み全体に統合することで、チームはシステムの最もリスクが高い部分を最初にビルドして効率的にテストすることが可能になります。そして、それらのリスクの高いシステムの部分に対するテストを自動化し、ビルドのたびに自動化テストを実行することで、それらの部分のテスト・カバレッジを改良できるため、新しいビルドが作成されたときに迅速にリグレッションを特定できるようになります。 サービス仮想化の典型的なシナリオは、モバイルと Web の開発チームがクラウド・アプリケーションに取り組み、メインフレーム・チームがオンプレミスで作業する場合でしょう。サービス仮想化により、IBM はこれらのハイブリッド・クラウドのシナリオに見られる環境への依存関係を切り離しています。環境の依存関係がないため、それぞれのチームが独自のスピードでビルドとテストを行い、独自の組織文化に適切な DevOps 手法を採用します。 テストの有効性を高めるもう 1 つの側面は、適切なテスト・データ・セットを使用することです。できるだけ本番環境に即したテスト・データを使用すれば、より多くのシナリオで、より効果的なテスト・カバレッジが実現します。本番環境からデータを抽出し、そのデータをマスキングしてセキュリティーを確保することで、実際的なテスト・データのセットを使用できるようになります。例外やエラーをテストするのは難しいことですが、このような有効性に優れたテスト・データのセットがあれば、チームが例外やエラーの状態を作り出すこともできます。 このように、効果的なテストのプラクティス一式により、テスターだけでなく、チーム全体が協力して品質を向上させて、新しい機能を提供するまでの所要時間を短縮できるようになります。従来のテスト環境に通常必要となる高額すぎる投資を行わなくても、これらのプラクティスを採用すれば、依存関係やボトルネックを取り除き、ライフサイクルの早期から継続的テストを行うことが可能になります。