アジャイルテストは、アジャイル手法の原理を製品テストに応用し、継続的テストを開発のすべてのステージに取り入れます。
ソフトウェア開発に対するアジャイルアプローチほど、企業のアプリ作成プロセスへのアプローチを完全に変えた開発手法はないでしょう。 従来型の「ウォーターフォール」手法は直線的システムのため、チームがプロジェクトフェーズ全体を完了しないと次のフェーズを開始できない仕組みですが、アジャイル開発は各チームが複数のプロジェクトフェーズに同時に取り組むことができます。
このアプローチには、商品化までの期間を短縮し、プロジェクトの透明性を高め、プロジェクトの途中で目的の変更や他の新しいデータに柔軟に対応して方向転換できるなどのメリットがあります。 そのアジャイルアプローチの中核的要素はなんといっても「アジャイルテスト」です。
アジャイルでは、プロジェクトの開発が完了するまでテストを待つ必要がありません。 むしろテストは他の開発作業と並行して継続的に実施されます。 テスターは開発者と共に作業し、ときには顧客も交えて高品質な最終製品を生み出すことを目指します。
アジャイルテストとウォーターフォール型アプローチには明確な違いがいくつかあります。
前述のように、従来のソフトウェア開発では、開発ライフサイクルのかなり終盤になるまでテストを開始できません。 ウォーターフォール手法では各プロジェクトフェーズを、前のフェーズの完了を待って開始しなければならないためです。 そのため、「テストと統合」フェーズはシステム設計と実装のフェーズの後でようやく着手できますが、この時点で開発作業はすでに完了しています。
この厳格な開発モデルは明確に構造化され、管理が比較的容易です。 ただし、短所もあります。 プロジェクト要件に想定外の変更が生じた場合、またはテストによって初期の構想段階での本質的な問題が明らかになった場合、こうした問題を考慮して対応することはほぼ不可能です。 つまり、テストが開発後まで待たされると、変更やソフトウェアのバグへの対応が困難でコストも高くつき、チームが納期を守れなくなる可能性もあります。 そのため、すべての問題を解決するまでリリースを延期するか、低品質な製品をリリースするか、というどちらを選んでも不幸な二択を迫られることになります。
ウォーターフォール手法と異なり、アジャイルではテストを開発のすべての段階で行うことを徹底します。 ソフトウェアのコードを更新するときはいつでもテストチームが介入し、自動的に機能を検証します。 あるいは、初期テストを使用して、作成するべきコードの形を決定します。 また、テストは自動ソリューションやエンドユーザーによる使いやすさのテストも取り入れることがあります。
すべての段階でテストを実装すると混乱を招くと思われるかもしれませんが、実際には開発の全期間を通じてテストを行うことで、チームはより質の高い最終製品を短期間で生み出すことができます。 そのためには、いくつかの重要なアジャイルの原理を順守する必要があります。
- 継続的フィードバック
テスターはユーザーのフィードバックとテスト結果を常に開発者に伝えなければなりません。 - 顧客満足度の向上
優れたユーザーエクスペリエンスを提供することがすべてのアジャイルテスターにとって第一の目標です。 - 制約のないコミュニケーション
アジャイルテストでは、コミュニケーションが最も重要です。開発者と直接会うことでエラーや誤解を減らし、ユーザーフィードバックも効果的に伝達できます。 - 簡潔さ
アジャイル手法において不必要なテストや場違いな作業が入る余地はありません。アジャイルテスターが実施するテストはすべて必要なものであり、必要とされるテストしか実施しません。 - 適応性
アジャイルテスターには、プロジェクトの変更やユーザーフィードバックに対応する能力が必要です。 - コラボレーション
テスターは人と直接協力し、人のために作業を行い、テクノロジーよりも対話を重視します。人に重点を置いているため、使いやすさが優先されます。
アジャイルテストはアジャイル開発手法の中核を担うため、そのメリットも他のアジャイルの利点と緊密に連携しています。 その利点とは次のとおりです。
アジャイルテストによってチームは開発プロセスのかなり早期に欠陥を検出して修正できるため、バグが発売時まで持ち越されにくくなります。 同時に、テストには開発チーム全員が関与するため、各自のスキルを投入してより優れた最終製品を作成できます。
従来の開発では、開発のすべてのフェーズが完了するまで製品はリリースされません。 ところがテクノロジーは日進月歩のため、わずか数か月の開発の遅れによって、展開の準備が整うころには機能または製品全体が完全に時代遅れになっている可能性もあります。 ライフサイクル全体で継続的に開発とテストを組み合わせることで、生産が迅速に次のフェーズに移行し、リリースされたアプリケーションが現在の市場に高い関連性を持つものになります。
チームが組み立てラインのように運営されている場合、プロジェクトがテストフェーズに入るまでテスターには無駄な待機時間が生じます。 アジャイルテストはこのダウンタイムをなくし、テスターは開発者と同時に作業を進めることができます。 このため、より短時間でより多くのタスクを完了できます。
顧客やその他のエンドユーザーは今すぐソリューションを求めています。製品の発売まで待たされると、興味を失ってしまうでしょう。 アジャイルテストにより、アプリケーションを迅速に提供するだけでなく、アプリケーションを常に改善し、カスタマーエクスペリエンスを向上させることができます。
アジャイルテストは開発ライフサイクルのすべてのステージで発生しますが、効果的なアジャイルテスト戦略自体のライフサイクルにも、以下の 4 つのステージがあります。
「イテレーション (反復) 0」と呼ばれることも多いアジャイルテストの最初のステージは、テストを進めるために必要な基礎作業の段階です。 ビジネスケース、範囲、プロジェクトの境界を設定し、主要要件の概要決定、リスクの特定、コスト概算の実施も含まれます。 さらに、基本的なテストリソース (人員とツール) の特定と確保も行います。
アジャイルテストの大部分はこのステージで発生します。 構築の反復とは繰り返し行うテスト作業を指し、「確認テスト」と「調査テスト」のいずれかに分類することもできます。 確認テストは、機能や製品が設計上対応すべき所定の目的を満たしていることを検証します。 調査テストは製品の目的に直接関連のないバグやその他の問題を特定します (使いやすさや統合の欠陥など)。
プロジェクトが完了に近づくと、アジャイルテスターはソフトウェア全体を完成品として検証する必要があります。 これには、フルシステムテストや受け入れテストが含まれ、一般に開発途中のテストよりはるかに厳しい内容になります。
最後に、テストが完了すると、製品は本番環境に移ります。
アジャイル開発に慣れてくると、多くの企業は自社のニーズに合わせた独自のアジャイルテスト手法を作ることを選びます。 とはいえ、多くの場合効果的なのは、まず確立された手法から始め、徐々に固有のユースケースに適合させていく方法です。 広く普及しているアジャイルテストのアプローチをいくつかご紹介します。
テスト主導の開発 (TDD) では、テストをアジャイル開発プロセスの開始時に実施します。 テストは各機能に対して作成され、実行されます。 プログラムがテストに不合格になった場合 (というより機能のコードもまだ書かれていないので不合格になるのは当然ですが)、開発者は最も単純なコードを記述してテストに合格させます。 自動テストスクリプトがあればテスト不合格の場合にのみ開発者がコードを記述すればよいので、コード重複のリスクを排除できます。
受け入れテスト主導の開発 (ATDD) は、標準的なテスト主導の開発と似ています。 違いは ATDD ではカスタマーストーリーの作成から始まるという点です。 チームは製品がどのように使用されるかに注目し、開発の参考としてユーザー受け入れテストを作成します。 このアプローチでは、ユーザーの期待値を開発サイクルで最優先します。
ATDD の自然な発展形といえる動作主導の開発 (BDD) も、ユーザーストーリーの作成から始まります。 ただし、このストーリーはビジネス成果に直結する必要があり、ビジネスの観点からなぜその機能が開発されるのかを具体的に示します。 そのうえでテストが構築され、求められているビジネス成果の方向性で開発が進められます。
TDD、ATDD、BDD テスト手法では自動テストスクリプトが採用されていますが、探索的テストでは手動アプローチを取ります。 人間のテスターが開発中の製品を探索して関連性のあるテストを生成します。 探索的テストは上記のテスト手法と比べて構造化や速度という点では劣りますが、テスターのスキルセットと直感を最大限に活用し、他のテストアプローチではすり抜けてしまうリスク関連の問題の特定には効果的です。
セッションベーステストは探索的テストの発展形です。 テスターの直感にそこまで頼らず、テストを実施する構造を追加します。 各セッションベーステストの開始時にテスターが作成する「チャーター」には、チームがテストで発見することを期待している内容を詳しく正確に記載します。 続いて中断なしの集中テストを実施し、そのテストの報告を行います。 明確な目標を念頭に探索的テストを開始することで、テスターは見過ごしている分野がないことを確認できます。
アジャイルテストは多種多様なアプローチやテストタイプに対応しているため、どのテストがどの状況に最適なのか、テストは手動と自動のどちらが適したアプローチなのかを見きわめることが難しくなる場合もあります。 開発チームを導くため、多くの企業はアジャイルテストの 4 象限を活用しています。
アジャイルテストの 4 象限は、基本的なテスト分類を示します。チームは左側の 2 象限を見て記述するコードの種類を迅速に判断でき、右側の 2 象限から記述するコードの詳細を知ることができます。 4 象限をひとつずつ見ていきましょう。
この象限はコードと製品を改善するためのテストが含まれます。 一般に自動テストであり、アプリ開発ライフサイクル全体で実施され、開発者にコード品質のフィードバックを提供することを目的としています。
第 2 象限は製品のビジネス成果の改善に役立つテストです。 手動と自動のスクリプトを組み合わせ、製品が想定通りの機能を発揮し、ビジネスと顧客の両方に価値をもたらすことを確認するためのテストです。
前述の 2 つの象限のテストに対するフィードバックを提供する第 3 象限は、ユーザー受け入れテスト、使いやすさのテスト、探索的テストで構成されます。 これらの手動テストの目的は製品自体とユーザーエクスペリエンスの両方をテストすることであり、開発者に製品に対する重要なインサイトを提供して、本来の目的である機能を満たしていることを確認できます。
第 4 象限は製品の機能以外の要件であるデータセキュリティ、安定性、互換性などに関連するテストが対象です。 こうした技術寄りの性能テストには、テストプロセスを自動化できるツールを使用します。
これら 4 象限を組み合わせることでソフトウェアテストの全体像を把握でき、情報に基づく意思決定ができます。 ただし、これはテストの優先順位を決定する手段ではありません。その決定はチーム自身で行う必要があります。
アジャイルソフトウェア開発は、企業の形態や規模を問わず、ソフトウェア開発の方法を変えました。アジャイルテストはこの革命の大きな部分を占めます。 しかし、開発ライフサイクルのすべてのステップに常にテストが統合されることで、テストプロセスがすぐに混乱する可能性があります。
IT 管理ソリューションの業界リーダーである ServiceNow は、企業がアジャイルテストを最大限に活用するために必要なツールを提供します。 ServiceNow テスト管理 2.0 アプリケーションは、テストプロセス管理の編成と簡素化を支援します。 マネージャーは、テストとテストセットの構築と監視、テスト計画とサイクルの作成、リソースの割り当て、テストとテスト結果の評価が容易にできます。 テスターもテストとテストセットの作成、テストの実施、結果の記録、欠陥の報告において多くのサポートを受けられるため、負担が軽減されます。
テストによってアジャイル開発を最適化しましょう。 ServiceNow テスト管理 2.0 をお試しください。テストがかつてない威力を発揮します。