継続的なデリバリーにおけるソフトウェア テスト
ソフトウェア テストのメリットと、継続的なデリバリーにおけるその役割についてご確認ください。
ソフトウェア テストは、ソフトウェア開発内の組織的なプロセスであり、ビジネス クリティカルなソフトウェアの正確さ、品質、パフォーマンスについて検証します。ソフトウェア テストは、想定されるビジネス システムと製品のフィーチャーが期待どおりに正しく動作することを保証するためのものです。
ソフトウェア テストは、手動または自動プロセスのいずれかで行われます。
- 手動ソフトウェア テストは、チームまたは個人が主導し、手動でソフトウェア製品を操作し、それが想定どおりに動作することを確認します。
- 自動ソフトウェア テストは、さまざまな機能を持つ多数のツールで構成されており、その機能は分離したコードの正確性チェックから、人間が主導する完全な手動テストのシミュレーションまで多岐にわたります。
ソフトウェアにおけるテストの種類
単体テスト、統合テスト、機能テスト、受け入れテストなど、さまざまな種類のソフトウェアテストを比較しましょう!
探索的テスト
探索的テストとその歴史について学びましょう。探索的テストの長所と短所、最適な使用時期をご覧ください。
コード カバレッジの概要
コード カバレッジの開始方法、適切なツールの発見方法、それを計算する方法について説明します。
統合テストのチュートリアル
Bitbucket Pipeline を利用して統合テストを実行する方法をご紹介するチュートリアルです。
ソフトウェア テストのメリット
ソフトウェア テストは、ソフトウェア開発と保守コストを削減するため、組織の時間とコストの節約につながります。ソフトウェア テストは、新しいフィーチャーの開発の安定性を保証します。テストは、フィーチャーが想定どおりに機能し、バグが出現しないことを確認するものです。
新しいフィーチャーの開発時間は、新しいフィーチャーを完全な成果物と見なすために必要な一連のテスト ケースを指定すると短縮されます。これにより、開発者が正確にタイムラインを推測し、新しいバグの発生を減らすための確実な目標が設定され、取り組むことができます。これらのテスト ケースを実施すると、全体的な保守コストを削減できます。テストは、すでに提供されているフィーチャーに対して実施し、想定どおりに動作することを保証できます。
ソフトウェア テストのレベル
ソフトウェア テストにはいくつかの基本のレベルがあり、それぞれが開発プロセス内で独自の支援からからソフトウェアの機能を確認します。それぞれのテストのタイプを順に確認し、その実用性を調べてみましょう。
ユニットテスト
ソフトウェア テストの基本のレベルは、ユニット テストです。ユニット テストは、コードの個々のユニットの入力と出力の正確性チェックを実際に測定するものです。この場合、測定単位はスタンドアロンのコード関数またはメソッドです。
ユニット テスト中、実稼働のコード関数は、テスト環境でシミュレートされた入力を使用して実行されます。関数の出力は、その入力に想定される出力と比較されます。出力が想定と一致する場合、テストは成功です。そうでない場合は失敗です。ユニット テストは、派生データ関数の検証に最適な方法です。
ユニット テストのユーザー ストーリーを想定した例では、「関数 2VAL、与えられた 2 つの値 x と y が常に x+y を返す」のようになります。ユニット テストでは、2 つの値で 2VAL を実行し、出力が x+y であることを確認します。ユニット テストは、金額を扱うコードの正確性チェックに最適です。
統合テスト
複数のユニットを対象とするソフトウェア テスト ケースは統合テストと見なされます。ソフトウェア テスト ケースの開発時点では、ユニット テスト間の線引きはすぐに統合テストに進化します。サードパーティ コードの依存関係に対して動作するユニット テストが開発されることも多々あります。依存関係自体はテストする必要はありませんが、その関係への統合が模倣、偽造されることがあります。
機能テストまたはエンドツーエンドのテスト
完全なユーザー レベルのエクスペリエンスをシミュレートするテスト ケースは、機能テストまたはエンドツーエンド テストと呼ばれます。エンドツーエンド テストでは、実際のユーザーの動作をシミュレートするツールを使用します。エンドツーエンド テストの一般的な手順は次のとおりです。
- ボタンをクリックする
- このテキストを読む
- このフォームを送信する
エクスペリエンス全体を実行する状況では、エンドツーエンド テストでソフトウェア スタックの全層にわたって正確性を検証します。
探索的テスト
探索的テストの実施はテストの演習であり、テスターには、テスト対象のソフトウェアを使用して完了する必要がある、緩く定義されたタスクが割り当てられています。つまり、世間に出回っている製品がどのように使用されているかを詳しく知ることができます。さらに探索的テストのセッションでは、多数の課題、最善の欠陥、または製品に対して予期しない操作の実施に対して報酬を提供することで、ユーザーのモチベーションを高めます。
探索的ソフトウェア テストのメリットの 1 つは、誰でもテストに参加できることです。つまり、製品を自由に使用してみることだけが必要とされているのです。探索的テストの実施はランダムではありませんが、手動テストのような厳密なものでもありません。
継続的なデリバリーにおけるソフトウェア テスト
継続的なデリバリーでは、上述のすべてのソフトウェア テスト戦略を利用して、完了したコード タスクのデリバリーを自動的に行うシームレスなパイプラインを作成します。最適なセットアップにより、開発者は最近完了したコードをすぐに継続的なデリバリー パイプラインにプッシュして評価することができます。その後、パイプラインは、各レベルのテストを経て新しくプッシュされたコードを実行します。コードがテストに合格すると、本番環境に自動的にマージされ、デプロイされます。ただし、コードがテストに失敗した場合、そのコードは拒否され、修正する手順が開発者に自動的に通知されます。
よく使用され、確立したソフトウェア開発エコシステムには、独自のサブセット テスト エコシステムがあり、テスト スイートの装備と開発に役立つユーティリティを提供するツールが多数用意されています。これらのツールは通常、プロジェクトで使用されるプログラミング言語に固有のパッケージ マネージャを介してインストールされます。
テストの装備に加え、テスト実行と開発のためのツールもあります。各種テスト ランナーをインストールして、テスト スイートから出力データを提供することができます。一般的な方法は、プロジェクト全体の「テスト カバレッジ」を測定することです。コード カバレッジ ツールを使用すると、適切にカバーされているコード ベースの量を示すことができます。
テスト スイートが開発され、ローカル プロジェクトで正しく動作したら、通常は CD パイプラインへの統合に進みます。ホストされている CD/CI システムの大半に、テスト スイートをパイプラインに統合する方法に関するガイドがあります。
テストを CD パイプラインの一部にする方法
完成し、付加価値のある真の CD パイプラインは、強力なテスト基盤を中心に構築されています。このテスト基盤は、手動テスト ケースから始まり、自動化されたソリューションへと進化します。
パイプラインのあらゆるステップで品質を強調する
開発者、テスターなど、全員が顧客とのよい関係に影響します。コードの 1 行ずつが、カスタマー エクスペリエンスの質を左右します。CD パイプラインのテスト スイートは、高品質で正確なコードを開発するための多面的なツールです。製品設計フェーズでは、フィーチャーを開発する方法の考慮事項を念頭に置き、前もってテスト スイートを検討しておくことができます。このテスト スイートは、主に開発プロセスを合理化するために使用されますが、ステージング環境や本番環境を実行して、その品質を保証することもできます。
開発者がフィーチャーの品質を証明できるように支援する
従来のテスト方法では、テストが開発者とのステップとは別のプロセスであるとされています。品質保証おいて、開発者が欠けることは、開発チームに対する顧客の共感の低下につながります。さらに、品質に開発者が関与していないため、コード ベースで問題が長期にわたって悪化していき、修正のコストが大きくなることがあります。この方法では、別の QA チームを採用して責任を負わせる必要があるため、組織内の従業員のコストも大きくなります。
継続的なデリバリーは、エンド ユーザー エクスペリエンスに対する開発者の認識と共感を促進します。開発者は、作成する機能のテスト カバレッジを提供し、開発環境から実稼働環境までそれを監督することを担当します。これにより、機能を所有し、品質を証明する機会が開発者に与えられます。
顧客からのフィードバックを反映する
継続的なデリバリーでは、ソフトウェア プロジェクトへの迅速な展開と更新が可能になります。これにより、顧客からのフィードバックを次のリリースに即座に組み込むことができます。ユーザーが課題を報告した場合、CD パイプライン テスト スイートを調べて、考えられる課題ベクトルの範囲をより適切に定義することができます。開発チームとテスト チームの顧客からのフィードバックへの対応は、これまで以上に迅速になっています。
独自の継続的なデリバリー環境を構築できるよう、当社がお手伝いをします。
強固なソフトウェア テスト戦略の構築
ソフトウェア テスト戦略を考案するときは、常に全体的な製品、ユーザー、ビジネスの戦略全体を念頭に置き、最も価値あるテスト カバレッジ ターゲットを検討する必要があります。
理想としては、ソフトウェア プロジェクトのテスト カバレッジが 100% を達成し、コードにバグがなく、想定どおりに動作することを保証できることを目指します。残念ながら、実際のビジネスの世界では、スケジュールと予算の制約があるため、これは現実的とは言えません。
テスト戦略が複数ある場合も、同じように成果物のソフトウェアの種類に応じて考慮する必要があります。ソフトウェアが GUI 駆動型アプリケーションである場合、高度なレベルのエンドツーエンド テストが非常に有用です。ヘッドレス UI フリー ソフトウェア プロジェクトでは、エンドツーエンド テストを不要として、ユニット テストの結果を重視します。
GUI ベースのユーザー アプリケーションの一般的な総合戦略は次のとおりです。
- すべてのコア ユーザー フロー、ログイン、サインアップ、チェックアウトなどにエンドツーエンド テストを活用する
- 金銭取引ツールなど、すべてのデータ機密のコード関数に対してユニット テストを活用する
- サードパーティ統合のあらゆるポイントで統合テストを活用し、データがサードパーティに送信され、エラーが正しく伝わっていることを確認する
継続的なデリバリーによるソフトウェア テストの改善
継続的なデリバリー ワークフローの追求には、多くのビジネス上のメリットがあります。品質保証、リリース管理とテスト エンジニアリングのロールに対する別々のチームの雇用と管理にかかる組織のコストは、CD ワークフローへのコミットメントによって大幅に削減できます。
継続的なデリバリーにより、全体的に従来の QA テスト ワークフローよりも製品の品質が向上します。CD テストでは、開発者がエンド ユーザー エクスペリエンスとそこから得たフィーチャーの品質を担当し、関与することが奨励されます。CD は、リリース品質に関する全社的なフォーカスとディスカッションを促すフレームワークを提供します。
堅牢なソフトウェア テスト戦略の導入は継続的なデリバリーの基盤であり、自動化が継続的なデリバリー パイプライン実現の鍵になります。
ソフトウェアのテストを強化する準備は整っていますか? CD 環境でのテストの詳細をご確認ください。さらに、アトラシアンやサードパーティのツールがどのようにワークフローのテストを統合するのかを DevOps テスト チュートリアルでご確認ください。
次のトピック
おすすめコンテンツ
次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。