1. Testing is organized in an agile way
2. Testing in agile development
The first refers to settings where testing is organized with backlogs, done in short(er) cycles and there is a daily stand-up. Testers are organized in a team all by themselves and maybe even locally distinct from the development team. If these teams are lucky, there also is something like a retrospective. It is not unlikely that testers are even there to sign off the work and give green lights for release. All of this is nice (the last part about signing off certainly isn't) and probably still an improvement, but testing is still a phase of its own.
The latter is referring to all kinds of testing activities that are conducted throughout all kinds of activities during a short iteration. Testers are part of the development team and not separated. The common goal is to deliver working software at the end of the iteration. To me, the latter definition fits the term agile testing a lot better than the first one. About testing techniques and methods, there isn't much change. But organizing testing and the goal of testing differs vastly. The mindset of agile testing is a whole lot different than more classic approaches. Well, this is true for agile development, but especially for agile testing. Sam Laing and Karen Greaves have splendidly summed up the changed mindset in the testing manifesto for agile testing, which I would like to comment on shortly: https://www.growingagile.co.za/2015/04/the-testing-manifesto/
“Testing throughout over testing at the end. “
Traditional approaches have testing at the end. There needs something that has been built to test it. An essential part of testing is providing information about the software, so you should go and get information as early as possible to adjust your development efforts as soon as possible. It's a bit like cooking. If you start tasting after everything is finished, you can certainly decide that the meal is good or not. But it's tough to change things if it's not right. That's why most people taste while cooking and add things here and there. Early information lets you adjust early and before things go out to a customer. For software development, that means that you start your testing as soon as possible and that testing does include questioning requirements, decisions, and assumptions well before the first line of code is written.
“Preventing bugs over finding bugs.”
That is closely related to the first point. It is not about finding bugs at a certain point in time, i.e., the testing phase. It is about making sure that bugs don't even come into existence. If you fire up your search engine of choice and let it look for the costs of fixing bugs, you will find a lot of different studies and publications about that. While the factor differs a bit, almost all of them agree that bugs early found in development are way cheaper to fix than the ones found later. And while we are at it, finding many bugs doesn't make you necessarily an excellent tester, it probably just means that there hasn't been enough testing earlier to prevent those bugs.
“Testing understanding over checking functionality.”
Agile development is (among other things) about delivering software quickly, which means that there is no time for prolonged testing phases. Heck, most iterations are even shorter than some system tests I have been on. The holy grail of the agile world is automation. Well, as we all remember from Indiana Jones, the shiny holy grail is not what it seems! Use your automation wisely for what it is useful for: checking that (obvious) things are as expected and freeing up valuable times of the testers (unless you are having just clicking monkeys, but then you are having problems anyway).
“Building the best system over breaking the system”
In one of my first projects we had a high score list for bugs found. It was a race for the top and about breaking the system. It was testers against developers. Like it or not, but you are on the same team now and hopefully have a common goal of delivering high-quality software (without going into the "what is quality" debate here). And oh, sorry to say so, but you don't break the software unless you put some buggy parts into the source code. To quote James Bach: "We don't break the software. We break illusions about the software." http://www.developsense.com/blog/2015/02/very-short-blog-posts-25-testers-dont-break-the-software/
“Team responsibility for quality over tester responsibility”
A former boss of mine repeatedly said that nurses don't heal a patient by only taking his temperature. By doing so, they are providing information for themselves or others to improve the condition of the patient. As for software testing, just testing doesn't get you more quality. It is one part of doing so. Just as writing good code, providing realistic requirements and writing a good instruction manual is. So it's everything and everyone that influences quality. Especially on agile teams, activities are more and more separated from persons and roles within a team. Activities are a team skill. Some people are better at certain things than others, but that doesn't mean that it is only the task of the specialist to do so. As testers, we are responsible for sharing our expertise with the other team members. Of course, it might take longer for others, but taking longer is still way better than not doing it at all or being the bottleneck.
If you take your testing knowledge from other testing environments and embrace the changed mindset for agile testing, you are already following the "inspect and adapt" part that is so prevalent in agile development and will certainly be able to build on that. Of course, there are certain methods, heuristics, and techniques that have proven helpful, but that topic certainly warrants a post of its own.
Christian Kram for TestBench Cloud Services