Leave a Reply


  1. "check all the links manually after posting" Hmmm… that doesn’t sound like test-driven writing to me 🙂

    Erno Reply

  2. I liked the mentioned article. Not only the part about Time, but also about using whitebox use cases and a rules dictionary to precisely specify the inner working. Is this a technique you see used often? Because it seems to fill in a missing link for me…

    Raimond Reply

  3. Use cases mostly show blackbox behaviour, but sometimes it is wise to show some more details of the inner working (whitebox behaviour) in order for all the parties that make use of the use case to understand what it is all about.

    Factoring out information to other artifacts is a good idea if the factored-out information is not valuable for the tester, the user and the technical writer (especially if you do not want to argue with them about the way your program will offer a solution to a problem).

    In the case described in the article, the information that the Payroll is not run immediately but later at a given time is essential information to both the tester, the user and the technical writer, so it should be included in the use case.

    Harry Nieboer Reply