3 worst defect reporting habits
欠陥は深刻なビジネスであり、小さな間違いは高額になる可能性があります。
あなたは欠陥を見つけたときに何をすべきかを知っています。あなたはそれを報告します。どちらかで 欠陥トラッカー /欠陥管理ツールまたはExcelシート。基本的な原則は、両方の方法で同じです。
欠陥管理ツールは、より良いレポートを保証するものではありません。 一日を節約するのは良い習慣です。
善を評価するには、そうでないものを認識しなければなりません。
学習内容：
3つの最悪の欠陥報告の習慣とそれらを破る方法
ここに行きます：
＃1）怠惰
あなたができる最善を尽くすために時間をかけない。
これは 欠陥追跡プロセス ほとんどのチームでフォローされています：
（（注意–画像をクリックすると拡大表示されます）
ご覧のとおり、テストリードは欠陥をQAチームから送信する前に確認します。
このレビューには、以下の確認が含まれます。
- 妥当性-それはバグですか？
- 完全性-タイトル、ステップ、データ、スクリーンショットなど。
- 重複
- 再現可能かどうか…など。
QAリードを100％徹底することは不可能であることを直接知っています。
それで、「私は問題を私が望む方法で報告します。 QAリードは再確認できます。彼は欠陥が有効/完全であるかどうかを判断できます」は、QAチームとあなたの信頼性の終わりです。
一部のクライアントには、許容可能な無効な欠陥の数に関するSLAがあることをご存知ですか？数を超えると、報告された無効な欠陥ごとに請負業者にペナルティを課し始めますか？
療法： デューデリジェンスを行い、成果物に責任を負います。十分な情報がないために欠陥が戻ってきたのですか、それともバグではないのですか？それは必ずしも開発チームのせいではないかもしれません。彼らがアプリケーションの問題を所有したくないというわけではありません。それは本物のQAチームの混乱かもしれません。それを起こさせないでください。
＃2）急いで
でこれをやってみましょう例。
以下はのスクリーンショットです OpenEMRの 作成-患者画面。オープンソースの病院管理システムです。
この画面では、ユーザーはカレンダー機能を使用して患者の生年月日を入力できます。エントリをカレンダーからの選択に制限することはありません。つまり、カレンダーから「1983年3月31日」と言うように生年月日を選択できます。後で「1983年2月31日」に変更します。
なぜ2月31日？実装する エラー推測 フィールドでネガティブデータを試してください。これがテストの要点ですよね？
完了したら、「患者の作成」をクリックします。日付が無効であるため、システムがエラーを表示し、患者を作成しないことを期待しています。しかし、それは起こりません。以下のように患者を作成します。
下の画面の(年齢)フィールドと(生年月日)フィールドに注意してください。
テストするときは、これを数回試して、次のことを決定することができます。
- バグです。
- 再現可能です。
- 重複ではありません（確認するにはチームに確認してください）
- あなたは問題の正確な説明を知っています
- また、あなたはそれを実現する正確なステップを知っています。
原材料が揃ったので、準備は完了です。
あなたはそれを報告し始めます。欠陥の重大度の割り当ては必須の手順であり、チームは次のようなものを使用している可能性があります。 参考のために次の表：
| 重大度 | 影響 |
|---|---|
| 1（クリティカル） | •このバグは、システムをクラッシュさせたり、ファイルの破損を引き起こしたり、潜在的なデータ損失を引き起こしたりするほど重大です。 •オペレーティングシステムへの異常な復帰を引き起こします（クラッシュまたはシステム障害メッセージが表示されます）。 •アプリケーションがハングし、システムを再起動する必要があります。 |
| 2（高） | •回避策により、重要なプログラム機能が不足します。 |
| 3（中） | •このバグは、システムの品質を低下させます。ただし、たとえば別の画面を介して、目的の機能を実現するためのインテリジェントな回避策があります。 •このバグにより、製品の他の領域をテストできなくなります。ただし、他の領域は個別にテストできます。 |
| 4（低） | •製品の使用への影響が最小限である、不十分または不明確なエラーメッセージがあります。 |
| 5（化粧品） | •製品の使用に影響を与えない、不十分または不明確なエラーメッセージがあります。 |
この欠陥は、システムのクラッシュや重要な機能のブロック、またはアプリケーションの他の領域のテストの妨げにはならないため、「低」を選択する可能性があります。
よろしいですか？
違う。患者のデータから、すべての予防接種と他のリマインダーは遅れています。これは正しい場合とそうでない場合があります。また、患者の年齢によって、小児科医と一般医のどちらに診てもらうかなどが決まります。
それは、私たちが知らないかもしれない薬や他の多くの治療分野の投与量に影響を与えます。
だから、私は「高」で行くつもりです。病院のスタッフが患者の生年月日を間違って入力する可能性は低いと私は同意します。しかし、それが問題をいつ修正するかの優先順位に影響を与える要因としましょう。
テスターとしての私の仕事は、問題の深刻さをできる限り伝えることです。
療法： 急いで報告しないでください。問題の影響をさまざまな角度から理解していることを100％確信してください。これは、テスターが提供できる最高の付加価値です。 「何かがうまくいかない」と言っているだけではありません。また、「これが機能しない場合は、次のようになります」と言っています。たくさんの違いですね。
＃3）創造性の欠如
テスターには、ソフトウェアを改善するための提案をする素晴らしい機会があります。
あなたの中で 欠陥管理ツール また、「拡張提案」タイプの欠陥を送信することもできます。これはあなたが創造的になることができるところです。
療法： 箱の外で考えてください。特定の機能に「すごい」要素が欠けていると思い、それを組み込む方法を知っている場合は、そのアイデアを提案してください。最悪の場合、拒否される可能性があり、それで問題ありません。重要なのは試してみることです。
また、この超大国は注意して使用してください。 「バナーの色が嫌いです。変更してください」などのコメントはしないでください。
ここに良いです例私が出くわした拡張提案の： 自動車販売店サイトの「ディーラーへのメール」を「ディーラーとチャット」オプションに置き換えます。より多くのトラフィックを売上に変換すると予測されています。
そんなにクリエイティブだったらいいのに！しかし、多分私たちは皆それに向かって取り組むことができます。
これがボーナスです。これらの悪い習慣を取り除くためのチェックリスト：
1.1。 私のタイトルは問題を明確かつ簡潔に伝えていますか？
例えば：「患者の作成が機能していない」というタイトルは適切ではありません。 「すべての入力フィールドに正しい値が含まれていても、患者の作成に失敗します」です。
2.2。 再現性はどのくらいですか？
言い換えれば、それは常に起こりますか？問題を繰り返す正確な手順の順序を知っていますか？
3.3。 この問題はプラットフォーム、ブラウザ、またはユーザー固有ですか？
四。 手順が完了し、問題が発生しましたか？
5 。 スクリーンショットは含まれていますか？
6.6。 特定の領域を強調するためにスクリーンショットに注釈を付ける必要がありますか？
7。 添付されている画像ファイルの名前はわかりやすいですか？
「Untitled.jpg」のようなものは使用しないでください。わかりやすい名前を付けます。
8.8。 テストデータを含めましたか？
例えば：承認資格情報を必要とする管理モジュールの欠陥については、それらを含めてください。開発チームは、QA環境にアクセスできる場合とできない場合があります。それほど基本的なことについての遅延やフォローアップは必要ありません。
9.9。 欠陥を補強するために他の詳細を提供できますか？
（（例：FRDへの参照またはクライアントとの会話など）
10.10。 さまざまな観点から問題がどれほど深刻かを理解していますか？
十一。 問題の根本原因を知っていますか？ はいの場合、証拠（おそらくログファイル）があり、それを含めることはできますか？あなたはこれを常に知っているとは限らないか、これを知る必要があるかもしれないことに注意してください。ただし、そうする場合でも、それを含めることは問題ありません。
12.12。 欠陥レポートには、文法、形式、スペル、句読点の問題がありませんか？
XboxOne用VRヘッドセット
13.13。 製品を改善する方法を知っていますか？
これには時間がかかると思いますか？まあ、それが習慣になると、それはもうありません。
より良い応援 欠陥報告 ルーチン！
著者について： この記事はSTHチームメンバーのスワティによって書かれました。
以下に質問/コメントを投稿してください。