機能テストとは
このセクションでは、Tailspin チームが自分たちのパイプラインの "機能テスト" を定義する際に参加します。 機能テストでは、ソフトウェアの各機能が要求されているように動作するかどうかを確認します。
チームは、最初に機能テストの対象を定義します。 いくつかの種類の機能テストを調査します。 その後、パイプラインに追加する最初のテストを決定します。
週 1 回のミーティング
チームは週 1 回のミーティングを行っています。 Andy はリリース パイプラインのデモを行っています。 チームは、ビルドがパイプラインを通じてあるステージから別のステージに正常に移行することを監視します。 最後に、Web アプリが "ステージング" に昇格されます。
Amita: 私はこのパイプラインにとても満足しています。 私の生活をはるかに楽にしてくれます。 1 つには、リリースが "テスト" 環境に自動的にデプロイされます。 つまり、ビルド成果物を手動でダウンロードして、テスト サーバーにインストールする必要がありません。 これはかなりの時間の節約です。
また、Mara と Andy が作成した単体テストでは、リリースを取得する前に回帰のバグがすべて除去されます。 これにより、大きなフラストレーションの原因が解消されます。 回帰のバグの発見と文書化に時間を費やすことはありません。
ただ、テストのすべてがまだ手動であるのではと心配しています。 このプロセスは遅くて、私が終了するまで経営陣に何も見せられません。 テストは重要であるため困難です。 テストにより、ユーザーが適切なエクスペリエンスを得ることが保証されます。 しかし、より速く提供するというプレッシャーがかかっています。
Andy: きっと私たちがお手伝いできると思います。 一番時間がかかるのは、どのような種類のテストですか?
Amita: UI テストだと思います。 正しい結果が得られるように、すべてのステップをクリックする必要があります。また、サポートしているすべてのブラウザーに対してそれを行う必要があります。 非常に時間がかかります。 また、Web サイトの複雑さが増すにつれて、長時間実行される UI テストは実用的ではなくなります。
Mara: UI テストは "機能" テストと考えられています。
Tim: 何の対語としてですか? "非機能" テスト?
Mara: その通りです。 そして、非機能テストには特に注意が必要です。
Tim: さて、私は混乱しています。
機能テストと非機能テストとは
Mara:"機能テスト" では、ソフトウェアの各機能が求められているとおりに動作するかどうかを確認します。 これらのテストでは、ソフトウェアで各機能がどのように実装されるかは重要ではありません。 重要なのは、ソフトウェアが正しく動作することです。 入力を提供して、出力が期待どおりであることを確認します。 Amita はこのようにして UI をテストします。 たとえば、ランキングでトップ プレーヤーを選択した場合、彼女はそのプレーヤーのプロフィールが表示されることを期待します。
"非機能テスト" では、パフォーマンスや信頼性などの特性をチェックします。 非機能テストの一例は、アプリに同時にサインアップできる人数のチェックです。 ロード テストは非機能テストのもう 1 つの例です。 あなたが気にしているのは、これらのパフォーマンスと信頼性の問題ですね、Tim。
Tim: 確かにそうです。 これについて少し考える必要があります。 パイプラインにいくらかの自動化を追加したほうがいいかもしれませんが、どうすればよいかわかりません。 どのような種類の自動テストを実行できますか?
Mara: 今のところは、機能テストに焦点を当てましょう。 これは Amita が行う種類のテストです。 そして、それは私たちが改善したい分野のようです。
実行できる機能テストの種類とは
さまざまな種類の機能テストがあります。 これらは、テストする必要のある機能と、通常実行するのに必要な時間や労力によって異なります。
以下のセクションでは、一般的に使用されている機能テストをいくつか紹介します。
スモーク テスト
"スモーク テスト" では、アプリケーションやサービスの最も基本的な機能を確認します。 これらのテストは、多くの完全で徹底的なテストの前に実行されることがよくあります。 スモーク テストは迅速に実行する必要があります。
たとえば、Web サイトを開発しているとします。 スモーク テストでは、curl を使用して、サイトに到達可能であることと、ホーム ページをフェッチすることで 200 (OK) HTTP 状態が生成されることを確認できます。 ホーム ページをフェッチすることで、404 (見つかりません) や 500 (内部サーバー エラー) などの別のステータス コードが生成された場合は、Web サイトが機能していないことがわかります。 他のテストを実行する理由がないこともわかります。 代わりに、エラーを診断し、修正して、テストを再開します。
単体テスト
「Azure Pipelines を使用してビルド パイプラインで品質テストを実行する」モジュールでは、単体テストを使用しました。
簡単に言うと、単体テストでは、個々の関数やメソッドなど、プログラムまたはライブラリの最も基本的なコンポーネントを確認します。 期待される結果と共に 1 つまたは複数の入力を指定します。 テスト ランナーでは各テストを実行し、実際の結果と期待される結果が一致するかどうかをチェックして確認します。
たとえば、除算を含む算術演算を実行する関数があるとしましょう。 ユーザーが入力することが予想される値をいくつか指定する場合があります。 また、0 や -1 などのエッジ ケース値も指定します。 特定の入力によってエラーまたは例外が生成されることが予想される場合は、関数がそのエラーを生成することを確認できます。
このモジュールの後半で実行する UI テストは単体テストです。
統合テスト
"統合テスト" では、複数のソフトウェア コンポーネントが連携して完全なシステムを形成していることを確認します。 たとえば、e コマース システムには、Web サイト、製品データベース、および支払いシステムが含まれている場合があります。 ショッピング カートに商品を追加してから商品を購入する統合テストを作成することもできます。 このテストでは、Web アプリケーションが製品データベースに接続して注文を満たすことができるかどうかを確認します。
単体テストと統合テストを組み合わせて、階層型のテスト戦略を作成することができます。 たとえば、統合テストを実行する前に、各コンポーネントの単体テストを実行することがあります。 すべての単体テストに合格した場合は、自信を持って統合テストに進むことができます。
回帰テスト
"回帰" は、機能を追加または変更した後に、既存の動作が変更または中断した場合に発生します。 "回帰テスト" は、コード、構成、またはその他の変更がソフトウェアの全体的な動作に影響するかどうかを判断するのに役立ちます。
1 つのコンポーネントの変更が別のコンポーネントの動作に影響を与える可能性があるため、回帰テストは重要です。 たとえば、書き込みパフォーマンスのためにデータベースを最適化するとします。 そのデータベースの読み取りパフォーマンスは、別のコンポーネントによって処理され、予期せず低下する可能性があります。 読み取りパフォーマンスの低下は回帰です。
さまざまな方法を使用して、回帰をテストできます。 これらの戦略は、通常、新しい機能やバグ修正によって既存の機能が損なわれないことを確認するために実行するテストの数によって異なります。 ただし、テストを自動化すると、回帰テストでは、ソフトウェアが変更されるたびにすべての単体テストと統合テストを実行するだけで済みます。
整合性テスト
"整合性テスト" には、ソフトウェアの各主要コンポーネントをテストして、ソフトウェアが機能しているように見えて、より徹底的なテストを受けることができることを確認することが含まれます。 整合性テストは、回帰テストまたは単体テストよりも徹底的ではないと考えることができますが、整合性テストはスモーク テストよりも広範なものです。
整合性テストは自動化できますが、多くの場合、機能の変更やバグ修正に応じて手動で実行されます。 たとえば、バグ修正を検証しているソフトウェア テスト担当者は、いくつかの一般的な値を入力することによって、他の機能が機能していることを確認する場合もあります。 想定どおりに動作していると思われるソフトウェアは、より完璧なテストの合格を通過できます。
ユーザー インターフェイスのテスト
"ユーザー インターフェイス (UI) テスト" は、アプリケーションのユーザー インターフェイスの動作を確認します。 UI テストは、ユーザーの対話式操作のシーケンス (順序) によって期待される結果が得られることを確認するのに役立ちます。 これらのテストは、キーボードやマウスなどの入力デバイスがユーザー インターフェイスに適切に影響するかどうかの確認にも役立ちます。 UI テストを実行して、Windows、macOS、または Linux のネイティブ アプリケーションの動作を確認できます。 または、UI テストを使用して、Web ブラウザー間で UI が期待どおりに動作することを確認できます。
単体テストまたは統合テストによって、UI がデータを正しく "受信" することを確認することもできます。 しかし、UI テストは、ユーザー インターフェイスが正しく "表示" され、結果がユーザーに期待どおりに機能することを確認するのに役立ちます。
たとえば、UI テストでは、ボタンのクリックに応じて正しいアニメーションが表示されることを確認できます。 2 番目のテストでは、ウィンドウのサイズが変更されたときに、同じアニメーションが正しく表示されることを確認できます。
このモジュールでは、手作業でコード化された UI テストを使用します。 ただし、キャプチャおよび再生システムを使用して、UI テストを自動的に作成することもできます。
使用性テスト
"使用性テスト" は、アプリケーションの動作をユーザーの視点から確認する手動テストの一形態です。 使用性テストは、通常、ソフトウェアをビルドするチームによって行われます。
UI テストでは機能が期待どおりに動作するかどうかを重視しますが、使用性テストでは、ソフトウェアが直観的でユーザーのニーズを満たしているかどうかを確認できます。 言い換えると、使用性テストは、ソフトウェアが "使用可能" であるかどうかを確認するのに役立ちます。
たとえば、ユーザーのプロフィールへのリンクが含まれている Web サイトがあるとします。 UI テストでは、リンクが存在することと、リンクがクリックされたときにユーザーのプロフィールが表示されることを確認できます。 ただし、人間がこのリンクを簡単に見つけることができない場合は、プロフィールにアクセスしようとしたときにイライラする可能性があります。
ユーザー受け入れテスト
"ユーザー受け入れテスト (UAT)" は、使用性テストと同様に、ユーザーの視点からアプリケーションの動作に焦点を当てます。 ユーザビリティ テストとは異なり、UAT は通常、実際のエンド ユーザーによって行われます。
ソフトウェアによっては、エンド ユーザーが特定のタスクを完了するように求められることがあります。 または、特定のガイドラインに従っていなくても、ソフトウェアの調査が許可される場合があります。 カスタム ソフトウェアの場合、UAT は通常、クライアントで直接行われます。 より汎用的なソフトウェアの場合は、チームが "ベータ" テストを実行することがあります。 ベータ テストでは、さまざまな地理的リージョンのユーザーや特定の関心を持つユーザーが、ソフトウェアへの早期アクセスを許可されます。
テスト担当者からのフィードバックは、直接であることも間接的であることもあります。 直接のフィードバックは、口頭でのコメントの形で提供される場合があります。 間接的なフィードバックは、テスト担当者の身振り、目の動き、または特定のタスクを完了するのにかかる時間を測定する形で提供される可能性があります。
テストの作成の重要性については既に説明しました。 しかし、このことを強調するために、ここでは、Microsoft のクラウド アドボケイトである Abel Wang が、DevOps プランの品質を確保するために役立つ方法を説明する短いビデオを示します。
Abel に聞く
チームは何を選択するでしょうか?
Tim: これらのテストはすべて重要そうです。 最初にどれに取り組むべきでしょうか?
Andy: 既に機能している単体テストがあります。 ユーザー受け入れテストを実行する準備はまだできていません。 私が聞いたことに基づけば、UI テストに焦点を当てるべきだと思います。 今のところ、これは私たちのプロセスの中で最も遅い部分です。 Amita、そう思いませんか?
Amita: はい、そう思います。 このミーティングにはまだ時間が残っています。 Andy か Mara、自動 UI テストの計画を手伝ってくれませんか?
Mara: もちろんです。 でも、いくつかの準備作業を片付けましょう。 どのツールを使用する必要があり、どのようにテストを実行するかについて話し合いたいと思います。
UI テストを記述するのに、どのようなツールを使用できるか?
Mara: UI テストの記述に関しては、どのような選択肢があるのでしょう? 多数あることがわかっています。 一部のツールはオープン ソースです。 その他は有償の商用サポートを提供します。 思い浮かぶいくつかの選択肢は次のとおりです。
- Windows アプリケーション ドライバー (WinAppDriver): WinAppDriver は、Windows アプリの UI テストを自動化するのに役立ちます。 これらのアプリはユニバーサル Windows プラットフォーム (UWP) または Windows フォーム (WinForms) で記述できます。 私たちにはブラウザーで機能するソリューションが必要です。
- Selenium: Selenium は、Web アプリケーション用の移植可能なオープンソースのソフトウェア テスト フレームワークです。 ほとんどのオペレーティング システムで実行され、すべての最新のブラウザーをサポートします。 Selenium テストは C# などのいくつかのプログラミング言語で記述できます。 実際、NUnit テストとして Selenium を簡単に実行できる NuGet パッケージを使用できます。 私たちの単体テストでは、NUnit を既に使用しています。
- SpecFlow: SpecFlow は .NET プロジェクト用です。 これは、Cucumber というツールに端を発しています。 SpecFlow と Cucumber はどちらも、振る舞い駆動型開発 (BDD) をサポートしています。 BDD では、Gherkin という自然言語パーサーを使用して、技術チームと技術以外のチームの両方がビジネス ルールと要件を定義するのに役立ちます。 SpecFlow または Cucumber のいずれかを Selenium と組み合わせて、UI テストを構築できます。
Andy が Amita を見ます。
Andy: あなたはこれらの選択肢になじみがないと思うので、Selenium を選んでもいいですか? 私はそれについてある程度の経験があり、私が既に知っている言語をサポートしています。 Selenium は複数のブラウザーに対して自動サポートも提供します。
Amita: もちろん。 ある程度の経験がある人が 1 人いる方がいいでしょう。
パイプラインで機能テストをどのように実行するのか?
Azure Pipelines では、他のプロセスやテストを実行するのと同じように、機能テストを実行します。 次のことを確認してください。
- どのステージでテストを実行するのか?
- テストはどのシステムで実行するのか? これらは、アプリケーションをホストするエージェントやインフラストラクチャで実行するのか?
チームがこれらの質問に答えるので、参加しましょう。
Mara: 私がワクワクしていることの 1 つは、アプリが実際に実行されている運用環境のような環境でテストできるようになったことです。 UI テストのような機能テストは、そのような状況で意味を成します。 これはパイプラインの "テスト" ステージで実行できます。
Amita: そう思います。 手動テストを実行するのと同じステージで自動 UI テストを実行すると、同じワークフローを維持できます。 自動テストによって時間が節約され、使用性に焦点を当てることができます。
Tim: Amita は自分の Windows ラップトップから Web サイトをテストしています。それがほとんどのユーザーがサイトにアクセスする方法だからです。 でも、私たちは Linux でビルドした後、Azure App Service on Linux をデプロイします。 それをどのように処理しますか?
Mara: いい質問です。 テストの実行場所についても選択できます。 次の場所で実行できます。
- エージェント: Microsoft エージェント、またはホストしているエージェント
- テスト インフラストラクチャ: オンプレミスまたはクラウドのいずれか
既存の "テスト" ステージには、1 つのジョブが含まれています。 このジョブは、Linux エージェントから App Service に Web サイトをデプロイします。 Windows エージェントから UI テストを実行する 2 つ目のジョブを追加できます。 Microsoft によってホストされている Windows エージェントは、Selenium テストを実行するように既に設定されています。
Andy: ここでも、私たちが知っているものにこだわりましょう。 Microsoft がホストする Windows エージェントを使用してみましょう。 後で追加のテスト カバレッジが必要な場合は、macOS と Linux を実行するエージェントから同じテストを実行できます。
計画
Mara: わかりました。 これから実行する内容を次に示します。
- Microsoft がホストする Windows エージェントから Selenium UI テストを実行します
- テストでは、"テスト" ステージで、App Service で実行されているアプリから Web コンテンツをフェッチします
- サポートしているすべてのブラウザーでテストを実行します
Andy: これは Amita と一緒にやります。 Amita、明日の朝に会いましょう。 会う前に、少し調査したいと思います。
Amita: すごい! では、また。
機能テスト計画を作成する
チームが最初の機能テストを実装する方法を決定するのを見ました。 チームがそのパイプラインに機能テストを組み込み始めたばかりの場合 (または、既にそれ実行している場合でも)、常に計画が必要であることに注意してください。
多くの場合、チーム メンバーは、パフォーマンス テストの計画について尋ねられたら、使用するツールのリストについて答えるのが一般的です。 ただし、ツールのリストは計画ではありません。 また、テスト環境の構成方法も検討する必要があります。 使用するプロセスを決定し、どのようになれば成功または失敗かを決める必要があります。
次のような計画であることを確認してください。
- ビジネスの期待を考慮に入れている。
- 対象ユーザーの期待を考慮に入れている。
- 使用するメトリックを定義する。
- 使用する KPI を定義する。
パフォーマンス テストは、最初から計画の一部である必要があります。 ストーリーやかんばんボードを使用する場合は、テスト戦略を計画できるエリアをその近くにすることを検討してください。 イテレーション計画の一環として、テスト戦略のギャップを強調する必要があります。 また、アプリケーションがリリースされる前にパフォーマンスを測定するだけでなく、デプロイされた後でそのパフォーマンスを監視する方法を検討することも重要です。