testing - 最適な量の自動化のやり直し

Question

機能の開発サイクル中、機能がすべての要件（UIの改善など）を満たした後でも、機能は絶えず変化しています。その機能の自動テストがある場合、これらの変更は自動化を壊す可能性があり、それをやり直す必要があります。ただし、機能が変更され続ける場合は、改訂のたびに自動化をやり直すことは意味がありません。ただし、ある時点で、回帰テストを実行できるように自動化する必要があります。自動化をやり直すのに最適な時間をどのように見つけることができますか？どうすれば最適な量を得ることができますか？私のチームは、機能の1つを自動化するために手直しをしすぎたことに同意しました。私たちが犯した間違いの1つの例は、会議の直前に自動化をやり直して、顧客からのフィードバックを得るために機能を顧客に披露したことです。お客様からのフィードバックにより、機能がさらに変更されることを知っておく必要があります。その場合、機能テストで十分だったはずです。誰かが共有するためのヒントや経験がありますか？

Answer 1

一般的なヒントは、機能の構築を開始する前に、機能の「完了」が何を意味するかについて合意に達することです。

ビルド中に、機能を改善するために追加したい新しい微調整に出くわした場合 (または何でも)、既存のストーリーにそれらを追加しないでください。新しいストーリーを作成してください...あなたがしなければならない他のこと。

これは、常にではありませんが、機能の増分が大きすぎることを示している場合もあります。機能の「完了」の非常に具体的な定義を書き留められるまで、ストーリーを分割してさらに薄くしてみてください。ビルドを開始する前に、これらの「完了」のテストを自動化することを検討してください (ただし、やりすぎないでください)。

Specification By Exampleの本が見つかるかもしれません。

Answer 2

私の経験によると、あなたが開発してきた機能はまだ顧客に完全には理解されていません。

@adrianhが提案したように、機能を小さな部分に分けます。

不安定な顧客へのもう 1 つのヒント: 疑似プロトタイプを最初に実際に見てもらいます。企画会議でも構いません (html に直接コーディングするか、プロトタイピング/ダイアグラム ツールのような簡単なものにコーディングします)。彼らにそれで遊ばせてください。このようにして、機能を簡単に使用できます。