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.
Conclusion
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.
Source:InfoQ
