In the past there have been multiple folks proposing a rename of the famous testing quadrants that Brian Marick wrote up a couple of years ago. Lisa Crispin and Janet Gregory labeled them Q1, Q2, Q3, and Q4 in their Agile Testing book. That naming misleads some folks as they think about a progression in the four quadrants. I recently read something that triggered a thought. I think we should rename these quadrant completely, and drop the counting digit at all. While several other folks have tried to find new names for the quadrants, I came up with a different thought: let’s try to find person names for the quadrants. Here is my first proposal for those.
Time and again I run into an ambitious tester that presents me his (or her) latest idea for a testing challenges. “What do you think about this situation where you set out the tester to learn X?” “You could provide product foo to the tester, and have him learn X. What do you think?” Time and again, I think there is something seriously flawed with this approach to create and design testing challenges.
This morning, when I took a look at twitter, I noticed a direct message from Michael Bolton on my latest blog entry on learning:
In your blog post on learning, you’ve left out community, and bafflingly to me, practice.
Wholeheartedly I thanked him for the idea for today’s blog entry.
We live in a cruel world. Our profession of software development is very young compared to other fields such as banking, hotels, or carpenters. I truly believe we have taken a couple of wrong turns in our short history. In this blog entry I try to shed some light on it by some seemingly unrelated stories.
I remember a lively discussion at DEWT 4 around self-education, and how you would know whether or not you are improving. There are lots of ways to engage with self-directed learning – in software testing, software development, leadership, and other areas surrounding this field. But with all these methods around, a single question remains: How do you know whether you’re improving with whatever technique you follow?
Have you every worked with a fake tester? How would you notice? How would you notice how much they are faking? Triggered by a discussion back at DEWT 4, I had an insight triggered by a book that I read earlier in my life: The No-Asshole Rule from Bob Sutton. Let’s see how fake testers and the no asshole rule connect in our workplaces.
While I was cleaning u my bag that I carry around with on various travels, I found the following notes. They were part of my introduction for the keynote at the Agile Testing Days 2012 in Potsdam, Germany. My talk was on “adaptation and Improvisation”, drawing an analogy from the famous geek movie “The Matrix”. I wanted to keep these notes somewhere. That’s why I decided to put them up on my blog. Hope you like it. Imagine Morpheus’ and Trinitiy’s voice.
Years ago, I wrote a book on ATDD. Only years later I notice the value that this practice can bring to an environment with multiple teams working together on the same platform. The connection to scaling agile in the larger enterprise wasn’t that obvious than it became when I started to dive deeper into how to scale agile. Though, most larger enterprise struggle with getting one team running, scaling has become the latest fuzz in the agile community. Let’s see why ATDD is relevant for this sort of environment, and how you can challenge your team colleagues about it.
I have to admit: I am German. Us Germans are well-known in the world to deliver good results. That said, we are very dedicated to deliver efficient results. There is one thing that troubles me about that. Having our main business in Germany, I often face questions with regards to efficiency while introducing agile methodologies. You can efficiently drive your car right into a wall. That would be very efficient, but unless you try to kill yourself, not very effective. The English saying ‘don’t try to run before you walk’ expresses this gallantly from my point of view. Let’s explore that thought.
Before I joined it-agile in 2010, I was exercising up to six times per week. When I joined it-agile, I knew I would be traveling more. It took me a bit more than four months until I noticed that I lacked some exercise. So, in January 2011 I started to go running, as this seems to be the only exercise compatible with a travel-rich job. Last year, I completed a 31,1 km run close to my hometown. While learning to to run, I noticed lots of parallels to Exploratory Testing. Here are the things that stuck.