For years I've known about software testing but I never had to apply it. This probably means that I wrote crappy software; but the bottom line is that people "accepted" it, one way or another. I used to just "get by". That all changed today.
I used to be a DEVELOPER, plain and simple. I'd write a web site and show it to the customer or users and it they said it was done, it was done. Then I became slightly more advanced in my practice and learned about UML "use cases" or "scenarios"; user stories. I learned how to write a stories and workflows and make software that aligned with those high level structures. But there is an even lower level that I had to go to that I was missing: unit tests. These matter!
My brand new tool/to y in my tool-set/toy-box are unit tests. I love these. These are important. They are critical. They are potentially even THE GLUE that could unify technical and non-technical types. They represent A LANGUAGE that can be understood by technical and non-technical types together that could be a unifying force in the process of designing custom software and business rules.
Acceptance tests, use cases, scenarios, and this kind of stuff are too "high level". In a way they are very "ethereal" (understood by few) and unverifiable. One person might think the test passes, and the other doesn't. In that sense they are very QUALITATIVE and ambiguous. Bad juju in business and softare!! Bad!
On the other hand, writing unit tests and ensuring that the code or business rules you write (policies) adhere with the spirit of the law is a beautiful thing. They are very low-level, understandable, and I would argue are NON-TECHNICAL. Yay, a non-technical thing for describing the business rules and logic that must be written. Awesome! Win win!
Overall, I think our organizations need three, types of people: Those who make rules, those who break rules, and those who watch the system and determine what to change. Each of us may need to be all three types of people sometimes; wear many hats. But having these clear distinctions between responsibilities is, I think, game-changing.
1 comment:
"Etherial" and "beautiful" all in the same blog! You go! This man's
found religion (with a small 'r' -- the kind that's about truth, not
Dogma).
I like your focus on "low level" and "understandable". For me, it
keeps coming back to SWIM - Say What I Mean. If what I'm saying is
that I want to integrate with code, why would I say that with anything
other than code. If you look at code as a conversation between
consumer and producer, the TDD code is consuming what the interface
produces. That's a tight conversation. There's no room in that
*tight* conversation, with absolutely no room for "the blunt tool
known as English" (to quote David Bernstein, another TDD/Scrum/Agile
trainer).
Post a Comment