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

Re: [XP] Re: Shouldnt done include everything.

Expand Messages
  • Steven Gordon
    ... Developer tests merely express what the developer thinks each unit of code should do. If the developers are doing TDD, I would expect exploratory testing
    Message 1 of 49 , Jun 1, 2010
    • 0 Attachment
      On Tue, Jun 1, 2010 at 7:40 AM, xtremenilanjan <xtremenilanjan@...>wrote:

      >
      >
      > This is a great response. however, I think my mention of exploratory
      > testing has opened up issues I wasn't thinking about. I also need to read up
      > Mike Cohn, Ron Jefferies. In the meantime,...
      >
      > My context: Developing software products/shrink wrapped
      >
      > Despite all XP practices, I would expect a good tester/exploratory tester
      > will find significant defects. In XP, he/she would endeavor to find these
      > defects as soon as possible, maybe by clarifying user stories or improving
      > developer tests.
      >
      Developer tests merely express what the developer thinks each unit of code
      should do. If the developers are doing TDD, I would expect exploratory
      testing to find few defects that were because the code did something
      different than the developers thought it should. I would expect most of the

      defects that an exploratory tester would find would be sequences of events
      that nobody had considered when creating the customer tests. I good way to
      think of these defects are missing requirements.

      > However, I still expect that the tester would find significant defects
      > during/latter part of the iteration. I think that would require
      > creative/analytical/thinking skills that XP practices can't guarantee.
      >
      There are no guarantees no matter how software is developed. There are no
      silver bullets. Agile is about honing in on perfection by reflecting and
      adapting every iteration, but the best we can hope for is to asymptotically
      approach perfection in the project context.

      >
      > Given that, I would plan some exploratory testing for the feature in the
      > iteration. I would plan some time and have some mechanism to determine if
      > that time is sufficient.
      >
      I believe the most pragmatic way is to do some "smoke testing" during the
      iteration to find defects in workmanship. All other defects found in
      exploratory testing should lead to new stories to be prioritized and
      scheduled by the product owner for future iterations. This way, there is no
      pressure to fit all the exploratory testing in the same iteration.

      >
      > It's possible that I don't really understand XP (as of now).
      >
      >
      If you have never done XP, it is highly unlikely that you could really
      understand it.

      SteveG


      [Non-text portions of this message have been removed]
    • Adam Sroka
      Hi Jeff: Are you responding to what Tim wrote below? Or to one of the earlier messages that I wrote? Anyway, thanks ;-) On Wed, Jun 9, 2010 at 3:52 PM, Jeff
      Message 49 of 49 , Jun 9, 2010
      • 0 Attachment
        Hi Jeff:

        Are you responding to what Tim wrote below? Or to one of the earlier
        messages that I wrote?

        Anyway, thanks ;-)

        On Wed, Jun 9, 2010 at 3:52 PM, Jeff Anderson
        <Thomasjeffreyandersontwin@...> wrote:
        >
        >
        >
        > Adam
        >
        > Your description of your coding life cycle was a breath of fresh air,
        > I sometimes get so surrounded by the old schoolers that I forget how
        > profound and powerful the XP approach is.
        >
        > Bravo.
        >
        > On 6/9/10, Tim Ottinger <linux_tim@...> wrote:
        > > FWIW
        > >
        > > My current company (an awesome place) is two years into agile transition.
        > > They are still releasing by content rather than time, mostly because it
        > > hasn't sunk in to upper levels the way it has been embraced in lower levels.
        > >
        > > There is a large legacy code base still, though it is constantly being
        > > whittled down. It has less coverage than the newer code.
        > >
        > > The ideal we strive for is that someday release will be a nonevent. There
        > > are many versions of our software in git that have had a full batch of
        > > unit and automated acceptance tests. Eventually, we will have sufficient
        > > trust in them that we can release any of them at any time. That's when
        > > we have arrived.
        > >
        > > While the code base and product management haven't fully transitioned, we
        > > have a 'code freeze' (really a branchpoint, after which we continue on) and
        > > there is manual testing and exploratory testing before a release. We are
        > > not really blocked by it, and we are programming on the day of release (on
        > > the next release).
        > >
        > > But someday a release will be a total non-event. Someone will pick a release
        > > package from the CI system and run the automated deploy on it in our big
        > > SAAS farm and nobody will stay up late or worry about it. Until then, we
        > > have the ever-thinning vestiges of an earlier circumstance.
        > >
        > > Tim Ottinger
        > > http://agileinaflash.blogspot.com/
        > > http://agileotter.blogspot.com/
        > >
        > >
        > >
        > >
        >
        > --
        > Sent from my mobile device
        >
        > Jeff Anderson
        >
        > http://agileconsulting.blogspot.com/
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.