“We are often badly in need of some fresh potting mix, such as pearls of wisdom from the testing community!”
During our school days, most of us learned about the lifecycle of a seed. I still remember how fascinated I was as a child when our teacher told us about the first root and shoot of a seed. I want to relate this concept to how I got the opportunity to be a test manager and how I came to realize, over time, that I already had a lot of what it takes to do the job right.
This is a story of a test automation engineer who now wears a test management hat. I am a senior test engineer with an inclination for automation and an Agile mindset. How did I get here? I am very grateful that through my hard work and passion for testing, I have been able to inspire several engineering teams with my communication skills, shift-left mindset, persuasive traits, and collaborative ways of working.
Get ready to hear my story: how I realized my strength gained from past work experiences, embraced the challenges of a technical tester turning to test management, absorbed like a sponge all that I could learn from my fellow stakeholders, committed to be accountable for all the good things we agreed deliver, and humbled to have the opportunity to practice empathy with my team members.
As a cherry on top of the sundae, this is a story of how the tester in me is still alive and will be so for the rest of my days. No matter which career cap I choose to wear, testing will always be the brightest feather in it!
The first root and shoot of this journey
Just as the first green shoot of a seed grows towards the light, the testing team at my organization aims for excellence, providing testing as a service to several product teams across business units. My management journey began here, when I got the opportunity to manage offshore testing activities for an application that incorporates a third-party tool.
And then there's the root, the part that grows deep down into soil to absorb all the nutrients necessary to sustain the plant. For me, that root was fed by the experience, observations, shortfalls, and achievements from my past projects. All of it prepared me for accepting a management opportunity. When I began, I realized this was going to be new to me, but I never doubted that it was meant for me.
The photosynthesis phase: Catching my breath
Sending down roots: Learning what (and whom) to ask for help
The green leaves of a plant are the solar panels that absorb light to prepare food for the plant. In the same manner, the initial couple of weeks of the project as a new test manager are vital.
On my project, we have an in-house business team that conveys requirements to an offshore team. The offshore team configures and builds the solutions on top of a third-party application tool. And we are also in touch with the third-party application team.
My initial struggle was to understand all the business terms and acronyms used by the teams, get a hang of the application side of things, and develop solid communication with the offshore testing team. Even though I had a good deal of experience, this specific situation was brand new to me.
I used my listening and reasoning skills to understand the project basics. I learned who the stakeholders were, what the various internal teams did, and how the communication flowed between the teams. I also learned about my part: where I sat within the current setup and whether I needed to bridge the communication between teams.
And I quickly committed to seeking help. For example, I asked the production support (PS) team to give me a demo of the application. Here's what I did that worked well:
- Scheduled learning sessions. Over several meetings, the PS team helped me to understand various user journeys and explained the functionality of each section of the application.
- Leaned into the experience of others. The main reason I chose the PS team to ask for help: they frequently hear from end users about configuration and permissions issues. So they could show me the possible configurations based on various levels of user permissions. And, since they provide on-demand training to end users, they are good at explaining things.
- Took advantage of established relationships. Since I had been a tester at the company for a while, I already had a good relationship with production support. So the education sessions helped a strong relationship grow even stronger.
More tips for the learning phase
Always embrace the learner in you! This is your photosynthesis phase if you are transitioning into a new team as a manager.
Please remember that you won't always have someone to explain all these aspects in a nutshell. My advice here is: take some time to catch your breath and if you have any doubts, speak up and ask questions.
Spread out your leaves to absorb all the light you can during the initial days! Understanding the basics of how the team operates will allow you to send your roots deeper and build on top of what the team already has.
The flowering phase: Growing my confidence
Colorful and bright flowers are, for many people, their favorite phase of a plant's life cycle.
Eventually I emerged from the initial getting-to-know phase and started to get the confidence to make contributions. I really enjoyed understanding and implementing my responsibilities across the various teams within the project.
Here are some of the strategies that I found helpful during this phase:
Write and maintain a tactical plan
In all projects involving offshore teams, the vital information resides in the tactical plan developed by the business and the offshore team. This plan includes the dates for each sprint, deliverable details, teams responsible for each deliverable, and many other such details. This document is my bible, since it contains all the core information of deliverables with timelines.
My advice to you is: if you’re new to the team, figure out what the tactical plan is, and it goes without saying that engineering teams use different terms to refer to these! If your team doesn't have one, suggest it right away.
Allocate enough time for testing the product and defect fixes
I made sure I always ensured to build in enough QA testing time between one environment release and the next. And I watched out for risks to release dates, like insufficient windows for testing or defect fixes, in-house and third-party releases scheduled for the same date or consecutive dates, and so on.
Always raise these issues during status meetings or stand-ups, and make sure any change to plan is communicated clearly. Test managers with a testing background can play an effective role as a "Quality Advocate’ in this area.
Strive for seamless communication
High-quality communication among team members is essential. Test plans need to be published, and test execution outcomes need to be recorded and shared. Reviewing the test plans can be effective for managers with testing backgrounds and also it's a great way to keep the tester within you alive!
Make good use of a solid test management tool
It is wise to record test plans and test execution results in a management tool. We use Azure DevOps Services. Make sure to add the environment configurations to be precise as to where tests are being conducted. (I learnt to double-check on this from a peer who is a very talented test manager herself.)
You may argue: this is a basic deliverable for any test team. Why point this out explicitly? Well, for example, if your project involves both onsite and offshore teams, your offshore teams may not yet be sharing test results with the onsite team. It's the responsibility of the test manager to make sure that all deliverables are visible to the onsite stakeholders and business.
Keep the team up to date on testing status
Be keen to discuss and agree when and how you will send status updates across teams. For example, I learnt from the previous testing lead to send a tracker sheet to delegate actions based on an agreed template. The tracker sheet referenced the test plans for pre- and post-release, lists of defects, application version, and so on.
I needed to know in advance when the in-house and the third-party company-wide releases were scheduled. I got this information from various sources: a calendar of third-party release dates, the tactical plan, the production support team, and the official support website for the third-party company. As a test manager, newbie or savvy, it’s a good practice to track all the sources for release dates and raise risks for any inconsistencies.
Full bloom
All the points we discussed above are similar to the bright and colorful petals of a flower. I hope you also understand how a tester turned manager can contribute at their best and bloom as brightly as a flower!
The fruits and seeds phase: Making an impact
Many people think that the purpose of a plant’s life is fulfilled when it yields fruits to be cherished and seeds to continue to live in a new form.
Let’s compare this phase to making an impact as a test manager. This is the phase where I got motivated to make fruitful contributions to the team and took on a new form by opening up to new understandings. Come join me to take some pointers: I hope this comes handy to the newbies in town!
Breaking the ice: Building the offshore relationship
To better explain my growth in relationship building skills, let me describe myself as I was when I first started my testing career. I once was the type of tester who logs in, stays mute in meetings, focuses solely on my automation tasks, and commits my code for review. I did little else other than that.
Even though I am an introvert, thankfully I outgrew the mindset of detachment from the rest of the team. I cultivated my communication skills and collaborative working patterns thanks to some good advice from my managers. The self-reflection and work on myself helped me grow in my career and improved my emotional intelligence.
Knowing what I know now, I routinely schedule regular one-on-one catch up calls with my testing counterparts on the offshore team. Through these meetings I am able to clarify doubts about what's happening within the configuration (dev) team, plan ahead for future releases, share workload when the offshore team requires extra help, and generally stay on top of the game.
An unanticipated benefit: I got to learn a lot from them as people, including how to respect cultural boundaries and social differences. Because you're well connected with your team members, you're a lot less likely to say things like "I have no clue what’s going on!" This process makes you more human.
Be strategic: Roll up your tester’s sleeves
In one of my other projects, I get to work with a talented test manager who is strategy-savvy! I am blessed to have had the opportunity to work with such a leader, as I still get to learn the basics again but now with strategic seasoning! Yes, even when a tester turns into a test lead or manager, he or she has to be thorough with the basics of testing and Agile concepts to strategize their moves.
I would like to share one of my learnings here as a real-world example. When the feature status on our Azure DevOps board moves into the "In Analysis" swimlane, our practice is to review the feature in a Three Amigos session. In these sessions, I learned how to elicit requirements from the tester's standpoint. How cool is that?
The Three Amigos sessions have spurred some positive momentum on our team. And I’m so proud to share this pointer to the wide world of testers. If you are a tester or a test manager or both: remember you can make jaws drop by persuading others to try what you feel is beneficial for the team!
Be the handyman: Who said that test managers don’t test?
As a test engineer wearing a test management hat, I make sure that the tester in me never gets lost. With my management workload in mind: I make sure I assign testing tasks to myself, work on the test cases, and take complete ownership of the task until it moves to user acceptance.
I frequently remind the offshore team to count me in if they need testing help. During one of our pre- and post-upgrade releases, I shadowed the sanity check test executions to get familiar with the application, to get some hands-on experience and also help the team out.
Another example: a production support team member once approached me about an issue with an add-in extension specific to the development environment. At that moment, as a test manager, I learnt I had to try to replicate this issue myself, take my findings to the relevant team, and facilitate the resolution of the issue. Taking charge of these responsibilities is vital.
I always keep in mind that I have a team under my wings to soar high! For all the newbie managers out there, get ready to hold the steering wheel for your team!
Delegate and communicate: As clear as crystal
When you are working on a project with multiple teams and there are a lot of communication threads looping in everyday, the possibility for confusion is great.
I learnt it’s important to agree to delegate responsibilities should the need arise, and then to act on that. A good manager clarifies who is responsible for carrying out the task, provides appropriate guidance, communicates priorities, empowers the team, and promotes autonomy as to approach as long as project standards are met.
Being clear in communicating those points to the team in advance will avoid misunderstanding within the team and allow for a relaxed preparation mindset.
Hone your business skills: A business analyst understands a tester like no one else
One of the best parts of being a test manager is that you get to work closely with the business owner and other stakeholders of the team as you represent the testing perspective of the project as a whole. In most situations, it is also the responsibility of the manager to discuss test strategies with the rest of the testing team and to take into account the team’s perspective before finalizing the ways of working with the stakeholders.
Teamwork and channeling skills come in handy here. I always enjoyed working closely with the business analysts (BAs) as it’s a great opportunity to learn requirements elicitation techniques. BAs thoroughly analyze the business objects and goals, gather requirements, and align these with the development team.
Let me share some instances of BA collaboration:
We were tasked with providing integration logic to onboard users from one application to the other seamlessly, based on a set of predefined conditions. As a test manager, I worked with the BA closely to understand the technical details of this logic and ironed out the positive, negative, and edge-case scenarios to be tested.
My interactions with the BA were beneficial. He easily understood the context of my queries and observations. More than that, he understood the planned test coverage if I happened to mention details of one test or another. I learnt how my BA thinks of various happy-path and edge case scenarios and relates them to the business logic. Our interactions led to several important changes in the requirements.
These experiences have changed my thinking pattern as a test manager.
- I learnt to ask the question: what business problem does the work item or the feature solve?
- Don't be afraid to dig deep into the testability aspects of the feature much earlier than you might have in the past.
- Always anticipate the "what if’s" of the user journey and revisit the requirements to see if there is a need for further elicitation.
My advice here is: never hesitate to work closely with business analysts. Build strong relationships and schedule regular meetings with the BAs: you have a lot to learn from the outcomes of the interactions.
Sometimes plants wilt: Mistakes made and lessons learnt
Not all plants bloom. Sometimes plants drop their leaves, droop, and wilt because of lack of water. Never feel gray about this: usually some water will perk them right back up again.
I compare this situation with the mistakes I have made during my journey. Just as plants recover quickly when watered, so do we recover from our mistakes from the lessons learnt.
Let’s look at some of the mistakes I have made and how they might be valuable pointers for you!
Keep important project dates front and center
One time, the third-party application team scheduled an upgrade on the development environment. I was in the habit of following the tactical plan sheet maintained by the business and the offshore teams to track deliverables and planned upgrades. For some reason, that particular upgrade date wasn't added to the tactical plan. And guess what: as a result, I sent my regular email communication on test plans and delegations on the very day of the upgrade rather than the previous week.
My lesson learnt: Keep an eye out for release dates and cross-validate key dates and communications!
Agree on and document team responsibilities
As I mentioned earlier in this article, one of the important to-dos of the manager is to communicate clearly about who is responsible for each deliverable.
What do you think I did when I was new to the team and unsure of the person to whom I should delegate the responsibility? At that point, I took the easy option, which is not a crime: I asked the offshore lead and the onsite service manager to which team I should delegate the pre- and post-upgrade test execution on a specific instance.
This wasn't a bad option, but I realized later that the more mature way of handling these ambiguities was to make an agreement, communicate it, and stick to the plan. In my case, this document had already been shared with me, but I'd completely missed reading this amidst the torrent of other information I had to review.
Lesson learnt: Flag important documents like agreements between teams and team members so that it's less likely that people will miss reading them.
Know where your defect fixes are: Use a dashboard and share what you know
In my project, the defects raised in Azure DevOps represent issues to be fixed by the offshore configuration team or third-party application team. The production support team also uses the board to track issues raised on the third-party application support portal.
I must admit I struggled to keep track of these until I realized I could request access to the third-party application support portal.
From then on, I made sure the defects on the Azure DevOps board were updated with all the reproduction steps, environment details, a link to the third-party application ticket, and copy-pasted comments from the third-party team.
As a newbie, set a trend in team dynamics by keeping track of all defects through dashboard queries and orchestrate teamwork by synchronizing defect tracking systems.
Get to know your team members and think about how you can best support them
We discussed emotional intelligence earlier, which is a highly valued characteristic for any manager.
As a test manager, I know that each of my team members is unique. This applies to managers too! Each person has a standout characteristic or skill.
Even though I now enjoy the people side of management, I used to feel some pressure when I had to review the deliverables of my team members! This can push some managers into micromanagement, which is toxic. I have been able to avoid that impulse, thanks to a culture of autonomy that my past managers fostered. It's now my turn to create such an ecosystem for my fellow teammates.
I learnt from my senior manager that I can review deliverables by using strategic checkpoints and review sessions. Example: After each "Three Amigos" session, I have a quick review meeting with testers to discuss test coverage.
Reflect on your peers as people. Tailor the support you need to deliver to your team based on peer needs! It can be "X’ for Adam and "Y’ for George.
The re-potting phase: The world is my oyster
When a plant is moved to a new pot, we have to loosen its roots and transfer it to the new pot with fresh potting mix.
I compare this process to onboarding into a new project and role. When we are shifting to a new project, there is unlearning, learning, and relearning to do. We are often badly in need of some fresh potting mix, such as pearls of wisdom from the testing community!
Some of you might feel that you are alone in your test management journey. That's simply not so. One Friday night, while I was in search of some badly-needed advice and motivation, I logged into my MoT Pro account, a mug of cardamom chai beside me on my desk. And I asked a question on The Club.
Over the next couple of days, my mobile buzzed again and again with great suggestions from all the wonderful contributors who bothered to take a few minutes from their busy life to respond to my post!
Here's the question I asked The Club about test management:
"Hi MoT Club,
I am now in a test management role in one of the recent projects I’m currently assigned. I have been a senior test automation engineer for many years now and I find this transition a great learning curve. Has anyone here been on a journey similar to mine?"
(Here's a link to my original question.)
And I got these great answers!
- Rahul Parwal talked about giving agency to your team and listening to them
- Antony Zhu mentioned setting up KPIs and encouraging use of new tools
- Jesper Ottosen suggested to read few MoT club posts related to test management
- Cassandra H Leung suggested thinking about other Ps apart from product - Project, People and Processes
To wrap up
I hope that sharing my experiences on this challenging journey will provide readers with valuable insights. You don't have to make the same mistakes as I did, and you also have an opportunity to stay on top of your test management game by implementing the ideas I've written about.
I hope you will bookmark this article for some mental and moral support while you're creating wonders in your new or current role!
For more information
- Growing Test Managers, Eric Proegler
- Ask Me Anything: Skills and Strategies for New Test Managers, Laveena Ramchandani
- Test Management Adaptations in Times of Distributed Testing, Joel Montvelisky
