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
Continue reading Tell a story at the daily standup
This is the title of a talk I submitted to two conferences this year. At one it made it into the program: the Agile Testing Days in Potsdam. It’s a pity that I got sick over the weekend, so I won’t give that talk. Anyways, I thought people might be interested in the talk, so I wanted to share some thoughts on my blog about it.
Continue reading I don’t want to be called QA anymore!
Today, I published the first set of attendees for the GATE Workshop on 1st of October in Hamburg, Germany. By name, these are
Maik Nogens, Meike Mertsch, Eusebiu Blindu, Sven Finsterwalder so far.
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.
Continuing the What you always wanted to know about Testing and Quality Assurance series, we will take a closer on Agile Test Management today. Please note that I consider the term Agile Test Management to be an oxymoron. The team is self-managing in Agile, and there is no dedicated manager role to grant the team enough power to manage itself. This surely needs lots of trust – especially when transitioning from a more traditional environment. but is essential to any team effort.
Continue reading What you always wanted to know about Testing and Quality Assurance – Agile Test Management