Huib Schoots approached me late last year regarding some contribution for the TestNet Jubilee book he was putting together. The title of the book is “The Future of Software Testing”. I submitted something far too long, so that most of it fell for the copy-editing process. However, I wanted to share my original thoughts as well. So, here they are – disclaimer: they might be outdated right now.
Continue reading My future wishes for software testingMonthly Archives: July 2012
The Testing Quadrants – We got it wrong!
The Testing Quadrants continue to be a source of confusion. I heard that Brian Marick was the first to write them down after long conversations with Cem Kaner. Lisa Crispin and Janet Gregory refined them in their book on Agile Testing.
I wrote earlier about my experiences with the testing quadrants in training situations a while back. One pattern that keeps on re-occurring when I run this particular exercise is that teams new to agile software development – especially the testers – don’t know which testing techniques to put in the quadrant with the business-facing tests that shall support the team. All there is, it seems, for them is critique to the product. This kept on confusing me, since I think us testers can bring great value. Recently I had an insight motivated by Elisabeth Hendrickson’s keynote at CAST 2012.
Continue reading The Testing Quadrants – We got it wrong!Actually, there are best practices
A while back I ranted about best practices. Among the things I found in that particular blog entry is that there are quite some definitions for the term “best practice” out there. Nowadays, if it’s not on google, then it doesn’t exist. For best practices google it turns out is quite capable of delivering a definition. Although I resonate with the principles of context-driven testing, I recently found the second principle unhelpful. The second principle states
There are good practices in context, but there are no best practices.
Like many other people that I respect I used to start ranting about best practices whenever people would ask for them. Particularly in training situations, though this does not help so much. J.B. Rainsberger‘s introduction to the Satir Communication Model helped me understand why that is.
Continue reading Actually, there are best practicesWhat I learned at Test Coach Camp 2012
A few days before CAST 2012 I attended Test Coach Camp in San Jose, CA. There were thirty passionate people spending time exchanging coaching tricks and ideas. Here is what I learned in these two days.
Continue reading What I learned at Test Coach Camp 2012CAST 2012: Helping Thinking Testers Think
At CAST 2012 Geordie Keitt held an introduction to the work of Elliott Jaques in Organizational Psychology.
Continue reading CAST 2012: Helping Thinking Testers ThinkCAST 2012: The Testing Dead
At CAST 2012 Ben Kelly spoke about the Testing Dead. I think it was a reference to some folks claiming testing to be dead, while Ben rather pointed out that testing is not dead, but rather undead with zombies carrying their undead bodies in front of a computer to do a 9-5 job.
Continue reading CAST 2012: The Testing DeadHow would you test this: Passenger Airline System
This is an experience report that falls in many categories at the same time. I think the most remarkable one is the personal fail category (hooray, I learned something!).
As a consultant I do some fair amount of traveling. Most of the time I stay on the ground, though on my most recent trip to San Jose, CA for Test Coach Camp and CAST that was not an option. So, while lying jetlagged in the hotel room, I decided to blog about my trip here, and why I ended up testing a passenger airline system, which bugs I found, and which follow-up tests I can imagine to run from here.
Continue reading How would you test this: Passenger Airline SystemDear Management,
Dear Management,
I owe you an apology. I have misled you by listening to someone who misled me instead of building my own opinion based on the sources that someone lied out. That said, I have been wrong by repeating rants, and inventing my own once based on a false premise. As a math teacher of mine once explained to me: Based on a false premise you can proof anything.
I found people willing to challenge my belief system, and I thank these people for that. They made me go the hard path to building my own opinion on the topic, and on the sources that the one who initially misled me pointed to. I was amazed that I came to a different understanding. A similar one in some sort of ways, a different one in the most basic claims of that other person. I am thankful for having the opportunity to learn something from this.
And now, beware alpha animal like betrayer of my thoughts. You not only lost a follower of your rants when I reached my own insights, but you also lost my respect. From now on I will tell others about my perspective on things, and where I think you have been astray. I will provide my own picture, and criticize your ideas wherever I feel it’s appropriate. I will warn others from you, if you cannot back up your claims with references. I can.
Sincerely yours
learning employee, and hardest critique.
An Afternote
I didn’t relate this to any real thing that happened in the text in the hope that you will notice how and where you have been misled in the past. Instead of being depressed about it, recognize your failure, learn from it, and confront the other person with your new insights. The worst thing that might happen is that you find out that this particular person is not interested in debating. In that case make sure to turn your Bozo filter on. Things could be worse.
My biggest take-away from Bug Advocacy
At times I find quite interesting things in topics that I don’t seem too particularly interested in. A recent example – again – comes from Let’s Test in May 2012. While at the conference, I read through the program and thought that I don’t need to learn anything new from recent trends in bug reporting. Preferring to work on Agile projects, I don’t think I will use a bug tracker too much in the future.
On the other hand, I knew that I had signed up for BBST Bug Advocacy in June. So I kept wondering what I will learn there, and whether it will be as work intensive as Foundations was. I was amazed at some things. This blog entry deals with my biggest learning: for building blocks for follow-up testing – something I think a good tester needs to learn regardless of their particular background.
Continue reading My biggest take-away from Bug Advocacy“How do you do all that stuff?”
I am often approached with the question whether I cloned myself. At least, when taking a look on the amazon pages for my book, this might be the case; yet I more seriously added my amazon accounts as authors for both the German and the American amazon pages.
A few months ago I had an interesting coaching session on whether or not I am burned out (there are questionnaires for this, I would claim these results do not hold for me), I put on too much work, etc. During that session I found myself confronted with the Diathesis-stress model which explains a lot of my thoughts around this topic.
While I write this, I am in Hamburg, Germany. So, imagine a ship. A ship has a keel, an anchor, a loading depth, and how deep the water currently goes. These four factors influence how fast a ship may sail. Let’s take a look on these four factors, and how they relate to the model as an analogy.
Continue reading “How do you do all that stuff?”