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.
- 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.
- 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.
- 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.
Such small giveaways go a long away in optimizing the team’s activities, saving time for everyone and, more importantly, promoting better product quality. While the entire team can derive immense value from these giveaways, these actions are easier said than done. The testers as well as the other members of the product team need a lot of maturity in handling such giveaways, as they could easily break the team’s relationship if not handled correctly.
Now that we’ve addressed the giving, equally important is the taking—the tester needs to now put some responsibilities on his plate. Here are some ideas about what you can take.
- Take ownership to build a professional testing culture. It is great to see the entire product team step in to contribute to product quality in possible ways. A tester now needs to step into the shoes of a quality consultant to empower everyone to contribute to product quality. This is also a great opportunity to define how everyone can help with the testing effort, with the goal of weaving a professional culture around it and giving the activity its much deserved facelift.
- Take responsibility while you enjoy controlled freedom. As we talk about the set of giveaways, some wrongly confuse these tactics with taking a haphazard approach to testing. The giveaways do not in any way mean the tester gives away his responsibility or role in shipping a quality product. He needs to see this newfound freedom as controlled freedom, assuming the required responsibility to continue to be accountable for the product quality. More specifically:
- Take on evaluating competing products. With the newfound time on his plate, a tester needs to look for ways to understand competition in the marketplace—what features other products offer and how they function, the performance and usability they provide, how secure they are, and what business model and pricing strategies other companies use—and arrive at an actionable comparison report with his product, specifically around quality. Discuss this with your core product team and see the difference you are able to create. Once you start this effort, it is positively contagious in the team, forcing everyone to think along these lines.
- Take part in defect triage meetings. The practice of holding triages just between the business owners and the developers is still prevalent in several development teams. If so, you should be the change agent and tell your team that there needs to be representation from test in the triage meetings. You bring an important perspective of end-user impact in defects filed and as the end-user representation, so don’t miss the chance of having test take part in defect triage meetings.
- Take on end-user analysis. End-users provide a lot of candid feedback for your product that, when closely analyzed, gives perspective on product quality, what kind of tests you should be taking on, what areas need more focus, etc. So, use this newfound time to take on closer end-user analysis—be it from past defects they reported, field studies, or customer forums.
At a conference where I spoke on this topic, a listener said that while he would love to follow the advice I outlined, how could he win his team’s buy-in to such gives and takes, especially if it is a conservative team? My response to him was to adopt a persistent and patient approach. Demonstrate the value of gives and takes through small steps. For example, if he is keen on sharing his testing know-how with the community but his organization does not encourage attending conferences, start small. Prove worth within the organization first before branching off to something bigger. Once the tester takes baby steps in winning the confidence of a conservative team, he has created a precedence and paved a way not just for himself, but also for his other fellow testers to embrace the give and take approach.
I recently thought of a fable that will help drive home the message of this discussion effectively. It is the famous hare and tortoise story that we all heard as kids, where the hare and the tortoise decide to race. The hare is complacent and over-confident about his running skills and loses to the tortoise because he becomes lazy. The moral is “Slow and the steady wins the race.”
There are three other sequels to this story that fit very aptly to our needs here. In sequel two, the hare does some soul searching and finds out why he lost the race, so he invites the tortoise to race again. He is fast and steady this time, winning the race hands down. Our takeaway here is “Slow and steady is good, but fast and steady is even better.” So, someone who is faster and equally consistent in an organization will be able to shine better than the others.
In the third sequel to this story, the tortoise does his soul searching. He knows what his capabilities are and tries to see if there is a way for him to win. He finds new playing fields that are dynamic and provide better potential for him to excel. So, he invites the hare to the race again, incorporating a river along the racetrack this time. The hare is fast in this race too, until he reaches the river. He freezes, not knowing how to proceed, while the slow and steady tortoise gets there and swims his way to the finishing line. The moral of this sequel is “Identify and leverage core competencies and explore new playing fields for growth and advancement.”
In the final sequel, by which time the hare and tortoise have become good buddies, the two decide to run together to the finish line as a team. They understand that doing this together will be more fun, effective, and successful for both of them. So, the tortoise jumps on the hare’s back to get all the way to the river. At that point, the hare jumps on the tortoise’s back to cross the river and reach the finish line. This is the sequel testers need to understand and buy into, the moral here being “Teamwork is about situational leadership and empowerment.” The person with relevant core competency in a situation should take the lead so the group can shine together. An approach of give and take lets the team win together with much less overall effort but much more fun and collaboration.
In summary:
- The playing field for software quality is changing.
- We need to look at the gives and takes to redefine our roles.
- Amidst all these changes, we should ensure we collaborate but don't lose our independence.
- And finally, let us remember the new hare and tortoise story to win together as a team!
User Comments
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
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!
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
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.
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.
Hi Rajini,
This is awesome! I especially love how you used the tortoise and hare fable so effectively!