Testing, Contracts, Agile and Axioms

Many, many thanks for the invitation to speak and the hospitality of the Dansk-IT Test Manager Klub. A very welcoming audience for my 'traditional' pitch on Contracts and Testing and also the discussion on Axioms and Agile. Thank-you.

You can see the Axioms talk and paper here. The Agile Contracts slides are attached to this post. Also, the Axioms Worksheet I used in the session.

Since I've pitched the Axioms talk at the TMF community and the Taicpart (mainly academic) community, the reaction has been very positive. Comments tend to be about wording and clarification of the meaning of the (still rather terse) descriptions. But this is the first time I've proposed an application of them. It seems to me that the best way to flush out issues with the Axioms is to actually try and use them for something. Call me agile? ;-)

So,I offered them up partly as a check-list, partly as a language or vocabulary to the Danish Test Manager community.

The 'language' aspect for me is particularly interesting. I suggested in the meeting that they could use the Axioms Worksheet as a framework for discussions with Developers in Agile projects.

It seems to me that most Test Managers have difficulty communicating with Agile development teams. Perhaps this is the real problem. Agile developers might test, but they see testing through the eyes of a developer. They might cover code, but do their tests demonstrate 'achievement', 'value'? See below.

Agile principles include: "Working software is the primary measure of progress","Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

So, perhaps, if Developers are willing to buy into Axioms, they would appreciate the need to align their testing with achievement and value (in the eyes of the testing stakeholders).

If we ask a developer, "what were you thinking of when you created these tests?", "what models were you using - for design, for coverage", "why did you stop there?", "how are we to interpret your test results?" and so on, perhaps we can have a sensible conversation rather than an antagonistic staring match (I exaggerate a little - of course :-)).

I'm convinced that we have to depend on developers to do most of the testing. Sure, to detect defects, but also to demonstrate achievement and value. But the thing is, testers have been indoctrinated into thinking that finding bugs is ALL WE DO. Therefore developers see testing as one-dimensional. Testers do it. The path of least resistance is to believe all testing is the responsibility of testers.

Surely, defect detection is a by-product of good testing. Defect detection is critical, of course, but testing is so much more. The Agile principles promote the idea of delivery of working, valuable software. Shipping code is one thing. Only testing can demonstrate the stuff is working and valuable. THIS is the mentality we should be promoting within our development community.