Difference between agile testers and everyone else?

This isn’t a new question but Matt Heusser recently wrote a blog post that got me thinking. My question here is, what is it that differentiates agile testers? Specifically, what skills differentiate agile testers? Surely there must be something specific about them aside from the environment and ideology or the term wouldn’t exist, right? Let’s see…

A question to think about in the mean time: is it possible to be an agile tester while not working on an agile team?

Environment
Agile Testing by Crispin and Gregory discusses this topic in quite a bit of detail. Topics such as tools, what a tester should be doing at a given point in an iteration, the whole team approach (though, I’m not sure what this means exactly), and the quadrants of agile testing are discussed. I suppose these things are in addition to the normal things that define agile teams such as daily stand-up status meetings, short development iterations, short feedback looks, and whatnot. There are five principals according to the book that define agile testers: continuous feedback, direct communication, simplicity, response to change, and enjoyment. What I see here for the most part is process definition and a little ideology, but nothing that uniquely defines what an agile tester is.

Ideology
Bret Pettichord wrote his Schools of Software Testing article almost 6 years ago now. Some people find the method of defining a school in this manner decisive, but I think it may be useful for this conversation. His article pretty succinctly describes the ideology of agile testers, though I rarely see people that self-identify into this school. Some defining characteristics are heavy emphasis on tool usage (specifically automation), defining when something is done through acceptance tests, and a lessened emphasis on documentation. The linked paper goes into more detail on this topic.

Defining skills?
I came across a recent linkedin thread talking about this very topic although there has been no clear conclusion yet. The million dollar question that I have so far been unable to answer nor have I seen anyone else answer. There is a distinct emphasis on tool usage among agile testers. There seems to be an emphasis on programming skills among agile testers. But what about specific testing skills? Critical thinking, modeling, systems thinking, observation, various testing techniques, bug reporting (RIMGEA for you bug advocacy folks out there), the list goes on. Is there some skill that is unique and highly developed among agile testers? Some skill that defines them?

After I started writing this, Shrini and Kulkarni and Lisa Crispin had a conversation via twitter about this very subject.

Ideology can’t be the only thing that defines agile testing, can it? What do you think? Help me out here…

My three months in BBST and ending radio silence

The last three or so months I’ve been a little more quiet than normal. Yep, even for my normal introverted level of quiet. I’ve happily committed a pretty sizable amount of time to the BBST Test Design, Instructors course, and co-instructing my first class for AST (Bug Advocacy).

The instructors class was really useful, mostly in the sense that it gave a good base of education theory and also in the sense that it gave a good method of communicating with students. The one area I found lacking in the course was how instructing works practically. Things like class flow, how to do certain common things within moodle, how much or little to interact with students, and so on. Some of this was resolved while co-instructing for the first time which I’ll speak to in a bit. Overall though, the class was a pleasure and very informative. The instructors manual created by Dr. Kaner, Dr. Fiedler, and Doug Hoffman was wonderful, useful during the instructors course and even more so for my first time co-instructing.

On to my first time co-instructing a class. Though the students have finished their parts of the classwork, there is still work to be done by the instructors. I participated minimally his time and frankly felt lost quite often despite talking with the other instructors. It seems like this is a common experience for first timers though. Learning the administrative side of moodle as well as figuring out my role as a co-instructor was trying. The experiences in the first class should make the next classes much better. That’s a good thing since I plan to lead classes eventually. I think early communication with new instructors and having some set of tasks specifically for new instructors to ease them in would go a long way to make that experience better. Actually, just something listing typical tasks that new instructors are generally successful with would be helpful. I aspire to participate much more for the next class which is in January if memory serves.

Oh! I’m also really excited to be helping with TWiSt an an editor. I edited my first episode this past week. If you haven’t listened yet, you can download the mp3 here. Free registration is required.