需要分析:
要件分析は製品担当者が策定するもので、単なる文書化ではなく、各機能の詳細や各ボタンの位置などを詳細化し、少し大きめの要件やより複雑な要件をモデル化します。
見直しが必要:
ここでは、参加するすべてのプロジェクト担当者、開発者、テスター、QA 担当者と呼ばれます。テスターが要件を出し、開発者が機能実現の計画や実現可能性を検討しますが、当然開発責任者も参加する必要があります。テスターは主に、要件に従ってユースケースを作成できるように要件を理解することに疑問を持ちます。QA担当者はソフトウェアの品質を最終的に検証するので、要件を理解する必要もあります
開発者はスケジュールを書きます。
開発者の要件は、必要な機能ポイントに従ってスケジュールされます。次に、開発計画をテスターに渡します。
テスト計画のスケジュール:
開発計画に従って、テスターはテストの特定のテスト時間、つまり開発機能が完了した後の時間に数回のテストを実行します。次に、プロジェクトの開発およびテスト計画をさまざまな部門の責任者およびプロジェクトに関与するすべての担当者に送信します。
テストケースを書きます。
根据详细的需求分档，开始进行用例的编写。
ユースケースのレビュー:
在用例进行评审之间，先以邮件形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节。
その後、テスターグループがユースケースレビューを実施し、開発者がユースケースと実際の機能が一致しない部分をチェックし、プロダクト担当者がユースケースを通じて機能の具体的な実現を把握するなどしていきます。
ベースラインをコミット:
开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试人员进行基线。
具体的なテストプロセス:
开发人员对于基到测试线的功能进行测式，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复，然后，准备第二轮基。
テスターは最初のテスト ラウンドを完了した後、テストの結論を作成し、関連する担当者に送信する必要があります。次に、ベースラインは第 2 ラウンドでテストされ、第 1 ラウンドで見つかった問題の退行に焦点が当てられます。
テストに合格しました:
新たな問題が見つからなくなるまで、一時的に解決できない問題や緊急ではない問題がなくなるまで、2、3、または 4 回のテストを繰り返します。上司に確認されれば通過可能です。テストレポートと合格計画を作成します。
受け入れ計画は QA によって検証されます。現在の会社のプロセスでは、テストとQAが分離されており、テスターは機能が正常に動作するかどうかに重点を置いています。QA は、エンド ユーザーの品質だけでなく、プロセス全体の品質にも関心を持ちます。QAとテストを区別していない企業もありますが、その場合はテストの要件が高く、機能だけでなく全体のプロセスや品質にも配慮する必要があります。
---The End---
如果对你有帮助请关注哦！