Teaching to the Test

  • Posted on: 14 December 2015
  • By: leor
Printer-friendly version

by Bill Rinko-Gay

This blog is a follow-on to the post entitled “Open Book Testing.” If you haven’t already, you may want to read that first.

Once you have reviewed all your test stories it’s time to prepare to execute them. A well planned test execution, in conjunction with a well planned code implementation, helps to actually build quality in as well as verify the quality of the completed software.

To begin with, you need to understand how the users will interact with the program. Remember, the developers will be focused on making features work properly. You need to focus on software that meets the user’s needs. As an example, I once did a comparison of two circuit board design packages. Technically, one product (I’ll call it A) was far superior to the other (B), but A was much harder to use. A would give the users far less clean up work after the auto-placement. B left more clean up work, but all the work would be done in less time because of the ease of use. The result was that we bought B. The poor usability decisions cost company A money.

As you break your test stories down into discrete steps you will be the one looking at how the package works as a whole. This is the time to share with your developers whether features are usable. Walk through the steps with them and help them understand what it will be like for the users to use the software. In the case of my example, this meant showing the difficulty in moving an integrated circuit and re-routing its traces, and why that made an excellent initial placement algorithm unimportant.

NOTE: You may have become used to using poorly designed software because of a key feature. Don’t fall into the trap of assuming that’s acceptable. If a trade-off must be made, it should be an explicit trade-off with the user’s needs in mind.

In addition to verifying usability, work with the developers to plan the development and test effort in groups of stories that make sense. A common test problem is that releases that change what’s already been tested create “test thrash”. I’ll focus on minimizing this test thrash in my next blog.

By working through your test steps during the implementation you help your developers create a good user experience from the beginning, rather than trying to patch it in the end. This is a powerful contributor to building quality in.