Loading ...
Sorry, an error occurred while loading the content.
 

Re: [scrumdevelopment] Re: Scrum and Traceability

Expand Messages
  • George Dinwiddie
    Marc, Tracing /test cases/ to requirements is pretty much a slam-dunk if you do them right. Each test case should directly relate to a requirement. The
    Message 1 of 137 , Mar 1, 2010
      Marc,

      Tracing /test cases/ to requirements is pretty much a slam-dunk if you
      do them right. Each test case should directly relate to a requirement.
      The implementation should describe that requirement. I'd hope that
      you run /all/ of the test cases in a life-critical application, whether
      you think you can predict the consequences of a change, or not.

      In the case of life-critical code, inspecting the code and design (as
      implemented) are excellent risk reduction techniques. Trying to trace
      lines of code to requirements seems very risky to me.

      - George


      Marc Bless wrote:
      >
      >
      > What about regulated environments like medical technology or safety
      > critical applications?
      >
      > Imagine you're software product gets audited by an external governmental
      > organization and/or a strong internal quality management department.
      > These guys will take a look at your product's initial requirements with
      > severe impacts (product risks). They want to know how these requirements
      > are fulfilled, what you have done to minimize product risks, and which
      > test cases have been defined and executed. What are you going to do
      > other than introducing traceability keys?

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • john_hermann
      @Mark Couldn t we write the tests such that they don t look like tests, but rather requirements? With one, and only one formal specification, which
      Message 137 of 137 , Apr 20, 2010
        @Mark
        <quote>
        Couldn't we write the tests such that they don't look like tests, but rather requirements?

        With one, and only one formal specification, which also happens to be executable against the actual system, aren't we better off than having to split time between two possibly out-of-sync artifacts?
        </quote>

        ThoughtWorks has a testing tool called Twist, which uses something called Business Workflows. And now it has a nestable declarative aggregator called a "Concept" (what a concept!).

        http://www.thoughtworks-studios.com/agile-test-automation
        <snip>
        Twist is... designed to help you deliver applications fully aligned with your business. It eliminates requirements mismatch as business users directly express intent in their domain language.
        </snip>

        I have not used the tool myself. If anyone has, please add some insight.

        -johnny
        P.S. I have no affiliation w/ ThoughtWorks.


        --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
        >
        >
        >
        > --- In scrumdevelopment@yahoogroups.com, "pauloldfield1" <PaulOldfield1@> wrote:
        > >
        > > (responding to George)
        > >
        > > > I feel like a broken record with my questions.
        > >
        > > I guess I need to learn to answer you better :-)
        > >
        > > > pauloldfield1 wrote:
        > > > > IMHO Traceability, of itself, has no value. However some of the
        > > > > things that we DO value may be achieved readily if we have
        > > > > Traceability.
        > > >
        > > > What are those things?
        > >
        > > Well, I gave you a list of 15 things that some people value.
        > > I guess we could take a lead from Hillel's sig line and say
        > > they are all various categories of attempting to use process
        > > to cover for us being too stupid to be agile.
        > >
        > > We value knowing that we are testing to see that our system does
        > > what the customer wants (but we're too stupid to write the
        > > requirements directly as tests)... etc. etc.
        >
        > And this continues to irk the sh*t out of me. Why do we create another intermediate artifact that has to be translated by an error-prone human into a set of tests? What does the requirements document provide that the tests don't? Couldn't we write the tests such that they don't look like tests, but rather requirements?
        >
        > With one, and only one formal specification, which also happens to be executable against the actual system, aren't we better off than having to split time between two possibly out-of-sync artifacts?
        >
        > If you continue to have a separate requirements document, and your tests don't reflect the entirety of the requirements, what mechanism do you use to verify the uncovered requirements? How is that working for you?
        >
        > Mark
        >
        > "A man with one watch knows what time it is; A man with two watches is never quite sure."
        >
        >
        > >
        > > Paul Oldfield
        > > Capgemini
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.