The first things many think about when considering Agile Testing are tools, automation, when and how to test, and the role of testers on a team. These are all very worthy topics. But which of these things are needed for success and which are nice-to-have?
Craig Knighton writes in Not In My Job Description when discussing a how teams should transition to Agile:
As a team, and by this I mean a self-organized, cross-functional team that recognizes that unless you get this challenge mastered, your products will not have the quality or timeliness that you desire. Unless quality becomes the responsibility of all team members, you won’t break the code-test cycle that is at the root of the problem. Manual regression is the software equivalent of 100% manual inspection on an assembly line. In that world, they understand that investments in automated inspection and in earlier process measurement are the key. However, a product may need to be altered to be testable through automated means – this could be as dramatic as a change in architecture or development tools. Investment in developer tests can decrease reliance on manual inspection, but this means a change in working habits for the developers. And finally, developers may need to help create the framework of an automated test suite.
This matches much of what is well known in the community. For teams new to Agile who are taking an incremental approach to adoption, the added emphasis on a self-organized, cross-functional team being a requirement and not a nice-to-have that takes responsibility for the success of the product and keeps away from the "it is not my wing on fire" mindset is important.
While on the subject of Agile Testing, we would be remiss not to mention the Agile Testing Days Conference that just took place in Berlin. Gojko Adzic wrote up a brief summary of several presentations at the conference. One of Gojko's reports on a talk given by Mary Poppendieck reports:
Poppendieck said that that “the biggest defect we have now [in software development] is tolerating defects”. She advised treating each failure (defect that escaped) as a learning opportunity. Determining the root cause of the failure and eliminating it so that the defect does not reappear in the future is the way forward.
The stop-and-fix mentality from Lean is directly related to a self-organized, cross-functional, responsible team. If the team is not working together, then the team will not stop, but one person will stop (if you are lucky). And if they do stop, they will not learn together. And learning is a very important part of software development, in fact, this reporter believes that learning is the bottleneck in software engineering.