Motivation
The definition of done for a user story contains the acceptance criteria. Testing these acceptance criteria assures actual business value is delivered and guarantees that a user story is actually done. This makes testing an essential part of any functionality delivered. Any functionality which is created without being tested is waste as its business value has not been determined.
Applicability
Whenever software is developed the focus must lie on creating fully tested functionality, if the goal is to deliver business value.
Application
The simplest way to track if tests are executed, is by creating a test-task for every user story. Testing should be done by, or in cooperation with, people who focus on functionality. They can either be functional testers or domain experts, such as the product owners or business analysts.
To ensure that testing doesn't become a bottleneck in your process, testing should have focus throughout the sprint.
In order to prevent testing results in a mini-waterfall (with testing right at the end of every sprint), testing must be done in advance, as part of the definition of ready for a user story. When modeling the acceptance criteria in executable specifications, these can be referenced by the developers and used for Acceptance Test Driven Development. The modeling of the test automation should be done in collaboration between testers and developers. This collaboration results in shared understanding of the functionality and it ensures user stories get extra attention on testability and completeness, before development starts. During the development phase the initial tests (that have been created upfront) can be extended with variations and corner cases. This approach results in the shortest possible feedback cycle and as an additional advantage it boosts communication between team members and stakeholders, but most important it results in fully tested user stories, within the sprint.