Test first , then Analyse

[HS Thomas]

Following Mark Herschberg's post in Can RUP...etc
set me thinking and thought the question warranted a separate post.

In XP what is the stage prior to:
The Planning Game: business and programming professionals collaborate to estimate the time for short tasks (called "stories" in XP)
Can Testing help in making sense of the *bits* of volatile information that may/may not be included in a system.
Kind of - a Test hypothesis first then it may be "worthy of deeper Analysis" approach. :roll:
I have assumed that by the time you come to Test first then Design , the *bits* of information worthy of implementing are already decided and agreed upon.
What about those *bits* of volatile information floating around the system but not dealt with.
Would a testing framework like JUnit be severley limited or can it be simply extended?
The closest I can come to something suitable is in Applications in Data Mining MineSet,EnterpriseMiner.
Some may argue this is a business activity not a systems one - but with the *new* technologies should it be solely a business one?
Anyone up for the challenge ? - it would be one
Agile business ! Think of the changing requirements taking shape and implemented in Iterations of ... a week to a month?
regards
[ July 04, 2003: Message edited by: HS Thomas ]

[HS Thomas]

The kind of Applications it would be useful
- very volatile ones like Customer Relationship Management. Judging by the amount of new books available these applications are already kicking off...
regards
[ July 04, 2003: Message edited by: HS Thomas ]

[Ilja Preuss]

Originally posted by HS Thomas:
In XP what is the stage prior to:
The Planning Game: business and programming professionals collaborate to estimate the time for short tasks (called "stories" in XP)

That's outside the scope of XP. Certainly somehow the Customer needs to find out about what type of system he wants to have developed.

I have assumed that by the time you come to Test first then Design , the *bits* of information worthy of implementing are already decided and agreed upon.
What about those *bits* of volatile information floating around the system but not dealt with.
Would a testing framework like JUnit be severley limited or can it be simply extended?

In the iterations planning meeting the developers are expected to split the scheduled stories into tasks and estimate those. For this they need to get more details from the Customer. They might also want to know what the acceptance tests for a story will look like.
When a pair is working on a task and finds out that it is lacking information, they will simply go to the onsite Customer and ask him questions.
In the meantime the Customer will work on writing his acceptance tests. He will likely include all the tiny bits he cares about, in an unambigious language.
Did that answer your question???

[HS Thomas]

In the meantime the Customer will work on writing his acceptance tests. He will likely include all the tiny bits he cares about, in an unambigious language.
Did that answer your question???

Yes, it did thank you. I get the distinct impression that you'd consider Analysis Testing/Acceptance Testing strictly a business activity and wouldn't care for systems to be involved.
Thought it might be useful on tracking trends in changing requirements but I guess that ought to filter down to systems anyway. That's what Business Analysts are there for, after all.
regards

[Stan James]

I wanted to focus on the "test first, then ..." part of the original post. The subject said "then analyze" and the body said "then design". I don't think either is exactly right.
First you need enough analysis to know what you want the thing to do. The story might be perfectly clear as written, but as mentioned above, if a programmer gets to a point where they don't have enough information, they can go to the customer and get more. We try to interview the customer and get a solid feeling for a story up front (waterfall warning bells ringing) but that's because the customer is not on site.
Design & test really happen together. Say I want to write a test for a new class. I code the test with a constructor with several parameters. I've just designed the first public aspect of the class. Some times there are a handful of classes interacting, and I do some abstract design of several classes even before I start writing tests. Now I have to admit our team does not work this way because the vendor code does not lend itself easily, but I'm dyin to try it!