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 testingTag Archives: it-agile-blog-planet
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!What 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 2012Dear 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?”Tracking testing on the Scrum taskboard
Today, a colleague of mine, Norbert Hölsken, started off a discussion in our internal communication channel. He asked:
How do you treat bugs on the taskboard that are found during testing? Create a new test for each bug, and put the test task back in ToDo? Or create a bug, and a bug-follow-up testing task?
As it turns out there are a lot of valid reasons to do it one way or another. Yet, the answer “it depends” does not help – neither a Scrum Coach, nor a tester working in a Scrum environment. So, I started raising some of my experiences and concerns, and some of my other colleagues replied as well.
Skip forward three hours, and I am writing a blog entry on my thoughts about it.
Continue reading Tracking testing on the Scrum taskboardATDD by Example
It seems that my book ATDD by Example: A Practical Guide to Acceptance Test-Driven Development is now available at least for Kindle. I received my first physical copy last week. So far amazon lists the physical copies due for end of this week.
It’s been quite a journey since I approached Kent Beck with the idea for the first time two years ago. As I was unsure whether I could actually write a book in a non-native language, I decided to give it a try during the Pragmatic Programmer’s Writing Month in November 2010, and completed the first part from three within the first month. Skip forward a few months, and there it finally is.
Now, with every book you as the author face two main struggles:
- when to stop believing that you can incorporate new stuff that you learned in the meantime so that the content will not be out-of-date
- when to stop polishing up what you have so that any mistakes that are still there get exposed to the public – and finally show your readers how bad an author and writer you are
For the first of the two points, I was glad to incorporate some of the stuff that I learned while finishing up the major draft version around New Year’s and now in a series of articles for inform IT. The first one of these will get you started with ATDD. It’s called Getting Started with ATDD: Overcoming the Biggest Mistakes Right from the Start.
For the second point, I have a deadline nearby middle of July to return any corrections for the second printing by then. So, if you happen to find any “bugs” in the final manuscript – and I know there are lots of it, although I decided to read through it several times – I would be more than glad if you dropped me line about it, so that I can get it corrected in the next printing.
I figured that I spread around some easter eggs from time to time in the projects that I am involved in. If you happen to find one, please keep it to yourself in order not to spoil others who are looking for it. I think I should set up a challenge around this some time in the future. Maybe I will spread a free copy of my next book then.
On the title, why did I call it ATDD by Example rather than Specification by Example by Example: Well, I think the name “Specification by Example by Example” would be stupid. A recent client gig where I consulted on “Specification by Example” I also found myself in the situation where a business expert asked me: “Does Specification by Example mean ‘all specifications’?” Since then I am convinced that we didn’t solve the naming problem – and I wonder if we will have to. For more on the name, make sure to read the preface. I explain why I picked that particular name – and a whole lot more on the background.
One final word: If you enjoy the book, tell others, so they read it. If you are disappointed or have any criticism, please tell me so that I can improve myself. Thanks. Enjoy.
Testautomation Coderetreat postponed
If you have followed this blog long enough, then you might have crossed the Testautomation Coderetreat in Munich which we planned for June 2nd. I apologize for having to cancel the first meeting on such a short notice, but we found it unprofessional to stick to the date. Here is the reason we had to postpone this date:
While this might mean, that I will have to do lots of other duties in the next few weeks – well, at least my priorities will change a bit – we also planned in a replacement for the for the first testautomation coderetreat. The new date is now the 11th of August, again in Munich, Germany. Here is the link to the event on eventbrite, please sign up there: Testautomation Coderetreat Munich.
Ukrainian Testing Dojo 2 Report
This is a guest blog entry from Andrii Dzynia. He contacted me a while ago on Testing Dojos, and wanted to run a session in Kyiv, Ukraine on his own. At their first public Testing Dojo they seemed to have had a great time. You can find his original blog entry in Russian on his blog.
Continue reading Ukrainian Testing Dojo 2 Report