how reproduce non reproducible defect
の世界で ソフトウェアテスト 、一度見つかった欠陥は一貫して再現可能であるため、テスターは確信を持って報告でき、開発者は明確に修正でき、QAチームは自信を持って閉じることができます。
「スクリーンショットを撮る」ボタンへのパスは次のうちどれですか？
ただし、このプロセスには独自の課題が伴う場合があります。この記事では、欠陥再現の暗い領域を明らかにしようとしています。
まず第一に、「 欠陥の再現 「？
特定の一連のステップが、予想される動作の逸脱が観察されるポイントにテスターを着陸させた場合、「再現するステップ」は、この正確な一連のステップの記録を含む欠陥フィールドです。同じ問題が発生した場合、これらの手順を実行するたびに、これは再現可能な欠陥と呼ばれます。
使用されたデータなど、より多くの証拠を再現する手順に加えて、 スクリーンショット またはスクリーン録画されたビデオも提供できます。この情報に一貫性がないか正しくないことが判明した場合、バグは割引され、それ以上の解決なしに無効としてマークされる可能性があります。
続きを読む => 「無効なバグ」ラベルなしですべてのバグを解決するにはどうすればよいですか？
したがって、「再現する手順」は重要であり、欠陥レポートのこの部分を作成する際に留意すべき点は次のとおりです。
学習内容：
欠陥「再現手順」の書き方：
- 正確に
- 簡単に参照できるように、テスト中に使用された正確なデータを含めます
- 手順は正確な順序である必要があります
- 該当する場合は、前提条件に言及してください
- 複合ステップを記述しないでください。例えば：シナリオでユーザーがMicrosoft Wordからドキュメントを保存する必要がある場合は、「(ファイル)メニューを開き、(保存)オプションをクリックしてください」と記述する必要があります。
- すべてのCookieとキャッシュメモリをクリアして、新しいシステムで再現するための手順を常に再確認してください。
- 文章が短く、明確であることを確認してください
誤って書かれた「再現手順」は、欠陥の有効性を危うくするだけでなく、明確に言及されていないことに関する説明と回答を探すという点で多くの時間を浪費する可能性があります。
また、読んでください => 良い欠陥レポートの書き方
YouTubeからビデオとオーディオをダウンロードする
欠陥を再現することがなぜそれほど重要なのですか？
それでは、「欠陥を再現することがなぜそれほど重要なのか」を調べてみましょう。
技術的に言えば、 バグを再現することはできません。修正することはできません。 。
以下は、欠陥が修正されるかどうかを決定するいくつかの要因です。
- 欠陥レポートの詳細で完全な情報
- 開発者が特定の条件下での欠陥の実際の発生を理解できる場合はどうなりますか？
- テスターによって欠陥が報告された開発者が環境、ツール、および正確なアプリケーションバージョンを利用できる場合はどうなりますか？
「再現性のない」バグ/欠陥とは何ですか？
すべてのテスターは、次の状況を経験している必要があります。
- 一日中問題を観察し、その欠陥を報告した日の終わりに、それはもはや再現可能ではないことがわかります。
- 問題を断続的に観察します。たとえば、新しいユーザーがカートに商品を追加できないとします。これは10回のうち6回発生します。
- アプリケーションを再起動したときにのみ問題が発生します。
これらすべての場合において、正確な状態を判断して正しく報告することは困難です。このような問題/欠陥の調査には多くの時間がかかります。これらのタイプの問題は、エンドユーザー/顧客も観察する可能性があるため、無視することはできません。
欠陥を再現する方法は？
役立つ可能性のあるいくつかのことは次のとおりです。
- すべてのキャッシュをクリアし、 クッキー シナリオの実行中。
- すべてのステップを監視して観察します。
- 同様のバグやパターンを探すことが、バグの再現に役立つ場合があります。パターンが理解されていれば、シナリオを特定しやすくなります。
- シナリオを簡単に複製するには、すべてのステップとその他の要素（テストデータ、環境、システム設定、スクリーンショット、サーバーログなど）を書き留めておくことをお勧めします。
- さらに数回確認して、欠陥の発生を判別します。問題の1回の発生に基づいて、それ以上信頼して報告しないでください。
- 忍耐を持ってテストすることが重要な要素です。これには多くの時間がかかる可能性があります。
さらに：
androidに保存されているapkファイルはどこにありますか
- あなたがいるときでさえ 探索的テストの実行 、すべての構成とシステム設定を知っていることを確認してください。
- 創造性を駆使してさまざまな方法でアプリケーションを探索し、いくつかの珍しいシナリオを試すことをお勧めします。この場合でも、ランダムな手順を実行するのではなく、論理的な順序に従うことをお勧めします。
- 問題が確認されたら、異なるブラウザ/オペレーティングシステムの組み合わせ、異なるデバイス（サポートされている）で同じ問題を確認することをお勧めします。これは、問題がシステム固有かブラウザ固有/デバイス固有かを判断するのに役立ちます。
- さまざまな種類の問題とその発生に関する新しいトレンドやフォーラムで最新情報を入手してください。これらは、システム固有、ブラウザ固有、製品固有、外部の問題などを区別するのに役立ちます。
- 一度発生した問題を再現しようとする代わりに、座って実行した手順を分析すると、解決策を見つけるのに役立つ場合があります。
- 他のチームメンバーと話し合う またはマネージャーが役立つ場合があります。また、ことわざがあります、 経験が重要 。
- スクリーンショットやビデオとは別に、画面を共有することも、開発者に問題を説明するためのオプションと見なすことができます。
- 問題の発生を確認するために、問題を複数回再現します。このような場合、テストに自信があり、開発者の質問や懸念に答えることができます。
結論：
全体的な議論から、バグを検証して修正するためには、「バグを再現する」ことが非常に重要であると明確に結論付けることができます。バグが再現できない場合、その特定のバグ/欠陥を見つけ、分析し、報告するために使用されるテスト作業は完全に無駄です。
バグを理解して再現するには、「再現手順」、バグが発生した状態と環境を詳細かつ適切に説明することが不可欠です。再現性のない欠陥を修正することは可能ですが、非常に時間がかかるだけでなく、非常に困難な作業になる可能性があります。もう1つの最も重要な要素は、適切な通信です。これがないと、有効なバグを無効にすることができます。
したがって、それだけの価値のある欠陥を見つけるためにテスト作業を行うには、上記のことが役立ちます。