top 25 functional testing interview questions
最も一般的に尋ねられる機能テストインタビューの質問と回答:
名前自体が定義するように、機能テストは、要件ドキュメントの仕様に関してアプリケーションをテストするプロセスです。
機能テストは手動または自動化のいずれかで実行できますが、各プロセスには、一連の入力を提供することによるアプリケーションのテストと、実際の結果を期待される結果と比較することによる結果/出力の決定または検証が含まれます。
機能テストには、テスト中に考慮すべきさまざまなフェーズがあります。この記事では、面接の質問と回答が複数あり、準備を整えるのに役立ちます。
最も人気のある機能テストの面接の質問
Q#1)「機能テスト」という用語で何を理解していますか?
回答: 特定の入力を提供することによって目的の出力を生成するためにアプリケーションの機能がテストされるブラックボックステスト手法は、「機能テスト」と呼ばれます。
機能テストの役割は、要件ドキュメントの仕様に従ってアプリケーションの動作を検証するだけでなく、アプリケーションをライブ環境にリリースする準備ができているかどうかを確認することでもあります。
以下に、一般的に使用されるいくつかの機能テスト手法を示します。
- ユニットテスト
- スモークテスト
- 統合テスト
- システムテスト
- ユーザビリティテスト
- 回帰試験
- ユーザー受け入れテスト
Q#2)機能テストでカバーされている重要なステップは何ですか?
回答: 以下は、機能テストの一部としてカバーする必要がある手順です。
- 要件ドキュメントの仕様を理解し、レビューコメントの形で疑問や質問をクリアします。
- すべてのケースで考慮すべきすべてのシナリオを念頭に置いて、要件仕様に関するテストケースを作成します。
- テスト入力を特定し、テストケースの実行、およびアプリケーションの機能の確認に必要なテストデータを要求します。
- テストする入力値に従って、実際の結果を決定します。
- アプリケーションの動作が期待どおりであるか、または何らかの欠陥が発生したかを判断するテストケースを実行します。
- 実際の結果と計算結果を比較して、実際の結果を見つけます。
Q#3)機能テストと非機能テストの違いを説明してください。
回答: 機能テストと非機能テストの違いは、次のように説明できます。
機能テスト | 非機能テスト |
---|---|
機能テストは、クライアントの機能要件に従ってシステムの動作を決定するために実行されます。 | 非機能テストは、クライアントの期待どおりにシステムパフォーマンスを決定するプロセスです |
機能テストは、最初に手動および自動化テストツールを使用して実行されます。 | 非機能テストは、必要な効果的なツールを使用した機能テストの後に実行されます。 |
クライアントの要件が機能テストの入力であるため、手動テストを簡単に実行できます。 | 非機能テストではスケーラビリティ、信頼性、速度、およびその他のパフォーマンスパラメータが入力されるため、手動テストを実行することは困難です。 |
機能テストには次の種類があります。 •ユニットテスト •スモークテスト •健全性テスト •統合テスト • ユーザー受け入れテスト • 回帰試験 | 非機能テストには次のタイプがあります。 • 性能試験 •負荷、応力、ボリュームテスト •セキュリティテスト •互換性テスト |
Q#4)「ビルド」と「リリース」の違いは何ですか?
回答:ビルド は、アプリケーションの実装された機能をいくつかのバグ修正とともにテストするためにテスターに渡される、アプリケーションのその部分を参照する実行可能ファイルです。ビルドは、アプリケーションの主要な機能を含む重要なチェックリストに合格しない場合、テストチームによって拒否される可能性があります。
アプリケーションのテストサイクルには、複数のビルドが存在する可能性があります。
リリース テスト段階ではなく、テストと開発の完了後、アプリケーションがクライアントに引き渡されるソフトウェアアプリケーションを指します。 1つのリリースには、いくつかのビルドが関連付けられています。
Q#5)バグサイクルについて説明してください。
回答: バグは、アプリケーション内で発生した不要なエラー、欠陥、間違いなどであり、アプリケーションが目的の出力を提供できないと言われています。テスト中にアプリケーションで欠陥またはバグが発生すると、欠陥のログ記録から解決まで、バグはバグライフサイクルと呼ばれる明確なライフサイクルを通過します。
以下の図は、バグのライフサイクルの概念を示しています。
(画像 ソース )
問題やバグが発生した場合、プロセス全体が進行します。かなりの形式に従ってバグ追跡ツールに報告/ログインされています。これらのバグは開発者に割り当てられ、そのステータスは「オープン」になります。開発者はバグを確認し、最後に再現して作業を開始できるようになりました。
バグが修正された場合、開発者はステータスを「修正済み」に変更するか、ステータスを「詳細情報が必要」、「修正しない」、「再現できない」などに移動できます。次に、QAはリグレッションを実行します。つまり、特定のアクションでバグを再検証し、それに応じて対応します。
問題/バグが期待どおりに動作している場合、そのステータスは確認済み/クローズに変更されます。それ以外の場合は再度開きます。
Q#6)バグのステータスとその説明を入力してください。
シナリオベースのチームリーダーの面接の質問
回答: 以下に、いくつかのバグステータスとその説明を示します。
- 新着: 欠陥またはバグが初めてログに記録されると、「新規」と表示されます。
- 割り当て済み: テスターがバグをログに記録した後、彼のバグはテスターリードによってレビューされ、対応する開発者チームに割り当てられます。
- 開いた: テスターはバグをオープン状態でログに記録し、開発者がそのバグに対して何らかのタスクを実行するまで、バグはオープン状態のままになります。
- 解決済み/修正済み: 開発者がバグを解決したとき、つまりアプリケーションが特定の問題に対して目的の出力を生成しているとき、開発者はそのステータスを「解決済み/修正済み」に変更します。
- 確認済み/クローズ済み: 開発者がステータスを解決済み/修正済みに変更すると、テスターは問題を最後にテストし、修正された場合は、バグのステータスを「確認済み/クローズ」に変更します。
- 再開: テスターがバグを再度再現できる場合、つまり開発者が修正した後もバグが存在する場合、そのステータスは「再開」としてマークされます。
- バグではない/無効: 報告された問題が機能どおりであるが、誤解によりログに記録される場合、開発者はバグを無効またはバグではないとマークすることができます。
- 延期: 通常、バグの優先度がリリースに対して最小であり、時間がない場合、その場合、それらの最小優先度のバグは次のリリースに延期されます。
- 再現できません: 開発者が問題に記載されている手順に従って、バグを最後まで再現できない場合。
Q#7)データ駆動型テストとは何ですか?
回答: データ駆動型テストは、テストケースを含む一連のテストスクリプトが、Excelスプレッドシート、XMLファイル、CSVファイル、入力値のSQLデータベースなどのデータソースを使用して繰り返し実行され、実際の出力が検証で期待されるものと比較される方法です。処理する。
例えば、 テストスタジオは、データ駆動型テストに使用されます。
データ駆動型テストのいくつかの利点は次のとおりです。
- 再利用性。
- 再現性。
- テストロジックからのテストデータの分離。
- テストケースの数が減ります。
Q#8)テストケースを作成する際に考慮すべき重要なポイントは何ですか?
回答: テストケースの作成は、テスト実行プロセスの最も重要なアクティビティであると言われています。これには、効果的で再利用可能なテストケースを作成するために、作成スキルとアプリケーションに関する深い知識が必要です。
テストケースを作成する際に考慮すべき重要な点は次のとおりです。
- テストケースの作成を開始する前に、クライアントの要件を明確に理解する必要があります。何も想定されるべきではなく、要件に関するすべての疑問が解消されるべきです。
- すべての要件はテストケースの形式で含める必要があり、何も省略しないでください。通常、トレーサビリティマトリックスは、すべての要件の実装とテストの完了をチェックするために維持されます。
- 要件ドキュメントの仕様に従って、UIインターフェイス、互換性を含むすべての機能要件と非機能要件をカバーする必要があります。
- テストケースは、繰り返しや冗長性がないか、時々チェックする必要があります。
- 優先度は、書き込み中にテストケースに設定する必要がある重要な要素です。この優先度は、テスターが最初に基本機能を含む高優先度のテストケースでアプリケーションをテストし、次に中程度の優先度のテストケースでテストするのに役立ちます。
- 特定のリリースでは、テストケースをスプリントごとに構築して、テスターと開発者がテストケースの実行に基づいて製品の品質を分析できるようにすることもできます。
- テストケースの構造は簡単に理解でき、単純な言語である必要があります。テストケースの入力データ値は、有効であると同時に広範囲である必要があります。
Q#9)自動化テストとは何ですか?
回答: 自動化テストは、テストカバレッジとテスト実行の速度を向上させるために、自動化ツールを使用してテストケーススイートを実行するテスト方法です。自動化テストは、事前に記述されたテストを実行し、結果をレポートして以前のテスト実行と比較できるため、人間の介入を必要としません。
再現性、使いやすさ、精度、および一貫性の向上は、自動化テストの利点の一部です。
いくつかの自動化テストツールを以下に示します。
- セレン
- テルル
- 水
- 石鹸
Q#10)ストレステストと負荷テストという用語を説明してください。
回答:
ストレステスト は、アプリケーションが労作またはストレスを経験することになっているパフォーマンステストの形式です。つまり、アプリケーションがクラッシュするポイントを特定するために、ブレークのしきい値を超えてアプリケーションを実行します。この状態は通常、ユーザーが多すぎてデータが多すぎる場合に発生します。
ストレステストでは、ワークロードが削減されたときのアプリケーションの回復も検証されます。
負荷テスト は、サーバーのピークパフォーマンス、応答時間、サーバースループットなどを監視するために、アプリケーションがさまざまな負荷レベルを超えて実行されるパフォーマンステストの形式です。負荷テストプロセスの安定性を通じて、アプリケーションのパフォーマンスと整合性は、同時システム負荷の下で決定されます。 。
Q#11)ボリュームテストで何がわかりますか?
回答: ボリュームテストは、同時ユーザー、およびデータベースからの大規模なデータ負荷がテスト対象のシステム/アプリケーションに加えられたときのサーバースループットと応答時間のパフォーマンスレベルを決定するパフォーマンステストの形式です。
Q#12)機能テストで使用されるさまざまなテスト手法は何ですか?
回答: 機能テストで使用される2つの異なるテスト手法があります。
それらは次のように定義できます。
- 要件ベースのテスト: この形式の機能テストは、リスク基準に基づいて要件に優先順位を付けて実行されます。これにより、すべての重要なテストパスがテストプロセスに含まれていることも保証されます。
- ビジネスプロセスベースのテスト: この形式の機能テストは、ビジネスプロセスの観点から実行されます。シナリオには、テストを実行するためのビジネスプロセスの知識が含まれています。
Q#13)探索的テストで何がわかりますか?いつ実行されますか?
回答: 探索的テストとは、スケジュールや手順に従わずにアプリケーションをテストまたは探索することを意味します。探索的テストを実行している間、テスターはパターンに従わず、独創的な考え方と多様なアイデアを使用して、アプリケーションがどのように実行されるかを確認します。
このプロセスに従うと、アプリケーションのごく一部でもカバーされ、通常のテストケーステストプロセスよりも多くの問題/バグを見つけるのに役立ちます。
探索的テストは通常、次の場合に実行されます。
- テストチームには経験豊富なテスターがいて、テスト経験を使用して可能な限り最良のシナリオをすべて適用できます。
- すべてのクリティカルパスがカバーされ、実行された要件仕様に従って主要なテストケースが準備されています。
- 重要なアプリケーションがあり、どのような場合でも見逃すことはできません。
- 新しいテスターがチームに加わりました。アプリケーションを探索することで、要件ドキュメントに記載されているパスに従うのではなく、シナリオを実行する際に自分の考えに従うだけでなく、理解を深めることができます。
Q#14)Webアプリケーションの場合、テストする必要のあるログイン機能は何ですか?
回答: 以下に、アプリケーションのログイン機能を完全にテストするために実行できるシナリオを示します。
- 入力フィールド、つまりユーザー名とパスワードを有効な値と無効な値の両方で確認してください。
- 間違ったパスワードで有効なメールIDを入力してみてください。また、無効なメールと有効なパスワードを入力してください。表示される適切なエラーメッセージを確認します。
- 有効な資格情報を入力して、アプリケーションにログインします。ブラウザを閉じて再度開き、まだログインしているかどうかを確認します。
- ログイン後にアプリケーションに入り、再度ログインページに戻って、ユーザーが再度ログインするように求められるかどうかを確認します。
- あるブラウザからサインインし、別のブラウザからアプリケーションを開いて、別のブラウザにもログインしているかどうかを確認します。
- アプリケーションにログインした後でパスワードを変更し、その古いパスワードでログインしてみてください。
テストできる他の可能なシナリオもいくつかあります。
Q#15)アクセシビリティテストと現在のシナリオにおけるその重要性について説明してください。
回答: アクセシビリティテストは、聴覚、色覚異常、視界不良などの障害を持つ人々がアプリケーションを簡単に処理できることを確認するためにテストが実行されるユーザビリティテストの形式です。今日のシナリオでは、Webは私たちの生活の中で主要な位置を獲得しています。 eコマースサイト、eラーニング、eペイメントなどの形式。
したがって、人生をより良く成長させるためには、誰もがテクノロジーの一部、特に一部の障害を持つ人々になることができなければなりません。
以下にリストされているのは、障害を持つ人々がテクノロジーを使用するのを助け、支援するいくつかのタイプのソフトウェアです。
- 音声認識ソフトウェア
- スクリーンリーダーソフトウェア
- 画面拡大ソフトウェア
- 専用キーボード
Q#16)アドホックテストとは何ですか?
回答: 通常ランダムテストとして知られるアドホックテストは、テストケースやアプリケーションの要件に従わないテストの形式です。アドホックテストは基本的に計画外のアクティビティであり、アプリケーションの任意の部分をランダムにチェックして欠陥を見つけます。
このような場合、計画されたテストケースに従わないため、発生した欠陥を再現することは非常に困難です。アドホックテストは通常、詳細なテストを実行する時間が限られている場合に実行されます。
Q#17)等価パーティショニングとは何ですか?
回答: 等価クラス分割とも呼ばれる等価分割は、入力データがデータクラスに分割されるブラックボックステストの形式です。このプロセスは、テストケースの数を減らすために行われますが、それでも最大要件をカバーします。
等価分割手法は、入力データ値を範囲に分割できる場合に適用されます。入力値の範囲は、同じパーティションの他のすべての条件がソフトウェアに対して同じように動作すると仮定して、各範囲パーティションからの1つの条件のみがテストされるように定義されます。
例えば: アカウントの残高に応じて利率を特定するために、異なる利率を獲得するアカウントの残高の範囲を特定できます。
Q#18)境界値分析について説明してください。
回答: 境界値分析メソッドは、等価クラスパーティションの境界値をチェックします。境界値分析は、基本的に、範囲値内ではなく境界でのエラーを識別するテスト手法です。
例えば 、入力フィールドでは、最小で8文字、最大で12文字を使用できます。その場合、8〜12が有効な範囲と見なされ、13が無効な範囲と見なされます。したがって、テストケースは、有効なパーティション値、正確な境界値、および無効なパーティション値に対して記述されます。
Q#19)重大度と優先度の違いを説明してください。
回答: 欠陥の重大度 テスト対象のアプリケーションの欠陥による影響のレベルまたは程度によって定義されます。欠陥の重大度が高いほど、アプリケーションへの影響は大きくなります。
欠陥の重大度が分類される4つのクラスは次のとおりです。
- クリティカル
- メジャー
- 中
- 低
欠陥の優先順位 欠陥を最初に解決する順序を定義します。つまり、欠陥の優先度が高いほど、アプリケーションが使用できないか、ある時点でスタックしていることを意味し、欠陥はできるだけ早く解決する必要があります。
欠陥の優先順位が定義されている3つのクラスは次のとおりです。
- 高い
- 中
- 低
Q#20)スモークテストはいつ実施しますか?
回答: ビルドを受け取った後、アプリケーションでスモークテストが実行されます。テスターは通常、ビルドがさらなるテストのために受け入れられるか、アプリケーションが壊れた場合に拒否されるかを確認するために、機能ではなくクリティカルパスをテストします。
煙のチェックリストには通常、アプリケーションのクリティカルパスが含まれており、それがないとアプリケーションはブロックされません。
Q#21)健全性テストで何がわかりますか?
回答: ビルドを受け取った後に健全性テストを実行して、修正する新しい機能/欠陥を確認します。この形式のテストの目標は、機能をほぼ期待どおりにチェックし、バグが修正されているかどうか、および修正されたバグがテスト対象のアプリケーションに与える影響を判断することです。
テスターによるビルドを受け入れて、健全性テストが失敗した場合に時間を無駄にすることには意味がありません。
Q#22)要件トレーサビリティマトリックスで何を理解していますか?
回答: 要件トレーサビリティマトリックス(RTM)は、テストのプロセス全体にわたって要件カバレッジを追跡するためのツールです。
RTMでは、すべての要件がスプリントの過程での開発として分類され、要件ドキュメントに記載されているすべてがリリース前に実装されたことを追跡するために、それぞれのID(新機能の実装/拡張/以前の問題など)が維持されます。製品。
RTMは、要件ドキュメントを受け取るとすぐに作成され、製品がリリースされるまで維持されます。
Q#23)リスクベーステストで考慮すべき要素は何ですか?
回答: プロジェクトのリスクベーステストでは、プロジェクトをリスクなしで提供するだけでなく、リスクベーステストの主な目的は、リスク管理のベストプラクティスを実行することによってプロジェクトの結果を達成することです。
リスクベーステストで考慮すべき主な要因は次のとおりです。
- 適切なアプリケーションにリスクベーステストをいつどのように実装するかを特定する。
- アプリケーションの重要な領域でリスクを見つけて処理するのに適切に機能する手段を特定すること。
- リスクとアプリケーションの品質および機能のバランスをとるプロジェクトの成果を達成するため。
Q#24)回帰テストと再テストを区別します。
回答: 回帰テストと再テストの違いは、次のように説明できます。
回帰試験 | 再テスト |
---|---|
回帰テストは、新しい機能または修正の実装がアプリケーションの他の部分または機能に影響を与えないことを確認するために実行されるテストの形式です。 | 再テストは、最後の実行で失敗したテストケースの欠陥を修正した後にアプリケーションをテストする形式です。 |
回帰テストの一環として、アプリケーションの新しい変更が既存の機能に影響を与えることはありません。 | 再テストの一環として、欠陥の検証が行われます。 |
プロジェクトの要件に基づいて、回帰テストを再テストと並行して実行できます。 | 再テストは、優先度が高いため、回帰テストの前に実行されます。 |
一般的なテストとも呼ばれ、合格したテストケースに対して実行されます。 | 計画テストとも呼ばれ、失敗したテストケースに対してのみ実行されます。 |
手動テストは時間と費用がかかる可能性があるため、回帰テストの自動化を行うことができます。 | 再テストのために自動化を行うことはできません。 |
Q#25)ユーザー受け入れテストについて説明してください。
回答: ユーザー受け入れテストは通常、製品が徹底的にテストされた後に実行されます。この形式のテストでは、ソフトウェアユーザー、つまりクライアント自身がアプリケーションを使用して、すべてが要件に従って、実際のシナリオで完全に機能しているかどうかを確認します。
UATはエンドユーザーテストとも呼ばれます。
結論
この記事を通して、私は機能テストのすべてのトピックを説明しようとしました。それにより、面接の準備をしている人は誰でも簡単にトピックを理解し、それらを覚えることができます。
これらの機能テスト面接の質問と回答は、完全に自信を持って面接を正常にクリアするためのガイドになります。
皆様のご成功をお祈り申し上げます。
配列をソートするJavaプログラム
これらの機能テストインタビューの質問と回答が、あなたのキャリアのある時点で役立つことを願っています。
推奨読書
- 機能テストと非機能テスト
- Micro Focus UFT(統合機能テスト)ツールの16の新機能-QTPとUFT
- 5つの最高のHP統合機能テスト(UFT)代替ツール
- 初心者のための完全な非機能テストガイド
- Jubulaのステップバイステップガイド-オープンソースの自動機能テストツール
- 機能テストとパフォーマンステスト:同時に実行する必要がありますか?
- タイプと例を含む完全な機能テストガイド
- Parrot QAチュートリアル:クロスブラウザ機能テストツールのレビュー
- Seleniumとの統合および機能テスト用のスポック
- 単体テスト、統合テスト、機能テストの違い
- 機能テストの面接の質問と回答トップ25
- 2021年のトップ30機能テストツール