The New Gives and Takes in a Software Tester’s Role

[article]
Summary:

As champions of product quality, software testers have an increasing responsibility in empowering the team to understand and own quality themselves. Testers need to optimize their efforts by giving away some tasks to others on the product team and taking on newer tasks to align with a more focused approach. Read on to realize what you should give up or take on.

Today, the software tester is at a crossroads. He needs to revisit his role to align himself with the changing times in the software quality and product development spaces.

For advice on how to navigate this, I lean heavily on Give and Take: Why Helping Others Drives Our Success. The book, written by a top-rated professor at Wharton, was one of the best-selling books in 2013 on Amazon. When you look at the concept of “give and take” more closely, it really stretches and applies itself across disciplines, helping pave a path to success. The software testing discipline is no exception.

Software quality is no longer a downstream activity. In the drive to move upstream in the development lifecycle, it has gotten a positive facelift, including a collective ownership for quality amongst the product team members. As champions of product quality, software testers have an increasing responsibility in empowering the team to understand and own quality in their own spaces. The tester is also optimizing his own efforts in this process, which means it is time for a round of focused clean-up, giving away some tasks on his plate to others on the product team and taking on newer tasks to align with this need.

When I look at gives, I look at them from two angles: “What can I give away totally from my plate?” and “What can I give away from my plate to someone else on my team?” Let’s look at the first set, what you can give away totally.

  1. Give away a detailed documentation approach. A few years back in one of my previous jobs, I was personally involved in creating a test strategy for a leading independent software vendor for a V1 product. The strategy was more than a hundred pages, and we put a lot of effort into it. However, within a few days it became bulky and obsolete, and several sections—especially ones such as resource mapping—could have been completely avoided. I am not advocating an antidocumentation approach, but it is important to pay close attention to optimizing wherever possible.
  2. Give away a complete script-based testing approach. Whether manual or automated, if you are adhering to a 100 percent script-driven approach, now is the time to give it away. Such an approach impedes on the tester’s creativity and contains even the most creative tester in a box.
  3. Give away age-old metrics that are carried forward year after year. Metrics are very useful and will continue to be used in the coming years to help us move from a world of quality assurance to confirmation. However, what metrics we use are very important to keep track of to ensure we update the set year after year, release after release, to derive true value.

Moving to the next set, now is the time for a tester to give a few tasks from his plate to his teammates, with the intent of further promoting collective ownership of quality. Think about scenarios where build verification tests can be handed off to the developer or to the build engineer to be included as part of the continuous integration suite. Give away sanity tests, like a set of automated tests, to the build engineer to empower him to troubleshoot issues. Include a small regression test suite when you report bugs to help developers verify them at the first level before the fix reaches your plate.

User Comments

6 comments
Joe DeMeyer's picture

Hello Rajini!

This is a great article and should be a catalyst for organizations everywhere, and especially for testers exploring methods of fully participating in projects.  I especially like your ideas around give and take and have a "give/take" suggestion.  I recommend giving developers the responsibility to test requirements. 
I recognize that not all requirements can be tested by developers but there are many that can.  For those requirements, the developer creates a set of tests (manual or automated) that demonstrate the requirements.  As a follow up, the developer reviews the tests and test results with the tester to verify the requirements are covered.  With the most requirements evaluated, testers "take" time to investigate and evaluate product risks through their testing.
I also appreciated your response to the question of how to introduce this change.  I agree patience and persistence is key.  I also believe that engaging other testers in the change can lead to a cultural mindset shift.

Thanks!

Joe

June 19, 2014 - 2:18pm
Rajini  Padmanaban's picture

Thanks Joe. Glad that you share these views. I see your suggestion as a potential "unit test" for the requirements...This is a good idea and could even be a paired effort between the developer and tester to not only load balance but also promote better collaborative understanding of the product even at the requirements stage. I had a lot of positive response when I presented on this topic late last year in a testing conference. This is welcoming for me to see that several people are now able to align with these ideas of gives and takes!

June 20, 2014 - 4:45am
Lisa Boden's picture

We don't have a separate test team at this point, but we want to incorporate a more "serious" testing attitude and implementation. I like your ideas in this article and will share with my team.

Thank you,

Lisa, CTFL

June 30, 2014 - 10:13am
Rajini  Padmanaban's picture

Lisa - Thanks for your note. I am glad this is useful to you. You are right - these are points that can be embraced whether or not an independent test team is in practice. If along the way, you need to discuss any of these further, I am happy to talk to you.

June 30, 2014 - 12:42pm
Dawn Jardine's picture

I recently published a similar article on LinkeIn (https://www.linkedin.com/pulse/changing-role-qa-analyst-dawn-jardine?trk...). I absoolutely agree that our role as QA analyst is changing. Being agile, bridging the gap with product owners and development group, and improving our technical skills are all ways that we can give away age-old tasks that QA territorially owned. Great ideas, and enjoy reading your perspective.

May 10, 2016 - 2:04pm
Gerie Owen's picture

Hi Rajini,

This is awesome!  I especially love how you used the tortoise and hare fable so effectively!

 

May 10, 2016 - 2:12pm

About the author

StickyMinds is a TechWell community.

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