Last Saturday we had the first testautomation coderetreat in Munich. Woohoo! This was a kickstart for this new coderetreat format – besides the original one from Corey Haines, and the Legacy Coderetreat format from J.B. Rainsberger. Here is my report from the facilitator’s point of view and with some hints about what I am going to try at different other follow-up coderetreats.
Continue reading Testautomation Coderetreat No. 1 – A reportCategory Archives: Testing
Software Testing
The BDD pitfall
Last week I went to the 2bd SoCraTes conference, the German Software Craftsmanship and Testing conference. We did two days of open space discussions, and we all had great fun. One thing though that caused me some extensive amount of trouble, was the amount of sessions around BDD.
Some time ago, I wrote about the given/when/then-fallacy. But this time was different. Despite the amount of emphasize that BDD puts on the ubiquitous language, I was shrugged by the fact that folks were pointing to different things while talking about BDD: It seems BDD suffers from the same thing that it tries to prevent: having a common understanding about stuff.
I don’t know where this particularly comes from, and I also saw a couple of bad scenarios when it comes to the usage of tools like Cucumber or JBehave. I don’t consider myself a BDD expert, and people pointed out that I do something different around acceptance tests. Still I thought to expose some of my thoughts about some of the examples that I ran across recently – and helped out improving. Here’s my though process on two of these scenarios.
Continue reading The BDD pitfallMy future wishes for software testing
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 testingThe 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 SystemMy 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