スペック債務は、修正しても消えるわけではない。それは移動するだけだ。
問題を解決したからといって、必ずしもそれが消滅するとは限りません。時には、単に別の場所に移動しただけということもあります。
最近、私はプロジェクトの仕様の負債（spec debt）を特定するための監査を行いました。これは、バグやAIの不適切な挙動を引き起こす指示の欠落を指します。私は7つの具体的な項目を修正しました。修正後、テストはパスしました。すべてがグリーン（成功）に見えました。
しかし、負債は消えませんでした。フィーチャーファイル（feature files）からステップ定義（step definitions）へと移動したのです。
これらの項目を修正して学んだことは以下の通りです：
- 精度が重要です。 「レスポンスが速い」と言う代わりに、「注文送信から12秒以内にレスポンスが返ってくる」と言いましょう。これにより、タイミングが明確に定義されます。
- 曖昧さを避けてください。 「2回リトライした」では不明確です。それは合計2回試行したという意味なのか、それとも3回なのか？確実を期すために、「合計の課金リクエストは2回以内」といった表現を使いましょう。
- メカニズムを明示してください。 「在庫が解放される」と言うのは漠然としています。「在庫サービスがアイテム X の解放リクエストを受け取る」のように具体的に指定してください。
- 偽の保証を排除してください。 もし、まだ存在しない機能のためにステップがパスしているのなら、そのステップを削除してください。存在しないフローに対してテストがパスしているのは、嘘と同じです。
- 「正しい」を定義してください。 「正しい」や「適切」といった言葉を、具体的な数値なしに使ってはいけません。「正しい ID が含まれている」ではなく、「order_id 123 が含まれている」のように使いましょう。
これらの問題を見つけるためのフレームワークを作成しました。すべてのシナリオに対して、次の5つの質問を投げかけてみてください：
- このシナリオの責任者は誰か？
- これによって、どのような決定が未決定のまま残されるか？
- ここですべての用語が定義されているか？
- これは振る舞い（behavior）を記述しているのか、それとも実装（implementation）を記述しているのか？
- この記述に欠けているものは何か？
最大の罠は、テキストとコードの間のギャップです。仕様書には完璧で精密な指示を書けるかもしれません。しかし、その背後にあるコードがテストをパスさせるためにショートカット（近道）を使っているなら、負債は依然として存在しています。
仕様書には「API経由で注文を作成する」とあります。しかし、実際のコードは時間を節約するために、データベースに直接注文を注入しているだけかもしれません。テストはパスしますが、負債は要件から実装へと移動したのです。
最初から完璧な仕様を書こうとしないでください。まずは書き、監査し、そして修正するのです。
Source: https://dev.to/diyaburman/spec-debt-doesnt-disappear-when-you-fix-it-it-migrates-d25
Optional learning community: https://t.me/GyaanSetuAi