メニュー

経験豊富な専門家向けのソフトウェア手動テストインタビューの質問

software manual testing interview questions

問題を排除するために楽器を試してください

経験豊富な専門家向けの最もよくあるシナリオベースの手動テストインタビューの質問と詳細な回答：

私は最近、このユニークな経験をしました QAコーチング （10年の経験）ロサンゼルスの大手エンターテインメント企業とのクライアントソフトウェアテストインタビューに参加する。テスト対象のサイトは、Webコンポーネントとモバイルコンポーネントの両方を備えた、顧客向けの単純なWebサイト（オンラインTVチャネルのようなもの）でした。

ソフトウェア手動テストインタビューの質問

コンサルティング会社は、このクライアントにプロファイルを投影していました。 オンサイトテスター+コーディネーターのポジション しかし、それらのどれもがテストインタビュープロセスを通過していませんでした。それで彼らは集めることに決めました QA面接の質問 以前の参加者から、彼らは私にアンケートをくれました。

経験豊富なパフォーマンステストの面接の質問

彼らは私が次の候補者とコーチに答えを与えることを望んでいました QA面接のテストに成功する人。

経験豊富な人のための手動テスト面接の質問

質問のリストを受け取ったとき、私は驚きと「驚きではない」と同時に驚きました。驚いた-質問は本当に基本的であり、10年の経験を積んだQAがそれらに簡単に答えることができたはずだったからです。 QAは、私の意見ではほとんど雑草が多いITの分野であるため、それほど驚くことではありませんが、それには入りません。

演習が終わった後、この経験をSTHの読者と共有するのはいいことだと思いました。初心者にとって、これは良いライブ露出になります。他の人にとっては、それはどれほど重要かを友好的に思い出させるでしょう ファンダメンタルズ どんなに経験があっても。

推奨読書=> 101以上のソフトウェアテストインタビューの質問と回答。

ここに行く…..

経験豊富な人のための手動テスト面接の質問

9初心者および経験豊富な受験者向けの最も一般的なQAソフトウェアテストの面接の質問：

#Q 1）テストスクリプトを作成するプロセスは何ですか？

回答：

ステップ1： AUTを完全に理解することです。

  • これは、要件文書を完全に読むことによる可能性があります。
  • ドキュメントがない場合は、以前のバージョンのアプリケーション、ワイヤーフレーム、スクリーンショットなど、私たちが持っている参照ポイントを理解しようとする可能性があります。

ステップ2： 要件を理解した後、このアプリケーションでテストする必要のある領域のリストを作成します。つまり、テスト要件を特定します。このステップの焦点は、テストする「何」を特定することです。このステップの結果は、 テストシナリオ 。

ステップ3： テストシナリオができたら、次にそれらをテストする「方法」に集中します。このフェーズでは、特定の機能をテストする方法、入力するデータ（ テストデータ ）そして期待される結果は何ですか。

これらの3つのステップが完了すると、テストの準備が整います。

例を使用したホワイトボックスとブラックボックスのテスト

#Q 2）バグレポートのフィールドは何ですか？

回答： 次の重要なフィールドをに含める必要があります 良いバグレポート ：

  1. 一意のID
  2. 欠陥の説明：バグが何であるかを簡単に説明します。
  3. 再現手順：エラーに到達する方法の詳細、正確なテストデータ、欠陥が見つかった時刻（該当する場合）環境：問題の再発生に役立つ情報
  4. アプリケーションのモジュール/セクション（該当する場合）
  5. 重大度
  6. スクリーンショット
  7. 責任あるQA：この問題に関するフォローアップの質問がある場合

#Q 3）顧客向けソフトウェアをテストする方法は？

回答： テストするアプリケーションでは、特定の要件セットがアプリケーションによって満たされているかどうかを確認しようとしています。しかし、ユーザー向けのサイトに関しては、機能に集中することは別として、いくつかのユーザビリティ機能、おそらくパフォーマンスとセキュリティの側面もある程度検討する必要があります。

テストの最初のレベルは ： サイトはその機能要件を満たしていますか？

例えば、 ローン管理サイトの場合は、新規顧客がローンを申請できるか、既存の顧客がローン情報にアクセスできるか、ローン金額に適用される利息％が正しいかなどを確認する必要があります。

次のレベルのテストは ：サイトの使用はどれほど簡単で、オプションは論理的に意味があり、ユーザーの期待に応えるかどうか。

例えば、 ユーザーが基本情報を送信するために3〜4画面を通過する必要がある場合、ユーザーは煩わしくなります。そのため、このような問題に対処する必要があります。

別の 例、 ユーザー名とパスワードを入力した後、ユーザーはタブをクリックする可能性があります。つまり、コントロールは(サインイン)ボタンに移動する必要があります。キャンセルする場合、ユーザーは本当にイライラし、サイトの使用経験は危険にさらされるだろう。そのような問題を捕らえる必要があります。

性能試験 完全な範囲ではないかもしれませんが、検索結果が表示されるまでにかかる時間や、システムがピーク時に顧客情報を取得するのにかかる時間などの単純な状況です。これらは、注目したいことです。

セキュリティ –サイトにアクセスするための安全なログインがあるサイトの場合、その周辺の最小限の機能をテストする必要があります。 例えば、 サイトを10分以上アイドル状態のままにした場合、自動ログアウトするかどうか。それと同じくらい基本的なことに焦点を当てるべきです。

#Q 4）テスト用の入力ドキュメントがないという課題を克服するにはどうすればよいですか？

回答： BRDやFSDなどの詳細な標準ドキュメントが利用できない場合、テスターは参照ポイントに依存する必要があります。

  • スクリーンショット
  • 以前のバージョンのアプリケーション
  • ワイヤーフレームなど

非常に役立つもう1つの要素は、開発者またはビジネスアナリスト（利用可能な場合）に相談して、疑問がある場合に私たちの理解または説明を確認することです。

これらの状況のいずれも機能しない場合は、以前のITアプリケーションの経験に基づいてアプリケーションを概念化し、テストスクリプトの基本セットを作成できます。テストフェーズが開始されたら、テストサイクルタイムの一部を設定し、テストケース管理を実行して（作成済みのスクリプトを完全にする）、次のフェーズのドキュメントを用意します。

#Q 5）入手方法 最大の生産性 オフショアチームから？

回答： 重要なのは、すべてのテスターがすべてのモジュールについて知っていることと、知識が1か所に集中していないことを確認することです。テストスクリプトのピアレビュー、欠陥会議、およびKTセッションに全員を参加させることで、全員が可能な限りアプリケーションを認識できるようになります。

また、チームワークの概念を奨励することで、チームメンバーが協力し、助け合い、助け合って生産性を向上させることができます。

定期的なフォローアップ会議もプロセスに非常に役立ちます。

#Q 6）オンサイトコーディネーターの役割と責任は何ですか？彼/彼女もテストしますか？

レジストリクリーニングソフトウェアについてのレビューを提供するサイト

回答： オンサイトコーディネーターは、オフショアチームとクライアントのテスト契約に関する情報の連絡窓口です。

この仕事には以下が含まれます：

  • オフショアおよびクライアントとの間のKT
  • すべてをテストするための環境の準備
  • 健全性テスト、スモークテスト
  • テスト–主要な機能。
  • バグレビュー–オフショアチームによって発見
  • それぞれの開発者へのバグ割り当て
  • 指標の提示
  • サインオフの提供

はい、オンサイトコーディネーターでさえテストする必要があります。

#Q 7）一貫性のないバグ-オンサイトでは見つけることができるのに、オフショアでは見つけることができない、またはその逆の理由–この状況に対処するにはどうすればよいですか？

回答： オンサイトで発生したかオフショアで発生したか、再現可能かどうかにかかわらず、すべてのバグを記録して分析する必要があります。テスターの仕事への真の付加価値は、単にバグを報告するのではなく、バグの根本原因分析プロセスに関与することです。

この状況に対処する方法のいくつかは次のとおりです。

  • すべてのオンサイトおよびオフショアチームメンバーは、発生するすべてのエラー（再現可能かどうか）についてスクリーンショットを撮る必要があるというガイドラインに従う必要があります。
  • ログやシステムファイルなどがある場合は、問題の証拠を見つけるのに役立つ可能性があります。それを見つけようとする必要があります。
  • これらすべての手順を実行しても、問題が発生する理由と時期がわからない場合は、できるだけ多くの情報を添えて、開発者に報告する必要があります。

#Q 8）ビデオ/オーディオ関連のテスト–これには何が含まれますか？

回答： ビデオまたはオーディオを備えたアプリケーションをテストする方法は？

考慮すべき重要なポイントは次のとおりです。

  • アクセスレベル（制限されているかどうか–パスワード制御）
  • さまざまな種類の環境
  • ブラウザの互換性
  • 画面の解像度
  • インターネット接続速度
  • 再生、停止、ミュートなど、ビデオの特定のオプション。
  • サイズ別のビデオ
  • 動画への返信–コメント（コメントの長さとコメント数の制限）
  • ビデオへのビデオ応答
  • ソーシャルネットワーキングサイトとのインターフェース–相互運用性
  • バッファリング速度
  • ビデオの埋め込み

#Q 9）モバイルアプリケーションのテスト–簡単に何が含まれていますか？

回答： モバイルアプリのテスト重要なテストシナリオ：

  • アプリが複数の携帯通信会社と複数のデバイスで正常に動作するかどうかを確認します。
  • モバイル画面での機能の使いやすさ。
  • AndroidやiOSなどのさまざまなモバイルプラットフォームでテストします。
  • インストール、アンインストール、ネットワークありとネットワークなしのアプリの起動、機能のテスト。
  • ネットワーク接続– WiFi、2Gなど
  • AndroidMonitor.bat用のiOSiPhone構成ユーティリティのログをデバッグに使用できます。

それだけです。さて、それはそれほど単純ではありませんでした。

最後に、STHの哲学を繰り返します。基本をよく知っていれば、残りは自動的に続きます。

この努力が読者にとって有益で意味のあるものになることを願って、私は結論を下します。私たちがどのようにしたかについてのコメントセクションで私たちに知らせてください。

著者： この投稿は、STHチームメンバーのSwatiSeelaによって書かれました。

推奨読書

^