QA in an Agile World - Chris Mastnak

Hear from Chris Mastnak, "Global Practice Lead - Agile Testing"
at Nagarro, on what it means for QA/Testing team members to work
in an agile environment. 


According to Chris, life in QA gets easier with agile. He tells a
story of major User Acceptance Test events at the end of a large
9-12 month build carrying a significant amount of risk. It's
simply too wide of an area to cover with testing after nearly a
year of development. Thanks to agile, QA can be much more
confident with testing because they're covering smaller batches
of functionality.


Unfortunately, just like in a traditional, waterfall project, the
greatest risks are pushed to the end of the timeline. This same
cycle shows up sprint by sprint, with QA getting 1 day to test
all of the stories of the sprint. The good news? On agile teams,
this kind of an issue resolves itself after a couple of
retrospectives. 


As your team gets better at delivering features more frequently,
you're going to need to get better at regression testing (making
sure everything that worked before is not broken by new
features/code). Before you were doing this a few times a year,
but now you're doing it every 2 weeks. Agile teams remedy this
issue by automating everything they possibly can. According to
Chris, manual testing is still very important, but automation has
to become a priority across teams. Chris suggests starting with
automation for regression testing and sticking to manual for
exploratory testing to make sure the new features are behaving as
expected.


What about teams that "don’t have time" to automate? Chris
suggests looking for automation tools and frameworks that fit
your team's situation. Aim to automate one story in each sprint,
this will slowly build your automation repo. 


According to Chris, an interesting side effect of agile is that
it creates a cross-over between Developers and Testers. On the
one hand, Testers get more involved with the development and
start to understand why a feature was developed the way it was,
giving them a better understanding of the behavior they should
expect from it. On the other hand, Developers get more involved
in the testing and start to become better at spotting gaps in
test scenarios or plans. Ultimately, the team's ability to build
and test a quality solution significantly improves as they work
together more and more. 


What does this mean for a QA Manager?


There's nothing in the Agile Manifesto about the role, nor is
there anything in the Scrum Framework for QA Manager, so what do
you do now? 


Aside from becoming a QA Coach and working to make your team of
Testers the best they can possibly be, Chris suggests elevating
your perspective. 


Start looking across development teams and consider how to
elevate transparency of testing beyond one team (it's easy for
one team, but how is it done across multiple dev teams?)

Start advocating for automation beyond one single team to
drive quality on a larger scale. 

Start anticipating what this years' big programs mean for
QA. 

Start thinking about and advocating for what Continuous
Integration or Continuous Deployment will require across
development teams. 

Things you may have already been doing, but will help clear
the path for your teams: 

Make sure your QA environments are well cared for 

Make sure your team is continuously honing its
skills 

Make sure your team has the necessary tools to do a
stellar job 





Still not satisfied? Chris points out that anyone at your company
with a few years of Testing experience has likely accumulated a
vast amount of knowledge about how your product works; which
makes them a potential Product Owner.