Agile does not refer to a testing style itself, but rather refers to a project management framework and a development approach. For it to be successfull it must really be used in its entirety and the Agile Manifesto adhered to correctly. It is about optimizing development and should not be used as an excuse to just not bother with adequate documentation or an understanding of the requirements. We have encountered a number of businesses that purport to be using Agile Methodology, but in fact are only using just a part of it and this has led them to waste time and not necessarily produce what was wanted.
Within this methodology there are various approaches, however, we see Extreme Programming (XP) as a development approach and SCRUM as a Project Management framework. As mentioned, these are not testing practices in themselves, but have a definite impact on the testing style, where testers and developers work closely together. Clear and unambiguous requirements, in user stories, still have to identified during the process to allow thorough and reproducable testing. Some people believe that Agile allows them to just do a cut down set of testing such as unstructured or ad hoc testing, however, if that is the case you might then want to question the value of that testing at all.
Project stakeholders determine the high level requirements (user stories) which are prioritized into short time boxes or "sprints", by small teams of developers and expediters. Best practice requires that the user stories contain clear and explicit acceptance criteria. These are then fit into an iterative framework that is easy to manage, often using cards showing estimations of effort required, in a task board. Burn down charts allow clear visibility of progress and backlogs.
Developers create the code, often working in pairs for peer review purposes, based on the user stories and conduct Unit Testing before releasing the code for Integration, System and Acceptance testing.
As each new set of functionality is released for testing it must be shown that the new code functions correctly and does not negatively impact any functionality that is already in place. This is best done by creating an automation Regression Test Pack, often using a computerized tool such as Unified Functional Tester or Selenium. This allows for quick and efficient re-runs of previous functional tests (regression testing), whilst running tests on the new functionality. Once satisfied that there are no impactful defects, the new tests are added to the automation Regression Test Pack and so it builds, ready for testing the next iteration.
Once the functional and Integration testing is complete, performance and other non-functional testing can be conducted.