Human evolution brought up some clever ideas how to survive in the wild. From my courses on becoming a swimming trainer, I know some parts of the physiological aspects in play when you exercise your body. While reading through Pragmatic Thinking and Learning from Andy Hunt, I was amazed that evolution build up the same concepts inside the brain. Here is my summary on it.
Continue reading Physical and mental evolutionMonthly Archives: April 2010
The Second System Effect in Software Test Automation
Matt Heusser blogged today on generating new ideas. In his entry, he cites from Weinberg’s Becoming a Technical Leader. Weinberg lists up the three obstacles to innovation – one of the three parts of his leadership model. The three obstacles to innovation are self-blindness, the No-Problem syndrome, and the single-solution belief. Continuing he explains the three keys to innovation based on this: Learn from your errors, learn from others, and copulate together two great ideas to form an even greater idea. Matt also mentions my struggle to find an article where a great software test automation framework became shelfware just because it couldn’t stand the technical challenge – or maybe just the human aspect of it? So far, we just found opinions on software test automation projects having failed, but no real hard data.
So, to overcome this lack of available material, let me write about my experience with software test automation, the problems we had, and how we overcame them. Thereby, I will not only enable myself to learn from my own errors, but also provide a system you may copy yourself, or which you might combine with another great idea that you have established in your company. In fact, most of this shouldn’t surprise you. During the last year, I also presented our approach on a test conference – here‘s the paper I wrote on this.
Continue reading The Second System Effect in Software Test AutomationThe Needle Eye Pattern
Having finally read Alistair Cockburn‘s article on Hexagonal architecture I see a great covariance to my understanding and application of our enterprise system. This is my take on the Ports and Adapter pattern and how I apply it in the context of the application server JBoss within the infrastructure of the product we happily sell.
Continue reading The Needle Eye PatternSoftware Management 0.5
Just this morning, it appeared to me, and there the solution was to all our problems. It had been there, so directly in front of my face, that I haven’t seen it, but it is so clear now.
We need to separate testing from the act of programming.
Wow. That’s a statement. But I’m serious. It has never worked and the large amounts of failing teams with Scram or Krumban, or whatever they call it, got it wrong. Yeah, Agile got it wrong. Collaboration is for the weak. After having spent over fifteen years with this crap, we need to get our bricks for the silos out from the closet again, and build up walls between those teams. Give testers different offices, on different floors, in different buildings, heck, what am I saying, give them different planets to be on, so they communicate mainly over the bug tracking system.
And I want to see a test plan, with every written detailed test up-front. Now. Show me. And I want to see Gantt chart based progress report, every week, and every day or even twice a day if there is an escalation. And I don’t want to spent time on re-planning. The initial plan must hold. Test design documents are fixed after being created initially. Yeah, that’s what we’re going to do.
While we’re at it, is there a way to get that waterfall model more heavy? How much celebration may we add to it? Just that? Come on, give me more than just the usual bug metrics and that crap. I want three additional testing cycles in the end. And I want QA to approve every delivery we make. Sure, they have to sign it. On paper, three copies to each major division head. Exactly.
If you haven’t figured yet, this is a rant about a personal Black Swan that a friend of mine just told me about his replaced management. Exactly, they’re separating the collaboration between programmers and testers, dividing them, right now, in this century, nearly ten years after the Agile manifesto and it’s focus on team-values, and cross-functional teams. This manager made the experience that developers and testers agree upon a delivery in a dysfunctional way. Therefore he wants to separate them again. And every major change project is failed if it is not implemented after 90 days. I’m not that good as a clairvoyance, so, what would you suggest my friend to do next?
Testing Dojos
About a year ago, I heard about Coding Dojos for the first time. Getting back to work, I nearly immediately tried out the idea with some colleagues. The implementation was great, and we had a lot of fun. Every since I wondered how to get testers involved into this deliberate learning. It took me some time and thought, but now I ended up with Testing Dojos. We ran several of them at work so far. I decided to provide you with some know-how that should get you started as well. In case you’re looking for personal experience, I will be presenting the topic together with a sample session at the XP 2010 conference in Trondheim in June this year.
Continue reading Testing DojosWell-crafted and craftly tested software
A while back, I submitted my article Software Testing Craft to the Agile Record. Having coined the zeroth law of professionalism in it, ever since I heard about Uncle Bob‘s call for craftsmanship I believed that the craft of software testing had been formed far longer than the emerging software craftsmanship movement. Having followed the great work in the testing field from Michael Bolton, Cem Kaner, James Bach, Matt Heusser, and the many, many more professional testers out there, built early on the picture of a very well developed craft about software testing.
It definitely pleases me to see a blog entry from Uncle Bob listening to a talk from James Bach. Uncle Bob immediately got the point that James is talking about craftsmanship in software testing. Though, there is one point in which I disagree with him:
I like the fact that testing is becoming a craft, and that people like James are passionate about that craft.
Testing is not becoming a craft, it always was as Jon Bach put it in the comments. I share Jon’s view on this. And it pleases me to see testers talking about their craft for more than a decade now.
Another stream of thought on the comments discusses the fact, that Uncle Bob called for developers to strive to deliver software that put testers out of business. Knowing Uncle Bob as the lead developer on FitNesse, I know that he is not saying to get rid of the testers completely. Far from it. As he stated in his Craftsmanship and Ethics talk, programmers should strive to the ideal that tester do not find any problem in the software they’ve produced. Of course, this does not mean that testers will not find any problem at all. Testing is still necessary. You can’t fool yourself by skipping testing. As Weinberg put it in the Quality Software Management series:
Actually, it ain’t nothin’ ’til it’s reviewed.
Weinberg just provided half the truth. It might be nothin’ ’til it’s reviews, but it still ain’t nothin’ ’til it’s tested, too.
Uncle Bob initially called for the craftsmanship movement with the call for
Craftsmanship over crap.
At around that time, Lemmy Kilmister stated in the song “Teach You How To Sing The Blues” from his band Motörhead
There’s no excuse for bullshit.
Later on, Uncle Bob refined his fifth value to
Craftsmanship over Execution
in order to reflect the nature of the Agile manifesto. Back in November I heard a famous German quote for this from Jens Coldewey:
Operative hectic replaces windlessness of the mind.
(It doesn’t translate that well, but it basically says that shouldn’t try to run before you walk.)
Amen.
The Deliberate Tester – Part 2
The Deliberate Testers continues. On the second half of his first day, our hero Peter is concerned about test automation. The Software Testing Club hosted this second part of my testing series on their blog. This episode is called The Deliberate Tester – Facing the Business with Automation.
Testing and Management mistakes: Causes
So far, we have taken a look on how to give the right response to common management mistakes. Today, I would like to take a closer look on the underlying problems that make a test manager react to management mistakes in an inappropriate way. By re-iterating over the dialogue of our manager Magnus and our tester Tim again, we’ll try to guess what the initial reaction could have caused, and therefore seek out for opportunities on how to solve the process problem.
Here are the links to the prequel of this blog entry:
- Management mistakes (Part 1) from Michael Bolton
- Testing and Management mistakes
- Testing and Management mistakes: Replacing placating with blaming
- Testing and Management mistakes: Congruent responses
Testing and Management mistakes: Congruent responses
This week Michael Bolton wrote a nice story about a usual situation at work where the project manager asks a tester to come in for the weekend. As I just faced a similar situation with a colleague who was asked to stay in, I started to explain some of the mistakes I saw. Challenged by Phil Kirkham I also started to replace the testers behavior – placating – with another behavior – blaming. Today, I’m going to take a closer look on an improved conversation flow by using congruent communication. Just in case you’re interested in more about the Satir Interaction Model, I whole-heartedly suggest you to read through Weinberg’s Quality Software Management series, especially Volume 3 should be of interest.
Here is the list of prequels leading to this post:
- Management mistakes (Part 1) from Michael Bolton
- Testing and Management mistakes
- Testing and Management mistakes: Replacing placating with blaming