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.
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.
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.
The second GATE workshop will take place on September 8th 2012 in Munich, Germany. GATE is a workshop that falls into the series of peer workshops on testing like LAWST, LEWT, DEWT, and SWET.
As the content owner of this workshop, I worked with my peers to identify the following main theme:
The future of Agile and Exploratory Testing
We expect participants to submit content in line with this theme. We are interested in contributions such as
innovative approaches to testing
combining session- and thread-based test management
collaborative test chartering
testing in practice (Testing Dojos, Testautomation Coderetreat, Hands-on testing)
Feel free to contact us if you are unsure. We will be most glad to provide you feedback.
You will find more detailed information on the GATE homepage over the course of the next months.
I look forward to meeting lots of testers in Munich in September.
At the Let’s Test conference, the first ever context-driven testing conference in Europe, Michael Bolton delivered the first keynote on Monday morning. He was talking about context-driven testing – what else?
I remember a talk from Cory Foy back at XP 2010 in Trondheim, Norway. He referred to Corey Haines as the happiest guy in the world. Although he lost his job, he started to travel around in the world, from shop to shop, from company to company. He was able to learn so much in a single year that he continued his journeyman tour after that.
One thing that Corey Haines invented alongside is a Coderetreat. Up until the global day of Coderetreat last year on 3rd of December I didn’t know what a Coderetreat actually is. At the core are six sessions of 45 minutes each where you solve a problem in code. Then you delete your code, and do it again – maybe with a different pair partner.
Recently J.B. Rainsberger invented the idea of a Legacy Coderetreat. The idea there is similar to a Coderetreat, but have to deal with legacy code and improve it. I attended one Legacy Coderetreat in the mean time, and it was quite interesting to solve the problem of a big mess of code.
At some point back last year I got in touch with Corey Haines and Adam Goucher. We bounced some ideas back an forth, and I refined them later with Adrian Bolboaca to yield a Coderetreat for testautomation code. Now I am happy to announce the first Testautomation Coderetreat in Munich on June 2nd.
As a prequel to the Let’s Test conference in May, I interviewed some of the European context-driven testers. Today we have Ilari Henrik Aegerter, the first participant in this series. He’s a tester and coach that was highly recommended by James Bach in the past few months.
As a prequel to the Let’s Test conference in May, I interviewed some of the European context-driven testers. Today we have Martin Jansson, one of the test eye bloggers.
