3 strategies dealing with blocker defect
ブロッカーの欠陥は、通常のテスト日に大量のドラマを追加します。
この記事では、テスターがそれらに対処するときに実行できるいくつかの手順について説明します。
親愛なる読者はすでに欠陥の重大度と優先順位を深く理解していると思います。簡単な要約が必要ですか? これをチェックしてください。
さて、ブロッカーの問題に遭遇した場合、テストを完全に停止する必要があることを常に意味しますか?
「はい」の場合もありますが、常にそうとは限りません。いくつかのテスト活動が可能な場合があります。
注目すべきモノのインターネット企業
画像 ソース
以下は、私がテスターとしてのキャリアの中で経験したいくつかの状況です。このプロセスを簡単にするために、以下に概説する手順(後でフローチャートに統合)に従う必要があると強く信じています。
すぐに飛び込みましょう。
ブロッカーの欠陥に遭遇したときに取るべき手順
ステップ1:問題が発生した場合は、時間をかけて根本原因を見つけてください。
テスターとしての私たちの仕事は、 欠陥の報告 。時間が許せば、問題の原因を探る必要があります。常に正確な問題領域を指摘できるとは限りませんが、可能な限りトラブルシューティングを試みてください。追加のコメントとして、同じ詳細を欠陥で更新できます。
私は自分のプロジェクトでこれをたくさん行いました、そしてこれは迅速な修正をもたらしました。 根本原因分析の利点 は:
- 付加価値であるため、これは間違いなく開発者にバグ修正のより良い方向性を提供することができます。
- また、QAテスターは、この問題が自己作成されているかどうか(データ入力または人間の使用上の問題)を認識でき、そうである場合は、テスター自身が修正できます。 QA側から確認せずに、このようなエラーが開発者に報告された場合、 問題ではないと見なされた テスターに否定的な評判をもたらす可能性があります。
したがって、欠陥をログに記録する前に、必ず最後に再確認することをお勧めします。
上記の点を補強する私のプロジェクトからのいくつかのリアルタイムの例はここにあります:
私は、テストで指定された場所にファイルをドロップする必要があるプロジェクトに取り組みました。構成内の名前と一致するように名前を変更します。スケジュールされたジョブは、データファイルを取得し、データをシステムにロードします。その後、データベースとフロントエンドのデータを検証します。
以前は、ジョブは実行されてもデータが読み込まれないという問題が発生していました。調査の結果、テスターがその場所にファイルをドロップするときに名前を変更しなかったことが原因でした。
これは私たちにとってブロッカーでしたが、開発者の注意を必要とするものではありませんでした。私たちは細部に注意を払い、そのような小さな間違いを避けなければなりませんでした。
以下は、いくつかの一般的なカテゴリ、根本原因、および対策です。
#1)ホストファイル 問題 –たとえば、hostsファイルに正しくないパラメーターがあり、問題を引き起こしているとします。この場合、ホストファイルを自分で更新するか、更新してテストの実行を続行するためのアクセス権を持つ誰かに助けを求めることができます。
開発者が調査するように、同じものの欠陥を提起する必要がありますが、回避策を使用して機能テストを続行できます。
注意: QAチームがこれらの変更を行う前に、これらの変更を行っても問題がないかどうかをプロジェクトチームに確認してください。
オブジェクトの配列を作成するjava
#2)構成 –多くの場合、正しい環境を指していないなどの構成の問題や、ブロックの問題であるその他のセットアップの問題に気づきました。このような場合でも、テスターは変更を加えてテストを続行できます。
注意: もう一度、これを行う前に許可を求めてください。
#3)コードの問題– 問題の原因がコードであると思われる場合、テスターは何もできません。ブロッカーの欠陥をログに記録し、修正がテストを続行するのを待ちます。
#4)展開の問題– 不適切な展開はブロッカーの問題のもう1つの一般的な原因であり、これらは健全性テスト中に検出される可能性があります。ここでも、新しいビルドを受け取るまでテストをすぐに停止する必要があります。
#5)環境のダウン– 環境がダウンしている場合は、データベースがサーバーに接続されていないか、Webサイトの場合はURLが機能していないと言います。これらの場合、テスターは欠陥を報告し、システムが稼働するのを待つ以外に多くのことを行うことはできません。
したがって、回避策が存在する場合は、それを使用してテストを続行します。上記の回避策が存在する場合、それを見つける唯一の方法は、根本原因を調査することです。多くの場合、代替手段があるかもしれません。
ステップ2:根本原因を調査するとき、無限ループに陥るのは非常に簡単です。だから、それが一日中そしてすべての努力を消費していないことを確認してください。
ここにいくつかのポインタがあります:
- バランスを見つけて、そこに着いたら停止点を認識します。
- テスターの経験と専門知識は、RCAを成功させるために重要です。ただし、必要に応じて、チームとチームリーダーを参加させることをお勧めします。
- RCAに時間がかかると感じた場合は、まず問題をすぐに報告し、できるだけ多くの情報を提供してください。スクリーンショットは常に役立ちます。
- 必要に応じて、フォローアップします。重大な問題に注意を向けるために、マネージャーまたは開発者に電子メールを送信します。
- 必要な関係者に警告した後、トラブルシューティングを続行します。
ブロッカーの欠陥をすぐに報告する必要がある理由:
- 問題が目を見張るような欠陥である場合は、管理者にすべてのダウンタイムを認識させる必要があります。この情報はクライアントに中継する必要があり、プロジェクト計画の更新(QAタイムライン)、成果物の変更などを要求する場合もあります。
- QA成果物の遅延は、証拠によって裏付けられる必要があります。そのため、一日の終わりまで待つのではなく、できるだけ早くコミュニケーションをとることをお勧めします。
ステップ3:問題の分析と伝達が完了したので、最後のステップに進みます。次は何ですか?
- 問題が1つの機能領域へのアクセスをブロックしている場合は、これが他の領域に影響を与えるかどうかを確認します
- フロントエンドアプリがダウンしている場合は、バックエンド/ミドルウェア/データベースのテストを続行できるかどうかを確認してください。
- テスト実行アクティビティを実行できない場合は、次のことを試してください。 いくつかのドキュメントに取り組む あなたのプロジェクトに関連しています。
- また、試すことができます 自動化の領域を特定する 手動で多くの作業を繰り返す場合。自動化は必ずしもツールを使用する必要はありません。たとえば、レポートの生成は単調な作業です。これは、単純なExcelマクロなどで自動化できる領域の1つです。
- プロジェクトに実装できるオープンソースツールについて知るために時間を費やしてください
- 最後になりましたが、 、イノベーション、現在世界を支配しているマントラに向けて努力してください!
最後に 、ディスカッション全体をまとめたフローチャート!
フローチャート:ブロッカーの欠陥を処理する手順
著者 :この素晴らしい記事は、STHチームメンバーのPriyaRによって書かれました。
ブロッカーの欠陥に遭遇した場合、どのような手順を実行しますか?