My Experience as a QA in Scrum

| Posted by Priyanka Hasija Follow 1 Followers on Jul 17, 2012. Estimated reading time: 12 minutes |

Scrum is an Agile approach to software development, which focuses on delivering valuable business features in short development iterations of 2 to 4 weeks. Scrum teams have two defining characteristics – they are cross-functional (i.e. they include every skill set necessary to get the job done) and they are self-organizing (i.e. the team is expected to figure out how best to get the job done). After working for nearly two years as a quality assurance (QA) analyst on a Scrum team, I have learned that the role of QA in Scrum is much more than just writing test cases and reporting bugs to the team.

Contrary to the synchronous activities of a traditional Waterfall project, Scrum expects development activities to be performed in the order they are needed – i.e. asynchronously. This break from tradition raises a common question by many of the clients, developers, and business stakeholders new to Agile – “How can testing professionals engage effectively during a sprint before anything has been built?” This article focuses on explaining how the QA role performs agile testing and the place of importance they hold on a Scrum team. Much of what I have learned about the roles and responsibilities of QA on a Scrum team I will be sharing with you throughout this article. 

More Than Just Building Test Cases

On traditional Waterfall projects the QA role is only involved at the very end of the project – once all coding is complete. On these projects, the QA role would typically be given a requirements document and the completed code and would be expected to write and execute test cases which verify that the application does exactly what the requirements document says. However, the QA role in Scrum is not just about executing test cases and reporting bugs.

On a Scrum team the QA Analysts participate and fulfill a variety of responsibilities conjointly with other team members. They are involved right from the very beginning of a project where they work closely with business analysts and developers. In Scrum, the QA role is not a separate team that tests the application being built. Instead the Scrum team is a cross-functional team where developers, business analysts and QAs all work together. Apart from building test cases, QAs can also help the Product Owner (PO) write acceptance test cases by playing the role of proxy product owner. Having QA fill in as a proxy for the Product Owner when they are not available helps keep the team moving forward at all times. They can also interact with the Product Owner by asking questions and challenging assumptions to help clarify the business requirements. 

Participate In Estimating Stories

Quality assurance analysts are typically very good at creating test case scenarios based on user requirements. They also excel at identifying and capturing complex and negative test case scenarios. In fact, they are typically much better at it than developers, who tend to focus mostly on the “happy path” of the user story. Including testers during Release and Iteration Planning, when user stories are estimated, can help the team think beyond the happy path. This helps the team produce a more realistic estimate since both “happy” and “unhappy” paths have been considered. Estimation is a tough task and it is good practice to have the whole team participate in coming up with the estimate. 

Help Keep Vision And Goals Visible

As the team works through the testing and stabilization activities, QAs should take the lead to plan, organize and involve the whole team in the testing work and to keep people motivated just as the Scrum Master (SM) does. Since very few developers enjoy testing work, the QAs , along with the Scrum Master, must make the testing vision and goals visible to the whole team and help to keep the motivation level of the team high. Sometimes it helps to be creative when testing scenarios require help from developers or other team members. Try making the testing activity fun by using amusing test scenarios, funny test data, fun competitions, etc. Do what you can to help the team enjoy and contribute to the testing work. 

Collaborate With Customers And Developers

One of the primary responsibilities for the QA role is to provide feedback from their testing experience to the Product Owner as well as collecting feedback from them. QAs work closely with the Product Owner to help them develop detailed acceptance criteria for their user stories. Based on what the team learns during each sprint, QAs can also help the Product Owner modify or enhance existing user stories to better reflect the true requirements.

On occasion, the quality assurance analyst may be asked to act as a proxy for the Product Owner. In these situations, QAs and developers will sit and work together as a team to help improve the quality of the project. The QAs can pair up with developers for writing unit test cases and for discussing acceptance criteria. The more these roles work together, the greater the shared clarity will be on requirements. The increased clarity that results from working together will reduce the questions and doubts developers often encounter during coding time, which produces greater efficiency and a big time savings for developers and testers alike.

The whole team should be expected to pitch in and assist with testing whenever required based on the needs and the availability of team members. This practice helps create balance in the team and a shared responsibility for getting the work completed. It also helps produce the required pace to move faster with early testing feedback and increased quality. 

Provide Fast Feedback

The build-test-fix cycle that traditional Waterfall teams repeat endlessly produces a lot of extra work for the team and usually ends up wasting a lot of time. This activity is much simpler in Scrum as QAs and developers work together throughout the entire process. Developers can consult the QAs about acceptance criteria or the expected behavior of any functionality from the user's perspective while working on the feature, which results in saved testing and bug fixing cycles. 

Automate Regression Testing

It is often said that automation is the tester’s best friend since it provides repeatability, consistency, and better test coverage over the software’s functionality. This is particularly true on a Scrum project with small sprint cycles of 2-4 weeks, since QA generally has even less time to test the application. During each 2-week sprint, QA must perform full functionality testing of the new features being added during this sprint as well as perform full regression testing for all the previously implemented functionality. As would be expected, this responsibility grows significantly with each passing sprint so any automation that can be applied to these tests would greatly reduce the pressure the QAs feel.

Automated tests are particularly helpful in providing rapid feedback when teams implement Continuous Integration (CI). Each time there is a new build, the automated tests can be executed and provide immediate feedback as to whether the new features are working correctly or whether there have been any regressions of previously working functionality. Without automation, QA must perform these tests manually, which becomes a very monotonous and error prone task. Automation can help detect the defects early and give QA more time to explore the edge cases of the new features being developed. Automation can help QA deliver testing work much more efficiently and effectively. 

Participate In Release Readiness/Demos

At the end of each sprint, the team holds a Sprint Review meeting where the team must demonstrate the user stories completed during the sprint to the Product Owner and other interested stakeholders. This Sprint Review meeting provides a healthy dose of accountability to the team and motivates them to complete as many user stories as possible.

With small sprint cycles of 2-4 weeks, everyone on the team must stay focused on his or her respective tasks in order to complete them on time. Developers stay busy developing their assigned user stories and fixing bugs while QA stays busy writing test cases, clarifying questions from Product Owners, and automating previous sprint stories. Having short sprint cycles also means that developers have less time to explore the complete functionality of their user stories on their own. As a result, developers typically consult with QA to better understand the user stories since they are the ones aware of the complete functionality and know each and every requirement and acceptance criteria. As a result, it can be a good practice for QA to perform the demo at the Sprint Review meeting and field functional questions coming from business. That can free up the developers to handle any technical questions that surface. 

Analyze User Requirements

QAs are the proxy product owners of the Scrum team. QAs are generally good at understanding the business requirements from the user's perspective since they are often asked to use the application as the end users would. QA can help provide feedback to the Product Owner based on their testing experiences and can help the Product Owner better understand the application from the end user's point of view. 

Enforce the Definition of Done

Having a clear Definition of Done (DoD) is important to a Scrum team. A DoD is nothing more than a simple list of team defined completion criteria - all of which must be completed before the user story can be considered done. This list typically includes things such as writing code, performing functional and regression tests, and gaining the approval of the Product Owner. A very simple DoD might include the following:

  • Code Complete
  • Unit Test complete
  • Functional / UI Test Complete
  • Approved by Product Owner

While it’s not the sole responsibility of QA to define the DoD, it is often QA’s responsibility to monitor the work being performed by the team and to ensure that each completed user story meets the benchmark DoD. An efficient Scrum team will review their DoD before starting each new user story to make sure they know what is expected. A team’s Definition of Done is not static and may evolve over time as the Scrum team needs evolve. DoDs can be defined for sprints and release as well. 

Always Plan Testing With Testing Strategies

Since there is not a test lead or even a specific test team in Scrum, building a test plan or following specific test strategies on a Scrum team can be an issue. Scrum believes in preparing only enough documentation to support the immediate needs of the team. As such, QA will prepare just enough high-level documentation for test strategies and plans to guide the team. Since there are no QA leads in Scrum, the QA analyst typically decides the test strategies. 

Tester and Analyst Roles Converging

On Scrum teams it is common to see the responsibilities of QA and those of the business analyst begin to converge. The Business Analyst role is typically responsible for creating and maintaining the sprint and product backlogs, analyzing the user stories from the business perspective, and prioritizing the backlogs with input from the Product Owner. The QA role, on the other hand, is typically responsible for defining / refining the acceptance criteria for each user story, testing the completed functionality each sprint from the end user's perspective, and ensuring all previously completed functionality has not regressed. As QA tests each user story and verifies the defined acceptance criteria has been met from the end user's perspective they are also analyzing the user stories in term of the business as well. So, in many ways the QA role and the business analyst role share many of the same responsibilities, required skills, and overall objectives.

Normally, a Scrum team gets their user stories and the pre-defined project scope from the Product Owner at the beginning of a project. However, in Scrum the team is encouraged to suggest new features or changes to existing features if it will improve the end users experience. The team is also encouraged to recommend changes to the priority / sequencing of user stories in the backlog when they find technical dependencies that suggest a different implementation order would be more efficient. Whether its defining requirements, analyzing user stories, defining / clarifying acceptance criteria, building acceptance test cases, or closely working with customers, the roles of tester and analyst are clearly converging. While this offers many advantages – particularly for small teams - it also has its disadvantages as well. The biggest concern is that neither the tester nor the business analyst role will get as much attention as it would with a team member fully dedicated to that responsibility.


While QAs still write tests and report bugs, they also support many other roles and responsibilities on the team. They are an important part of the team and are involved in the project right from the very beginning.

Working as a QA Analyst on a Scrum team for the past two years has been a great experience and has provided many learning opportunities. I have filled many different roles and responsibilities including QA analyst, proxy product owner, helping developers write unit test cases, acting as the team's quality conscience, and keeping track of problems and software bugs. In short, this experience has added many wonderful skills to my toolbox and has helped me learn how to play many different roles – all at the same time. Most importantly it has taught me to ask questions rather than just follow the documentation and do whatever it takes to help the team succeed.

While QAs still write tests and report bugs, they also support many other roles and responsibilities on the team. They are an important part of the team and are involved in the project right from the very beginning.

About the Author

Priyanka Hasija is a Test Consultant at Xebia IT Architects having worked in the IT industry for the past 2 years. During this time she has developed a sound understanding of Agile principles and has had the opportunity to practice them successfully on several Agile projects. While working at Xebia, Priyanka has gained experience performing manual test as well as working with automated testing tools such as JMeter and Selenium. She is an avid blogger and has written several posts on automated testing tools like JMeter, Selenium, soapUI, and Exploratory Testing. In addition, Priyanka co-presented a topic at the Agile Tour-Hyderabad conference in 2011.


Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Not necessarily agile by sumit bisht

Even though the role of QA is quintessential in maintaining software, the testing should be the main responsibility of developers.
'helping developers write unit test cases' doesn't really inspires a happy picture of the team, which is supposedly doing scrum.

Scrum costs/benefits by Jose Delgado

Hi Priyanka,

As an active Scrum practitioner, I am sure you can help me answering my questions on Scrum...
I am looking for documentation (fair&balance) that provides evidence that Scrum improves anything in software development.
I mean that by using Scrum, productivity increases, quality improves, creativity grows, better User satisfaction final product, etc.

Same, I would like to know the costs associated to Scrum.. like the time used on the "daily standup" and other prescribed meetings. Cost per developer, cost per team, costs per product(s) and costs per compan(y/ies).

Where could I find the costs/benefits of Scrum?

Thank you
jD @

This so captures what testers contribute on agile teams! by Lisa Crispin

This matches my own experiences working as a tester on agile teams. Thank you for sharing your experiences! And cool that you are on the Xebia team, testing a test framework, it's a great challenge.

Great Article by Graham Perry

Priyanka - great article and thanks for sharing your experiences.

I have 2 questions where I would value your feedback:

1 How do you see the role of the tester evolving in the future regarding DevOps - ie the movement to integrate development and operations? I can see a bigger role for testing in assuring the Application Lifecycle process as well as being involved in the testing of individual sprints.

2 What is your experience of performance testing within agile development? The majority of people I have interviewed say that they do performance testing towards the end of a major release - but this seems like testing in a waterfall scenario. I have come across some instances when an application has to be re-architected due to late performance testing. There seems to be little evidence of organisations doing performance regression tests at each sprint to ensure that incremental features don't impact performance.

Graham Perry

Re: Scrum costs/benefits by Melle Koning

As a scrum master I can say the time of a daily standup can be 10 minutes, sometimes this goes to 20 if some explanations are started to 'chickens' without a clear way of getting that 'offline' (after standup).
However your notion of costs related to meetings strikes me. Do you regard communication between developers a bad thing?

Re: Scrum costs/benefits by Jose Delgado

As a scrum master I can say the time of a daily standup can be 10 minutes, sometimes this goes to 20 if some explanations are started to 'chickens' without a clear way of getting that 'offline' (after standup).
However your notion of costs related to meetings strikes me. Do you regard communication between developers a bad thing?

If there is hard evidence that referred time contributes on having better software products: final user satisfaction, performance, quality, etc... definitely no. But with out having metrics on the costs/benefits on anything (in this case SCRUM); you never know it.

Based on your practice could you provide any evidence that SCRUM works?

Thank you

Re: Scrum costs/benefits by Melle Koning

Dear Jose,

The question is what you want to measure. My experience with the scrum practice is not that 'production' in terms of lines of code or number of feauters go up, but better the quality of the delivered work goes up. This can be measured in terms of customer satisfaction, build features that are actually used by clients, less bugs and less work coming back because of misunderstood requirements.
The interaction between developers and clients (because of demo's in iterations) makes for evidence that scrum 'works'. Developers better un derstanding customer needs, clients better understanding the complexities of certain requirements and why alternatives might be a better option.

So yes, if you can build what the customer actually wants that is evidence scrum works.

The separate QA role might be needed for certain teams. The role described in the above article gives a good view on the succes factors for that role.


Re: Scrum costs/benefits by Jose Delgado

Hi Melle,

I am asking for any kind measurement you can provide...
BTW, this article that just appeared in INFOQ, I would say is trying to answer the same kind of questions about SCRUM.

Providing measurements under a cost/benefit analysis would really help to decide weather SCRUM works.

On the other hand:

The interaction between developers and clients (because of demo's in iterations) makes for evidence that scrum 'works'. Developers better un derstanding customer needs, clients better understanding the complexities of certain requirements and why alternatives might be a better option.

Do the clients participates in the stand up meetings? From where is exactly the developers are "understanding the customer needs". I don't much about SCRUM; that is why I am so interested in knowing if works or not.

Thank you

Re: Scrum costs/benefits by Jose Delgado


Somehow the link to article on "is agile a scam", didn't work...

You can google it to get it


Re: Scrum costs/benefits by Melle Koning

In our case yes clients can join the standup. This is because i currently work for a travel company who develops what is needed inhouse.

I have seen the agile is a scam article based on a report where companies sell agile services. Well, we hired a scrum coach to get off to a good start. That does not mean all scrum coaches try to scam you right?

For our company, the transition to agile came from the dev ranks and the board followed quickly. If you do not have experience yet, why not try? The most effective are the shorter feedback loops between devs and clients.

Back on this QA topic: the shorter feedbackloop is what makes the QA role in a scrumteam different from the tester in an approvalteam.


Re: Scrum costs/benefits by Jose Delgado

Try it... I don't think so. It seems people had used it is totally polarized about it.
Thank any way.

Re: Scrum costs/benefits by Rommert de Bruijn

Hi Jose,

I have to agree with Melle and others. Scrum offers a simple self-improving process where inefficiencies (be it on the customer side or on the developer side) are identified and improved on within weeks. The amount of time consumed with creating specifications is reduced considerably because there is less need for assumptions about design/functionality. For each sprint, the product owner defines what he needs the most *given the product in its current state*. The time consumed with customer-communication is reduced, because there is 1 person (and 1 person only) that decides what the team has to deliver. The time consumed with team-communication is reduced because they meet every day, sit next to each other, and know the product (and its domain) through and through. What's not to love about that?

Your question: do I have documentation that scrum works? Nope. But does scrum put a smile on my face? Yes. Does my customer get exactly the product he desires? Yes. Does my team like to work on the product? Yes. Show me a waterfall project that does all that.

Re: Scrum costs/benefits by Jose Delgado

Hello Rommert,

This is exactly the point "Is there hard evidence the Scrum works?"... and your answer is NOPE.
Supposedly Scrum is a Software engineer product. Engineers in any field measure the cost/benefit of techniques, practices, approaches.

Using the argument that "communication an iterative process" is good... Of course is good. But what is the cost/benefit of it. Have you ever thought how much does it cost the referred stand-up meeting and the other prescribed meetings to your company?.

Let try to make an estimation of it... Let say there is a team of 6 people, 5 developers and one Scrum master.
Every day they meet for 10 mins for answering the 3 questions. At the end of the session will 6 x 10 mins = 1 hour of development time. At the end of the week will be 5 hours, at the end of month 20 and at end of year at least 240 hours of development. Some months come with more that 4 weeks. 240 hours is the time cost of the stand up meetings only, now add the time of other ones. Now turned into bottom line $$$that matters very much to companies... The cost of an hour of US development time is around 50/hr or $12,000.00/year. To have the whole picture you have to add the cost of the tools required, training and others. You can buy a lot of "chickens" with this money.

Can you for sure tell your company the benefits will overcome the costs of applying Scrum?
What about the cost of "waterfall" is half of the Scrum and the customer satisfaction is 80%.

Would let you customer/client to choose? I warranty there will be a bigger smile in your client/customer if you show the cost/benefit of the matter.

Thank you
jD @

Re: Scrum costs/benefits by Melle Koning

Dear Jose,

You start to show your inexperience with agile AND you are reluctant to try. Woops.
The 80% success rate for waterfall compared to scrum came from your software company stats?

So you consider a 10 minute meeting waiste and define it as costs?

Are code review meetings costs?
Are knowledge sharing meetings costs?
If two developers are behind one screen Also known as pair programming, is that costs as you rather see each individual behind their own pc?
If devs hear what they have to work on in the sprint estimation/backlog meeting costs?
Is the retrospective meeting, learning from past experiences, costs?
Is showing what you build to the client and receiving proper feedback in the end of sprint demo, that meeting, costs?

Do you want to enable developers to know what they have to build, or keep them at the bottom of the waterfall?

You of course do not have to answer as these are rethorical questions.

Re: Scrum costs/benefits by Jose Delgado


Ask yourself the following questions...

Did we have great successful complex software deliverer prior to Agile. Yes we have. Systems and applications like OS, compilers, DBMS, Internet, etc. Somehow IT made it -unintentional rhyme here- without agile for a while -another unintentional rhyme-.

Agile is only one possibility... The thing we don't know how good or bad is because there is no measurements. Only emotions not analysis.

To be consistent agile should apply principle #1 to itself... There is a lot of frustration about it and you know it.


Re: Scrum costs/benefits by Jose Delgado


Sorry, I missed the 80% stats question...

I comes exactly form the same rhetorical repository where you are picking yours.


Re: Scrum costs/benefits by Melle Koning

Dear Jose,

You do not think improvements can be made on the non agile way of working because it did give results in the past, is that it?

Why change a Lada or Kever?

The facts are that agile does work. You can measure productivity, velocity and more if you want.

Thanks for trolling though :-) on to other discussions,


Re: Scrum costs/benefits by Jose Delgado


Your are very welcome...
I still have the hope that someone analytical -and emotional too- can answer my questions...

Hasta la vista,

Re: Scrum costs/benefits by Melle Koning

Jose, contact me. We can have a talk via mail and or skype.

Re: Scrum costs/benefits by Jose Delgado

Hello Melle,

I truly believe in your sincerity and respect your points very much...
I really don't understand why you threw the trolling-card to me. I thought we were having a civil professional exchange.
Besides, I was replying to Rommert when you came back all way doing such thing to me.

What I suggest to you is to post your opinions on agile so everybody can read them. I am going to do it on my development blog too.

You can reach me anytime @
Thank you

Re: Scrum costs/benefits by Juan Jose Zapico


You say "Supposedly Scrum is a Software engineer product". You are showing here a lack of basic understanding of what Scrum is. So I suggest you to learn the basis about Scrum and try it by yourself before you start a rant. Although they are related, agile and Scrum are two different concepts. What is for you the principle #1 of agile?

Scrum works in the apropiate context. For some projects is better to use other approachs like waterfall. If you work in an organization that is driven by numbers like the example you put (cost of a 15 minute meeting) looks like Scrum is not for you (yet). Do you know the cost of every meetings you have?

If you are so interested in numbers look for them in organizations that gathers statistics about software development like the Standish Group or Gartner. Here you have some basic "official" numbers to start with:


Re: Scrum costs/benefits by Jose Delgado

Hi JuanJo,

Your suggestion is very welcome... I just verifying weather or not is worthy doing such.
Please don't characterize my posts as rants... I just trying to get some facts from people that had succeed using them.

On your point "Do you know the cost of every meetings you have?". You have to understand that for an outsider; the dogmatic requirement of having to meet everyday for answering the same questions all-the-time is really odd.

I wonder how much the status of a project can change for one-day-to-the-other that justify/mandate such action.

It seems more a play coming from a sweat-shop playbook than software engineering technique.

Thank you

Re: Scrum costs/benefits by Juan Jose Zapico

"I wonder how much the status of a project can change for one-day-to-the-other that justify/mandate such action."

You don't have to meet everyday if it not necessary in your context. You don't need to meet exactly 15' if less are enough. You don't have to answer those 3 well known questions. The daily meeting is not a status report.

The inspect & adapt cycle of Scrum (through the retrospectives) could allow you to tailor the daily meeting to your particular context.


Re: Scrum costs/benefits by Jose Delgado

It makes perfect sense to me now...

Thank you

Re: Not necessarily agile by Ingo Saxer

But you did get what this was about?
Regression, performance, security, etc. tests don't have anything to do with unit tests!
I am since more then a year working on a scrum team as a technical tester and yes, there is something more to it, especially when you get to integrate automated functional and performance test in CI where every hour you get the current results of what potentially went wrong with the latest check in.
Unit tests are great but they don't help you much neither on regression, performance nor security.

For a more complete discussion by Jordan Bortz

For a more complete discussion I might guide you to this URL:


Unit tests by Jordan Bortz

Yes I agree here. I go into depth on my blog


Re: This so captures what testers contribute on agile teams! by Priyanka Hasija

I am so glad you read my article and appreciated it.Getting appreciation from you is itself a big thing.

Scrum Training by Victor Simson


I am a beginner in SCRUM/AGILE. Can anybody guide me? Is it required to have Scrum Master certification. I did find a list of courses on the following link. Any suggestions?

Re: Scrum costs/benefits by Troy Alford

I am a little late in joining this discussion, but I wanted to provide the following resources on the effectiveness of Scrum:

The first is a fairly high-level description of the benefits of Scrum from a conceptual standpoint from

The second is an analysis of both the mindset that causes this question to be asked, with a statistical answer demonstrating the increased effectiveness of Agile-methodology projects over more traditional approaches. The link includes a number of charts and graphs, mostly taken from the DDJ 2007 Project Success Survey, DDJ 2008 Project Success Survey and 2010 IT Project Success Rates Survey. This article can be found at

Most importantly, however - I'd like to point out the fact that the very question you're asking somewhat pre-supposes the answer you're expecting. In other words - the idea of measuring the result before you begin the process is a stereotypical thought-trap that old-school companies often find themselves in, and it ignores the central feature of Agile/Scrum or any other iterative process: adjusting as you go.

The biggest benefit of these processes is that you don't have to know everything up-front, you just need to know enough to get started. Will Agile make your project/company/team/process better? By definition, yes - because it is the process of embracing continual improvement as a goal, rather than perfect prediction. How much better? That all depends on your implementation, your nimbleness in the face of change, the scope of your project, the adaptability of your team, etc.

Assuming ownership of software product we test by Farrukh Latif

Hi Priyanka! This is an excellent article on QA in Scrum methodology is very informative. Much appreciated. Can you please also shed some light on the subject "QA Engineer assuming ownership of software product s/he is testing". Actually, testers usually perform testing following predefined set of test plans, test cases and other documents without realizing the significance of testing and go through the QA cycle in a mechanical way. In fact, QA enginer should assume responsibility with a sense of ownership while certifying or testing the product before it gets out to end user or customer. It would be nice if you or anybody in the thread could throw some actionable ideas on the subject of "assuming ownership".

Thanks & Regards,
Sr. Software Quality Analyst.

Re: Assuming ownership of software product we test by jai singh

Hello Farrukh,

In Agile World, QA Team members plays a very important role not only in the QA Areas but also in the whole Product Lifecyle.QA should be involved in early phase of the Project which is not the case with Water Fall model of Project. Expectations from QA specially the lead or SME is bit high as compared to other Models. Ownership is the important aspects when you are working in Agile Projects. Not only QA Tasks i.e. Preparing Script, Execution and Reporting bug. QA needs to be involved in Sprint Planning, Backlog Meeting, UAT Planning, Integration Plan creation, Iterative Retrospective meetings etc..

Just wanted to conclude, Ownership is key area for QA Team to work in Agile Project w.r.t Water Fall model.

re:My Experiences as a QA in scrum by Phillip Ellis

A reasonably summary of Agile. Absolutely no need to make an erroneous comparison to Waterfall.

I have worked on several agile products some more successful than others. I have also worked on several Waterfall projects and would just like to say that Priyanka Hasija'a paragraph on Waterfall is incorrect and misleading -

“On traditional Waterfall projects the QA role is only involved at the very end of the project – once all coding is complete. On these projects, the QA role would typically be given a requirements document and the completed code and would be expected to write and execute test cases which verify that the application does exactly what the requirements document says. However, the QA role in Scrum is not just about executing test cases and reporting bugs.”

First the QA role is not just involved at the end of the project, certainly not just handed a requirements document and completed code. Neither as the paragraph implies is the QA role just about executing test cases and reporting bugs.

I can only suppose the author has never heard of verification & validation and the QA role in these activities? These start at the beginning of the project, reviewing, identifying and correcting issues in project artefacts (not just code).

Please don't assume from my response that I am not for Agile.. I am only doing what any QA would do reviewing and commenting on provided documentation.

Convergence? by Bob Lieberman

"On Scrum teams it is common to see the responsibilities of QA and those of the business analyst begin to converge."

That's a new one on me, Priyanka. I can see how a business analyst would be doing acceptance testing, but a business analyst who writes automated regression tests or inspects code with a developer? I wonder if you're overstating... What is the exact area of convergence you're referring to.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

34 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you