Directory Image
This website uses cookies to improve user experience. By using our website you consent to all cookies in accordance with our Privacy Policy.

Agile Methodology: The Complete Guide to Understand Agile Testing

Author: Kumar Kumar
by Kumar Kumar
Posted: Oct 16, 2018

Introduction:

  • This is the guide for software developers and testers to understand and start working on the very famous Agile SCRUM methodology for software development and testing. Learn the basic but important terminologies used in Agile Scrum process along with a real example of the complete process.
  • SCRUM is a process in agile methodology which is a combination of Iterative model and incremental model.
  • One of the major handicaps of the traditional
waterfall model was that – until the first phase is complete. And if by chance there are some changes in the later stage of the cycle, it becomes very challenging to implement those changes, as it would involve revisiting the earlier phases and redoing the changes.

Some of the key characteristics of SCRUM include:

  • Self-organized and focused team
  • No huge requirement documents, rather have very precise and to the point stories.
  • Cross functional team works together as a single unit.
  • Close communication with the user representative to understand the features.
  • Has definite timeline of max 1 month.
Important SCRUM Terminologies:

1. Scrum Team

  • Scrum team is a team comprising of 7 with + or – two members. These members are a mixture of competencies and comprise of developers, testers, database people, support people etc.
  • Scrum team sitting arrangement plays a very important role in their interaction; they never sit in cubicles or cabins; but a huge table.

2. Sprint

Sprint is a predefined interval or the time frame in which the work has to be completed and make it ready for review or ready for production deployment.

This time box usually lies between 2 weeks to 1 month. In our day to day life when we say that we follow 1-month Sprint cycle, it simply means that we work for one month on the tasks and make it ready for review by the end of that month.

3. Product Owner

  • The product owner is the key stakeholder or the lead user of the application to be developed.
  • The product owner is the person who represents the customer side. He/she have the final authority and should always be available for the team. In case any one has any doubts that need clarification.

4. Scrum Master

Scrum Master is the facilitator of the scrum team. He/she make sure that the scrum team is productive and progressive. In case of any impediments, scrum master follows up and resolves. Scrum Master is the mediator between the PO and the team.

5. Business Analyst (BA)

A BA plays a very important role in SCRUM. This person is responsible for getting the requirement finalized and drafted in the requirement docs (based on which the user stories are created). If there are any ambiguities in User Stories / Acceptance criteria, he/she is the one approached by the technical (SCRUM) team who then takes it up to the PO else if possible resolves on his own.

6. User Story

User stories are nothing but the requirements or feature which has to be implemented. In scrum, we don’t have those huge requirements documents, rather the requirements are defined in a single paragraph, typically having the format as:

For example:

  • As an Admin I want to have a password lock in case user enters incorrect password for consecutive 3 times to restrict unauthorized access.
  • There are some characteristics of user stories which should be adhered. The user stories should be short, realistic, could be estimated, complete, negotiable and testable.It is the responsibility of the SCRUM Master and the BA (if applicable) to make sure that the PO has drafted the User Stories correct with the proper set of the Acceptance Criteria".
  • Every user story has an acceptance criterion which should be well defined and understood by the team. Acceptance criteria details down the user story provide the supported documents.

7. Epics

  • Epics are equivocal user stories or we can say these are the user stories which are not defined and are kept for future sprints. Just try to relate it with life, imagine you are going for a vacation. Since you are going next week, you have everything in place like your hotel bookings, sightseeing, travellers check etc.
  • An Epic is just like you next year’s vacation plan, where you just know that you may want to go, but where, when, with whom, all these details you have no idea at this point of time.

8. Product Backlog

Product backlog is a kind of bucket or source where all the user stories are kept. This is maintained by the Product owner. During planning meeting (see next section), one user story is taken from the product backlog, the team does the brainstorming, understands it and refine it and collectively decides which user stories to take, with the intervention of the product owner.

9. Sprint Backlog

Based on the priority, user stories are taken from the Product Backlog one at a time. The Scrum team brainstorm on it determines the feasibility and decides on the stories to work on a particular sprint. The collective list of all the user stories which the scrum team works on a particular sprint is called s Sprint backlog.

10. Story Points:

Story points are quantitative indication of the complexity of a user story. Based on the story point, estimation and efforts for a story are determined. A story point is relative and is not absolute.
Rate this Article
Leave a Comment
Author Thumbnail
I Agree:
Comment 
Pictures
Author: Kumar Kumar

Kumar Kumar

Member since: Sep 19, 2018
Published articles: 2

Related Articles