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.
Over the course of the Let’s Test conference in Runö, Sweden, I noticed a problem with context-driven testing. In the past one or two months this turned into two problems I see with context-driven testing. I finally decided to put them out there for further discussion. I hope a lot of you don’t agree with me – and I hope a lot of you folks speak up.
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.
