When it comes to testing on agile projects it is common practice for agile teams to adopt a "whole team testing" approach where the team itself does its own testing. To accomplish this agile teams will often embed testers in the development team. Programmers will work closely with the testers, often via non-solo development strategies such as pair programming, to pick up their valuable testing skills. The testers will in turn pick up new skills from the programmers, and in effect both groups will move away from being just specialists (testers or programmers) to being what’s called generalizing specialists. Whole team testing can be very different from traditional approaches where programmers may do some testing, often unit testing of their own code, and then throw it over the wall to testers and quality assurance (QA) professionals for verification and validation.
My experience is that whole team testing is a very effective strategy, that agile testing and quality strategies in general appear to be far more effective than traditional testing and quality strategies, but that whole team testing isn’t the full agile testing picture. At scale, particularly in complex domains, complex technical situations, or in regulatory compliance situations, Disciplined Agile Delivery (DAD) teams will extend whole team testing with a parallel independent test team. Although the development team still does the majority of the testing, the independent test team which is working in parallel to the development team looks for problems which are harder or more difficult for the development team to find and then reports potential defects back to the development team.
The types of testing that the parallel independent test team performs may include:
*
Pre-production system integration testing. Does the solution work within your overall organizational ecosystem? Importantly, if this is one of several teams currently developing new solutions, does this team’s solution work with what will be in production (including the work in progress of other teams) when they go to release? In mid-to-large organizations the only economical way to do this sort of testing is via an independent, centralized team.
*
Usability testing. Although it’s possible to do usability testing on the development team, the reality is that usability testing is a specialized skill that few people have (although could pick up via non-solo development). Furthermore, particularly for solutions with many potential users, you may want to invest in a usability testing lab. This is a centralized resource, or an outsourced resource these days, which is shared across many teams.
*
Security testing. Security testing is also a specialized skill, albeit one well supported with sophisticated security testing tools such as the Rational Appscan suite which can be included in your continuous integration (CI) strategy. Many organizations will centralize their security testing efforts.
*
Exploratory testing. The fundamental goal of exploratory testing is to discover where the solution breaks, as opposed to confirmatory testing which focuses on showing that the solution conforms to the requirements (this is the type of testing the development team typically focuses on). Exploratory testing is also a skill, a good one which everyone should strive to pick up, but exploratory testers are often few in number in many organizations. So, to leverage their skills effectively you may want to have some of them on the independent test team while they mentor others while doing so.
*
Non-functional testing. Non-functional requirements have a tendency to fall through the cracks on some development teams. Knowing this the independent test team will often "test to the risk" and focus on non-functional issues.
*
And much more. The above points are just exemplars, not an exact list. Please follow some of the links above for greater detail.
Source: https://www.ibm.com/developerworks/mydeveloperworks/blogs/
ambler/entry/agile_and_independent_testing25?lang=en