リリース直前の数千の欠陥の注文/処理
この質問は本当に良い会社とのインタビューで私に尋ねられました。以下に私たちの相互作用の形で質問を提供します（M：me＆I：interviewer）。明確な答えはありませんが、私は何を知る必要がありますインタビュアーが本当に望んでいたアイデア/回答：
I：シナリオは、あなたと他の2人がテストチームで構成されていることです。自動化を実行できるのはリードであるあなただけであり、他の人は手動テストのみを実行できます。発生したバグは10,000近くあり、この製品が納品されるまでに4〜5週間以内です。製品が時間通りに配達されることを保証するためにあなたは何をしますか？
M：バグを優先的にフィルタリングし、再テストします。それまでの間、どの機能がより多くのリグレッションに直面しているかについてログを記録し、自動化を開始してください。同様または関連するバグは、さらにテストするために他の人に提供されます。
I：どのバグにも優先順位が付けられていないとします。あなたは何をしますか？
M：日付でフィルタリングします。どのような種類のSDLCでも、アジャイルなものであっても、コアコンポーネントが最初に開発されます。コアのバグがある場合は、最初に修正する必要があります。
I :(残念ながら）非常に重要な機能が後のスプリントで追加された場合はどうなりますか？また、チームメイトと自動化する能力をどのように活用しますか。
M：日付とともに、テスターとして、これまでの製品のコアと重要な機能を知る必要があります。そのことを念頭に置いて、各スプリントのコア領域を見つけることができます（チームメイトについては同じことを答えました）従来通り）。
I：たとえば、バグには各スプリントのタイムラインがマークされていません。あなたは何をしますか？
M：バグリストを検索して、リリースできない重要な機能を表すキーワードを付けます。そこからバグを選びます。
I :(やはり残念ですが）キーワードを使用すると、非常に多くの結果が得られますが、それらを1つずつ確認しますか？
M :(ゆっくりと希望を失って）タイトルを見て決めます。
I：一般的にタイトルはそれほど説明的ではありませんが、どのように扱いますか？
M：製品の納品を決める必要があるので、バグを調べるのではなく、自分で製品のテストを開始し、直面している同様のバグを検索します。
I：では、これらの多くのバグを無視しますか？利害関係者は同意しない場合があります。（この後、私はそれを完全に失い、ただしゃべり続けました、そして私は他に何が尋ねられたか覚えていません。またどこでも他の2人の手動テスターの管理/仕事が尋ねられました）
これはSrSDETへのインタビューでした。
回答
他の回答が言ったことに加えて、インタビュアーは、チームへの新たな追加として、あなたが勝てない状況にどのように対処するかを探していると思います。率直に言って、私は、少なくとも、会社が過去にこの種の状況に陥っていたのではないかと思います。最悪の場合（私は冷笑的であることを自由に認めます）、ポジションを取得した人は誰でも同様のことが直面することになります。
インタビュアーとして、私がインタビューしていた人からこのようなものが欲しいです：
まず、これらのバグがどのように構成されているか、特に優先度、重大度、およびリスクについて知りたいと思います。私はこのような状況に陥っていると思いますが、最初から関わっていたわけではありません。このような状況は、どこかで事態がひどく間違っていることを示唆しているからです。
バグが優先度、重大度、およびリスクを含む方法で編成されていない場合は、他のテスター、プロジェクト管理、および開発に相談して、予測される展開に最大のリスクをもたらすことがわかっている問題を特定したいと思います。日付。
そのような組織があれば、テスター、プロジェクト管理、開発に相談して、最もリスクの高いバグを確認したいと思います。理想的には、製品をリリースする前に修正する必要があるバグのリストを作成する方法を探しています。10,000個のバグがある場合、そのリストの作成には時間がかかります。これは、報告されたバグが非表示またはブロックしているためにテスターが見つけられなかったバグがないことを前提としています。
状況がどれほど悪いかがわかったら、私の意見では、計画どおりにアプリケーションをリリースできるかどうかを判断できます。ほとんどのバグが比較的リスクが低く、リスクの高いバグはかなり簡単に修正できると思われる場合は、チームをリスクの高いバグに集中させ、プロジェクトマネージャーや他のチームリーダーと協力してリスクを最も高くします。 （重大度が高く、フィールドで発生する可能性が最も高い、および/またはアプリケーションのブロック領域）バグが修正およびテストされました。
製品を時間内にリリースする方法がわからない場合は、プロジェクトマネージャーと上司に相談して、堅実な機能の限定ベータリリースを行う方法があるかどうか、またはリリースを遅らせる方法があるかどうかを確認します。私はそのポジションに慣れていないので、リリース日を動かせないようにする可能性のある契約要件や私の管理外の他の要因があるかどうかはわかりません。
また、リリース後、関係するすべてのチームのリーダーと協力して、このような状況がどのように発生したのか、再発を防ぐためにどのような行動を取ることができるのか、そしてどのように協力して取り組むことができるのかを確認しました。バグのバックログを停止します。
これはSDETの役割とは何の関係もないことに注意してください。インタビュアーがSDETがテストリードとしても機能することを期待していることは質問から明らかです-これは特に良いことではないと思います。率直に言って、これが会社が期待していることであるかどうかを知りたいと思いますSDET。
面接はストレスの多い状況ですが、横向きに考えて、飛び込むのではなく、尋ねられた質問の意味を調べようとすることを覚えておく価値があります。ストレスを感じて最善を尽くそうとしているため、行うのは難しいです。しかし、インタビュアーが質問で何を探しているのかを頭の中で自問するのに少し時間がかかる場合は、通常、より良い答えを与えることができます。
最初に頭に浮かぶのは、これらのテストはこれまでに機能したことがあるかということです。もしそうなら、慌てる必要はありません。コードベースまたはテストフレームワークのいずれかで何かが変更されたため、それらのグループが失敗した可能性があります。それを追跡し、一度に数千の失敗を排除できるかどうかを確認します。手動で再度通過したものを読み直して再確認する必要がありますが、おそらく数日しかかかりません。
私がまだ同様のことをする前にそれらがチェックされなかった場合-大きなグループを一度に修正できる可能性のある共通点を探してください。
そうしないと、そこに非常に多くのノイズがあり、失敗している重要な何かを見逃す可能性があります。
その後、すべてに到達できず、金儲けのコードパスに集中できない可能性があることを受け入れます。働かなければならないことやビジネスは折りたたまれます。次に、それらをさらにいくつかクリアした後、1日おきまたは3日おきに、前述のようなグループ化された障害がもうないかどうかを確認し、さらにいくつかのグループをクリアしてみます。
注：SDETの観点からこれに答える-問題のあるコードベース自体を修正できる人。
インタビュアーがテストの失敗ではなくバグについて言及していた場合（テストの失敗が@Lewisによる回答を参照している場合）
まず第一に、製品に10000のアクティブなバグがあることは、本当に大きな危険信号です。
そして、そのような製品をリリースしてはいけません。しかし、経営陣の決定がまだリリースされる場合は、
インタビュアーが期待していた答えは「重大度」でしょう。
チームは、優先順位がない場合は最初に重大度の高いバグの修正に集中し、緊急の要件ではなく、実際のビジネスロジックに影響を与えない場合は、保留状態を低く保つ必要があります。
そして、最初にスモークテストの自動化に集中してから、すべての回帰スイートの自動化を開始します
バグをグループ化し、バグクラスタリングが発生する場所を確認し、修正が行われたらそのモジュールを厳密にテストします。
リリース前に、すべてのスモークテストシナリオを手動でテストします（重要なビジネスロジック）
また、10000のバグがあると、これらのバグが製品内のいくつかの重大なバグをマスキングしている欠陥マスキングが発生する可能性があります。
したがって、修正が行われたら、モジュールの周囲でより厳密なテストを行って、より重大なバグを掘り下げる必要があります。
だから私がインタビューに参加していたなら、私は次のように答えます：
- どのプロジェクトでも10000個のバグは大きな危険信号になります。これは、適切なバグ修正プロセスと見積もりが行われていなかったことを示しています。私は確かに欠陥クラスタリングと欠陥マスキングについて心配します。つまり、バグのほとんどが単一のモジュールに集中している可能性があり、この多くのバグは、モジュールを厳密に修正して再テストした後にのみ識別される他の重大なバグをマスキングしている可能性があります。そして、この理由から、リリース日をさらに延期することをお勧めします。
開発チームがバグの修正に忙しい中、スモークテストのユースケースとバグのユースケースの自動化を開始します。修正が到着したら、再テストタスクを手動テスターに割り当て、モジュールに対して厳密なアドホックテストを実行して、マスクされた重大なバグを見つけます。
- 優先順位がない場合は、最初に重大または重大度の高いバグを再検討し、バグの存続期間を調査して、バグがそれほど長く修正されない理由を理解して、将来のプロセス全体の改善に役立てることはできません。
重大度の低いバグについては、タイムラインと、これらのバグを含む最初のバージョンをリリースするかどうかのリリース決定についてチームで決定する必要がありますが、必要に応じて同じ問題と回避策を文書化します。また、可能であれば、可能な修正の次のリリース日を提供します。
したがって、上級QAである場合は、危険信号が表示されたときに「いいえ」のままでいるという強い意見を提示する必要があります。柔軟性が高すぎないでください
質問のポイントが具体的な答えを与えることである場合、ここでの他の答えは良いです。
しかし、多くのインタビュアーは、あなたがどのように考えているかを知りたい、またはあなたが質問について推測しているのかどうかを理解したいので、具体的な答えなしに漠然とした質問をします。彼らはあなたに詳細を得るために彼らに明確な質問をすることを望んでいます。これはあなたの答えを導くのに役立ちます。
シナリオは、あなたと他の2人がテストチームで構成されていることです。自動化を実行できるのはリードであるあなただけであり、他の人は手動テストのみを実行できます。発生したバグは10,000近くあり、この製品が納品されるまでに4〜5週間以内です。製品が時間通りに配達されることを保証するためにあなたは何をしますか？
尋ねるべきいくつかの質問：
- 手動のQAテスターはどのくらい経験がありますか？
- 手動テスターはこのプロジェクトで経験がありますか？それとも、彼らはプロジェクトに不慣れですか？
- 10,000個すべてを納期前に修正する必要がありますか？
- チームが使用するバグトラッカーソフトウェアはありますか？もしそうなら、何？
- 既知のバグはどのように追跡されますか？優先度、重大度が記載されていますか？それらは機能ごとにグループ化/タグ付けされていますか？
- ソフトウェアで現在使用されている自動テストはありますか？もしそうなら、ユニットテスト、統合テスト、UIテストはいくつありますか？または、4〜5週間の時間枠ですべての自動テスト/フレームワークを最初から作成する必要がありますか？
- 開発者はどのくらいのテストを担当していますか？彼らはユニット/統合テストを作成していますか？
- 10,000個のバグはUIのバグですか？または、単体テスト、統合テスト、UIテストを使用してテストできるバグの組み合わせですか？
- テストにはどのデバイスを使用する必要がありますか？
- ユーザーと利害関係者を満足させるために到達する必要のある品質のレベルはどれくらいですか？利害関係者は品質をどのように認識していますか？
- 利害関係者はプロジェクトの立ち上げの成功をどのように判断しますか？
- 完了のチーム定義は何ですか？
- プロジェクトのリリース後、チームはバグを修正する時間がありますか？それとも次のプロジェクトに移りますか？時間が取れたらどれくらいの時間がありますか？
- チームはアジャイルSDLCまたはウォーターフォールSDLCを使用していますか？
よく考えられた答えを提供するために必要な説明を得るために尋ねることができる質問は無数にあります。
そして、上記の詳細な会話から、インタビュアーは、手動テスターを計画に含める方法の詳細を求め続けました。これにより、インタビュアーが探しているものの大きなヒントが得られます。インタビュアーは、このプロジェクトを自分でテストするという全責任を負わせたくないのです。彼らは、シニアレベルのSDET / QAエンジニアとして、ジュニアレベルのテスターのチームをどのように指導/指導するかを知りたがっています。
面接は、質問に答えるだけの尋問ではないことを覚えておいてください。面接は、質問を明確にするのに役立つことなら何でも質問できる会話でなければなりません。