Agile testing life cycle is based on the 'more is less' principle which focuses on communication management among stakeholders. The adoption of this principle results in quality software product as shown in Figure 1. The foremost component of this principle is 'more interactions' among all stakeholders. If communication between the tester and other stakeholders is very frequent, and effective then there would be very few doubts or more clarity. On the basis of more clarity, team focus increases on the relevant portion of user stories. If relevant portion of user stories are covered with high focus, there would be fewer severe during the time span of sprint. This principle ensures that testing activities along with effective communication and collaboration among major stakeholders, such as business analyst, market evaluator, customer, and developer, results in software products having only few defects. An Agile tester interacts and collaborates with two circles, namely an outer circle and an inner circle (Fig.2). The outer circle is connected to the outside world. In the outer circle, the tester collaborates with customers and market evaluators. A customer's job is to provide an informal set of requirements in one specific domain, and a market evaluator's job is to study the market trends of the same domain. Further, from the outer circle, a tester may extract the latest technology trend, competitor's software product features, and the latest market standard. All these factors are analysed by the market evaluator and an updated set of data is provided during the user story finalization meeting in the presence of the Product Owner (PO). The PO's role is to satisfy the customer in terms of available bandwidth and expertise of the team while converting the informal requirements into a formal set of requirements known as the user story.

After finalizing the user story, the tester converts that user story into a ready story. This ready story acts like a checklist at the time of verification or acceptance of the user story by the customer. This ready story is the outcome of performing two types of testing. The types of testing carried out for a specific user story are: Exploratory testing (ET) and Acceptance testing (AT).

UT= Unit Testing, FT= Functional Testing, IT= Integration Testing, ST= System Testing, T=Technology, C= Competitor, MS=Market Standard, AT= Automated Tool, P= Pattern, AT= Acceptance Testing, ET=Exploratory Testing,TDD= Test Driven Development.

Exploratory testing is the testing in which different possibilities or scenarios are considered as per the market analysis performed by market evaluators having positive and negative limitations. At the same time, the risk of user story may be identified so that effort estimation may be accurate in terms of effort complexity, and time.

Acceptance testing performed by a tester sets the acceptance criteria for a user story. These criteria are also known as verification points, which are needed to set the complexity level of the user story. Specifically, based on some factors or some expert techniques like planning a poker game, the complexity level of the user stories is identified. These verification points are then deeply analysed. In this case also, the tester does not work in isolation and rather collaborates with the product owner to finalize the acceptance criteria of the user story.

In the inner circle, the tester collaborates with team members and the product owner. The tester's job is to manage test cases along with delivering products to the customer. In Agile, regression testing is important, as Agile is based on responding to change rather than following a fixed plan. Therefore, regression testing is an ongoing activity in Agile. After looking at the verification points of the user story, the tester starts with writing failed test cases. For any user story of the sprint, test cases are designed by the tester using TDD approach which means failed test cases are written for the upcoming user story. Using this, developers try to convert these failed test cases into pass test cases This approach of testing comes under white box testing. This TDD approach may be implemented in a pair-programming style in which, first, on a single terminal, failed test cases are written, after which the code is written by the developer. This practice helps in getting immediate feedback so as to embed quality in the final deliverable.

Further, unit tests for any user story are written by extracting support from automated tools like Eclipse for Java applications and xUnit for web-based applications. This helps in reducing the overall time for any sprint. In addition, the pattern may be utilized so as to handle an existing problem with the best evolved solution. By following the pair-programming practice, the functionality of the user story is checked; this means black box testing is performed as per the verification points of the ready story. During the sprint, integration testing is also performed among user stories of a sprint by considering dependencies among the user stories. Moreover, integration testing is also performed among user stories of the different sprints. Further, to manage test cases, effective regression techniques, such as regression test selection (RTS) and test case prioritization (TCP) are implemented so as to run only a subset of the test cases out of all the test cases.

Finally, depending upon the feedback cycle of customers, the product is released by the operational team in collaboration with the tester by performing all necessary testing including usability, scalability, etc. Feedback of customer is an important input for getting good quality product. Finally, 'definition of done' is declared by the customer after matching the verification points of the ready story with the actual product. This is an easy way to check the validity of user stories in a sprint.