Agile testing – Traditional testing perspective
If you haven’t read my post about bridging communities, please start there.
In many of the places and discussions I have been this year, people have been trying to define what Agile testing really is. And it is quite interesting that even 3 (almost 4) years after THE book on Agile testing came out, people are still trying to define what it is. What has interested me more is the fact that I’ve seen the area evolve in different communities, and that is what I want to share. I will talk about some extremes in communities, so forgive me if I step on toes. I am emphasizing other peoples opinions to make my point.
Traditional(ish) testing communities
I might not be completely fair to all the people involved in the communities of TestZonen and SAST, but now that I want to make my point I need to be relentless. Even though I don’t agree with Jagge that Agile testing is “an activity”, reading between the lines shows his actual understanding. Thank you Jagge for triggering me to explain what has been boiling in my head for quite some time.
As much as I don’t want to admit it, they still exist, the traditional testers. People in this category are traditional to different degree. But there are just too many people out there that still think of testing as document driven standardized activities to assure quality in software. Preferably in a setting where programmers and testers are on separate teams so they are not biased from the others and software is thrown over the wall to be retaliated by bug report ping pong games.
That is when the test team preferably gets smaller pieces thrown over the wall but by smaller agile teams of programmers, resulting in more numbers of pieces that haven’t been integrated before the wall throwing. And of course we need a test specification done before each and every piece and iteration resulting in more work than ever. And hey, lets create a high level definition of this in the ISTQB syllabus that no one can relate to anyway: ”Testing practice for a project using agile software development methodologies”. Nothing more, nothing less than just traditional testing of stuff created by agile teams.
And if the problem of discussing this definition (see comments) lies in not being able to get out of your own context and thinking about the difference between static vs dynamic testing (probably related to another syllabus problem), then getting over to Agile testing is a big leap in discussions.
Another example was when I attended a SAST evening seminar (about 2 years ago) about “Agile testing in Scrum”. My guess would be that less than half of the audience knew the fundamentals of Scrum, so the speaker had to explain it, taking half of the time from the actual subject. Moreover, the speaker himself explained it wrong! It was just so awful that I just could not sit there without explaining at least the fundamentals so that everyone was on the same page. Even if knowledge in Scrum is a bad example I consider it relevant in this case.
- The knowledge of Agile in itself is lacking or,
- You are stuck in irrelevant definitions or,
- You cannot relate to other things than your very own context,
Is it possible to try to make out a definition of Agile testing? Or even get close?