Over the past decade I have sometimes struggled with the difference between the two. I admit that I have on occasion even described them as being the same thing. Having given it some thought, I now think differently.
The insight came to me when I had a conversation with someone about both topics recently. The courses I'm doing have different audiences, different outlines, and different expected behaviours/outcomes. Yes, there is some overlap, but not much.
I have written previously about what I believe is ET (it's an interesting post - I suggest you take a moment to read it if you haven't already). Near the end of that article, I mention Agile Software Development and the Agile Testing Quadrants, so there is some relationship between the two.
ET is sometimes described as an exemplar of the Context-Driven Software Testing community. If you read through the seven basic principles of the Context-Driven Testing (CDT) School you may see where there are similarities in the philosophies between it and the values & principles listed in the Agile manifesto. Things like:
- CDT: People work together to solve the problem
- Individuals and interactions over processes and tools
- ...face-to-face conversation
- Business people and developers work together daily throughout the project
- CDT: Projects are often unpredictable
- Respond to change
- Welcome changing requirements, even late in development...
- Deliver working software frequently...
- CDT: No best practices
- Continuous attention to technical excellence and good design ...
- The best architectures, requirements, and designs emerge from self-organizing teams ...
So what are some of the differences?
For a start, I learned and practiced ET long before the Agile Manifesto was written. That tells me that I am not necessarily doing AT any time I am doing ET. Let me say that again: if you are doing ET, that's great, but it doesn't mean you or your team are agile.
ET is something you can choose to do when you want to say "yes" to thoughtful, mindful testing that takes into account not only the people and the context involved in the project, but also the desire to provide meaningful qualitative and quantitative feedback that cannot [presently] be automated by a computer.
Allow me to illustrate an example of an ET effort compared to a standard test approach on a given project.
Let's say a particular "test case" has a step that asks you answer the question: "What time is it?"
A) A standard/traditional or automated test result might simply be:
- 5:30 pm
B) An exploratory tester may provide an answer along these lines:
- 5:30 pm ... or do you want "PM"?
- Do we need seconds? Do we need fractions of seconds?
- 5:30:42 PM EST on Thursday, 12 February 2014.
- Wait, do we care about Date/Time stamp, or just the time?
- What if I have a sundial? Is an approximation good enough?
- Sunset, dusk
- "It's Tiny Talent Time" (okay, that dates me ;))
- It's Miller time. (or whatever other beer brand you may prefer)
- Hammer Time!! (then bust a move..)
- Winter time (or other appropriate season)
- Dinner time.
- Banana time. (aside: cheers to the old EA Tools team! ;))
- Overtime. Are we getting overtime pay? Is someone ordering food? ...
- Hm, how will this input be used in the system? Are there some boundary conditions I can play with that will expose potential downstream failures?
- What kind of input validation exists on this input field?
- Can I enter anything into this field? Can I try some constraint attacks, XSS or SQLi inputs?
- Is this a required field? What if I skip it completely?
- Is there any user documentation, marketing material, or online help that provides guidance on how I should answer this question?
We have doubt and so any of the above responses may be valid in one context or another. Without further investigation we cannot be sure which subset of the above responses will help us discover interesting things about: (1) the system, (2) the people using it, or (3) the problem we are trying to solve with the given product or functionality.
You can also see how a tremendous amount of questions and information may be generated by a single exploratory tester. This blows up really fast and will likely slow down your progress through any project if you pause to do this with every single field, function or feature. (NOTE: I'm not trying to discourage you from doing ET here; I want to help you set the right expectation by understanding this reality.)
The point here is that I am describing a process of discovery and exploration, a process of learning. This is an individual's story. Testers usually/often (but not always) work alone, especially in pre-Agile days and even now on large-scale Waterfall-type/outsourced projects.
Doing ET well requires skill and practice. There are numerous models, heuristics, techniques and tools that you need to become comfortable with. [Product/System/User/Problem/Industry/Business] Knowledge comes from effective ET practice. Improved shared knowledge and understanding among the project team members is a marker of a good ET practitioner, but that's not always the case depending the team and project dynamics.
So what about Agile teams or Agile Testing (AT)?
For a start, any tester who finds him/herself alone, sitting at a computer and trying to understand the context of a feature or product, just remember: YOU ARE NOT IN AN AGILE TEAM. (This situation is a clear symptom that your team needs a good agile coach.) Exploratory Testing is a crutch in this case, a kludge. It is way more helpful to both you and your team to use your brains (i.e. to use ET) to provide good feedback quickly, however, [structured] guesswork is a stupid and inefficient way to get by. And that goes against the intention of the Agile Manifesto.
Here it is: AGILE TESTING IS A TEAM SPORT.
When I teach or coach agile teams on how to deliver value more rapidly, I don't teach ET. I get the whole team together and I ask them to work together to develop shared understanding of what they want to deliver. This may include different activities, such as:
- Lean Startup (i.e. product/feature hypothesis and assumption-checking activities)
- Story Mapping
- Specification By Example (what I consider to be the exemplar of Agile Testing)
- Team pairing:
- Product Owner (or Business Analyst, customer...) & Developer (i.e. one or more of [designer, programmer, tester, tech writer] )
- Dev & Dev (i.e. select one of [designer, programmer, tester, tech writer] and add one more from that same set, even the same role)
- Sprint/Iteration Planning - Definition of Done (and "Quality") for the deliverables
- Sprint Demonstration (i.e. take your completed, working code and give it to your customer to play with)
- and more...
To those [traditional] testers who are worried that they don't know how to fit into an agile team, here is a quick test for you. Please look at the Agile Manifesto values and ask yourself one question: Which items do you value more - the left or the right?
If it's the right (i.e. processes, tools, plans, comprehensive documentation), then, yes, you should update your résumé and seek out new opportunities where you will be happier. I will coach the remaining development team members on how to replace your testing/checking contributions with automated test scripts integrated into their build process. (The truth hurts. Agile isn't for everyone. Accept it.)
If it's the left (i.e. people, working software, responding to change), then you are open to learning new ways to interact with your development team members to provide value to the project. This requires courage. We are asking you to adapt to a new role, maybe more than any other development team member. A good starting point for you that may answer some questions during the transition is in Crispin & Gregory's book Agile Testing.
There's more to AT than what you will find in that book though. Joining an agile team is making a commitment to learning. Practicing ET also requires a commitment to learning. They have this aspect in common. ET focusses on your [individual] learning efforts and what you can do to help provide great, timely feedback to the decision-makers. AT focusses on your ability to facilitate learning and understanding among all the team members to ensure that everyone is on the same page when you deliver working software to the customer.
Yes, I believe that knowing ET will help make a better Agile Tester. You need to know more than just ET though. You can also learn to be a great Agile Tester without formally learning ET. A good agile team will provide you with the feedback you need to help you grow.
What do you think? Does this help clarify the differences and similarities?