test objects design

As I have recently been interviewed for a prospective job one of the questions asked was about Agile and I was presented with some buzzwords. I couldn’t help but point out couple of times to the interviewing person that ultimately it comes down to ‘doing good work’ no mater how you slice it.

I am off topic here… so I wanted to say few things about being a Test Developer on Agile team. I do like the 3 C’s from Ron Jeffries. Card, Conversation, Confirmation. As a Tester I have similar view but I call it: Existence, Conversation, Conditions of Satisfaction… yep, it’s the same stuff but let me elaborate.

Ron J. says about ‘card is a token’ - passed around. To me a physical, visual representation, an existence token for what it is we are working on. As a tester I want more Existence Structures.. More Tokens, More Visual reminders on What it is we are working on.

We build those Existence Tokens with Conversations. Tokens without Conversations are useless. Cards are useless when there are no Conversations that give them the Existence, breathing. Else we just pass around pieces of paper that do not prompt us act. Conversations are the centerpiece, Cards are moving parts in a game, other existence tokens act as visual indicators to stimulate conversation and slow down entropy because in the sea of conversations it is easy to forget why we are building something

In Conversations we start presenting Conditions of Satisfaction that such and such function, user story, use case, bla bla whatever is done. In specifying Conditions of Satisfaction we do specify the Existence of the-What-That-Thing-you-know were talking about along the whole time. We specify Tests as Expressions of something ‘Working’ ; Providing Value. We express those Conditions as Tests that we expect to confirm our conditions. Again, tests don’t mean anything in themselves just like Cards don’t mean anything without the context of Conversations and Conditions of Satisfaction.

Here is where Testers can add a lot of value on Agile teams. They can be master designers of expressions for Conditions of Satisfaction; showing where there is Value Loss when certain conditions are not accounted for in a user story… yep, pretty much it; that’s my job as a tester, report to you conditions under which Value Loss occurs in a context of conditions of satisfaction that are a lot more than Confirmation alone. The truth is that Conditions of Satisfaction are almost never fully expressed because technical correctness is used as a proxy for ‘done’. - Here I are reminded what Uncle Bob keeps saying in his book ‘Clean Code’ that most programmers arrive at ‘working’ code and never make it ‘clean’ because for them the whole confirmation is ‘it runs’. That’s a pretty low condition of satisfaction I think.