Before I joined it-agile in 2010, I was exercising up to six times per week. When I joined it-agile, I knew I would be traveling more. It took me a bit more than four months until I noticed that I lacked some exercise. So, in January 2011 I started to go running, as this seems to be the only exercise compatible with a travel-rich job. Last year, I completed a 31,1 km run close to my hometown. While learning to to run, I noticed lots of parallels to Exploratory Testing. Here are the things that stuck.
Over the course of the past year, I had the opportunity to work with some great trainers. I learned a lot from them, and by delivering co-trainings together. Today, I decided it was time to reflect on some of that stuff. Blog entries work great for me to do so. Here is a first blog entry in a series of entries to come.
Stick long enough into testing, and you will face an argument pro or contra traditional test cases. Most of us have been there. Most of us know what worked for them in the past. Most of us won’t agree with each other. During a particular co-training, I became aware and reminded again about process control, and realized why I think exploratory testing is better suited in most software development shops around. Let’s see what process control consists of, and check in which of the models testing falls, and where exploratory testing can help you.
There is a misconception floating around that Agile Testing is mostly about automated checking. On the other way the whole testing community fights since decades about the value of test automation vs. the value of exploratory testing. I find these two different extreme position unhelpful to do any constructive testing. Most recently I ended up with a model that explains the underlying dynamics quite well, to testers, to programmers, and to their managers. Here’s the model.
On my way back from the Agile Practitioners Conference 2013 in Tel Aviv, Isreal I digest lots of information and bar discussion content. After attending Dan North‘s tutorial on Tuesday, I have six sheets of paper on notes with me, that will probably fill my writing buffer for the next half year. Time to get started. Here I connect Dan’s model of the Three Ages to Software Testing.
Yesterday during my keynote at the Agile Testing Days 2012 I said I see a lot of standups, where testers report on their yesterday’s work in the following way:
Yesterday I tested the thing with the stuff. I found some bugs, and filed them. Today I will test the foo with the bar.
I think this is horrible test reporting. While concluding the fifth beta of Elisabeth Hendrickson‘s upcoming book Explore it! I found a few more hints in the same direction. On the same line I will relate good test reporting during the standup to what for example Michael Bolton talks about when it comes to test reporting – we should tell three stories during test reporting:
- a story about the product
- a story about testing
- a story about the process
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.
A while ago, I called for some participation on the state of our craft. I promised back then to present some intermediate answers in late January. Here they are.
One of my colleagues made a claim yesterday which I would like to put some numbers on. I raised the question on twitter, and received suspicious answers about the numbers of my colleague. Please forward this survey to anyone you know who is programming: http://www.shino.de/programmer-survey/ It consist of just four question, so you should be able to answer them in a few minutes.
Over twitter I also received the feedback that things are worse for testers. I would like to put numbers on that as well. Therefore I also put up an equally small survey for tester: http://www.shino.de/tester-survey/ Please forward this survey to anyone in the software business that you know of.
From time to time to I will publish some of the results. I aim for end of January for the first set of data.
Last Saturday the first German Agile Testing and Exploratory workshop took place in Hamburg, Germany. As the content owner I asked every participant upfront in an e-mail to prepare a statement on the following three questions:
- What is your position in regard to Agile Testing?
- What is your position on Exploratory Testing?
- What is happening in the field with regard to Agile and Exploratory Testing?
The participants for this first workshop were (in the picture from left to right)
Here are the insights from my notes and memories.
As we have received fewer submissions so far than we hoped, I think I need to write something about my expectations as I consider myself the content-owner of the German Agile Testing and Exploratory Workshop. What strikes me when I visit teams claiming to do Agile, I often find their teams doing either of the following:
- Exploratory Testing – applied bad, without debriefings, charters, and without the collaboration that would make it more structured, and provide product owners and managers with the information they are asking for
- Test Automation – mostly done by programmers or testers who have a strong background in programming, sometimes not even beyond unit tests on an integration level between multiple classes
As I see immense drawbacks focussing on one or the other of the two approaches, I am convinced that Agile teams can do better by using a combination of both worlds. Exploratory Testing alone might leave an Agile team with the problem, that exercising all the tests becomes a burden over time – especially when programmers lack proper unit tests. Test Automation – even with ATDD – alone ends with the drawback that for human obvious holes are left in the software.
That said, I am interested in good applications of Exploratory Testing on Agile teams, what helped them succeed, and what could help them manage their Exploratory Testing. I am also interested in Test Automation topics, how they helped Exploratory Testing gain momentum. Finally, I am also interested in talks about how to prepare the tester’s mind, and where the connection between traditional testing techniques and Agile testing techniques might be.
So far, there is a strong balance towards Exploratory Testing in the schedule. I like this to some extent, but I would also see more attendees on Test Automation, ATDD, BDD, you name it. So, if you think you have something to contribute, drop Maik or myself a line, and we may have a discussion about that. IF you’re unsure what GATE will be, read my initial blog entry on it.