さまざまな種類のソフトウェア テスト

1. ユニット テスト

単体テストは、非常に詳細なレベルのアプリケーションのソースに近いテストです。ソフトウェアで使用されるクラス、コンポーネント、モジュールの個々のメソッドや機能のテストで構成されます。単体テストは一般に比較的安価で自動化できて、継続的なインテグレーション サーバーで非常に高速に実行できます。

2. 統合テスト

統合テストは、アプリケーションで使用されるさまざまなモジュールやサービスが全体として良好に機能することを確認します。たとえば、データベースとの相互作用のテストや、マイクロサービスが期待どおりに連携して動作することを確認する場合などを指します。この種類のテストを実行する場合は、アプリケーションの複数のパーツを稼働して実行する必要があることから、より高額になります。

3. 機能テスト

機能テストは、アプリケーションのビジネス要件に焦点を当てています。アクションの結果を検証するだけなので、そのアクションの実行時にシステムの中間状態はチェックされません。

統合テストと機能テストはどちらも相互に作用する複数のコンポーネントを必要とすることから、紛らわしい場合があります。違いは、統合テストが単にデータベースの照会機能を検証するのに対して、機能テストは製品の要件で定義された特定の値をデータベースから取得しなければならない点です。

4. エンドツーエンド テスト

エンドツーエンドは完全なアプリケーション環境にあるソフトウェアを使用してユーザーの動作を再現します。さまざまなユーザーフローが期待どおりに動作し、ウェブページの取り込みやログインと同じくらい簡単に実行できることを検証し、さらに複雑なシナリオで電子メール通知やオンライン決済などを検証します。

エンドツーエンドテストは非常に便利ですが、実行が高額で、自動化された場合の維持が困難になる可能性があります。主要なエンドツーエンドテストの数を少なくして、互換性を破る変更をすばやく識別できるよう、より詳細レベルのテスト (単体テストや統合テスト) への依存を増やすことをお勧めします。

5. 受け入れテスト

受け入れテストは、システムがビジネス要件を満たしているかどうかを検証する正式なテストです。これらのテストではアプリケーション全体を実行する必要があり、ユーザーの動作の再現に焦点を当てます。またしかし、さらに先に進めてシステムのパフォーマンスを計測して、特定の目標が満たされない場合に変更を却下できます。

6. パフォーマンス テスト

パフォーマンス テストでは、特定のワークロード下におけるシステムの動作を評価します。これらのテストはアプリケーションの信頼性、速度、拡張性、応答性を測定するのに役立ちます。たとえば、パフォーマンス テストでは多数のリクエストを実行する際の応答時間を観察、または大量のデータでシステムがどのように動作するかを確認できます。アプリケーションがパフォーマンス要件を満たしているかどうかを判断、ボトルネックを特定、ピーク トラフィック時の安定性を測定などできます。

7. スモーク テスト

スモーク テストはアプリケーションの基本機能を確認する基本的なテストです。このテストは迅速に実行できるようになっており、その目的はシステムの主要な機能が期待どおりに動作するかを確認することです。

スモーク テストは、新しいビルドが作成された直後により高価なテストを実行できるかどうかを決定したり、デプロイ直後に新しくデプロイされた環境でアプリケーションが適切に実行されていることを確認したりする場合に使用します。

テストを自動化する方法

テストを自動化するには、対象のアプリケーションに適したテストフレームワークを使用してプログラムとして記述する必要があります。PHPUnit、Mocha、RSpec は、それぞれ PHP、Javascript、Ruby で使用できるテストフレームワークの例です。言語ごとに数多くの選択肢があるため、自分で調べたり、開発者コミュニティに尋ねて最も適したフレームワークを見つけることをお勧めします。

スクリプトを使用して端末からテストを実行する場合は、Bamboo のような継続的インテグレーションサーバーで実行を自動化するか、Bitbucket Pipelines のようなクラウドサービスを使用することができます。これらのツールは、リポジトリを監視し、新しい変更がメインリポジトリにプッシュされるたびにテストスイートを実行します。

探索的テスト

コードにより多くの機能や改善が加わるにつれ、システムが正しく機能するかを確認するため、より多くのテストが必要になります。また、バグを修正したら、新しいリリースで同じバグが発生しないかを確認するのが賢明です。自動化はこれを実現するキーとなり、テストを記述することは遅かれ早かれ、開発ワークフローの一部となるでしょう。

それでは、今も手動テストを行う価値はあるのでしょうか。端的に言って「その価値あり」です。また、手動テストでは非明示的なエラーを発見する探索的テストを実施するのが最適である場合があります。

探索的テストの実施セッションは 2 時間以内に終わるようにスコープを明確にして、テスターがソフトウェアの特定の領域に集中できるようにする必要があります。すべてのテスターが説明を受けた後は、さまざまなアクションを試してシステムの動作を確認する必要があります。

テストに関する注意事項

このガイドを完成するには、テストの目標について話し合うことが重要です。ユーザーがアプリケーションを実際に使用できるかどうかをテストする (ログインしてオブジェクトを保存できる) ことが重要であるのと同様に、不良データや予期しないアクションが生じた際にアプリケーションが破損しないことをテストすることも重要です。ユーザーがタイポした、不完全なフォームを保存しようとした、または間違った API を使用した際に、何が起こるかを予測する必要があります。誰かが簡単にデータを侵害した、または許可されていないリソースにアクセスすることがないかどうかを、確認する必要があります。優れたテスト スイートではアプリの破壊を試して、その制限を理解できます。

最後に、テストもコードの一種です。したがって、コード レビューが本番環境への最後の関門になることを忘れてはなりません。

アトラシアンの Open DevOps は、お気に入りのツールを使用して CD ベースの開発パイプラインを構築できるオープン ツールチェーン プラットフォームを提供します。アトラシアンやサードパーティのツールがどのようにワークフローのテストを DevOps テスト チュートリアルに統合するのかをご確認ください。