Teaching Agile Testing
February 13th, 2007
Filed under Agile, Ruminations, Thinking Like a Tester
You probably already know that I offer an Agile Testing class. If the feedback forms from participants are any indication, it’s a pretty good class. Participants get a lot out of it. But something is bothering me about the class. It can be better. And I’m all about continuous improvement, so I want to make it better.
One participant summed it up when she said, “This is one of the best general introductions to Agile I’ve seen.” Initially, I took her words as a compliment. In fact, her words are one of the reasons that Dale Emery and I decided to adapt the Agile Testing class into Developing Agile Teams, our general Agile class.
But it recently occurred to me that those kind words are a double-edged sword. They suggest that the Agile Testing class covers Agile well, but they also suggest the class could emphasize Testing more.
It’s true that my Agile Testing class, in its current incarnation, emphasizes Agile practices and values over specific Testing techniques. That was deliberate.
When I set out to design the class, it seemed to me that an Agile Testing class should not try to cover testing basics like boundaries and other testing heuristics, testing from state models, equivalence class partitioning, all pairs analysis, and the like. If a tester needs to learn these kinds of general test design techniques, there are numerous resources available.
Further, many of the practices that interfere with succeeding at Agile Testing have to do with the tendency for test teams to be isolated, to over-document, and to emphasize plans, process, quality gates, and repeatability over adapting, whole-team collaboration, and rapid feedback.
Thus, I designed the exercises and simulation in the Agile Testing class to emphasize adapting, collaboration, feedback, and other Agile values, seen through the lens of Testing. The Testing part wasn’t absent; it just wasn’t presented as a specific set of Testing skills.
However, I’m realizing that my Agile Testing class would benefit from more emphasis on specific testing skills and practices. I think it should still emphasize Adapting, Feedback, Collaboration, etc. But I’d like to increase the emphasis on testing practices.
With all that in mind, I have a question for you, my reader:
What specific skills or practices would you expect or want taught in a class titled Agile Testing, and to what level of depth?
4 Comments
Leave a Comment
Because of the rise in blog-spam, I've turned on comment moderation. If it takes a while before your comment appears, I hope you understand.
Moderation Policy: I approve substantive comments. I reject ads. And if I don't know whether it's substantive or advertising, it sits in my moderation queue until I get sick of looking at it, at which point I reject it, kind of like the questionable meatloaf in the fridge. But please be assured that I think long and hard before clicking that reject link. I really am grateful for every comment any human takes the time to make. (Spambots, not so much. But if you're reading this, you're probably human.) So please contribute to the conversation...
Feb 13, 2007
5:57 pm
I would suggest hitting on the software available to handle mocking/stubbing. This was the hardest part of testing when I started out. Some suggestions are NMock, RhinoMocks, or EasyMock. I personally use RhinoMocks.
A developer can also handle mocking with their own code, but utilizing the tools out there can speed development time.
Very good idea to emphasize testing because it is the majority of the daily life of an agile developer.
I currently work on a 15 developer team practicing agile.
Keep the classes going.
Feb 14, 2007
9:32 am
I wanted to respond with something pithy and concise, but struggled. The answer came in the title of your prior post on this blog: “Thinking Outside the Explicitly Defined Acceptance Criteria Box”.
Lately, James Bach and I have been trying to get a handle on the Universal Test Procedure (this is intended to be somewhat whimsical, of course). The naive, v1.0 view of this is “Try it and see if it works.” A more sophisticated take on it, we think, it is “Try it to learn /sufficiently/ about how it /can/ work and how it /might/ fail.” That’s v1.5.
Your pre-Agile course, Creative Software Testing, focused on variables and variation as rich sources for test design ideas. That has been inspiring to me. One of the things that I see from some promoters of Agile practices is a limited vision of what can go wrong, based on what I view to be oversimplification of the models (and a limited number of models) for a given testing problem.
So: if I were to teach a course called Agile Testing, I’d certainly preserve your focus on right-sizing documentation and process stuff, but I might emphasize your earlier material, in which you point out the number of ways in which things can be different. That leads to a richer set of oracles and coverage models, and that allows us more easily to engage in “Thinking Outside the Explicitly Defined Acceptance Criteria Box”.
Cheers,
—Michael B.
Feb 19, 2007
9:25 am
I enjoyed this so much that I wrote up a reply that was, well … long. Instead of posting here, I wrote it up on my blog: http://xndev.blogspot.com/2007/02/teaching-agile-testing.html
Regards,
–heusser
Jun 07, 2007
11:40 pm
My contribution is this, encourage testers to own the requirements, and treat them not as carved in stone, but rather the first drafts of design drawings for a magnificent building, in which they will have to work. It is their responsibility to see the requirements blossom through cleverly crafted acceptance tests so that the end building is safe for all to work in and does its job well.