QA Role in Scrum Team
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 who are new to Agile – “How can testing
professionals engage effectively during a sprint before anything has been
built?” this Post will focus on QA role in agile
testing and the place of importance they hold on a Scrum team. Much of what I
have learned through 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.
Conclusion
While QA Team member 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.
This Article is inspired from Priyanka Hasija Article on "QA Role in Scrum".
