1 はじめに
BUG と比較すると、正しく動作しないプログラムや期待と一致しないプログラムが BUG であることは誰もが知っていますが、ここで BUG をテスターの観点から見てみましょう。
2. BUGの記述・作成方法
テスターは、開発者のコードをテストして、開発者が見落としている可能性のある問題を見つけ出し、その問題を開発者に報告する必要があります。バグを明確かつ簡潔に説明するには、多くのことが関係します。これは、単に単純なステートメントではありません
。 BUG が発生しました。
対象となる BUG の説明は次の部分に分かれています。
- 問題が見つかったバージョン: ほとんどのソフトウェアには多くのバージョンがあるはずです。テスターは、対応するバージョンのコードを取得して障害を再現するために、問題に対応するバージョンを知る必要があります。
- 問題が発生する環境：環境はハードウェア環境とソフトウェア環境に分かれており、WEBプロジェクトの場合はブラウザのバージョンやクライアントのOSなども記載する必要があります。 APP プロジェクトでは、モデル、解像度、オペレーティング システムなどを説明する必要があります。詳細な環境の説明は、障害の場所に役立ちます。
- エラーを再現する手順: 問題を再現するための最小限の手順を説明します。
- 予想される動作の説明: ユーザーの観点から開発者をガイドするのは正しいです。
- エラー問題の説明：BUG発生時のシーン
BUG の説明は、上記の部分のみを含めることを意味するのではなく、BUG がフロントエンドの問題であるかバックエンドの問題であるか、BUG のレベルなど、他の側面も説明することもできます。 。
BUG を記述できると、BUG の作成が簡単になります。
3.バグレベル
BUG にはさまざまな重大度レベルがあり、BUG の定義は企業ごとに異なるため、レベルを定義する前に企業の仕様を確認する必要があります。
例えば：
- ブロッカー (クラッシュ) : 開発やテストを妨げる問題。システムのクラッシュ、クラッシュ、無限ループを引き起こし、その結果、データベース データの損失、データベースとの接続エラー、主要な機能の損失、基本モジュールの欠如が発生します。例: コード エラー、無限ループ、データベースのデッドロック、重要な第 1 レベルのメニュー機能が使用できない、など (この問題がテストで発生することはほとんどありません。発生した場合は、現在のバージョンのテストを直ちに終了する必要があります)。
- クリティカル (深刻) : システムの主要な機能が部分的に失われ、データベースの保存と呼び出しが不正に行われ、ユーザー データが失われ、第 1 レベルの機能メニューが使用できなくなりますが、他の機能のテストには影響しません。機能設計が要件を大幅に満たしていない、モジュールを開始または呼び出すことができない、プログラムが再起動する、自動的に終了する、関連プログラム間の呼び出しの競合、セキュリティの問題、安定性など。例：ソフトウェアにデータを保存した後にデータベースに表示されるエラー、ユーザーが必要とする機能の不足、プログラムインターフェースのエラー、数値計算統計エラーなど。
- Major (General) : 機能は完全には実装されていませんが、使用には影響しません。また、機能メニューには欠陥がありますが、システムの安定性には影響しません。例: 長い操作時間、長いクエリ時間、間違った形式、間違った境界条件、削除の確認ボックスがない、データベース テーブル内のフィールドが多すぎる、など (この問題は実際のテストで最も多く存在します)
- マイナー (マイナー) : インターフェイス、パフォーマンスの欠陥、提案、操作機能の実行に影響を与えない問題、パフォーマンスを最適化できる解決策など。例: タイプミス、不規則なインターフェイス形式、ページの重複表示、表示すべきでないものの非表示、不明瞭な説明、プロンプトの欠落、不均等なテキスト配置、不正なカーソル位置、ユーザー エクスペリエンスの低下、パフォーマンスを最適化できる解決策など (多数あります)テストの初期段階ではこのような問題が発生するため優先度は低くなりますが、テストの後期では問題が少なく、時間内に対処する必要があります）
4. バグのライフサイクル
テストを実行する過程で、対応する BUG が存在する場合、テスターは対応する BUG 管理プラットフォーム上で BUG を作成する必要がありますが、
各企業および各ツールでのバグ ライフ サイクルの定義には一貫性がありません。
例:
- 新規: テスターがバグを作成する
- Open：開発者がBUGかどうかを確認し、BUGであればステータスがOpenに変更されます
- 拒否: バグではないとみなされる場合、変更は拒否されます。
- 修正済み: 開発者がバグを修正すると、ステータスが修正済みに変更されます。
- 遅延: BUG を確認した後、BUG のレベルが高くない場合、または開発者がすぐに BUG を修正できない場合、ステータスは遅延に変更されます。
- Closed: BUG は修復が完了したことを確認し、テスターは BUG を Closed に変更します。
- 再開: 開発者はバグを修正しましたが、バグは修正されておらず、バグのステータスが再開に変更されました。
5. 開発に関して紛争が生じた場合の対処方法
結局のところ、テスターは開発者のコードをテストしてバグを発生させるために最善を尽くさなければなりません。適切に処理されないと、開発との紛争が発生しやすくなります。紛争が生じた場合はどうすればよいでしょうか? この問題については、次のようになります
。我们要坚持"对事不对人".
- 「批判的思考」を持ち、説明したバグが十分に明確でないかどうかなどを考えてください。
- 開発者が BUG のレベルを認識していない場合は、BUG のレベルが正当であることを確認する必要があります。
- BUGを提案すると開発者の負担が増え、小さな問題が解決しない可能性も考えられますが、このとき開発者は「あなたがユーザーだったら、こんな状況でも受け入れられますか？」という共感を誘導することができます。
- BUGの提案だけでなく、解決策の提案も行います
- それが本当にバグであり、現時点でフレンドリーなコミュニケーションによって問題を解決できない場合は、バグレビューが開催されます。
上記の回答は参考用です。より良いアイデアがあれば、追加することもできます。
補足: BUG レビューに参加する必要がある人には、プロダクト マネージャー、開発担当者、テスト担当者などが含まれます。議論の内容は、大きく 2 つの部分に分かれています。1. BUG を解決する方法 2. 同様の問題が発生しないようにする方法。
ご覧いただきありがとうございます! この記事があなたのお役に立てれば幸いです!
コラム: 「ソフトウェア テスト」は随時更新中です、購読を歓迎します!
「励まし、一緒に働きたい!」
