Agile Testing – Agile perspective
Did you miss my previous posts that relate to this? Consider reading these as well. And yes, I will be exaggerating in this post as well.
Agile Testing – Traditional testing perspective.
I did explain some parts of the Agile perspective after I had been to the Agile conference. Some of my experiences also come from the local Agile communities like Agile Skåne, Öredev and my company Jayway. I will mostly relate to the global community here.
Originally Agile people were mostly programmers that realized that the important stuff is not only the software itself, but how the customers will gain value from it. But then came the Agile wave; all companies, teams, managers, developers, contracts, practices, templates <enter anything here> need to transition/change to/become Agile. Out of this comes a community consisting of process people, coaches, CSXs, Agile transition coaches, management consultants and a few people that can actually develop software that stuck around.
At the Agile 2012 conference I met a whole bunch of these people. They do know about software development and the processes around it. However, digging through the surface, it is quite obvious that Agile testing mostly stands for unit testing and automation. Just a few know about the Agile testing quadrants and the value of different types of testing. When explaining to people at Agile conference about exploratory testing, getting the question of how that fits into TDD is just a mess. It quite clearly shows the ignorance about testing that the Agile community as a whole has. (Yes, Rob Sabourin gave me an example of how ET and TDD relate and I agree with him, however only with deeper understanding of both its possible to draw those conclusions.) And then to be honest, if I would have dug into the Agile coaches and transitioners knowledge about TDD, I am still not sure I would have found much knowledge there either.
Alas, not very many people that I met of the regular Agile crowd know anything /at all/ about testing as a discipline and how it is actually done. Of course, any team member should be capable of taking on any task right?
I have also seen examples where people that don’t know anything about testing try to just append testing into the Agile values, example here. While the intentions might be good with that blog post, I am not convinced enough thought was put into it.
- knowledge of testing is lacking
- mentality is that good programming practices like TDD are enough to create good quality software and deliver value to the customer
- whatever problems you struggle with are related to the Agile wave
- you think testing as a practice is dead
Will you ever be able to define what Agile testing is? Why do you even bother? Or you might not even care.