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

Re: {Possible Spam?} [agile-usability] bug or missing feature?, was: just one bug's enough to make a program useless

Expand Messages
  • Brian Marick
    ... Agreed. Going beyond what you say: a tester without understanding of the domain will not only make bad usability suggestions, she will also report too many
    Message 1 of 23 , Jan 3, 2006
    • 0 Attachment
      On Jan 3, 2006, at 2:18 PM, Jeff Patton wrote:
      >
      > I have observed a pattern where testers become acutely aware of
      > inefficiencies in the workflow for the test cases they execute often
      > without regard for how realistically the test case reflects an actual
      > users' goals or usage.
      >
      > For example I used to do a lot of work in a brick and mortar retail
      > environment. Testers often asked for features to create items to
      > sell with less mandatory attributes, or navigate directly from item
      > creation to transaction entry, or to easily remove items. While all
      > these seemed logical, in large retail organizations those creating
      > items weren't the ones entering transactions. And removing items
      > with any transactional history had larger legal implications. The
      > feature suggestions would have indeed improved workflow for the
      > tester executing test cases, but not necessarily the user doing work.
      >
      > Now I know enlightened testers such as Brian and others wouldn't fall
      > into this trap. But to help the less enlightened I've always found
      > it important to have a strong understanding of the applications users
      > and their workflow. A good user model and task model serve that
      > purpose. Some concisely written user scenarios help with that also.
      > It's hard to remember sometimes that we're not the user and the
      > models help remind us.

      Agreed. Going beyond what you say: a tester without understanding of
      the domain will not only make bad usability suggestions, she will
      also report too many bugs that don't matter to real users and too few
      bugs that do.

      As Michael Bolton and a host of others would instantly remind me, the
      good tester is also operating under the assumption that the good user
      model and good task model are wrong in some important ways, and that
      part of her job is probably to find out how. (Similarly, her own
      understanding is doubtless wrong, too. It's the Turtles of
      Uncertainty all the way down.)


      P.S. Making changes to improve the usability for testers does have
      business value, unless their time costs nothing. I have some faith,
      but no evidence, that it would also improve the code, much like
      catering to JUnit or Fit does.

      -----
      Brian Marick, independent consultant
      Mostly on agile methods with a testing slant
      www.exampler.com, www.testing.com/cgi-bin/blog
      Book in progress: www.exampler.com/book
    • Desilets, Alain
      Maybe PhotoShop defended the feature where Undo-Undo redoes the undid thing. That s actually useful in some situations, because you can do blink comparator
      Message 2 of 23 , Jan 3, 2006
      • 0 Attachment
        Maybe PhotoShop defended the "feature" where Undo-Undo redoes the undid
        thing.

        That's actually useful in some situations, because you can do "blink
        comparator" from one keystroke.

        Never mind.

        -- Alain:
        Interesting point. Do you think this is something that you would be
        likely to find out through upfront design and paper prototyping?

        My guess is that this is exactly the kind of thing that does not become
        apparent until (even to the end user) until you look at real users
        laying their hands on the real thing and trying to carry out a real
        task.
        ----
      • Jeff Patton
        ... In the situation I was thinking about, making changes to the delivered product to better support testers would have broken business rules in the
        Message 3 of 23 , Jan 3, 2006
        • 0 Attachment
          --- In agile-usability@yahoogroups.com, Brian Marick <marick@t...>
          wrote:
          > P.S. Making changes to improve the usability for testers does have
          > business value, unless their time costs nothing. I have some faith,
          > but no evidence, that it would also improve the code, much like
          > catering to JUnit or Fit does.

          In the situation I was thinking about, making changes to the delivered
          product to better support testers would have broken business rules in
          the application. Basically it would have made it easier/faster for the
          tester to set up and tear down test data by forgoing some of the rules
          around creating and deleting - and also installing quick navigation to
          jump from creation directly to transaction entry, again, inapropriate
          for our app, but workflow the testers did often.

          Alain is right that lots of these tedious bits of testing should be
          automated.

          You're right that spending a little money to help testers complete
          their work faster - or not go crazy doing it - is a good idea. We just
          need to know why we're doing it. If it was a feature strictly for
          testing, I'd want some way to hide or disable it from a production
          release.

          But, your point is well taken. Also Michael's point you referred to as
          well.

          thanks,

          -Jeff
        • Larry Constantine
          ... Many bugs (both code bugs and usability defects) can be avoided by effective design practices and found prior to having running software through
          Message 4 of 23 , Jan 4, 2006
          • 0 Attachment
            Alain wrote:

            > By their nature, bugs cannot be caught by design. They can only be
            > caught after the buggy implementation has been implemented. This is one
            > of the great advantage of early delivery and TDD. They allow you to get
            > actual running software in the hands of users early, and catch bugs
            > early on in the process.

            Many bugs (both code bugs and usability defects) can be avoided by effective
            design practices and found prior to having running software through
            inspections and walkthroughs. Multiple research studies and extensive
            practice have shown inspections to be more cost effective than is testing
            for finding and eliminating bugs (both kinds).

            --Larry Constantine, IDSA [mailto:lconstantine@...]
              Chief Scientist | Constantine & Lockwood, Ltd.

            > -----Original Message-----
            > From: agile-usability@yahoogroups.com
            [mailto:agile-usability@yahoogroups.com] On Behalf
            > Of Desilets, Alain
            > Sent: Tuesday, 03 January 2006 11:40 AM
            > To: agile-usability@yahoogroups.com
            > Subject: RE: [agile-usability] just one bug's enough to make a program
            useless
            >
            > How can we usabilitists catch these blind spots in design, before they
            > lose us customers?
            >
            > -- Alain:
            > Sorry for late response... Catching up on pre-Xmas break email.
            >
            > ----
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.