例による BDD/ATTD/仕様の専門家のアドバイスが必要です。（長いエッセイで申し訳ありません。問題をより少ない言葉で表現する方法がわかりませんでした）
問題の説明
私たちは約1年間、中規模のプロジェクトに取り組んできました。チームは、受け入れテスト (詳細なテスト ケースの形式で記述) によって駆動されるフロー ベースのプロセスを使用しています。
そして今、要件が進化するにつれて、これらのテストの保守性に問題が生じ始めました。
- それらは（非常に）読みにくく、製品仕様として機能しないことは間違いありません
- テストが実装の詳細と結びつきすぎているため、要件のわずかな変更により、何日ものリファクタリングが必要になります
解決方法
この問題を解決するために、テストを実行可能な仕様に変換します。私が読んだすべての本/記事 (例: Gojko Adzic による仕様書) では、ビジネスを満たすために製品が何をすべきかではなく、製品がどのように実装されるべきかを示す低レベルの詳細で仕様を過負荷にしないことを推奨しています。期待。
仕様がより読みやすく、保守しやすく、過度に指定されていない場合、ソフトウェア設計ではなくビジネス目標を反映する可能性が高いため、これは妥当と思われます。ただし、これらの低レベルの詳細を簡単に破棄することはできません。ビジネス ユーザーから明示的に要求されることはありませんが、予想されることには変わりありません。たとえば、ユーザーが「プロセス ボタン」を押した場合は、処理が完了するまで無効にして「キャンセル ボタン」を有効にしたほうがよいでしょう。このような詳細は仕様では不要に思えますが、アプリが顧客に受け入れられるために必要です。
私たちはあらゆるレベルで (A)TDD を使用しており、テストに合格するためだけにコードを書くことに慣れています。詳細なテストの代わりに、より抽象的な実行可能な仕様があり、それらの低レベルの詳細をどこに置くべきかを単純に理解していません.
質問
では、誰かが仕様に到達できない低レベルの要件を管理するための優れた方法を提案できますか?