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

Re: [XP] Explain the Test Case

Expand Messages
  • Arien Malec
    ... What if you pretended that the story on the story card is the statement of what the customer wants, and the acceptance test is the statement of what the
    Message 1 of 16 , Oct 1, 2002
    • 0 Attachment
      --- Chris Johnson <cjohnson@...> wrote:
      > Could someone explain to me what the test case on a story card is
      > supposed to provide?

      What if you pretended that the story on the story card is the
      statement of what the customer wants, and the acceptance test is the
      statement of what the application will do? If the statement on the
      card is not a sufficient statement, write that sufficient statement.

      I'm confused about your terminology. In XP, developers write "test
      cases" or "unit tests" or "developer tests", and customers with QA
      write "acceptance tests" or "customer tests". Which kind of test case
      are you talking about?

      If you assumed the role of QA in XP is to be the aid to the voice of
      the customer, translating that voice to an automated specification
      which, if passed, ensures that the application does what the customer
      wants to do, what should be on the card?

      Arien

      __________________________________________________
      Do you Yahoo!?
      New DSL Internet Access from SBC & Yahoo!
      http://sbc.yahoo.com
    • Phlip
      ... One requirement of a UserStory is that it be testable. The OnsiteCustomer must prove the card meets the requirement by writing the test case on it. Hence
      Message 2 of 16 , Oct 1, 2002
      • 0 Attachment
        Chris Johnson sez:

        > Could someone explain to me what the test case on a story card is supposed
        > to provide? I understand that it gives the developer additional context
        > for the story, and an initial test to validate the card, but I struggle
        > with understanding the relationship between the test case on the card, and
        > the complete suite of test cases that QA will write for a card. In our
        > lab, a card does not pass just because the test case on the card passes.
        > One test case on a card usually never captures the complete functionality
        > that arises in conversations between the customer and the developers. Does
        > the test case on the card only provide a starting point for the developers?
        > Are we using the concept of the test case correctly? How are others using
        > it?

        One requirement of a UserStory is that it be testable. The OnsiteCustomer
        must prove the card meets the requirement by writing the test case on it.

        Hence "The NSA can't hack us" is not a valid UserStory because there's no way
        to test it on the bench.

        --
        Phlip
        http://www.greencheese.org/PeaceAndCalm
        -- Why is the "Cheesy Horror Movie Channel" called "SciFi"?? --
      • Chris Johnson
        ... We view the story on the card as the beginning of a conversation between the developer and the customer. It is not intended to capture every detail. That
        Message 3 of 16 , Oct 1, 2002
        • 0 Attachment
          > -----Original Message-----
          > From: Arien Malec [mailto:arien_malec@...]
          > Sent: Tuesday, October 01, 2002 10:47 AM
          > To: extremeprogramming@yahoogroups.com
          > Subject: Re: [XP] Explain the Test Case
          >
          > What if you pretended that the story on the story card is the
          > statement of what the customer wants, and the acceptance test is the
          > statement of what the application will do? If the statement on the
          > card is not a sufficient statement, write that sufficient statement.

          We view the story on the card as the beginning of a conversation between the
          developer and the customer. It is not intended to capture every detail.
          That would be reverting back to use cases and requirement docs.

          >
          > I'm confused about your terminology. In XP, developers write "test
          > cases" or "unit tests" or "developer tests", and customers with QA
          > write "acceptance tests" or "customer tests". Which kind of test case
          > are you talking about?
          >
          Acceptance tests.

          > If you assumed the role of QA in XP is to be the aid to the voice of
          > the customer, translating that voice to an automated specification
          > which, if passed, ensures that the application does what the customer
          > wants to do, what should be on the card?
          >
          True, but that "automated specification" is more than the single test
          written on the story card. Again, if we captured the entire suite of
          acceptance tests on the card, I fear we would be taking a step backward.
        • Phlip
          ... That s an implementation of XP. The confusion comes because XP asks for certain artifacts, but not certain relationships. Programmers write customer tests.
          Message 4 of 16 , Oct 1, 2002
          • 0 Attachment
            Arien Malec sez:

            > I'm confused about your terminology. In XP, developers write "test
            > cases" or "unit tests" or "developer tests", and customers with QA
            > write "acceptance tests" or "customer tests". Which kind of test case
            > are you talking about?

            That's an implementation of XP. The confusion comes because XP asks for
            certain artifacts, but not certain relationships. Programmers write customer
            tests. If the customer is a programmer, or the QA department is available...

            --
            Phlip
            http://www.greencheese.org/SkeletonCrew
            -- Now collecting votes for a new group:
            news:alt.flame.moderated --
          • Chris Johnson
            ... I agree that it must be testable. The question here isn t the absence of a test, but what happens when there are several tests that go into the validation
            Message 5 of 16 , Oct 1, 2002
            • 0 Attachment
              > -----Original Message-----
              > From: Phlip [mailto:pplumlee@...]
              > Sent: Tuesday, October 01, 2002 10:48 AM
              > To: extremeprogramming@yahoogroups.com
              > Subject: Re: [XP] Explain the Test Case
              >
              > One requirement of a UserStory is that it be testable. The
              > OnsiteCustomer
              > must prove the card meets the requirement by writing the test
              > case on it.
              >
              > Hence "The NSA can't hack us" is not a valid UserStory
              > because there's no way
              > to test it on the bench.
              >

              I agree that it must be testable. The question here isn't the absence of a
              test, but what happens when there are several tests that go into the
              validation of a story. Should we limit the number of acceptance tests on
              the story card? If not, aren't we falling into having to provide a detailed
              test plan up front? Is that even a bad thing?
            • Dinwiddie, George
              Chris Johnson said ... Consider the test written on the card as a reminder of the most important test that the story has to pass. Further elaboration is in
              Message 6 of 16 , Oct 1, 2002
              • 0 Attachment
                Chris Johnson said
                > > -----Original Message-----
                > > From: Arien Malec
                > >
                > > What if you pretended that the story on the story card is the
                > > statement of what the customer wants, and the acceptance
                > test is the
                > > statement of what the application will do? If the statement on the
                > > card is not a sufficient statement, write that sufficient statement.
                >
                > We view the story on the card as the beginning of a
                > conversation between the developer and the customer. It is
                > not intended to capture every detail. That would be reverting
                > back to use cases and requirement docs.

                Consider the test written on the card as a reminder of the most important
                test that the story has to pass. Further elaboration is in the conversation
                with the Customer and in the acceptance tests.

                - George
              • Chris Johnson
                ... I agree. I m concerned about a disconnect between the developers, the customers and QA. Everyone can agree on the test(s) written on the card. Going
                Message 7 of 16 , Oct 1, 2002
                • 0 Attachment
                  > -----Original Message-----
                  > From: Dinwiddie, George [mailto:George.Dinwiddie@...]
                  > Sent: Tuesday, October 01, 2002 11:17 AM
                  > To: 'extremeprogramming@yahoogroups.com'
                  > Subject: RE: [XP] Explain the Test Case
                  >
                  > Consider the test written on the card as a reminder of the
                  > most important
                  > test that the story has to pass. Further elaboration is in
                  > the conversation
                  > with the Customer and in the acceptance tests.
                  >
                  > - George

                  I agree. I'm concerned about a disconnect between the developers, the
                  customers and QA. Everyone can agree on the test(s) written on the card.
                  Going forward from there, the developer discerns the remaining functionality
                  in conversations with the customer. QA also discerns additional test
                  scenarios/cases with the customer. How do we make sure that QA and the
                  developers are getting the same message, or interpreting the customer's
                  requirements in the same way? We often get to QA and are flagged for bugs
                  that the developers never knew about.
                • Dale Emery
                  Hi Chris, ... Do these two conversations happen at different times, in different rooms? Could you do them at the same time, in the same room? Dale
                  Message 8 of 16 , Oct 1, 2002
                  • 0 Attachment
                    Hi Chris,

                    > ... the developer discerns the remaining functionality in
                    > conversations with the customer. QA also discerns additional test
                    > scenarios/cases with the customer.

                    Do these two conversations happen at different times, in different
                    rooms? Could you do them at the same time, in the same room?

                    Dale
                  • William Wake
                    Chris - ... I guess I d expect them to be a reminder of tests, just as the card is a reminder of the story. I wouldn t expect all the tests for a story to fit
                    Message 9 of 16 , Oct 1, 2002
                    • 0 Attachment
                      Chris -

                      >I'm concerned about a disconnect between the developers, the
                      >customers and QA. Everyone can agree on the test(s) written on the >card.
                      I guess I'd expect them to be a reminder of tests, just as the card is a
                      reminder of the story. I wouldn't expect all the tests for a story to fit on
                      the back of a card, just like I don't expect cards to be fully fleshed-out
                      use cases.

                      >How do we make sure that QA and the
                      >developers are getting the same message, or interpreting the customer's
                      >requirements in the same way?

                      Is the whole team sitting together? This is a place where being in "earshot"
                      can help. Is the whole team participating in planning meetings, standups,
                      etc.?

                      >We often get to QA and are flagged for bugs
                      >that the developers never knew about.

                      "Get to QA" sounds like a "big-bang" (or at least "little-bang" release)
                      where you don't know the test until you get there. Can you shift to a more
                      incremental approach where you get the tests as they're written? The ideal
                      is to get the tests before you even start implementing a story, so you have
                      even fewer surprises.

                      We don't want to play a guessing game; customer tests are part of the
                      requirements and we want the team to know them. This is a shift from the
                      "independent verification and validation" attitude some QA teams have.

                      --
                      Bill Wake William.Wake@... www.xp123.com


                      _________________________________________________________________
                      MSN Photos is the easiest way to share and print your photos:
                      http://photos.msn.com/support/worldwide.aspx
                    • Ron Jeffries
                      ... To me, the information that goes with the card should be how this story will be tested . That s not necessarily one test case: it could be many. It might
                      Message 10 of 16 , Oct 1, 2002
                      • 0 Attachment
                        On Tuesday, October 1, 2002, at 11:06:26 AM, Chris Johnson wrote:

                        > Could someone explain to me what the test case on a story card is supposed
                        > to provide? I understand that it gives the developer additional context for
                        > the story, and an initial test to validate the card, but I struggle with
                        > understanding the relationship between the test case on the card, and the
                        > complete suite of test cases that QA will write for a card. In our lab, a
                        > card does not pass just because the test case on the card passes. One test
                        > case on a card usually never captures the complete functionality that arises
                        > in conversations between the customer and the developers. Does the test
                        > case on the card only provide a starting point for the developers? Are we
                        > using the concept of the test case correctly? How are others using it?

                        To me, the information that goes with the card should be "how this
                        story will be tested". That's not necessarily one test case: it could
                        be many.

                        It might be that QA will write lots of test cases for the story. The
                        programmers and customer, however, should have enough tests to give
                        them great confidence that QA isn't going to find anything.

                        Ron Jeffries
                        www.XProgramming.com
                        It's easier to act your way into a new way of thinking
                        than to think your way into a new way of acting. --Millard Fuller
                      • Chris Johnson
                        ... The conversations happen in the same room, but usually between Customer and Developer or Customer and QA. Should we try to pull QA over every time a
                        Message 11 of 16 , Oct 1, 2002
                        • 0 Attachment
                          > -----Original Message-----
                          > From: Dale Emery [mailto:dale@...]
                          > Sent: Tuesday, October 01, 2002 11:58 AM
                          > To: extremeprogramming@yahoogroups.com
                          > Subject: Re: [XP] Explain the Test Case
                          >
                          > Do these two conversations happen at different times, in different
                          > rooms? Could you do them at the same time, in the same room?
                          >
                          > Dale
                          The conversations happen in the same room, but usually between Customer and
                          Developer or Customer and QA. Should we try to pull QA over every time a
                          developer has a question for the Customer?
                        • Chris Johnson
                          ... Good point. ... Yes. ... The developers often don t know the tests that QA is going to perform, other than what is written on the story card. When in the
                          Message 12 of 16 , Oct 1, 2002
                          • 0 Attachment
                            > -----Original Message-----
                            > From: William Wake [mailto:william.wake@...]
                            > Sent: Tuesday, October 01, 2002 12:06 PM
                            > To: extremeprogramming@yahoogroups.com
                            > Subject: RE: [XP] Explain the Test Case
                            >
                            > I guess I'd expect them to be a reminder of tests, just as
                            > the card is a
                            > reminder of the story. I wouldn't expect all the tests for a
                            > story to fit on
                            > the back of a card, just like I don't expect cards to be
                            > fully fleshed-out
                            > use cases.
                            >
                            Good point.

                            > Is the whole team sitting together? This is a place where
                            > being in "earshot"
                            > can help. Is the whole team participating in planning
                            > meetings, standups,
                            > etc.?
                            Yes.

                            > "Get to QA" sounds like a "big-bang" (or at least
                            > "little-bang" release)
                            > where you don't know the test until you get there. Can you
                            > shift to a more
                            > incremental approach where you get the tests as they're
                            > written? The ideal
                            > is to get the tests before you even start implementing a
                            > story, so you have
                            > even fewer surprises.
                            The developers often don't know the tests that QA is going to perform, other
                            than what is written on the story card. When in the XP process should QA
                            flush out the acceptance tests for a story? Should that be before the card
                            is ever introduced to the planning game?

                            >
                            > We don't want to play a guessing game; customer tests are part of the
                            > requirements and we want the team to know them. This is a
                            > shift from the
                            > "independent verification and validation" attitude some QA teams have.
                            >
                            Again, good point.
                          • Dinwiddie, George
                            ... No, there s no point in writing acceptance tests for a story that s never scheduled. But once a story is selected for an iteration, it seems that the
                            Message 13 of 16 , Oct 1, 2002
                            • 0 Attachment
                              Chris Johnson asked:
                              > The developers often don't know the tests that QA is going to
                              > perform, other
                              > than what is written on the story card. When in the XP
                              > process should QA
                              > flush out the acceptance tests for a story? Should that be
                              > before the card
                              > is ever introduced to the planning game?

                              No, there's no point in writing acceptance tests for a story that's never
                              scheduled. But once a story is selected for an iteration, it seems that the
                              tests should be written ASAP. Until they're available, the acceptance
                              criteria written on the card can help guide the developer and remind her of
                              the goal.

                              - George
                            • Robert Martin UncleBob
                              ... Putting a test case on a card is not a common XP practice. There s nothing wrong with the idea; but it s not like anybody said it s required. A test case
                              Message 14 of 16 , Oct 1, 2002
                              • 0 Attachment
                                > -----Original Message-----
                                > From: Chris Johnson [mailto:cjohnson@...]

                                > Could someone explain to me what the test case on a story
                                > card is supposed
                                > to provide?

                                Putting a test case on a card is not a common XP practice. There's nothing
                                wrong with the idea; but it's not like anybody said it's required.

                                A test case on a story card is just another way to describe the story. Test
                                cases are usually less ambiguous than natural language. However, since that
                                test case is not automated, and since QA needs to create the automated test
                                cases before the end of the iteration, I think the test case on the card is
                                little more than a comment.

                                -----------------------------------------------
                                Robert C. Martin |
                                President & Founder |
                                Object Mentor Inc. | unclebob @ objectmentor dot com
                                PO Box 5757 | Tel: (800) 338-6716 x15
                                565 Lakeview Pkwy | Fax: (847) 573-1658
                                Suite 135 |
                                Vernon Hills, IL, | www.objectmentor.com
                                60061 |
                                -----------------------------------------------
                              • Tony Milici
                                Putting a written description of the test case on the story card (maybe on the back side) might not be such a bad idea. It would force you to keep your stories
                                Message 15 of 16 , Oct 2, 2002
                                • 0 Attachment
                                  Putting a written description of the test case on the story card (maybe
                                  on the back side) might not be such a bad idea. It would force you to
                                  keep your stories small. If you can't fit the test case on a card,
                                  maybe your story is too big?

                                  Tony.

                                  -----Original Message-----
                                  From: Robert Martin UncleBob [mailto:unclebob@...]
                                  Sent: Tuesday, October 01, 2002 12:01 PM
                                  To: 'extremeprogramming@yahoogroups.com'
                                  Subject: RE: [XP] Explain the Test Case



                                  > -----Original Message-----
                                  > From: Chris Johnson [mailto:cjohnson@...]

                                  > Could someone explain to me what the test case on a story
                                  > card is supposed
                                  > to provide?

                                  Putting a test case on a card is not a common XP practice. There's
                                  nothing
                                  wrong with the idea; but it's not like anybody said it's required.

                                  A test case on a story card is just another way to describe the story.
                                  Test
                                  cases are usually less ambiguous than natural language. However, since
                                  that
                                  test case is not automated, and since QA needs to create the automated
                                  test
                                  cases before the end of the iteration, I think the test case on the card
                                  is
                                  little more than a comment.

                                  -----------------------------------------------
                                  Robert C. Martin |
                                  President & Founder |
                                  Object Mentor Inc. | unclebob @ objectmentor dot com
                                  PO Box 5757 | Tel: (800) 338-6716 x15
                                  565 Lakeview Pkwy | Fax: (847) 573-1658
                                  Suite 135 |
                                  Vernon Hills, IL, | www.objectmentor.com
                                  60061 |
                                  -----------------------------------------------


                                  To Post a message, send it to: extremeprogramming@...

                                  To Unsubscribe, send a blank message to:
                                  extremeprogramming-unsubscribe@...

                                  ad-free courtesy of objectmentor.com

                                  Your use of Yahoo! Groups is subject to
                                  http://docs.yahoo.com/info/terms/
                                Your message has been successfully submitted and would be delivered to recipients shortly.