アジャイルテストとその実践的応用の簡単な分析

導入

インターネット技術の発展に伴い、製品の急速な反復と市場の需要への適応能力が大手企業にとっての悩みの種となっています。従来の開発モデルは、製品を迅速に反復するには適していません。この場合、アジャイル開発モデルは、反復性が高く、配信が頻繁で、変更への適応性が高いため、さまざまな分野で広く使用されています。同時に、アジャイル開発の発展により、ソフトウェアテストに対する要件もさらに高まりました。したがって、アジャイル テストは、テストの効率を改善し、製品の配信品質を向上させるために非常に重要です。

アジャイル開発の発展と特徴

2001 年 2 月、Martin Fowler 氏とその同僚は Agile 宣言を提案し、次のように述べています。

• プロセスやツールよりも個人と相互作用を重視する。
• 動作するソフトウェアは包括的なドキュメントよりも重要です。
• 顧客との協力は契約交渉よりも優先されます。
• 計画に従うよりも変化に対応するほうが良いです。

業界や製品に関係なく、ソフトウェア開発の最終的な目標は、顧客のニーズを満たし、顧客の根本的な利益を実現することです。インターネット業界では市場の需要が急速に変化しており、この特徴は従来の業界よりも顕著です。顧客のニーズに応じて開発内容と進捗をタイムリーに調整し、従来の開発モデルによって生じる不必要な無駄を削減するにはどうすればよいでしょうか。これはおそらく、すべてのインターネット企業が考えている質問でしょう。アジャイル開発は、継続的な蓄積、反復的な成長、タイムリーな対応のプロセスです。そのため、アジャイル開発モデルは世界中で最も人気のあるソフトウェア開発モデルになりました。

アジャイル開発モデルにおいて、スクラムは増分反復開発フレームワークの 1 つです。人間中心の反復的かつ段階的な開発手法が広く採用されています。 Scrum アジャイル メソッドを使用すると、開発サイクル全体を複数の小さな反復サイクル (スプリント) に分割できます。各サイクルは通常 2 ～ 4 週間です。 Scrum フレームワークでは、製品要件は Backlog を使用して管理されます。バックログはビジネス価値などの原則に従ってソートされたリストであり、リスト項目はユーザーストーリーに従って反映されます。

Scrum アジャイル手法を使用して開発する場合、通常、顧客にとって価値の高い要件が最初に開発されます。各反復サイクルにおいて、開発チームは優先開発のために製品から最も価値のある要件を選択できます。スプリント計画会議では、開発チームが要件を分析および議論し、バックログを見積もります。反復を完了すると、スクラム チームは出荷可能な製品の増分を提供できるようになります。

スクラムのアジャイル開発モデルは、非常に短いリリース サイクルでビジネス価値の一部を提供し、開発サイクル中に継続的な反復と段階的な進歩を遂げることが特徴です。アジャイル開発モデルでは、需要の更新を継続的に受け入れるため、顧客のフィードバックにタイムリーかつ継続的に対応できます。

アジャイル開発とテストの応用

ソフトウェア テストはソフトウェアのライフ サイクル全体にわたって実行され、ソフトウェアの品質を確保するための基礎となります。テスト チームは、適切なソフトウェア テスト テクノロジとテスト ツールを選択することで、ソフトウェア開発およびテスト プロセスを継続的に改善します。アジャイル開発モデルが急速に発展するにつれて、アジャイルテストもソフトウェア開発チームとテストチームの共通の焦点になりました。

アジャイル テストでは、ソフトウェアを継続的にテストし、テスト結果に関するフィードバックをタイムリーに提供することで、ソフトウェアの品質を向上させ、ユーザーのニーズを満たします。 「継続的なテスト」と「タイムリーなフィードバック」を重視します。したがって、アジャイル テストは、ある程度アジャイル宣言に従ったテスト手法とも考えられます。

図1: アジャイル開発とテストのプロセス

図 1 からわかるように、スプリントにおけるアジャイル開発とテストのプロセス全体は、次のステップに分かれています。

やることリスト

ToDo リストには、このスプリントで開発されるすべての機能がリストされます。これらのリストは通常​​、ユーザー ストーリーの形式で機能を記述し、プロジェクトの反復に応じて更新される可能性があります。

分割プラン

ToDo リスト内の機能を改良し、サブ機能を生成し、各サブ機能の特定の要件をリストします。分割計画フェーズでは、開発者とテスト担当者の両方が各機能の要件を理解している必要があります。

反復的な開発とテスト

図2: 反復的な開発とテストのプロセス

この段階では、図 2 に示すように、開発者は対応する機能に対する需要分析を行い、開発反復計画を策定し、機能開発と自己テストを実行します。テスターは、要件分析を実施し、テスト計画をリストし、テストケースとスクリプトを記述する必要もあります。開発者が機能開発と自己テストを完了すると、対応するテスト可能なバージョンが生成されます。テスターは要件に従ってテストケースを実行し、生成された欠陥は開発者によって修正され、その後、継続的な開発が行われます。

図3: 開発およびテストフェーズのプロセス

図 3 に示すように、開発およびテストのフェーズでは、開発者はモジュール開発と単体テストを実行し、TDD によって駆動されるモジュールをリファクタリングします (TDD については、後続の章で簡単に説明します)。モジュールの開発が完了して統合された後、テスターはスモークテストと受け入れテストを実施し、生成されたバグは開発者によって引き続き修正されます。

機能リリース

テスターがテストを完了すると、テスト結果に基づいて特定の機能が提供できるかどうかを確認するためのテスト概要が作成されます。

アジャイルテストの主な方法と実践

テスト駆動開発 (TDD)

テストはテスターだけの責任ではありません。開発者は、ソフトウェア配信の品質を向上させるために、ユニット テストやモジュール機能テストなどの継続的なホワイト ボックス テストを通じて独自のコードをリファクタリングする必要もあります。

TDD では、開発者はコードを書く前にテスト ケースを記述し、その後コードを記述し、コードがテスト ケースに合格する必要があります。継続的な反復とリファクタリングにより、テストケースの数と範囲は増加し続け、プログラムによって実装される機能はますます複雑になります。開発者は、コードの使いやすさを向上させるために、ユニット テストの範囲を継続的に改善する必要があります。

継続的かつ徹底的なコミュニケーション

チームは緊密にコミュニケーションを取り、ドキュメントに過度に依存しないようにする必要があります。さまざまな役割とコミュニケーションをとることで、テスターは短期間でプロジェクトの全体的な要件を完全に理解し、最も適切なテストケースを設計できます。製品の品質が顧客の期待を満たすことを保証するために、テスターは継続的な製品の反復中にテストケースを絶えず変更し、優れた品質を達成する必要があります。

• テスターと開発者間のコミュニケーションは、ソースコードの一部を読み、製品のアーキテクチャを理解し、技術的な観点から問題について話し合うことで実現できます。
• テスターとユーザー間のコミュニケーションにより、テスターは顧客の視点からいくつかの問題を検討し、必要に応じて競合他社の同じタイプの製品と比較することができます。
• テスター間のコミュニケーションは、経験を共有し、問題を伝えるプロセスでもあります。この交流を通じて、個人の経験がチーム全体の経験に変換されます。

ぼやけた警戒線

アジャイル モデルでは、チーム間の高度なコラボレーションが重視され、テストと開発の役割の境界が曖昧になります。

開発者は開発タスクの完了を確実にするだけでなく、ユニットテストやその他のタスクを使用してコードの品質を確保する必要があります。アジャイルテスターとして、プロジェクトにおける顧客のニーズ、ソフトウェア設計フレームワーク、ソフトウェア言語なども理解する必要があります。テスターは、製品コードの一部を読み書きすることで、製品の内部ロジックを理解できるようになります。

テスターがテストケースを設計するプロセスでは、チームの全メンバーが、顧客の環境と使用シナリオに一致するテスト計画を共同で設計する責任を負います。アジャイル モデルでは、チームはテスト ケース レビュー ミーティングを開催することで、すべてのメンバーの参加を確保できます。

オートメーション

アジャイル開発のプロセスでは、プロジェクトは継続的に反復され、短いサイクルでリリースされます。したがって、テスターは、各反復で新しい機能ポイントが完全に実装されていることを確認するだけでなく、以前の反復の機能が影響を受けないことも確認する必要があります。その結果、テストの作業負荷が継続的に増加し、重大な重複が発生します。

アジャイル プロジェクトでは、自動テストを適切に実装すると、テスターの効率だけでなくプロジェクト全体の効率も向上します。一般的に、プロジェクトの初期の反復では、テスターは自動化のために最も基本的で頻繁に使用されるテスト ケースを選択し、反復プロセス中に自動化スクリプトを継続的に改善および最適化して、機能テストの範囲を拡大します。このように、プロジェクトの後期段階での回帰テストでは、蓄積された自動化スクリプトを一度だけ実行することで、基本的にほとんどの機能をカバーできるため、回帰テストでテスターが基本的な機能を検証するために費やす時間が短縮されます。テスターは、製品の品質を向上させるために、探索的テストに多くの時間を費やすこともできます。

継続的インテグレーション

開発プロセス中、開発者は頻繁に新しいコードをマージします。では、新しく開発されたコードの品質をどのようにテストするのでしょうか?また、新しいコードがライブラリにマージされた後、古いコードの機能に影響を与えないことを保証しますか?これを保証するには、自動化された継続的なビルド（コンパイルと自動テストを含む）が必要です。継続的インテグレーションの主な目的は、欠陥をより早く発見して解決し、ソフトウェアの品質を向上させ、ソフトウェア更新の検証とリリースに必要な時間を短縮することです。

図 4 に示すように、継続的インテグレーション プロセスには通常、次の側面が含まれます。

1. タイミング、固定サイクル、手動開始などの特定のトリガー条件を設定します。
2. 起動後、継続的インテグレーション フレームワークはバージョン管理ツールから最新のコードをチェックしてダウンロードします。そうでない場合、統合プロセスは終了します。
3. コードが正常にコンパイルされたら、自動テスト環境を起動して自動テストを開始します。
4. テストレポートは自動的に生成され、電子メールまたはその他の手段で対応する責任者に送信されます。

図4: 継続的インテグレーションプロセス

アジャイルテストの実施方法

いくつかのプロジェクトでは、一部のチームでは基本的にアジャイルな開発管理ができるようになりましたが、心理的に抵抗があり、このモデルに慣れていないメンバーもまだいます。アジャイル テストに関しては、イデオロギーの観点から、すべての従業員の品質意識を促進します。プロジェクトチームの全メンバーが製品の品質に責任を持つ必要があります。製品の品質を確保することは、もはやテスターだけの責任ではありません。開発者は、ユニット テスト カバレッジを通じてコードの正確性を確認する必要があります。

ソフトウェアの組み込み品質を保証するには、設計段階で要件や設計ロジックなどを包括的に分析し、テスト可能性を向上させる必要があります。アジャイル テストでは、テスターはソフトウェアのライフサイクル全体を実行し、できるだけ早い段階でテストに参加する必要があります。計画に実装する機能を十分に理解した上で、テスト計画を策定し、反復的にテストタスクを完了します。自動テストと組み合わせた継続的インテグレーションを確立し、各反復でテスト結果を迅速にフィードバックします。また、後続の回帰テストや受け入れテストのために、自動テスト フレームワークを継続的に維持します。