Agile and Scrum Methodologies from a Testing/QA Perspective

Member Submitted
  1. programmable tasks and written in a white board together along with the time estimates for completion. If you have never seen a product backlog, you can check few samples here in QAZone . Sometime real customers are invited to the kickoff meeting as well to review and clarify the product backlog with the agile team.
  2. The next step in the sprint/iteration planning , in which the team collectively decides the sprint goal and sprint backlog (list of prioritized work to be done for that particular sprint). While the team is collectively creating the sprint backlog, stories need to be broken into either sub-stories or smaller tasks. During this collective team exercise you can really see the differences in project management (at least if you have a more rigid and formal waterfall like type of background), because there is no management authority that assigns tasks to team members. On an agile team all the members jointly associate level of difficulty to specific tasks, they can remove or add additional stories and/or tasks, and tasks are distributed among the team on a per volunteers basis. Unlike a traditional project manager function, the ScrumMaster role in this meeting is to maintain the backlog list in the meeting based on team feedback and consensus, make sure that nobody is volunteering for too many tasks to the point of overload, and facilitate the process of building personal commitment to the team.
  3. Now that the Sprint planning is ready in the form of sprint backlog –which is dynamic and not set in stone, in fact it is very likely that it will adapt and change based on new stories, new tasks and/or impediments found throughout the iteration– scrum meetings will be set at the same time and in the same place on a daily basis. If you have never attended a scrum meeting, these meetings are very dynamic in nature and fast, never more than 30 minutes, and ideally 10-15 minutes. The objective is to go around so each team member can answer 3 questions: what have I accomplished since the last meeting (developed, tested, written, etc), what will I be working on next, and what are the problems, if any, preventing me from accomplishing my goals. These meetings are very important to make sure that the team moves towards achieving their sprint goal, or adapts/evolves and changes priorities and tasks as needed if new stories, impediments or new scenarios are encountered.
  4. At the end of the sprint or iteration, usually a final acceptance meeting takes place, which is typically done by presenting what the team has accomplished, and by delivering a demo to the customer or to a larger audience.
  5. At the end of an iteration there is also a sprint retro meeting , similar to a postmortem meeting at the end of other traditional projects, so the team gets together to evaluate what worked well, and what needs to be improved during their next iteration.

Top 3 things a QA professional should expect when an organization adopts Agile/Scrum development techniques
Agile and Scrum are really changing the way testing is perceived throughout the project. Testing is not a phase at the end; it really is integrated throughout the entire iteration cycle, and it goes hand in hand with programming tasks. In my experience, when comparing a testing role performed within an agile project, or when using more rigid and formal approaches, I have found that with agile methodologies there is:

  1. Better communication and more collaboration among QA & development folks Gone are the days of "give me requirements" and "I will give you bugs

User Comments

Payilagam Chennai's picture

I have a question on Agile.  In the Planning meeting, if the Product Owner is absent all of a sudden, do we need to conduct the planning meeting without Product Owner or should wait for him.  Please answer

April 15, 2015 - 3:54am
sridhar bandha's picture

It depends actually. If your product owner has already prioritized all stories then all rest of team has to do is decide what all stories they can complete in that sprint. But then Product owner has to informed about the scope of the sprint (in terms of stories) and he should be fine with that. So my take if you have your stories prioritized then go ahead and decide based on priority and then later have a chat with Product owner get his feedback before actually starting the sprint.

May 4, 2015 - 9:48am
Sanat Sharma's picture

A real time scenario which I am facing now a days in Agile - Product owners are not interested in the product and wants to kill the products. But on the other side, there is a full fleshed Product backlog items list that can be implemented in the product.

There is a deadlock on this and Engineering team have spent 3 weeks (doing nothing) without even finalizing the release requirements to be implemented in the further release.

October 6, 2015 - 6:45am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.