this scenario explains how important it is document frequently encountered errors
ソフトウェアエラーは一度だけ発生し、修正されると二度と再発しないと思いますか？エラーの約30％が再発しているように感じます。
この記事では、頻繁に発生するエラーのいくつかを文書化することがいかに重要であるかについて説明したいと思います。
以下に、いくつかあります 問題が見られる一般的な領域 そしてそれらを文書化するためのテンプレート。
お役に立てば幸いです。
画像 ソース
シナリオ＃1
コードがデプロイされ、QAの準備が整います。テスターのジョンは、テストケースの準備ができています。テストの途中で、彼は問題に遭遇します。彼はそれが数回前に気づいたと感じていますが、ジョンはそれを解決する方法を知りませんでした。
ジョンとシェリルの両方が、以前に同じエラーを見て、以前にそれを解決したスミスを探しに行きました。残念ながら、スミスはその日休暇をとっていました。
ジョンは今何をすべきですか？スミスが不在の場合でも、ジョンはスミスに連絡して解決策を見つけるようにすべきですか？
したがって、環境問題が複数のリリースにわたって繰り返し見られる場合、 詳細を文書化することをお勧めします 共有場所に配置します。これにより、1人の個人への依存がなくなり、これが発生したときにすべてのチームメンバーが自分で解決策を見つけるのに役立ちます。
シナリオ＃2
Johnは新しいリリースをテストしていて、既知のエラーに再び遭遇します。今回、彼は過去のリリースの1つで欠陥が作成されたことを知っています。しかし、問題は、「欠陥番号やその他の関連する詳細をどのように見つけるか」です。
この場合も、ジョンに何が役立つと思いますか？
これらは可能性です。
しかし、私の意見では、そのような問題が別の領域で十分に文書化され、チームと共有されている場合、それは付加価値をもたらし、時間を節約します。
学習内容：
エラーが頻繁に発生する領域の一部：
1）パラメータファイル – Informaticaツールの使用経験に基づいて、多くの場合、paramファイルが誤ったDB接続を指していることに気付きました。同じ問題が何度も発生しています。主な理由は、接続が開発者とQAの間で共有されていたためです。そのため、エラーを回避するために、必要に応じてparamファイルを常に更新する必要がありました。
2）間違ったDBを指すURL
3）アクセスの問題– DBへのアクセス許可が不十分または不正確な場合、ユーザーは問題に遭遇します。この場合、実行する手順または連絡する人の概要を示すドキュメントが非常に役立ちます。
4）テストデータの問題– データの形式や値が正しくないと、問題が発生することがよくあります。
5）DBの問題– DB接続のタイムアウトは、そのような一般的な問題の1つです。一部のダウンタイムは一時的で計画的であり、場合によってはDBAの支援が必要になることがあります。計画的なメンテナンスについては事前にユーザーに通知されますが、一時的なエラーと解決のために、テスターは間違いなく必要です
最も繰り返されるエラーは一般的に 環境問題 。
しかしながら、 コードの問題 無視することはできません。上記の説明は一般的なものであり、コードの問題はアプリケーション、フレームワーク、プログラミング言語などに固有であるため、コードの問題は含まれていません。
品質保証と品質管理
欠陥の小さな領域も データ入力または人間の使用ミス s 。
ダウンロード頻繁に発生するエラーを追跡するためのテンプレート
Word形式
=> エラー追跡テンプレートのダウンロード（世界）
Excel形式
=> エラー追跡テンプレートのダウンロード（Excel）
頻繁に発生するエラーを文書化する利点
1）依存関係を排除します –シナリオ1では、ジョンは解決のためにスミスに依存していました。ジョンが参照するための文書があったとしても、そうではありませんでした。
2）より速いターンアラウンド– シナリオ2を取ります。高頻度の問題に関する専用のドキュメントがあれば、テスターはすでにログに記録された欠陥のリスト全体を調べる必要はありません。
3）新しいチームメンバーが自給自足できるように支援します
4）ヒューマンエラーの解決を支援します
結論
より頻繁な問題を文書化することは、すばらしい参照と付加価値をもたらすので、間違いなく有益だと思います。
テストの実行中に文書化するのは面倒になるかもしれませんが、ベストプラクティスとして、実行中に大まかなメモを取り、後で共有文書に要約して更新することができます。