May 042010
 

Whenever the topic of quality assurance (QA) over a project is brought to a conversation, testing is the first thing to come to most people’s minds. QA actually goes far beyond just testing code. In any case, being test centric can become more effective from the standpoint of QA at the project level if we expand our view of testing by taking the following five considerations:

  1. Test the software development process. A fundamental part of continuous improvement is to mature the software development process, whether or not you are using an agile or lean methodology. If you plan a development strategy and stick to it instead of adjusting it to become more effective over time and to follow the actual project needs, then the quality of the product or service and the performance of the stakeholders will suffer. Does the infrastructure count with continuous integration? Is the software delivered to the customer frequently and continuously (good), or as a whole at the end of the product’s lifecycle (poor)?
  2. Test the use of the application. This has to do with the perceptual integrity of the product in terms of how easily and rapidly the user gets productive with it, and it applies to new and to seasoned users. Is the application easy to use or does it require a steep learning curve? Does the application make sense, or does it confuse the user?
  3. Test the results of using the application. This also has to do with the perceptual integrity of the product, but from the standpoint of how useful it actually is to the user. That is, how much productivity is increased. Is the application actually useful or is it making life more difficult for the customer? Is it adding value or being a diversion? Does its use result in frequent mistakes by the customer — mistakes which are, in reality, not user mistakes but usability failures?
  4. Test the software developed. This has to do with the conceptual integrity of the product. Is it being implemented using design patterns? Is the code being continuously refactored? Is test code implemented and executed before (great), during (good), or after (poor) the features are coded?
  5. Test the data used by the application. What if everything in the project works great except that the data doesn’t make sense at all or, even worse, the data is corrupted? Good data warehousing and handling are extremely important but, unfortunately, little is done to test the data compared with code testing.

All five considerations should be tested keeping in mind the agile-testing quadrants; that is, consider the business, technology, product, and team perspectives. This requires a good combination of test tools, test automation, manual testing, and a lot of customer interaction. It does not mean that the enterprise has to invest vast amounts of capital in QA, but it does mean that good quality doesn’t come free. However, good quality pays for itself in the long run by significantly reducing technical debt. As much as possible, customers or users should be involved in testing the product, since they are the product’s target.

avatar

Masa K. Maeda

Masa K. Maeda is a Senior Consultant with Cutter's Agile Product & Project Management Practice. He has 23 years of experience in the USA, Japan, and Mexico.

Discussion

  4 Responses to “Five Steps to Improve Quality”

  1. […] Pro Tweets New blog post: Five Steps to Improve Quality http://blog.cutter.com/2010/05/04/five-steps-to-improve-quality/ cuttertweets – Tue 04 May 13:16 All Things […]

  2. Testing doesn’t do much for software quality, it mostly just ensures requirements have been met. And I don’t think it does anything at all for technical debt, unless you are talking about test-driven development.

  3. Kurt,

    I entirely agree in that testing in itself is not software quality. It is rather a mechanism to determine the existence of some defects (not all defects). Software quality is vast and goes from ways of thinking to ways of acting to generate products, services, solutions, or other to provide value to customers in a way that satisfies customer’s needs or desires. It does help determine the degree of technical debt and helps reduce or avoid technical debt under TDD.

    Cheers,
    Masa K Maeda, Ph.D.
    Senior Consultant, Cutter Consortium

  4. To hear more from Masa on agile practices, you may download a sampling of his Cutter Consortium research here: http://www.cutter.com/offers/maeda.html. Happy reading!

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)