Some weeks ago James Bach began a series on Quality is dead. Since up to now he did not yet write up more of it, I get in touch with him via instant messaging. He explained to me that quality is dead, it cannot be brought back to live. How come?

James explained to me that most of our currently used systems are built on top of other software components. Indeed, when going over the list of the applications I regularly use, I see hard interdependencies. Even most of the components my preferred applications use are built on other components. These components in turn are also built on other ones. This chain seems to continue for quite a while. How come?

The urge to built more and more abstractions in order to be able to describe in more human terms what our software should do, favors this approach. Clearly, I am a supporter of this. The more and more we are directly able to use DSLs and tool support to write our programs, we are more likely to reduce our errors in them. How come James Bach sees a problem in this approach?

Well, it’s part of our human being to make mistakes and learn from them. Indeed most of our learning abilities are based on this. Agile methodologies favor feedback, so that the individual in the project is able to learn quickle, timely and a lot from her work. The problem with the intertwined dependencies in low-level software components comes into play, when there are problems and errors in it. Unaware of this we incorporate most of the time new software on this. When we realize a problem, we file it into the bug tracking system of the other library or to the issue tracking system of the other company and in order to avoid getting stuck, we work around the problem in order to get our customers happy again.

This is why Software Craftsmanship demands for long-lived and wisely chosen technology when sticking with an approach. By making sure that our underlying tools are not used for this week and then thrown away, we deal with the risk of quality problems in the underlying library and thereby our own. On the other hand we enable ourselves to reuse the approach in the next project for the next customer at hand. We are able to gain practice today and are able to come up with a cleaner solution tomorrow based on our expertise with the component or tool. This demands also high professionalism for choosing the right tool. Personally I made good experiences with FitNesse over the last year and also started to support the project a while ago by making some contributions to it – some smaller ones, but it still showed me the power of a good unit and acceptance test suite.

How does all this relate to the initial subject? Testing quality into the product is a term which I don’t like to hear. My mentor in the Miagi-Do school of Software Testing, Matt Heusser, sent an article round this weekend for peer review. It contained a challenge regarding impossible to answer question in software testing. How do you (testers) test quality into the product? is the addition that I would like to propose to the already existing list of these sort of questions. Why?

First of all as a tester I do not decide on which component to base the classes of the production code. However, I will have to deal with it. If the decision is made to use Haskell as the programming language, there is little I can do to incluence this decision. Still I will have to cope with the situation at hand.

Second as a tester there is little I can do about the particular degree of software design decisions. The programmers lead and the programmer at hand will make the decisions. Sure, I can guide them to motivate the usage of test-driven development, point out the books, if asked for (I made some amazon.de reviews (in english) over this week), etc., but still I will not ultimately participate in the decision.

Third as a tester I can only guide by giving the informations the managers on the team need in order to make the right decisions. If there is an unknown factor of failure, since every time a new test gets run there are ten new bugs found, it indicates another decision to be made as when all tests I could think of pass. Sure, I could have made the mistake to not understand the business of the customer and come up with some irrelevant tests, but I put my reputation at stake by doing so and by endangering the sucess of the project.

There is a simple quote from Michael Bolton which I felt to print out and hang it all over the office at work since it summarizes this pretty well:

One important step is to stop thinking about testers as “QA” — unless the A stands for “assistance” or even “analysis”, but not “assurance”. We’re testers. Management (in one sense) and the whole team (in another) provides the “assurance” bit, but since we don’t have control over schedule, budget, staffing, project scope, contractual obligations, customer relations, etc., etc., we can’t assure anything. We should be here to help–not to slow the project down, but to aid in the discovery of things that will threaten value.