Home > Point2 - Technical > Software Quality

Software Quality

March 13, 2009

A number of the sessions I’ve attended here at SD West 2009 cover the same theme: software quality. There are a number of practices that can ensure quality; most of them involve the same thing – feedback.

  1. Requirements analysts can build prototypes to get rapid feedback from usability tests before building any code – time frame: hours or days
  2. Developers can write a unit test before each bit of production code to get quick feedback – time frame: minutes
  3. Business analysts can pair with QA roles to develop acceptance criteria / acceptance tests for each user story – time frame: hours or days
  4. Developers can run continuous intergration test suites to get feedback on whether they broke existing functionality – time frame: seconds or minutes
  5. Executives and product owners can communicate their vision for the product or feature, so the team can work toward common goals. Team members then can constantly validate what they are working on, and make design choices based on shared understanding of priorities – time frame: continuous
  6. QA teams can do exploratory testing on working code to find subtler bugs, usability problems, spelling and grammar mistakes – time frame: hours or days
  7. Developers can peer review each others code to find code smells and spot potential bugs early – time frame: hours
  8. Developers in some languages can use strong typing systems to their advantage. Strongly typing parameters and return values to validate input and output – time frame: instant
  9. Developers can use static analysis tools that help find places your code is likely to do something other than what you intended. Some of these tools are shipped with your compiler or IDE, but you can always get more detailed ones, and you can write your own to enforce local coing standards. These tools can be part of your continuous integration – time frame: seconds or minutes
  10. Agile teams can estimate task sizes to identify risks as early as possible – time frame: 1 hour

One thing that was empasized over and over, was that developer and tester are two very different roles. Developers want to write code that works; testers want to break it. Developers will always need that foil, trying to break their code using just as creative techniques as developers are using to write the code in the first place.

TDD is a method of development and code design, not a method of testing. People often get this mixed up because of the name. Even if TDD reduces your bug count by 95%, your QA team will have plenty of work to fill their time, doing what should have been their role in the first place – exploratory testing: testing the unknown-unknowns (everyone who said this, first felt the need to apologize for the Rumsfeldian phrase – you know they must really mean what they are saying, because nobody’s going around quoting Donald Rumsfeld just for the fun of it).

By: Todd Sturgeon

  1. Kevin Baribeau
    March 14, 2009 at 12:36 PM

    Hey, I really like the feedback trend you outlined. I think I’ve got another interesting way of characterizing the TDD-completeness problem.

    I had a university prof that had a method of describing bugs that stuck with me.

    A program has to be correct: for every input it has to produce the correct output.
    A program also has to be complete: it has operate over the full set of valid inputs.

    For example, a program that did integer addition but failed to add very large numbers because of an overflow bug could be characterized as being correct, but not complete.

    I think that TDD addresses correctness, but not completeness. Exploratory testing seems like good way to address completeness, but it seems to me that it is very difficult (or impossible) to verify that any program is complete for a non-trivial domain.

  2. March 16, 2009 at 10:20 PM

    If you train all your devs and BAs and QAs in basic usability princliples, product UI standards, and the problem domain, you should be able to at least avoid embarrassing yourselves. So much of craftsmanship is avoiding of embarrasment. Then you seek feedback from the end users asap after release. Once you’ve grokked Agile, you come to realize that release is just the beginning.

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: