テストデータの管理は、自動化における古くからの問題の一つです。自動化の初期段階（Excelでのテストスクリプト、マクロ、古いQTP）では、データがしばしばテストの著者の「頭の中」にあったり、コードの中に直接書かれていたりしました。CI/CDと並行実行の発展により、新しい戦略が必要になりました：複数のテストが同時に同じデータを使用する際の競合を回避し、結果の再現性を確保するにはどうすればよいか。
問題：共有されたテストデータは、迅速に競合を引き起こし、予測不可能な結果をもたらします。テストは不安定になり、デバッグが困難になり、データの断片がデータベースを「混乱させ」、複数のスレッドでの実行がエラー（データレース）を引き起こします。
解決策 — 「各テスト用データ」の戦略の導入：
主な特徴：
プロダクションデータをテストデータとして使用するのは普通ですか？
いいえ！これはセキュリティやプライバシーにリスクがあり、データの変動性によってテストが予測不可能になります。
データのクリーンアップにsetUpとtearDownを使うのは十分ですか？
必ずしもそうではありません。これはリスクを最小限に抑えるのに役立ちますが、並行実行が行われると、データがグローバルである場合やユニーク化されていない場合、テストが衝突する可能性があります。
同じテストデータをスモークテストと回帰テストの両方で使用できますか？
いいえ、可能であれば。その方が良いです。スモークテストは最大限独立しているべきで、回帰テストはデータの包括的な準備が必要です。そうしないと、false positivesが発生する可能性があります。
会社には、すべての自動テストで使用される1つの共有ログインといくつかの「共有」ユーザーと注文がありました。並行実行により、テストが互いに注文を消去したり、複数のスレッドで1つの注文のステータスを変更したりするという問題が発生しました。
利点：
欠点：
テストデータファクトリーが導入され、各シナリオのテスト実行前にユニークな注文とユーザーが作成され、テスト完了後に削除され、そのサンドボックス環境が再初期化されました。
利点：
欠点：