Thursday, June 26, 2008

Beware of hiding requirements as tests

User stories are beautiful things. Details concerning the user story, when expressed as tests, are precious gems adorning the beautiful thing.

But one must take care to not let the tests be a requirement in their own right. Those tests should circumscribe, limit, and clarify the story, just the story, and nothing but the story. If they do more than that then one runs the risk of hidden requirements, and that is evil. Remember, the Principle of Least Astonishment applies to all parties involved in the endeavor.

Edit:  It's 10/13/2011 now.  I've changed my mind.  Tests ARE requirements.  Requirements ARE tests.  They are the same thing.  If a test, especially the Acceptance Criteria alluded to above, describe requirements that would otherwise be missed, Rejoice!

The question is not one of hiding requirements, it is of size.  I've learned that Epic Stories are beautiful ways to manage large amounts of information.  Often the A/C for an epic are stories in their own right.  That isn't something to avoid, it is something to embrace.


jef said...

Can you provide an example? I think I know what you mean, but I am not sure.

CharlesGary said...

Sure. Here's the example that spurred me to post in the first place. Note-it ain't a good user story:
On behalf of the processor the system must send trade posting to Phase3 (an external system) concurrently with settlement instructions to the Market.
-Test that trade posting appears in Phase3 withine one(1) minute;
-Test that the correspondent's special reference number appears in Phase3 somewhere.

That last test is a requirement of content, not concurrency. -1 for me for writing it the first time.