Agile testing techniques in most cases are similar to their traditional counter parts. However, Agile methodology may need some special considerations due to variances that standout with respect to techniques, jargon and documentation.

Acceptance Criteria, Adequate Coverage, and Other Information for Testing

Requirements in Agile Projects out flow as user stories and the Product Owner along with the team are responsible for writing user stories. The user stories follow a prescribed format from a point of value of the end user. All the user stories are stacked in Product backlog which is prioritized by the Product Owner frequently as per the business needs. The user stories contain acceptance criteria in which the requirements of a story are explained in brief. The acceptance criteria may also contain certain non-functional requirements, boundary conditions, and usability and performance conditions and may also relates dependency with other user stories.

The User stories should be related to a testable outcome, and they pave the way for incremental agile architectures, few examples of are outlined below

• Expert judgment and previous learnings
• Existing features, functionality and the technical characteristics of the architecture.
• User Personas (context, system configurations, and user behavior).
• Code quality and tools deployed
• Wireframes that serve as mockups
• Defect density from current and previous iterations
• Any regulatory standards, if applicable (e.g., DO-178B for avionics software, IEEE, SOX, FDA)
• System quality and risks (see Assess quality risks in agile projects)

The development team in every iteration implements features that are prescribed in the user stories, with all the strings attached like verifiable quality built in, code checked in, and validated by acceptance testing. The acceptance criteria should comply with the following traits,

• Functional behavior: The functionality of the product increment should be reflected as working software in the format when X is given as input and we see Y as output under conditions Z

• Quality Characteristics: The performance of the system subjected to specific quality attributes like quality characteristics, reliability, usability that forms the patterns of system behavior.

• Scenarios (use cases): A set of actions in a specific order between a User persona and the system, in order to fulfill a business goal.

• Business Rules: These are collection of activities that operate on the system under given conditions subjected to various external procedures and constraints (example: The call routing mechanism when a cell phone network initiates a call)

• External interfaces: The inter system joints and intra system joints that are yet to be developed for external world. These may be categorized into various types (User interface, other systems interface, etc)

• Constraints: Design descriptions and implementations may form certain constraints that will crunch options to the development team. For example: Embedded software devices may often have the constraints related to size, weight, dependency and interfaces.

• Data definitions: The customer described format of data type, default values, character lengths for a data items to frame complex business rules and data structures (example: the ZIP code in U.S. snail mail)

Apart from the above considerations, the tester may also find some information about:

• System usage and its interfaces and operational modes
• The importance of current tool kit and it scalability
• Tester’s competency about the current testing tasks.

Other popular articles:

• What is Acceptance Test-Driven Development in Agile Methodology?
• What is User Story Template in Agile software development?
• What are Test Pyramid and Testing Quadrants in Agile Testing Methodology?
• What are Project Work Products in Agile testing?
• What is Acceptance testing or User Acceptance Testing (UAT)?