how perform test documentation reviews 6 simple steps qa process
今では、テスターにとって、 ドキュメンテーション 彼の日常生活の不可欠な部分です。作成、レビュー、承認、使用、保守、および配布されるテスト成果物が過負荷になっています。ドキュメントの作成方法、使用方法、誰に送信するかなど、明確なプロセスが常に用意されています。
この記事を通じて、小さいながらも重要なトピックであるレビューに光を当てます。
レビューもテストの一形態です。静的テストとも呼ばれるV＆Vの検証部分です。
学習内容：
- レビューの種類
- ステップ1：基準を定義する
- ステップ2：チェックを実行する
- ステップ3：結果を記録する
- ステップ4：必要な変更を共有、話し合い、実装する
- ステップ5：関連するドキュメントのバージョン管理
- ステップ6：サインオフしてドキュメントを意図したとおりに使用する
- 覚えておくべきポイント
- あなたに
- 推奨読書
レビューの種類
- 自分の作品のレビュー–セルフチェック
- ピアレビュー
- 監督
妥当性確認がテスト手法の半分である場合、妥当性確認はもう一方ですが、ガイドラインが曖昧なことがよくあります。それでは、今すぐ変更しましょう。 STHの記事の一般的な慣習ですか、質問から始めます、何ですか？どうして？どうやって？
何をレビューしますか？
作成されたものはすべてレビューする必要があります。以下は、レビューされた一般的なアーティファクトの一部です。
- テスト計画
- テストシナリオ
- テストテンプレート
- テストケース
- テストデータ
- レポート…など
なぜレビューするのですか？
まったく同じ理由で、ソフトウェアをテストします。 例えば、
- エラーを発見するには
- 完全性を確認するには
- 基準とガイドラインが遵守されているかどうかを確認するために…など。
レビューする方法は？
関係する活動のリストは次のとおりです。
- 基準を定義する–何を探すべきかについてのチェックリストがありますか？
- チェックを実行します
- 結果を記録する
- 必要な変更を共有、話し合い、実装する
- 関連するドキュメントのバージョン管理
- サインオフして、意図したとおりにドキュメントを使用します。
ここで、「方法」セクションの各ステップ、つまり、それを実行するプロセスについて説明します。
（私たちのほとんどのテスターはワードプロセッサが好きではありませんか？私たちにとって、それは私たちがしたくない場合でも、私たちがしなければならないより多くの仕事またはいくつかの高レベルの管理タスクを意味します–のために私たちが知らないコンプライアンスのために。しかし、あなたが思いついたとき、私を信じてください 動作するプロセス なぜそれをしなければならないのかを理解するのに十分簡単です、それは楽しいかもしれません！私と一緒に遊んでください。）
最高のyoutubeからmp3へのコンバーターは何ですか？
私によれば、ピアレビューとスーパーバイザーレビューのプロセスは同じです。なぜなら、スーパーバイザーは、より高い指定にもかかわらずピアでもあるからです。
ステップ1：基準を定義する
＃1） あなたは何を見つけることを期待していますか？ 次のようなものを探すことができます：
- つづりの間違い（ばかげているように聞こえますか？そうは思いません。ある記事で「WebObject」ではなく「WedObject」と書いたことがあります–意味が完全に変わります。ほとんどばかげすぎて真剣に受け止められません。）
- フォーマット/テンプレートコンプライアンス
- 機能範囲と正確性
- 理解のしやすさ
- 従う標準–命名規則、一貫した番号付け…など。
＃二） チェックリストを作成する –チェックリストは非常に用途が広いです。レビューチェックリストのように複雑な場合もあれば、買い物リストのように単純な場合もあります。作るのに少し時間がかかるだけで、一度作ったら、ONまたはOFFをチェックするのと同じくらい簡単です。
＃3） 結果を報告する方法は？ –都合のよいもの、できれば記録および追跡できる方法を選択します。
- これは、テストケースを含むExcelシートに列を追加し、本来あるべきものではないときに赤で何かを書くのと同じくらい簡単な場合があります。
- 口コミになることができます
- メールのリスト
ステップ2：チェックを実行する
＃1） 以前に作成したチェックリストを使用して、ドキュメントを確認し、フィードバックを提供します。
ステップ3：結果を記録する
＃1） ここでも、ステップ1で決定した方法を使用して、結果を記録して報告します。
＃二） コメントや変更の提案を報告するときは、欠陥を報告するのと同じように扱ってください。何も見逃さないでください。詳細に説明してください。
＃1） 自分の仕事が正しくない、または不完全であると言われるのを好む人は誰もいません。したがって、負帰還を提供するときは、次のガイドラインに留意してください。
- 建設的な批判を提供する–人を批判するのではなく、この製品の欠陥を指摘することを忘れないでください
- 競争力をつけないでください。彼がテストケースについて30件のレビューコメントを提出したからといって、それを打ち負かそうとしないでください。
- コメントを支持する理由を挙げてください
＃二） サインオフを取得します。
＃3） 変更を加えます
ステップ5：関連するドキュメントのバージョン管理
＃1） 古いバージョンのドキュメントは削除しないでください。それらに適切な名前を付け、一元化されたプロジェクトフォルダに保存します。結局のところ、これは私たちのすべての仕事の証拠です
ステップ6：サインオフしてドキュメントを意図したとおりに使用する
＃1） すべての変更が組み込まれ、バージョンが保存されたら、レビュープロセスにサインオフを与え、ドキュメントの作成目的でのドキュメントの使用に進みます。
＃二） もう1つの質問は、変更が行われた後に再確認するかどうかです。このプロセスは何回続きますか–作業-レビュー-修正-そして再びレビューされますか？ときまで？
いいえ、レビューを何度も繰り返す必要はありません。これは、テストエイドが正しく作成されているかどうかの検証に焦点を当てた品質管理活動です。いつものように、欠陥のないドキュメントは不可能です。したがって、妥当なレベルのレビュー-ピアによる1回のレビューは許容されます。
これで完了です。このプロセスは簡単ではありませんか？
覚えておくべきポイント
- すべてのプロジェクトがこの正式なレビュー方法に従う必要はありませんが、非公式な方法が実施されている場合でも、これらの手順は期待を設定し、ガイドするのに役立ちます。
- テストドキュメント タイムラインの見積もりは通常、ドキュメントの作成と確認に必要な時間に基づいているため、常に認識しているとは限りませんが、ドキュメントに組み込まれています。
- レビューは、手動テストチームに限定されたプロセスではありません。自動化チームは、コードのウォークスルー、設計レビューなども実行します。
最後に、これはテストケースの典型的なレビューコメントドキュメントがどのように見えるかです。コメントは赤で表示されています。必ずしも実際のコメントではありませんが、それがどのように行われるかを示すものです。
サンプルテストケースレビュードキュメント： （クリックすると画像が拡大します）
あなたに
それで、あなたはまだプロセスが気が遠くなると感じますか？プロジェクトでレビューを行いますか？以下にあなたの経験、挑戦、質問、コメントを共有してください。
Windows10でepsファイルを開く方法
著者について： これはSwatiSeelaによる投稿です– 9年以上の業界経験を持つ手動および自動化テストの専門家 。 彼女はまた、ソフトウェアテストトレーニングコースのインストラクターでもあります。
専門家からソフトウェアテストを学びたい場合は、次のバッチのスケジュールを確認してください。 このページのこのコースの詳細 。
推奨読書
- アジャイルプロセスへの移行を成功させるためのアジャイルテストマインドセットの開発に向けた4つのステップ
- ソフトウェア製品テストの実行方法-詳細なプロセスと方法と例
- ビジネスプロセステスト（BPT）-BPTを使用してテストプロセスを簡素化および高速化する方法
- Specflow機能ファイルのPicklesを使用してリビングドキュメントを生成する
- ソフトウェアテストドキュメントガイド（なぜそれが重要なのか）
- QAテスターがリリースおよび展開管理プロセスについて知っておくべきこと
- 簡単な例を使用したUnixのGrepコマンド
- テストレポートをさらに改善するための6つの最も重要なステップ