開発では、通常、テストする予定のデータ、シナリオ、および実行手順を文書化する独自のテストスクリプトを使用します。これは私の開発テスト計画です。機能がTestに展開されると、テスターは独自に作成したテストスクリプトを使用してテストします。UATでは、ビジネスユーザーは独自のテスト計画を使用してテストします。
振り返ってみると、デベロッパーテストではブラックボックステストとホワイトボックステストが混在し、テスターやビジネスユーザーはブラックボックステストに重点を置いているため、より良いカバレッジが得られるようです。しかし一方で、これはステージごとにのみ実行される別個のテストケース（つまり、テスト担当者がテストステージでのみ実行されると考えるケース）を表示し、開発者がそれを逃したことを望みます。 。
テストスクリプトを最初から統合する価値はありますか？したがって、1つの統一されたテストスクリプトを使用しますか、それともこれを事前に行うのは少し難しいですか？
回答:
まず、QAはテストではありません。QA部門が開発プロセス全体に関与していない場合、それらはQAではなくテストです。QAは、仕事をするとき、品質保証を提供しますが、テストは品質の不足を示しますが、品質の存在を証明できません。つまり、テストはQAが失敗したが、成功したことを示すことができないため、テストとQAは同じ部門であってはなりません。
最善の方法は、各グループに独自のテストを管理させることであると思います。ただし、各チームはできるだけ早くテストを開始する必要があります。つまり、ユーザーが使用できるものがあるとすぐにUATが開始され、テストの対象となる部分の準備が整うとすぐにテストが開始されます。これにより、異なるテストケースが遅れて検出されなくなります。多くの場合、UATとTestは完全な製品で動作し、部分的に完全な出力をテストするためのトレーニングを必要とするため、作業モデルの修正が必要になる場合があります。ワークフローが統制されておらず、開発者の「完了」が完了を意味しない限り、より高価になる可能性があります。
QAは、他の品質尺度とともにこれを監視して、プロセスが目的の品質出力を提供するだけでなく、適切な効率レベルであることを保証する必要があります。
編集：QAへの元の質問参照は削除されたため、この回答は現在OTと表示されています。
最初からUATを使用します。
これは普遍的な基準として機能し、うまく機能すると思います。より小さなコンポーネントに対して開発者またはテスターのみが使用するテストスクリプトがある場合もありますが、テストの方向は常に1つの統合されたターゲットに向けられています。結局のところ、重要なのはUATだけであるため、最初に焦点を合わせることができます。
最初からUATを実行することにも利点があります。それは、顧客の期待とあなた自身のあいまいさを明確にします。
完璧な世界では、開発者はユニットテスト（xUnit）、テスター-自動統合テスト（Selenium）、ビジネスユーザー-受け入れテスト（FIT）を持っている必要があります。彼らはお互いのテストにアクセスできます。