Today I read an article on various approaches for Product Backlog Grooming meetings. Underlying the write-up there seemed to be some misconceptions about the purpose and goals, the duration, the participants, the approach, and how often and when to hold a Product Backlog Grooming meeting.
On the bottom of James Bach’s recommendations of people there is a small paragraph:
That One German Guy
Germany has no excuse. There are TONS of smart people there. How is it only one intellectual software tester has emerged from the ISTQB-addled masses to demand my respect with his work? My theory is that Germany has a more command-and-control culture, which perhaps disparages independent thought of the kind required to achieve excellence in testing. This pains me, because I am descended from Germans and I would love to visit and teach there.
Anyway, the one German guy who shines in my community is Markus Gaertner. I’ll do a write-up on him, shortly.
Yeah, it’s about me. From time to time I am asked by James and other people in our community where the German testers actually are. Here are some folks I am in touch with, that have raised my attention, and I think will need some attention from the wider community. There is not only one guy testing in Germany, seriously.
Here is a thing I learned from J.B. Rainsberger at XP 2012 in May 2012. I used it in the past months quite extensively for debugging communication based upon the Satir Communication model. While doing some research for this blog entry, I discovered that some others have also written about the topic. I especially liked Dale Emery’s Untangling Communication which seems to go a bit deeper than my understanding of the topic. Anyways, here’s my write-up which might give a different perspective.
Recently I restarted the Wandering Book. The Wandering Book is a tiny book passed on from Craftsman to Craftsman, fromCmmunity to Community intended to collect the Zeitgeist of Software Craftsmanship. I deliberately decided to start passing this to the German Softwerkskammer user grups. The idea is to collect the different notions, sort of a guest book of all the local events happening all over Germany.
Since the first book seems lost, I decided to put a disclaimer in it at the beginning. Here is the initial entry I made.
There is a misconception floating around that Agile Testing is mostly about automated checking. On the other way the whole testing community fights since decades about the value of test automation vs. the value of exploratory testing. I find these two different extreme position unhelpful to do any constructive testing. Most recently I ended up with a model that explains the underlying dynamics quite well, to testers, to programmers, and to their managers. Here’s the model.
I came across this blog entry earlier this week. While I also can resonate with most of the books that Soronthar read from Jerry, I felt like to tell my own story with Jerry’s books. Among my colleagues I am most well-known to cite a lot from Jerry’s work – mostly that is because I took the effort to type-copy the references to his meaningful laws on my computer, so that I can pull out Rudy’s Rutabaga Rule from the Secrets of Consulting quite easily:
Once you eliminate your number one problem, number two gets a promotion. (The Secrets of Consulting, page 15)
But that’s not where my story with Jerry started. Here’s the full story.
One word of disclaimer: I know a lot of people that are not comfortable reading Jerry’s books. To most of them I have a lot of respect. And I think it’s ok, if you can’t read his books. I am just going to share, what I learned, and what sticks even years later.
I have a confession to make: I am addicted. In this blog entry I would like to warn you about it, so you don’t go the same route down as I did. Don’t follow me on that path, even if the temptation looks promising and convincing.
You don’t have a clue what I am talking about? I talking about conferences. I am addicted to them. In this blog entry I would like to foster my coming-out, and provide the things that make me addicted. Don’t fool yourself that you won’t become addicted. Stay away from conferences! Don’t go there!
A while ago, Elisabeth Hendrickson wrote a piece on endings and beginning. There was one sentence striking out to me:
I believe that the traditional software QA model is fundamentally and irretrievably broken.
I think there is something fundamentally broken in the way we are used to build and ship product. Triggered by Elisabeth I had an eye on stuff while starting to read The Psychology of Computer Programming only recently – yeah, I didn’t read all of Jerry’s books so far. Shame on me. These are my early raw thoughts on what might be broken.
Stick in software testing long enough, and you will see enough ideas come and go to be able to sort out the ones that look promising to work, and the ones that you just hope will go away soon enough so that no manager will pay any of her attention to it. There have been quite a few in the history of software testing, and from my experience the worst things started to happen every time when someone tried to replace a skilled tester with some piece of automation – whether that particular automation was a tool-based approach or some sort of scripted testing approach. A while ago, Jerry Weinberg described the problem in the following way:
When managers don’t understand the work, they tend to reward the appearance of work. (long hours, piles of paper, …)
The tragic thing is when this also holds true for the art of discovering the information about how usable a given piece of software is.