mentoring

Mentoring Software Testers

Mentoring is important in any field, but it’s especially critical for software testing. I’ve been blessed with good mentors throughout my life, and I’ve also been honored to serve as a mentor for other software testers. In this article, I’ll explain what mentoring is and how to practice it within the context of software testing.

What is Mentoring?

Mentoring is a one-on-one relationship in which the experienced guides the inexperienced.

  • It is explicit in that the two individuals formally agree to the relationship.
  • It is intentional in that both individuals want to participate.
  • It is long-term in that the relationship is ongoing.
  • It is purposeful in that the relationship has a clear goal or development objective.
  • It is meaningful in that growth happens for both individuals.

Mentoring is more than merely answering questions or doing code reviews. It is an intentional relationship for learning and growth.

Why Software Testing Mentoring Matters

Software testing is a specialty within software engineering. People enter software testing roles in various ways, like these:

  • A new college graduate lands their first job as a QA engineer.
  • A 20-year manual tester transitions into an automation role.
  • A developer assumes more testing responsibilities for their team.
  • A coding bootcamp graduate decides to change career.

There’s no single path to entering software testing. Personally, I graduated college with a Computer Science degree and found my way into testing through internships.

Unfortunately, there’s also no “universal” training program for software testing. Universities don’t offer programs in software testing – at best, they introduce unit test frameworks and bug report formats. Most coding bootcamps focus on Web development or data science. Certifications like ISTQB can feel arcane and antiquated (and, to be honest, I don’t hold any myself).

The best ways we have for self-training are communities, conferences, and online resources. For example, I’m a member of my local testing community, the Triangle Software Quality Association (TSQA). TSQA hosts meetups monthly and a conference every other year in North Carolina. Through these events, TSQA welcomes everyone interested in software testing to learn, share, and network. I also recommend free courses from Test Automation University, and I frequently share blogs and articles from other software testing leaders.

Nevertheless, while these resources are deeply valuable, they can be overwhelming for a newbie who literally does not know where to begin. An experienced mentor provides guidance. They can introduce a newcomer to communities and events. They can recommend specific resources and answer questions in a safe space. Mentors can also provide encouragement, motivation, and accountability – things that online resources cannot provide.

How to Do Mentoring

I’ve had the pleasure of mentoring multiple individuals throughout my career. I mentor no more than a few individuals at a time so that I can give each mentee the attention they deserve. Mentoring relationships typically start in one of these ways:

  1. Someone asks me to be their mentor.
  2. A manager or team leader arranges a mentoring relationship.
  3. As a team leader, I initiate a mentoring relationship with a new team member (because that’s a team leader’s job).

Almost all of my mentoring relationships have existed within company walls. Mentoring becomes one of my job responsibilities. Personally, I would recommend forming mentoring relationships within company walls so that both individuals can dedicate time, availability, and shared knowledge to each other. However, that may not always be possible (if management does not prioritize professional development) or beneficial (if the work environment is toxic).

My teammates and me at TSQA 2020!

From the start, I like to be explicit about the mentoring relationship with the mentee. I learn what they want to get out of mentoring. I give them the top priority of my time and attention, but I also expect them to reciprocate. I don’t enter mentoring relationships if the other person doesn’t want one.

Then, I create what I call a “growth plan” for the mentee. The growth plan is a tailored training program for the mentee to accomplish their learning objectives. I set a schedule with the following types of activities:

  • One-on-one or small-group teaching sessions
    • The best format for making big points that stick
    • Gives individual care and attention to the mentee
    • Provides a safe space for questions
  • Reading assignments
    • Helpful for independently learning specific topics
    • May be blogs, articles, or documentation
    • Allows the mentee to complete it at their own pace
  • Online training courses
    • Example: Test Automation University
    • Provides comprehensive, self-paced instruction
    • However, may not be 100% pertinent to the learning objectives
  • Pair programming or code review sessions
    • Hands-on time for mentor and mentee to work together
    • Allows learning by example and by osmosis
    • However, can be mentally draining, so use sparingly
  • Independent work items
    • Real, actual work items that the team must complete
    • Makes the mentee feel like they are making valuable contributions even while still learning
    • “Practice makes perfect”

These activities should be structured to fit all learning styles and build upon each other. For example, if I am mentoring someone about how to do Behavior-Driven Development, I would probably schedule the following activities:

  1. A “Welcome to BDD” whiteboard session with me
  2. Reading my BDD 101 series
  3. Watching a video about Example Mapping
  4. A small group activity for doing Example Mapping on a new story
  5. A work item to write Gherkin scenarios for that mapped story
  6. A review session for those scenarios
  7. A “BDD test frameworks” deep dive session with me
  8. A work item to automate the Gherkin scenarios they wrote
  9. A review session for those automated tests
  10. Another work item for writing and automating a new round of tests

Any learning objective can be mapped to a growth plan like this. Make sure each step is reasonable, well-defined, and builds upon the previous steps.

I would like to give one warning about mentoring for test automation. If a mentee wants to learn test automation, then they must first learn programming. Historically, software testing was a manual process, and most testers didn’t need to know how to code. Now, automation is indispensable for organizations that want to move fast without breaking things. Most software testing jobs require some level of automation skills. Many employers are even forcing their manual testers to pick up automation. However, good automation skills are rooted in good programming skills. Someone can’t learn “just enough Java” and then expect to be a successful automation engineer – they must effectively first become a developer.

Characteristics of Good Mentoring

Mentoring requires both individuals to commit time and effort to the relationship.

To be a good mentor:

  • Be helpful – provide valuable guidance that the mentee needs
  • Be prepared – know what you should know, and be ready to share it
  • Be approachable – never be “too busy” to talk
  • Be humble – reveal your limits, and admit what you don’t know
  • Be patient – newbies can be slow

To be a good mentee:

  • Seek long-term growth, not just answers to today’s questions
  • Come prepared in mind and materials
  • Ask thoughtful questions and record the answers
  • Practice what you learn
  • Express appreciation for your mentor – it’s often a thankless job

Take Your Time

Mentoring may take a lot of time, but good mentoring bears good fruit. Mentees will produce higher-quality work. They’ll get things done faster. They’ll also have more confidence in themselves. Mentors themselves will feel a higher satisfaction in their own work, too. The whole team wins.

The alternative would waste a lot more time. Without good mentoring, newcomers will be forced to sink or swim. They won’t be able to finish tasks as quickly, and their work will more likely have problems. They will feel stressed and doubtful, too. Forcing people to tough things out is a very inefficient learning process, and it can also devolve into forms of hazing in unhealthy work environments. Anytime someone says there isn’t enough time for mentoring, I would reply by saying there’s even less time for fixing poor-quality work. In the case of software testing, the lack of mentoring could cause bugs to escape to production!

I encourage leaders, managers, and senior engineers to make mentoring happen as part of their job responsibilities. Dedicate time for it. Facilitate it. Normalize it. Be intentional. Furthermore, I encourage leaders to be force multipliers: mentor others to mentor others. Time is always tight, so make the most of it.

More Advice?

I hope this article is helpful! Do you have any thoughts, advice, or questions about mentoring, specifically in the field of software testing? I’d love to hear them, so drop a comment below.

I wrote this article as a follow-up to an “Ask Me Anything” session on July 15, 2020 with Tristan Lombard and the Testim Community. Tristan published the full AMA transcript in a Medium article. Many thanks to them for the opportunity!

Let Me Google That For You

A brief memoir on self-improvement through self-humility.

I learned one of my most important life lessons before my career officially started. From 2007 to 2009, I interned on-and-off for the Rational Business Developer team in IBM’s Software Group. The team was great and let me do everything: development, testing, automation, builds, and even fun Web examples. However, my junior-level experience often made me doubt myself (e.g., imposter syndrome), and there were “known unknowns” by the truckload.

200px-shyguycttt_artwork

A photograph of me as an IBM intern. (j/k)

For my own survival, I quickly learned to fearlessly ask questions. This was a big step for a shy guy like me. My team mates were more than happy to help me, which put me at ease. Asking questions was a good thing.

…Until one time, it became a bad thing.

I forget exactly when it happened and what my specific question was, but I do remember the person and the method. I “pinged” (IBM lingo for “send an instant chat message to”) one of the senior developers with a question, and he replied with a link. When I clicked it, the browser loaded Google, moved the cursor, typed my question, and clicked the search button.

He sent me to Let Me Google That For You.

I was horribly embarrassed. It was an introvert’s worst nightmare come true. I never knew about LMGTFY before, and the sarcasm didn’t hit me until after the search was complete. My fledgling confidence was shattered.

embarrassed-anime-girl

My face after my first LMGTFY.

I couldn’t tell if the guy:

  1. Thought lowly of me
  2. Was annoyed with me
  3. Was trying to coach me
  4. Was having a bad day
  5. Was just a jerk

The reason didn’t matter, though. He made a valid point: the question was Google-able, and I could have searched for an answer myself before asking others. As I picked up the pieces of my confidence, I introspected on how to do better next time. Was it wrong to ask questions? No. It is never wrong to ask questions, and anyone who says otherwise is a jerk. Was it wrong for him to send me to LMGTFY? It certainly was unprofessional and harmful to our team dynamic. But, was there a better way to ask questions? Yes:

When faced with an unknown, pose it as a question. Then, ask yourself the question first before asking others.

I call this the “self-Socratic method.” Whenever I don’t know something, I write a list of questions. Then, I try to answer those questions using my own resources, like Google, Wikipedia, and books. When I answer a question, I cross it off the list. Inevitably, answers lead to more questions, which I add to the list. As the list grows, new questions become increasingly specific because the unknowns become smaller. I also find that I can answer most factual, knowledge-based questions myself. The questions that require me to ask someone are typically wisdom-based or experience-based. For example, the question, “How do I build a Web app?” could reduce to, “Why do you prefer to use Angular over React as the JavaScript framework?” because the World Wide Web already has much to say about the technologies behind itself. At the very least, even if I can’t find much by my own searching, my due diligence shows good faith when asking others.

socrates-e1483729570531

A photograph of me as a professional, self-Socratic software engineer. (j/k)

How much time do I spend searching for an answer before asking somebody who knows? This is a popular interview question. When using the self-Socratic method, I’d say (a) when the first two pages of Google results yield nothing, (b) when I spend more than 15 minutes absolutely stuck in code (from the time of the last “epiphany”), or (c) when I hit a wisdom- or experience-based question.

I’ve used the self-Socratic method for everything from learning how Web apps work to learning how to cut my lawn. I learned my lesson the tough way, but I’m glad I learned it early!

White Guy in a Kurta: My Passage to India

Life never gives us what we want at the moment that we consider appropriate. Adventures do occur, but not punctually.

From “A Passage to India” by E. M. Forster

Back in July of 2013, NetApp sent me on an awesome business trip to Bangalore, India. I had already planned to take a personal trip to China during a company shutdown, and I convinced my senior manager to send me to Bangalore on my way back to the States. The main reason for the trip was to help our offshore contractors build up their test automation skills for an upcoming release. While they benefited from my assistance, I likewise benefited from a much deeper appreciation for international workers. This article documents my experiences and the lessons I learned from my trip.

Transportation

My connecting flight from Kuala Lumpur (on Malaysia Airlines – gasp!) landed in Bangalore at around midnight, local time, on a Monday. NetApp provided a private cab for my whole stay. I felt a little bad because he spoke minimal English with a thick accent, but he was very friendly. I couldn’t see much on the drive to the hotel except a bunch of road blocks and a half-constructed highway. When he dropped me off at the Hyatt, I slipped him a few crumpled rupees my aunt had given me before my trip – she had visited India the previous year and implored me to always leave small tips.

Every morning that week, my cabbie picked me up from the hotel at 8am and returned me at 8pm. (The days were long.) He drove a crossover-like vehicle that felt like a minivan but drove like a small SUV, with flowers and Hindu statues over the dashboard. Even though the office was only a few miles from the hotel, a one-way trip took about 25 minutes. And I saw everything: “two-wheelers” (bikes with or without motors), “three-wheelers” (auto-rickshaws), “four-wheelers” (what we could call “cars” in the USA), pedestrians young and old, buses with people hanging on the side, and even cows just moseying through the streets. It was freaky to see not only everyone driving on the left side of the road, but to realize that the roads did not have any lane markings painted on them. In traffic, you just go with the flow, rather than obey specific conventions. Going to lunch one day, my “substitute” cabbie (not my typical driver) actually hit a two-wheeler, tearing off part of the cab’s bumper. Thankfully, the other guy just spat some pithy words in Hindi and sped away.

Traffic is chaos.  No lanes, few control mechanisms, and they drive on the left.

The view from the backseat of my cab: driver on the right, driving on the left (I think).

india-auto-rickshaw

The quintessential auto-rickshaw, driving rain or shine. And apparently, Bangalore has Taco Bell!

A cow at the bus stop!  Just chillin' there, no big deal...

Moo.

My Team

NetApp had a huge company site in Bangalore, but I spent all but one day at Mindteck, a nearby contracting firm hired by my organization. My team in Raleigh worked extensively with our group of Mindteck contractors. I felt delighted to meet them in person – they became more than broken voices and blurry profile pictures. And the team graciously welcomed me as one of their own. Every afternoon at about three or four o’clock, they tapped me to join them on the roof for masala chai (tea). There was never any shortage of Kinley water bottles, either. Embarrassingly, the team was so large that I struggled to remember who was who, but they never forgot who I was.

india-with-mukesh

Mukesh, one of my team mates from Mindteck, on the right. Me, in my kurta, on the left.

India Kinley.jpg

Kinley, the bottled water choice of champions! We call it “Dasani” in the USA.

During my visit, my team and I worked a lot. Every day, we had meetings, meetings, and more meetings, all about the “big A” – automation. Hearing my Raleigh team mates on the other end of conference calls felt like a strange reversal. I led automation workshops to teach our contractors a new framework we had developed in Raleigh. They also shared a number of problems with me, in the hopes that I could somehow help. Some were simple programming problems that took nothing but a simple proofread to correct. Others were out of my league. One evening, I sat locked in a conference room with an IT guy trying to figure out some obscure network failure, while two managers stared at us silently for almost two hours. I did my best to not feel awkward, assuming this style of management-by-pressure was cultural.

One problem I couldn’t solve for Mindteck was red tape. NetApp put a lot of restrictions on what the contractors could and could not do. They were restricted from accessing certain systems. NetApp’s Bangalore site also wouldn’t give them a direct network connection, which slowed down their network speeds to the point where test scripts would regularly crash from timeouts. Mindteck showed me their lab in disarray and admitted that they didn’t always get the hardware they needed for proper testing. Most frustratingly, I learned that the contractors were not even permitted to ask engineers on the parent team in Sunnyvale, California for help! In Raleigh, getting help from Sunnyvale was always a struggle, but at least we never had our hands slapped for asking. We all vented loudly about that ridiculous rule.

I spent only one day with the employees at the NetApp site. When I arrived, nobody was ready for me, so I poked around the cubicles until I saw plaques with names I recognized. Thankfully, everyone was friendly there, too. I don’t remember much of the NetApp site except meeting a few friends, seeing the Engineering Support center, and getting evening snacks at 6pm.

India NB Team.jpg

Lunch with NetApp employees in my organization. I wish this picture turned out better.

NB gets snacks every afternoon.  What are we doing wrong, Solomon Wube and Warren Campbell?

NetApp gave out snacks every day at 6pm. These were spicy!

The Hotel

NetApp approved only two or three hotels in Bangalore for travel. Arbitrarily, I chose the Hyatt, and they treated me like a king. Every manger, director, and VIP with a business card greeted me throughout the week. Bellhops always assisted me with luggage. Room service was always quick. And it was definitely a luxury hotel. Later, I learned that I was the first NetApper to stay there, and they sought to impress me in the hopes of future business from NetApp.

Exploring on my Own

The evenings were the only chance I had to explore Bangalore. As much as I wanted to hop an auto-rickshaw, I feared getting lost or scammed, so I stayed near my hotel on foot. Around the corner was a fancy shopping mall. The first store I entered was Big Bazaar, India’s version of Walmart. As a dumb American, my first mistake was attempting to enter Big Bazaar through the exit doors – a pair of armed guards quickly corrected my mistake by pointing me to the real entrance. Inside, I meandered through the store amazed by the essentials of Indian life, most of which were not much different from my own in America. When I tried to buy a few snacks from the grocery section, I made my second mistake by presuming the cashier would give me change – nope, I lost a few rupees. Before exiting through the proper exit doors, I detoured through the clothing department and bought myself a souvenir: a black kurta with red embroidery on the collar. I’ve since worn my kurta many times at Indian festivals in Raleigh.

BIG BAZAAR, India's version of a Walmart Super Center.

Big Bazaar – it was pretty big!

Across from Big Bazaar was a movie theater. Since I had nothing else to do, I moseyed over to see what films were playing, hoping to see a Bollywood movie with English subtitles. Instead, they had Despicable Me 2 playing, which I could not resist. The ticket plus samosa and Slice mango drink cost only a few dollars – a fraction of the typical movie cost in the USA. However, when I entered the theater, an armed guard who didn’t speak English forcibly patted me down. In public places, Indians took security very seriously. My coworkers told me the security was necessary to protect against Islamic terrorists.

Bangalore had such stark dichotomies. Near my hotel on MG Road were modern buildings with posh stores and fancy restaurants and security guards, while right around the corner were dilapidated houses with refuse burning on the street. Next to billboards for mobile phone plans were temples with innumerable statues. Two constants, though, were the crowds of people everywhere and, sadly, the pollution they left behind.

fruit stands are common

A mango peddler near Mindteck.

Hinduism

I passed many Hindu temples while riding around in my cab.

The Food

It’s a good thing that I loved Indian food. At work, my Indian counterparts showed much hospitality through their food. Every day, they provided lunch for me. One day, Mindteck catered a full lunch buffet as part of a meeting marathon. On the day I was on-site at NetApp, a friend bought me lunch in the cafe – 100 rupees, or about $1.50. For the remaining two days, both NetApp and Mindteck planned off-site lunches at delicious Indian restaurants. I ate it all: rice, naan, roti, curry of every color, chicken, lamb, paneer, aloo, palak, and gulab jamum for dessert. Nobody was surprised that I was “non-veg”, but they did appreciate my culinary adventurousness. For me, I was surprised to discover that, in India, eating with your bare hands is normal.

india-gulab-jamun

Gulab jamun, hot and fresh at an Indian buffet.

In the evenings, I had two fancy meals on my own. The best was my last night at the hotel. Since NetApp covered all travel expenses, I chose to eat dinner at the Hyatt’s fancy restaurant. It was totally empty, but that meant I received the best service. After serving my chaat and my curry, the head chef himself came out to greet me. The other fancy dinner was at a South Indian restaurant on the top floor of the nearby shopping mall – prawns, yellow-green curry, and round flatbread washed down with a Kingfisher. When the waiter served the food, he put the napkin on my lap for me. A third dinner I ate at the hotel’s standard restaurant while they played live music. On the night I went to the movies, I ate a Chicken Maharaja Mac at McDonald’s – let’s just say the Big Mac is better with beef.  (Come on, I’m a red-blooded American.)

Southern Indian curry.

The South Indian dinner at the fancy shopping mall.

These were the best shrimp I have ever eaten.  Indians always call them "prawns."

Some of the best “prawns” (not shrimp) I’ve ever eaten.

The Maharaja Mac is made using chicken, since it is illegal to kill cows.  The combo cost about $3.25.

The Chicken Maharaja Mac Meal. #MURICA

Goodbyes

On my last day in Bangalore, I wore my kurta. As I left in the morning, the front desk lady at the Hyatt shouted out, “Very nice kurta, Mr. Knight!” My Mindteck team planned a proper sendoff in the afternoon. We took group photos, and they gifted to me a small desk clock that I keep to this day. And they offered one final treat – an ice cream bar. There were six small scoops of various colors, and I had to taste each to guess the flavor. To everyone’s surprise, I got them all right! I didn’t have the heart to tell them that I suffered from lactose intolerance. My belly ached during the whole flight home, but the experience was well worth it.

My flight out of Bangalore departed in the wee hours of the morning. My cab picked me up from the airport shortly after midnight. I flew to Qatar, then NYC, and finally to Raleigh for a nearly day-long transit. My biggest regret was not having enough time for sightseeing in India.

india-mindteck-team

The Mindteck team and me: coworkers and friends.

 

Lactose intolerance in India sucks.  I ate the ice cream anyway.  These flavors are blueberry, mango, baked apple, jackfruit, lychee, and watermelon!

The ice cream bar, from left to right by row: strawberry, banana, lychee (?), jackfruit (?), mango, and blueberry.

Lessons Learned

I gained a genuine appreciation for our offshore teams after my trip. Oftentimes, I hear American workers complain that offshore workers are “stealing jobs,” and “you get what you pay for” in quality of work. But I learned firsthand that these folks are good people just trying to make a living. They aren’t trying to steal our jobs – they’re taking the opportunities in front of them as part of a global economy. Frankly, big companies hire offshore resources so they can throw more bodies at their projects. And quality suffers greatly when any team is not co-located due to challenges with communication, time zone, technology, bureaucracy, etc. Moreover, our guys and girls wanted to be more than just hired help: they sought to learn more, improve their skills, and increase their contribution.

Overall, I was very grateful for the opportunity to visit Bangalore, and I hope to return some day!

 

This post is dedicated to all of my friends from India.