Currently there is a thread ongoing on the XP mailing list. Based on a rant from Nick Robinson, the discussion started about programmers that take pride in their work as opposed to programmers that just do that coding stuff. Today, Kurt Häusler wrote a reply in which he states his experience. You should go and read it – now – the initial rant from Robinson is in there, too. I’ll wait here for you to come back.
Category Archives: Testing
Software Testing
A little challenge
Rob Lambert blogged over the weekend on being a tester as opposed to be a follower of something that someone else said. This triggered a little challenge, that my wife and I crossed while taking a closer look on a wedding present we got two years ago.
A former colleague of mine is working in a supermarket, and he was able to organize a collection of smurfs put as gift into some candy eggs. Since my wife collects these toys from the eggs, this was a neat present.
I took two pictures from the arrangement. It’s a smurf house with some smurfs in it, and there is something wrong with it. Tell me what you notice. Here are the pictures (hopefully in high enough resolution):
In a follow-up I will reveal what my wife and I noticed.
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 DojosThe 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
Testing and Management mistakes: Replacing placating with blaming
Phil Kirkham suggested in the comments on my entry about Testing and Management mistakes to do a write-up on how Tim could have responded in a better fashion. Personally, I decided to show to fashion of this: the incongruent style and the congruent style. Today I will begin with the incongruent one, providing a more congruent view in a later blog entry. Just in case you haven’t read the source of inspiration from Michael Bolton, yet, you can read it here.
Continue reading Testing and Management mistakes: Replacing placating with blaming