0

私は、製品の動作を定義するために SBE 仕様が作成されている、かなり大規模な既存のコード ベースに取り組んでいます。

現在、約 450 のシナリオがあり、この数はコード ベースに新しい機能が追加されるたびに増加しています。

従来の 1 行の要件ステートメントと比較して、SBE 仕様の冗長な性質のために、システムの機能を高レベルで理解することは困難です。例として、ストーリーには現在合計 46,830 語があります。

$ find src/main/resources/stories/ -name *.story | xargs cat | wc -w
   46830

もう 1 つの問題は、ストーリーの共同作業にgerrit コード レビューツールを使用していることです。これにより、チーム間のコミュニケーションが正式化されています。

質問 1 : SBE は完全で包括的な回帰テスト スイート (例) である必要がありますか? それとも、各スプリントで必要な主要な機能のみに集中する必要がありますか?

質問 2 :こちらの回答で述べたように、大規模なプロジェクトのストーリーを管理するために課題トラッカーなどのツールが必要ですか?

4

1 に答える 1

1

通常、受け入れテストと動作テストは、それ自体がブラック ボックス テストの一種であるため、価値が提供されていることを確認することに重点を置いています。

したがって、1. の場合、答えは NO です。完全であってはなりません。価値を生み出す外部の行動が後退しないようにする必要があります。

2.については、時間ベースの情報を取得するためにクエリを実行するのが非常に難しいため、このようなツールは避けます。通常、Rally やバージョン 1 などのアジャイル ツールは、バーン ダウン チャートを作成して、日ごとのバーン ダウンと速度チャートを提供します。トラックにはバグトラッカーを、アジャイルにはアジャイルツールを使用してください!

于 2014-01-14T15:03:10.530 に答える