how complete should SBE specifications be?

问题:

I'm working on a fairly large existing code base where SBE specifications are created to define the behavior of the product.

There are currently around 450 scenarios, and this number is growing with each new feature added to the code base.

Compared to traditional one line requirement statements, it is difficult to get a high level understanding of the functionality of the system due to wordy nature of the SBE specifications. As an example, the stories currently have a total of 46,830 words:

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

One other issue is that we are using gerrit code review tool for collaborating on stories, which is resulting in formalized communication between the team.

Question 1: Should the SBE's be a complete and comprehensive regression test suite (example)? Or, should they only focus on the key functionality required in each sprint?

Question 2: As mentioned on the answer here, are tools such as issue trackers required to manage stories for large projects?

回答1:

Normally acceptance tests and behavior tests focus on making sure value is delivered because by their own nature they are a form of black box testing.

So for 1. the answer is NO, they should not be complete. They should make sure that the external behaviors that produce value do not regress.

Regarding 2. I would avoid such tools, because they are devilishly hard to query to get time based information: typically agile tools like Rally or Version one are able to do burn down charts to give you burn downs by day and velocity charts. Use bug trackers for tracks and agile tools for agile!