40以上の人気のあるテストQAアナリストのインタビューの質問と回答(2021リスト)

40 popular test qa analyst interview questions

最もよくあるテスト/品質保証アナリストのインタビューの質問と回答：

自分がなりたいキャリアを決めるとき、決め手は自分が楽しく仕事ができると思うものだけではありません。

しかし、そのカテゴリーに入るには、あなたが選んだキャリアに必要な職務だけでなく、責任を理解するために、多くのスキルが必要です。 QAアナリストとしてのキャリアを選択する際にも同じことが言えます。それはあなたが優れたテスター、素早い学習者、並外れた思想家である必要があるだけでなく、複雑な問題解決者である必要もあります。

上記の品質はすぐには達成されませんが、明らかに経験と日々の努力も必要です。

この記事では、QAアナリストになるために知識が必須であるすべての側面について説明します。ここに含まれている最も頻繁に尋ねられるQAテストアナリストの面接の質問と回答は、面接の準備について明確なアイデアを提供します。

人気のQAテストアナリストのインタビューの質問

Q＃1）QAアナリストの責任は何ですか？

回答： QAアナリストは、ソフトウェアソリューションの各機能を機能的および技術的にテストするためにあらゆる可能な手段が講じられていることを確認する人です。

QAアナリストの主な責任は、次のように参加できます。

• テスト計画の目的を達成するために、すべてのアクティビティを実行および管理します。
• 製品を開発するために高品質のプロセスを選択してください。
• 要件を分析し、手順を文書化できる必要があります。
• すべての欠陥を文書化して再確認します。欠陥の優先度と重大度を設定します。
• テストケースを作成、文書化、および保守できる必要があります。
• テスト結果の分析。

Q＃2）テスト計画についてどのように理解していますか？

回答： 何を、いつ、どのように、そして誰が行うかについて明確な考えを持っていると、物事はより簡単になります。ソフトウェアテストの場合も同様です。テスト計画は、テストプロジェクトの範囲、アプローチ、リソース、概要、およびプロジェクトの進行状況を追跡するためのアクティビティで構成されるドキュメントです。

テスト計画は、次のようなプロセスの記録です。

• タスクのテスト
• テスト環境
• 設計手法
• 入退場基準
• リスク等

Q＃3）QAチームによって定義されたテストタスクの優先順位を製品開発に参加させます。

回答： テストタスクの優先度は次のように定義されています。

• テストプロジェクトの概要と範囲からなるテスト計画が作成されます。
• テストケースは、テストに必要なデータですべての主要な機能とマイナーな機能をカバーするように準備されています。
• テストサイクルでのテストプロジェクトの今後のビルドで実装される機能に従って、テストケースを実行します。
• 再検証を伴う欠陥報告とその進行状況の追跡。
• テスト実行レポートの要約を準備します。

Q＃4）ソフトウェアテストの実行中に直面する主要な課題のいくつかを参加させてください。

回答： 完全なテストは決して達成できないと私たちが言うように、それにはいくつかの課題があります。小規模であろうと複雑であろうと、プロジェクトのソフトウェアテストを実行する際に直面するいくつかの課題があります。

以下に、いくつかの重要な課題を示します。

• 通常、主題の認識の問題に直面する熟練したテスターの不足、および顧客のビジネスに関する十分な知識の欠如。
• 完了する必要のあるタスクの膨大なリストがある場合、通常、テスターは品質テストによるテストカバレッジではなく、主にタスクカバレッジに焦点を合わせるため、時間も要因として考慮されます。
• どのテストケースを最初に優先的に実行する必要があるかを決定します。これは通常、仕事の経験によって達成されます。
• 要件が誤解されている場合、すべてのテスト作業をゼロにする可能性のある要件を正しく理解する。
• より少ない時間とより効果的にテストを完了するために必要な最高のツールが利用できない。
• テスターと開発者の関係を適切なコミュニケーションと分析スキルで処理します。

Q＃5）ユースケーステストを定義します。

回答： ユースケーステストは、「アクター」と「システム」の間で発生した一連の相互作用をキャプチャする機能的なブラックボックステスト手法として定義できます。ここで、「アクター」はユーザーとそのインタラクションによって表されます。

ユースケーステストの特徴を以下に示します。

• プロジェクトの機能要件が整理されています。
• 最初から最後までのパスまたはシナリオを記録します。
• 統合の欠陥、つまり異なるコンポーネント間の相互作用の結果として発生した欠陥をカバーできます。
• 主な流れとイベントの例外的な流れについて説明します。
• ユースケースが機能するために必要な前提条件は、事前に指定する必要があります。

Q＃6）テスト戦略を定義します。

回答： テスト設計と一般的なテストアプローチを決定するためにプロジェクトマネージャーによって通常実行される一連のガイドラインまたはテストアプローチは、テスト戦略として定義されます。これは、テスト計画の小さなセクションとして検出され、複数のプロジェクトで使用されます。

製品の性質とドメイン、製品の故障のリスク、提案されたツールの使用に関する専門知識などの要因に基づいて、さまざまなテストアプローチが実行されます。

これらのアプローチは、さらに次のように分類されます。

• 積極的な取り組み 、ビルドが作成される前にテスト設計アプローチが開始されます。したがって、ビルド前にバグを見つけて修正するのに役立ちます。
• リアクティブアプローチ 、テストの設計とコーディングの完了後にテストアプローチが開始されます。

Q＃7）品質管理と品質保証の違いを説明してください。

回答： '品質管理' そして '品質保証' テストプロジェクトまたは製品に関して使用される2つの主要な用語です。通常、この分野に不慣れなテスターは、2つの実際の違いを理解していません。

以下の表を参考にして、違いを理解しましょう。

Q＃8）あなたによると、プロジェクトでQAを開始するのに適した時期はいつですか。

回答： ソフトウェア開発ライフサイクル（SDLC）によると、テストフェーズは「実装とコーディング」フェーズの完了後に実行されます。しかし、今日のシナリオでは、最良の結果を達成するには、プロジェクトの開始時にプロジェクトまたは製品のQAを開始する必要があります。

このアプローチに従うと、以下に示す主な利点が得られます。

• 顧客の品質に対する期待に応えるための初期のプロセス計画。
• チーム間の良好で健全なコミュニケーション。
• テスト環境のセットアップに必要な十分な時間を与えます。
• テスト計画の早期レビューと承認を可能にします。

Q＃9）検証と妥当性確認のプロセスを区別します。

回答： 検証と妥当性確認のプロセスは通常、2つの有名な質問によって決定されます。 システムを正しく構築していますか？」 そして 「私たちは適切なシステムを構築していますか？」 。

以下の表で、これら2つのプロセスのその他の違いを見てみましょう。

Q＃10）破壊検査の利点を説明してください。

回答： 破壊試験は、さまざまな負荷の下で製品の故障点を特定するために、つまり、アプリケーションの構造性能を評価してその強度、靭性、硬度、または堅牢性を決定するために、試験チームによって実行される試験の形式として定義されます。

以下に、破壊検査の利点を示します。

• アプリケーション設計の弱点が決定されます。
• アプリケーションの耐用年数を決定します。
• コストと失敗を減らすのに役立ちます。

Q＃11）再テストは回帰テストとどう違うのですか？

回答： 再テストと回帰テストにはいくつかの違いがあります。

これは、以下の表から簡単に理解できます。

Q＃12）データ駆動型テストについて何を知っていますか？

回答： 自動化テストスクリプトが、記録された一連のユーザーアクションでテストされるアプリケーションの領域のみをカバーすることは、すべての自動化テスターに​​とって非常に明白です。通常、これらのアクションでは、記録中に入力した条件下で入力データのみが取得されるため、エラーは発生しません。

ここでは、データ駆動型テストが明らかになります。ここでは、あらゆるタイプの入力値に対してアプリケーションが期待どおりに機能するようにします。この目的のために、データ駆動型テストに必要なデータはハードコーディングされていませんが、テストスクリプトはCSVファイルやODBCソースなどのデータソースからデータを取得します。

要約すると、データ駆動型テストはループ内で次のアクションを実行します。

xmlファイルを開くための最良の方法

• ストレージから入力テストデータを取得します。
• アクションを実行するためにアプリケーションに入力されたデータ。
• 期待される結果で実際の結果を確認します。
• 新しい入力テストデータを使用して、同じ手順を繰り返します。

Q＃13）トレーサビリティマトリックスとは何ですか？すべてのプロジェクトに必要ですか？

回答： プロジェクトのトレーサビリティマトリックスは、新しい機能の実装、既存の機能の強化などに関するプロジェクトの進捗状況を追跡する手段です。トレーサビリティマトリックスを使用すると、プロジェクトの進捗状況を常に監視できます。日付。

要件トレーサビリティマトリックスは、実際には要件仕様書に準拠している以下のパラメータで構成されています。

要件トレーサビリティマトリックスのパラメータは次のとおりです。

• 要件ドキュメントのすべてのセクションは、RTM（要件トレーサビリティマトリックス）でカバーされるポイントです。
• 各ポイントの見出しは、要件仕様の各セクションの見出しです。
• 各ポイントに対応して、その特定のセクション用に記述されたテストケースIDが記載されています。
• BUG /新機能IDも各セクションに記載されています。
• 最も重要な点は、プロジェクトのビルドとその機能が実装されている機能の追跡も維持されることです。
• 別のパラメータには、セクションが完全にテストされているか、まだテストステータスにあるかが含まれます。

Q＃14）アジャイルテストの利点を説明してください。

回答： テスターであるため、エンドユーザーの要件を理解し、最も重要なこととして、エンドユーザー側からの欠陥がないことにより、高品質の製品をより短時間で提供することに重点が置かれます。ここでは、アジャイルテストが、アジャイルソフトウェア開発の原則に従い、クライアントの要件を迅速に検証する様子を示しています。

アジャイルテストの利点は次のとおりです。

• クロスファンクショナルなアジャイルチームがテストに含まれ、テストは頻繁に結果を提供します。
• 多くの時間とお金を節約します。
• 少ないドキュメントとエンドユーザーからの時々のフィードバックが含まれています。
• テスターだけでなく、マネージャー、顧客、開発者を含むチーム全体が対面のコミュニケーションに関与しています。
• 毎日の会議の結果として、問題は事前に十分に決定することができます。
• チームの生産性が向上し、プロジェクトの技術的側面についての理解が深まります。

Q＃15）ネガティブテストとは何ですか？

回答： ネガティブテストは、製品またはアプリケーションの安定性が維持されていること、または予期しない入力が行われたときに失敗しないことを確認する方法です。この形式のテストの主な目的は、無効な入力データの可能性に対してアプリケーションを検証します。

この形式のテストは、 「障害テスト」または「エラーパステスト」 その主な目的は、ネガティブなシナリオでのアプリケーション機能の信頼性をチェックすることです。また、ソフトウェアの弱点を明らかにし、障害を発見し、データ破損の明確なアイデアを提供します。

Q＃16）アドホックテストと探索的テストを区別しますか？

回答： アドホックテストと探索的テストにはいくつかの違いがあります。

以下の表の違いを見てみましょう。

Q＃17）自動テストが手動テストよりも好まれるのはなぜですか？

回答： さて、自動化テストと手動テストはどちらも、テストの世界で重要性と存在感を持っています。

以下に示すのは、自動テストが手動テストよりも優先されるいくつかの重要な側面です。

• 毎回同じテストスクリプトを使用してテストを実行できるため、自動化テストが最も信頼性が高く効率的なテストと見なされます。
• 回帰テストと繰り返し実行の場合に最も好まれます。
• 自動化テストは、長期間実行する場合に費用効果の高いテストであると見なされているため、ソフトウェアの品質が向上します。
• テストスクリプトは再利用可能で高速であり、誰でも結果を確認できます。
• 自動化テストに使用されるツールは、手動のアプローチと比較すると、より高速で信頼性があります。

ただし、いくつかの要因により、手動テストよりも自動テストが優先されることが決定されます。上記が主な要因です。

Q＃18）「テストの有効性」と「テストの効率」から何がわかりますか？

回答：テスト効率 特定の機能を実行または実行するために消費されるリソースとテストコードの数を計算することとして定義できます。また、ソフトウェア製品の作成に使用されるリソースの数も決定します。

これは、次の式で決定できます。

テスト効率= （解決された欠陥の数/提出された欠陥の総数）* 100

テストの有効性 テスト環境とそのソフトウェアアプリケーションへの影響を評価する尺度として定義できます。ここでは、アプリケーション要件が満たされたときに顧客の応答が評価されます。

これは、次の式で決定できます。

テストの有効性= （検出された欠陥の数/実行されたテストケースの数）

Q＃19）プロジェクトの調整のプロセスを説明してください。

回答： プロジェクトの調整は、プロジェクトのパフォーマンスが正しく、ビジネス要件に従っていることを確認する、一貫性のある継続的なプロセスです。プロセス全体には、組織の現在の運用上のニーズに応じて、プロジェクトデータを確認および変更することが含まれます。

レビュープロセスは組織レベルで行われますが、調整計画の実装はプロジェクトレベルで行われます。組織の主な目標と要件、および顧客とユーザーの関係は、プロセスで考慮すべき2つの主要な要素です。

調整プロセスの下での組織の目標によるいくつかの側面は次のとおりです。

• プロジェクトアプローチ
• 戦略
• 関連する制御とプロセス
• 役割と責任

Q＃20）プロジェクト内の欠陥の優先度と重大度をどのように区別しますか？

回答： 「優先度」と「重大度」の両方がバグに割り当てられ、問題/バグを修正のために取得される順序で分類します。これらはさまざまな要因に基づいています。

以下の表で、それらの違いとともにさらに理解しましょう。

Q＃21）アプリケーションに対してパフォーマンステストを実行する必要があるのはなぜですか？

回答： 簡単な言葉で言えば、パフォーマンステストは、さまざまな状況でのアプリケーションの動作と応答を判断するために行われます。これは、アプリケーションの安定性、スケーラビリティ、速度などに関する情報を収集するのに役立ちます。

パフォーマンステストを行う理由は、以下の点から理解できます。

• これは、ワークロードの下でのアプリケーションコンポーネントの応答時間とパフォーマンスを決定します。
• ユーザーのアクティビティの応答時間が計算されます。
• 広範な技術用語を備えた経験豊富なプログラマーが必要です。
• 負荷がかかっているとき、つまりユーザー数が瞬時に増加したときのアプリケーションの動作を決定します。

Q＃22）仕様駆動型テストとは何ですか？

回答： 名前自体が定義するように、仕様駆動型テストは、機能仕様が実行されるテストの基礎として機能するアプリケーションの要件仕様に基づいて行われます。

この形式のテストは、ユーザーが複数のデータを入力してから出力を監視する「ブラックボックステスト」と同じです。これは、仕様とテスト計画を使用したすべてのレベルのテストに適しています。

Q＃23）CMMIについて説明してください。

回答： CMMIは、能力成熟度モデル統合の略です。このモデルは、Software Engineering Institute（SEI）によって開発されました。これは、製品またはシステムの管理と開発に関連するプロセスが品質を決定するという原則に基づいています。

また、製品または組織全体のプロセス改善のためのガイドラインも提供します。

CMMIは、以下に示すように5つのレベルに分けられます。

• レベル1： 初期
• レベル2： 管理
• レベル3： 定義済み
• レベル4： 定量的に管理
• レベル5： 最適化

Q＃24）CMMIを実装することの利点を説明してください。

回答： CMMIを実装することにはいくつかの利点があります。

それらは次のようにリストされています。

• 製品ライフサイクルの詳細なカバレッジとレポートを提供し、プロセスの改善に役立ちます。
• 組織の既存の標準、それらのプロセスおよび手順は、CMMI実装の一部として改善されます。
• CMMIの実装の結果、納期厳守と顧客満足度が向上します。
• また、エラーを早期に検出できるため、効果的な管理とコスト削減にもつながります。

Q＃25）いくつかの自動化テストツールを参加させます。

回答： 自動化テストツールの一部を以下に示します。

• セレン
• 水
• 風車
• 石鹸
• テルル

Q＃26）ユニットテストで回帰テストを実行できますか？

回答： 絶対に。回帰テストは、他の欠陥を修正することの副作用としてコードに導入された可能性のある望ましくない欠陥をテストすることです。単体テストは、コードの小さな独立した個別の部分を実行するテスト実行です。

回帰テストは、単体テストから統合テスト、そして最終的には受け入れテストまで、あらゆるレベルで実行できます。回帰テストは視点に基づいたテストですが、単体テストはレベル（ボトムアップ、トップダウン）のアプローチです。

Q＃27） スモークテストと健全性テストの違いは何ですか？

回答：

• スモークテストは、ビルドの古い顕著な機能または既存の機能のテストであり、健全性テストは、新しく追加されたモジュールの検証であり、ビルドの欠陥を修正します。
• スモークテストが最初に行われ、次に健全性テストが続きます。
• スモークテストは、ソフトウェアが提供する重要な機能のテストを対象としているため、ソフトウェア全体に拡張されます。一方、健全性テストは、最近追加されたモジュールのみに絞り込まれ、詳細にテストされます。

Q＃28） オフィスでの手動テスト担当者としての日常の活動は何ですか？

ハンドブック： システムで最初にチェックするのは、ダッシュボードを更新して、現在のイテレーションの要件/拡張機能またはバグのステータスを確認することです。その後、テストシナリオとテストケースを定義するための毎日のスクラムコールとレポート、ディスカッション、ブレインストーミングセッションが続きます。

これらのケースは、レビューに従って再ドラフトした後に実行されます。非機能要件についてクライアントと連絡を取ることも、私のプレートの主要な活動の1つです。

Q＃29） あなたのオフィスの自動化テスターのメンバーとしてのあなたの毎日の活動は何ですか？

オートメーション： 私の1日は、新しいビルドでテストケースのバッチを起動した場合に備えて、昨日の自動化の結果について話し合う毎日のステータスミーティングから始まります。

実行サイクルはヘルスチェックと呼ばれ、ビルドの健全性を確認できます。

その後、スクリプトの失敗、機能の設計変更に基づいて欠陥を報告します。スクリプト/ライブラリまたは関数を維持し、新しい要件のために新しいスクリプトを自動化してチェックインし、必要に応じて関数ライブラリ内の新しい関数をチェックインします。

自動化によってリグレッションの欠陥を見つけ、それらをテストスイートに追加するために、テストスクリプトを個別に再実行する必要がある場合があります。

Q＃30）要件と欠陥および拡張機能をどのように区別しますか？

回答 ：TO 要件 は、実装、テスト、および配信に不可欠なユーザーストーリーです。
アン 強化 は、既存の機能に追加または即興で作成された機能です。
に 欠陥 予想されるユーザーストーリーからの完全な逸脱です。

また、仕様書に別段の記載がない限り、欠陥が要件の特定の領域を明らかにした場合、それは要件またはその一部と呼ばれることもあります。

Q＃31） 開発者があなたが提出したバグの修正を拒否した場合、あなたはどうしますか？

回答 ：欠陥の修正を決定する重要な要素は、それに割り当てられた「優先順位」です。欠陥の優先度が高い場合、主要な機能をブロックし、一貫して再現されるショーストッパーは、ビルドで修正する必要があります。

テスターと開発者が一緒になって出荷される製品の品質に貢献するため、同じことを開発者に効果的に伝える必要があります。

開発者に短期間でバグを修正するよう説得するのに役立つ他の側面は、バグの品質報告と、バグの修正がリリースで最も重要であるという事実を開発者に理解させることです。

Q＃32） あなたが提出したものがバグであることを開発者が否定した場合、あなたはどうしますか？

回答 ：欠陥ライフサイクルの最も重要なフェーズは「拒否」です。これは、ログに記録されたインシデントレポートが有効なものではないことを意味します。要件を記載したビジネス要件ドキュメントは、ソフトウェア、したがって報告されたインシデントの性質を理解するのに役立ちます。

バグを分析し、バグに関する調査結果を開発者とチームに公開します。欠陥がある場合は、必ずログに記録してください。テスターがギャップ分析を提供し、それを開発者に提示しなければならない場合があります。それでも対立が解決しない場合は、チームの上級者が参加する必要があります。

Q＃33） 最初の再テストまたは回帰テストは何ですか？

回答 ：コードを再実行するため、再テストが最初に行われます。簡単に言うと、事前定義されたステップの繰り返し実行です。コードを修正した後は必要ありません。しかし、回帰テストは、解決された欠陥の副作用を評価することです。

確かに、1つの欠陥を解決し、別の欠陥をコードに追加することは、テストプロセスの目的ではありません。テスターの最良の発見と最良のキャッチは、通常、回帰欠陥です。ビルドは、回帰テストを行わずにリリースしないでください。

Q＃34） ベータテストの代替手段は何ですか？

回答 ：ベータテストは、開発者の関与を最小限に抑えてクライアントのサイトで開催され、実際の本番環境での障害を記録します。そのような慣行が会社によって実行されない場合、より安全なアイデアは、最新のビルドを取得するためにキューにいないクライアントに最初に製品を出荷することです。

数日間、クライアント構内の特定のサービスコンサルタントがソフトウェアを使用し、環境内でのリリースの安定性を保証するアクティビティを記録および監視できるため、重大なバグが修正されていない場合でも、事前にテストできます。ターゲットクライアントに配信します。別のアプローチは、偏りのないテストのためにチーム内の要件のスワップテストです。

Q＃35） あなたが直面したアジャイル実装/方法論の欠点は何ですか？

回答 ： 欠点は次のとおりです。

1. スプリントは通常、非常に締め切りに制約があります。
2. ドキュメントは優先事項ではありません
3. PBI（製品バックログアイテム）の切り替えは頻繁に行われる可能性があります。

Q＃36） 影響分析が重要なのはなぜですか？

回答 ：リスクベースを実践するには、影響分析を行う必要があります。そうすることで、テストケースは、顧客の観点から重要なすべての重大なバグを時間の前に解決できるように設計できます。ビジネス、クライアントのニーズ、およびソフトウェアの使用法についての十分な調査が必要です。

例えば、 銀行ドメインのソフトウェアに関連する最も重要なリスクはセキュリティです。既存のソフトウェアに追加された新しいフォームは脆弱になる可能性があります。適切なリンク、リダイレクト、およびナビゲーションを適切なページに追加し、必要に応じてプロキシをインストールすることにより、十分な量のセキュリティテストを行うことをお勧めします。

Q＃37） 例の助けを借りて、各パフォーマンステスト、ストレステスト、および負荷テスト？

回答 ：ここで取ることができる最良のケースは、ライブWebサイトです。

性能試験 リアルタイムシナリオと同様の条件を通過したときにシステムのグリッチを検証するために行われます。ストレスのある条件下で実行する必要はありません。パフォーマンステストの出力は、システムが本番環境に移行する準備ができているかどうかを確認するのに役立ちます。

単純なチケット予約フローの場合、パフォーマンスの問題が原因で速度が低下した可能性があります。たとえば、結合を使用する一部のクエリは少し遅く、不要な句を実装したり、データベースにデータを不適切に保存したりします。

ストレステスト は、ソフトウェアを極端な条件（重くて分散されていない負荷、限られた計算リソース、高い同時実行性）に置くことによって実行されるパフォーマンステストの一種です。

システムがデータの損失や破損、ストレスを取り除いた後でもリソースが使用されている、応答がない、または未処理の例外などの特定の動作を示す場合は、ストレステストに失敗したことを意味します。ディスク障害が発生したり、GDIカウントが不必要に増加したりすることもあります。

例えば、 すでに大量のメモリを消費しているマシンでホストされているWebサイトや、繰り返し要求が発生しているWebサイトがハングしたり、ログアウトしたりしないようにする必要があります。

負荷テスト は、しきい値に達するまでシステムの負荷を絶えず増加させながら、システムの動作を監視しています。通常、ワークロードモデル、メトリック、および負荷レベルは、負荷テストへの入力です。

例えば、 Tatkalの予約時間が午前10時または午前11時に近づくとシステムにログインするユーザーの数が増えるため、Tatkalの割り当てを予約する時間が近づくと、列車の空席を取得する時間が徐々に長くなります。

Q＃38） 回帰テストを行う際の最大の課題の1つは何ですか？

回答 ：回帰テストの実行中には、さまざまな課題が発生する可能性があります。

• テストを繰り返し実行することは、テスターに​​とってそれほどエキサイティングではなくなる可能性があります。
• 時々そのようなテストは独創的な思考を必要とするので、時間がかかります。
• 妥協したビジネス価値。
• 回帰テストケースの不適切な選択は、検出される主要な回帰欠陥をスキップする可能性があります。
• したがって、生産時に欠陥を再現することは一貫性がなくなります。
• 実行する大規模なスイート。

Q＃39） テストシナリオ、テストケース、テスト計画、テスト戦略を文書化するように求められた場合、何から始め、残りはどのような順序で続きますか？

回答 ：シーケンスは、テスト戦略、テスト計画、テストシナリオ、そして最後にテストケースになります。

Q＃40） 上記のいずれかを文書化できなかった場合はどうなりますか？テスト計画の文書化を見逃したとしたら、どのような結果になりますか？

回答 ：テスト計画の文書化を怠ると、その客観的なアプローチをテストする範囲が無効になり、テストに重点が置かれます。その場合、テストする機能、テストする手法、基準に合格または不合格、そして最終的にはテストに関連する主要なリスクを判断するのが困難になります。

Q＃41） 最近入手したビルドのテストをどのように開始しますか：従うアプローチはありますか？最初にスモークテストを開始し、次に健全性テストを開始しますか？

回答 ：スモークテスト>健全性テスト>探索的テスト>機能テスト>回帰テストと最終製品の検証。

Q＃42） 従ったバグレポートの形式を説明してください。

回答 ：

バグレポートには、次の情報が含まれている必要があります。

• バグID
• 要件/拡張/既存のバグへのマッピング
• バグの概要/タイトル
• 製品のバージョン
• 優先度
• 構成（システム仕様）
• 前提条件
• ステップ
• 期待される結果
• 実際の結果
• ログ。スナップショット、ビデオクリップ
• 状態
• その他の備考

Q＃43） 回帰テストケースをどのように選択するか、または回帰テストスイートを形成しますか？

回答 ： はい。これは影響分析の結果です。これは、テストしているさまざまな領域で使用またはアクセスされている機能の単純なマッピングであり、他の機能との統合、およびシステムのエンドツーエンドまたはフローテストとしての全体的なものです。

以前のビルドで同じ機能に対して以前に提出された欠陥をピックアップすることもできます。理想的には、機能を使用する少なくとも5つの異なるテストケースを使用して、1つの欠陥を回帰テストする必要があります。

Q＃44） 次の欠陥の例を教えてください

• 低優先度高重大度の欠陥
• 優先度が高く、重大度が低い欠陥

回答 ：特定のオペレーティングシステムで特定のタイムスタンプでのみ複製されたときにアプリケーションがクラッシュする欠陥は、重大度が高く、優先度が低い欠陥である可能性があります。

ダブルクリックでは開かないが右クリックで開くビューに対して提出された欠陥は、優先度が高く、重大度が低い欠陥である可能性があります。

Q＃45） 特定の紙がホワイトペーパーであるかどうかをテストするための効果的なテストケースを1つ作成しますか？

回答： 白い紙に書くソースインクの色が同じままの場合、紙は白です。たとえば、赤いインクで白い紙に書く場合、インクの色はペンでは赤のままで、紙でも赤く表示されます。

注意： この質問に対する他の多くの答えがあります。あなたは基礎となる論理でそのような有効な答えを考えるようになることができます。

Q＃46） チャーターテストとは何ですか？

回答： テストを開始する前に、チャーターの下にリストされている目標とアジェンダに基づいて実行されるセッションテストは、チャーターテストと呼ばれます。

ここでのテストは、ドキュメントにあまり焦点を当てず、テストだけに焦点を当てた固定の時間枠で行われます。これは、テストエンジニアが時間枠内でソフトウェアを検証する探索的テストの別の変形です（ 例えば、 開発されたいくつかのヒューリスティックに基づいてわずか2時間）。

Q＃47） 非常に短い時間で配信される優先度の高いリリースがある場合のアプローチは何ですか？

回答： そのような場合、よく考えられた計画が有益な場合があります。

時間不足のシナリオでのテストを支援するために、以下を実行できます。-

• 回帰テストを実行するための既存の更新された自動化スクリプトの使用。
• フローベースのシナリオをエンドツーエンドでテストします。
• 優先度の高いテストケースを実行し、時間が許せば、優先度の低いケースに切り替えます。
• 以前のバージョンで提出された優先度の高いバグを再テストします。
• 迅速なソフトウェアテスト
• 開発者は、単体テストを実行して、テストの対象範囲を広げるように依頼できます。

Q＃48） 周りにあるデバイス/オブジェクト（例：椅子）にテストケースを書きますか？

回答： ここでのアドバイスは次のとおりです。 常に要件の収集から始めます。これは、ソフトウェア開発ライフサイクルに対する成熟度を示しています。オブジェクトを選択した後、遠慮なく質問してください。

この場合：-

• どんなタイプの椅子ですか？オフィスチェア、書斎テーブルチェア、ソファチェア、ダイニングテーブルチェア、コンフォートチェア？
• 椅子の木材、鋼、プラスチック、室内装飾品の製造にはどのような材料が使用されていますか？
• 寸法（高さ、椅子の種類に基づく重量）を尋ねます。
• 空き状況を確認してください。そしてそれに基づいてあなたのケースを起草し始めます。

テストケースは椅子の種類ごとに異なりますが、思考能力に任せたほうがよいでしょう（ 例えば、 椅子の目的、椅子のタイプに応じた寸法、ポータブル-非飲用、軽量、購入オプション）。

椅子ごとに、 パフォーマンステストケースは次のとおりです。 引張強度または最大耐荷重能力を導き出します。

Q＃49） すべてを自動化できますか？

回答： –ある程度はい。ただし、自動化ツールには、他のソフトウェアと同様に制限があります。また、テスト中のソフトウェアまたはテスト中のアプリケーションはアップグレードされ続けます。

したがって、ソフトウェアテストが手動の介入なしで実行できるという保証はありません。結局のところ、ツールはテスターと同じくらい賢いのです。これは、さらに別のソフトウェアをテストするソフトウェアです。欠陥をテストして見つけるのに十分なインテリジェントさが必要なのは、コード/ scripts /ライブラリです。

結論

この演習がいくつかの質問でウォームアップし、面接の素晴らしいキックスタートを提供し、質問に答えながら自信を磨くのに役立つことを願っています。また、履歴書/プロフィールから出てくる可能性のある他のシナリオベースの質問がある可能性があります。

したがって、面接は面接官と候補者の両方にとって双方にメリットのある状況であることが判明するように、自己事前の手で模擬面接を練習することを常にお勧めします。品質アナリストはテストエンジニア以上のものであり、そのフィードバックは製品の品​​質だけでなく、ソフトウェアをテストするためのプロセスにとっても重要であることを忘れないでください。

インタビューに感謝し、頑張ってください！

推奨読書

• 面接の質問と回答
• 25以上の最も人気のあるADO.NETインタビューの質問と回答
• 25のベストアジャイルテストインタビューの質問と回答
• 回答付きのスポックインタビューの質問（最も人気があります）
• ETLテストの面接の質問と回答
• 20の最も人気のあるTestNGインタビューの質問と回答
• トップ30以上の人気のあるキュウリのインタビューの質問と回答
• トップ50の最も人気のあるCCNAインタビューの質問と回答