Let’s face it: working in software is tough. I’ve worked in software for over a decade, and I’ve learned a lot of things during my journey – oftentimes the hard way.
On April 7, 2022, I tried something new: every hour for 24 hours, I tweeted a lesson I learned during my software career. I covered topics like breaking into the industry, working on projects, and seeking advancement. I used the hashtag #PandyEveryHour to track my tweets. I started at 8am (US Eastern) on April 7, and I concluded at 8am on April 8. It was an awesome experience: lots of folks liked, retweeted, and commented. Some of my insights struck nerves.
In case you missed it while my tweets went live, I compiled all the tweets below in order. Give them a read! If you like any of them in particular, be sure to “like” them on Twitter so I know!
Breaking into the software industry
Working with others
Improving your skills
So, which lessons resonated the most with you? Which did you disagree with? Let me know!
The main photo for this article was taken at DjangoCon 2019 during one of the breaks between sessions.
At my new job as Developer Advocate at Applitools, I now permanently work remotely. Working from home is new to me. At my previous company PrecisionLender (later acquired by Q2), I worked in an office that was a seven-minute drive from my house. My office was a real office: an enclosed room with a door, walls, a large desk, and two huge whiteboards. Working from the office was a joy. We had free snacks and sodas. My colleagues and I all got along great, and we’d go out to lunch almost every day. After COVID-19 hit the USA in March 2020, I was heartbroken to abandon the office. I was so stubborn about eventually returning to the office that I refused to set up a decent workstation at home. For a year and a half, I worked exclusively on my laptop either from a desk in my living room or from the couch – no monitors, no mouse, and no separate keyboard. I mean, come on, the pandemic would be over in a few short months, right?
However, my attitudes about remote work are changing. At PrecisionLender, I was spoiled with the best kind of office situation someone could have. Many others in the software field are not so fortunate. Those who live in the big cities like New York and San Francisco pay thousands of dollars a month to split tiny apartments and spend an hour or more on one-way commutes. Not to mention, many of them move away from family and friends to take those opportunities.
Office layout trends in recent years have also been dismal. The open layout – no walls with clusters of desks sloppily smashed together – is the norm. Perpetual audio and visual distractions are a nightmare for anyone trying to concentrate. Widescreen monitors and noise-cancelling headphones only help a little. I experienced that frustration at MaxPoint and LexisNexis. Cubicles, while passé these days, are only a small step up from open floors. While the “walls” block out visual distractions, you can still hear everything that goes on around you. Plus, the enormous blocks of cubicles on a floor feel brutally confining. I frequently called the IBM 500 complex in RTP “Cubicle City” when I worked there.
Remote work can be a godsend for many hardworking folks who just want to do a good job while doing right by themselves. Folks, especially in software, can literally work anywhere. COVID-19 shutdowns have proven it. My wife and I even took advantage of it: we bought a vacation condo in Seattle, and I worked remotely from there for several weeks. I could automate tests during the day, grab beers with close friends, and catch a Mariners game on the weekend. Even with a 3-hour time zone difference, I was right in step with my team the whole time.
Recently, I saw a Twitter thread by Chris Herd in which he made several predictions on remote work in 2022 and beyond:
This thread really resonated with me. While I still have some concerns about remote work, I do believe it will be a net good for not only my country and people but also for the world. I’d like to highlight some of the points he made that really stuck out to me.
I agree completely with this, and I’m excited to see it happen. The US has so many awesome places, from sea to shining sea. There’s no reason why someone should need to move from their hometown to a big city just to work for a specific company (unless, of course, they want that adventure). Places like Raleigh-Durham, Nashville, Denver, Miami, Pittsburgh, Salt Lake City, Cleveland, and countless other smaller American cities are fantastic places to live. Each has a unique vibe and local specialties. Allowing folks to live where they want with good employment opportunities will rejuvenate local and regional economies. It will bring broader prosperity to all.
This is happening already. The Triangle of NC, where I live, is booming. My wife and I rent local listings on Airbnb, and all through the pandemic, the #1 type of guest we’ve hosted by far is someone interested in relocating to the Triangle.
I hadn’t thought about asynchronous work until Chris mentioned it, but he’s right. Life is 24/7, and people live all around the globe. Remote work can liberate us from a harsh 9-5 and instead embrace more flexible hours. For example, this past week, I had to work around the clock for a few days prepping a big webinar. However, I wasn’t working for 16 hours straight each day. I woke up a bit late, did some light administrative activities before lunch, hit it hard all afternoon, stopped for dinner and time with my puppy, and then burned the midnight oil after dark. That’s what worked for me.
Yes! I’m living it myself. My wife and I just adopted a French bulldog puppy, and I also started restoring a vintage 1970 Volkswagen Beetle.
I sure hope so! Break down those entry barriers. Do away with the gatekeepers. End coastal elitism.
I sure hope this one becomes true, but I’m skeptical.
This one is so ironic. Based on many articles I’ve read, upper management seems to despise work-from-home because they think their workers will work less. However, all the good, hardworking folks I know are actually working more than ever. Not only are folks more efficient, but they tend to keep working just a little extra because there are fewer barriers between work stuff and personal stuff. In my new job, I know I’m certainly working more hours right now than I probably should, and I’m hoping to settle into a more sustainable routine as I acclimate to my new role. Nevertheless, we absolutely need to protect ourselves against unintentional burnout.
One big concern I have with remote work is the loss of in-person contact. Humans need to be around each other, and screens are a poor substitute. I know I’ve felt lonelier working from home than when I worked in an office. That’s why I absolutely love this idea about regular remote retreats. Companies can still bring folks together, and they can hire professionals who know how to maximize that time. I go to software conferences frequently for similar experiences.
I think this goes hand-in-hand with async work. However, unless safeguards are put in place to prevent overworking, then life-work balance could quickly become work-more-work imbalance.
Honestly, this one was never much of a problem for me. The only “paddings” I’ve had in my workdays are long, boring meetings where I participated little. Thankfully, those were confined mostly to my days at IBM and NetApp earlier in my career.
YES! Even though my commutes have always been relatively short, I still appreciate the time I get back in my day. Here are some things I’ve done with my extra, more flexible time:
Sleep in a little later
Play with my puppy when I need a break
Share lunch nearby with friends
Run a quick errand in my Beetle
Grab an impromptu bubble tea with my wife
Take a walk around my neighborhood while thinking about work-related challenges
Documentation is the unspoken superpower of remote teams. I strongly value written communication for its clarity, searchability, and permanence.
Chris had lots of other good tweets in that thread, so be sure to read them. Overall, his tone was bullishly optimistic on remote work – not only in its benefits, but also in its inevitability. Personally, I hope remote work is here to stay, and that it’s not just a phase brought on by the COVID-19 pandemic. It’s a game-changer for individuals and industries alike. However, I’m still somewhat fearful that big companies will reign in wide scale returns to the office after the pandemic. Giants have already sunk millions to billions in commercial real estate for their offices that they can’t get back. I’m also worried about salaries in different geographies. Employers already pay folks who live outside of big cities much less for the same work due to cost-of-living differences. I don’t think that will be fair as people leave big cities in droves for smaller cities or the countryside. Already, the cost of living is skyrocketing in the Triangle, yet our average tech salaries are far below those of Silicon Valley. We’ll see what happens.
Overall, I am optimistic about remote work just like Chris.
So, what do y’all think? Please leave comments below. I’d love to learn different perspectives!
I’ve always been frustrated with poor quality audio recordings. Microphones built into laptops are very convenient, but they usually yield tinny sound lacking the depth of real voices. When I asked my audiophile friends for advice, they recommended studio-level equipment that was beyond my comprehension and my budget. As a software guy, I just wanted an audio setup that captured high-quality audio while still being convenient for everyday usage. I’d need it for remote meetings as well as for recording talks and tutorials. I was willing to pay for good equipment as long as I could use it well. Unfortunately, my biggest frustration was ignorance. I didn’t know anything about recording.
When I did my research, the Blue Yeti microphone was at the top of everyone’s recommendation list. The nicest thing about a Blue Yeti mic is that it connects via USB. You simply plug it right into your laptop and select audio input and output channels. The mic doesn’t need an external power source, either.
Initially, I bought only the Blue Yeti mic and the foam windscreen. Instead of using the boom arm, I used the tabletop stand that came with the mic for all my recordings. This was a big mistake. The tabletop stand picked up a lot of local noise, like typing on a keyboard. The audio quality it picked up also sounded like it had a bit of an echo, which may have been due to sound bouncing off the tabletop or my hardwood floors.
The boom arm and shockmount made a huge improvement in recording quality. Plus, with the boom arm mounted firmly to my desk, I can easily move it towards me for recording or out of the way otherwise. It feels quite sturdy. I chose to use all Blue products so that I could be certain that they’d work together. You can save quite a bit of money if you buy the microphone, boom arm, and shockmount together as a bundle on Amazon (~$200), instead of a la carte like I did (~$250).
I plan to get a docking station for my laptop so that I can plug the microphone’s USB cable into the dock, simplifying desk’s cable management.
Even with this new setup, I still felt like I didn’t understand how to use my Blue Yeti microphone to its full potential. Thankfully, YouTube came to the rescue! This video greatly helped me understand things like tuning the mic’s gain and positioning the mic while speaking:
In summary, here’s what I like about the setup:
It yields very good (maybe professional?) audio recording quality.
It is simple enough for anyone to set up and use.
It is convenient to use for remote meetings, video recordings, etc.
It feels quite sturdy.
It is relatively affordable (compared to other audio equipment).
Please note: I am not an expert in audio equipment, and this article is not sponsored by any company. I simply hope that someone can benefit from the things I learned (and possibly save a few bucks) if they want to improve their own recording game!
Happy Global Testers Day! For 2021, QA Touch is celebrating with webinars, games, competitions, blogs, and videos. I participated by sharing an “upside-down” story from years ago when I accidentally wiped out all of NetApp’s continuous integration testing. Please watch my story below. I hope you find it both insightful and entertaining!
In February 2021, Matthew Weeks interviewed me for the Work in Programming podcast. Matthew asked all sorts of questions about my story – how I got into programming, what I learned at different companies, and why I started blogging and speaking. I greatly enjoyed our conversation, so much so that it lasted an hour and a half!
If you’re interested to hear how my career has gone from high school to the present day, please give it a listen. There are some juicy anecdotes along the way. The link is below. Many thanks to Matthew for hosting and editing the interview. Be sure to listed to other Work in Programming interviews, too!
Back in 2011, I was a recent college grad working at IBM as a “performance engineer” for z/OS mainframe software. Now, I didn’t know anything about mainframes, but I was thankful to have a job on the heels of the Great Recession.
At the time, IBM had recently released the Jazz platform with Rational Team Concert (RTC), a collaborative project management tool geared towards Agile software development. Teams company-wide started adopting RTC whether they wanted it or not. My team was no different: we created a team project in RTC and started writing work items in it. In my opinion, RTC was decent. It was very customizable, and its aesthetics and user experience were better than other tools at the time.
One day, I made a typo while trying to assign a work item to myself. When typing a name into the “owner” field, RTC would show a list of names from which to choose. For whatever reason, the list included all IBM employees, not just members from my team. IBM had nearly 400,000 employees worldwide at the time. I accidentally selected someone else with a similar name to mine. Blissfully unaware of my mistake, I proceeded to save the work item and start doing the actual work for it.
About a day later, I received a nastygram from another IBMer named Andrea Knight, demanding to know why I assigned her this work item in RTC. I had never met this person before, and she certainly wasn’t on my team. (To be honest, I don’t remember exactly what her name was, but for the sake of the story, we can call her Andrea.) At first, I felt perplexed. Then, once I read her message, I quickly realized that I must have accidentally listed her as the owner of the work item. I immediately corrected the mistake and humbly replied with an apology for my typo. No big deal, right?
Well, Andrea replied to my brief apology later that day to inform me that she was NOT responsible for that work item because she had NEVER seen it before and that she would NOT do any work for it.
I was quite taken back by her response.
I let it go, but I couldn’t help but wonder why she would answer that way. Perhaps she was having a bad day? Perhaps her manager scrutinized all work items bearing her name? Perhaps the culture in her part of the company was toxic? Was my mistake that bad?
Even though this incident was small, it taught me one important lesson early in my career: a little bit of grace goes a long way. Poor reactions create awkward situations, hurt feelings, and wasted time. If we make a mistake, we should fix it and apologize. If someone else makes a mistake, we should strive to be gracious instead of unpleasant. I try to practice this myself, though, sometimes, I fail.
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:
Someone asks me to be their mentor.
A manager or team leader arranges a mentoring relationship.
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).
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
Helpful for independently learning specific topics
May be blogs, articles, or documentation
Allows the mentee to complete it at their own pace
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:
A small group activity for doing Example Mapping on a new story
A work item to write Gherkin scenarios for that mapped story
A review session for those scenarios
A “BDD test frameworks” deep dive session with me
A work item to automate the Gherkin scenarios they wrote
A review session for those automated tests
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.
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!
PyTexas 2019 was an incredible Python conference. It was held at the Central Library in Austin, Texas from April 13-14. I’m so glad I went. Even though this was my seventh Python conference, it was one of my favorites so far. Here’s a brief recap of my experiences.
Why I Went
I consider myself very fortunate to have been able to go to PyTexas 2019. After my talk proposals for PyCon 2019 were rejected, I saw this tweet from Dustin Ingram, the conference chair for PyTexas:
Thankfully, my talk was the very second talk of the conference. I could get it out of the way early so I could enjoy the rest of the conference without the nerves. And everyone always loves the pandas.
I also gave a Lightning Talk for the first time! I talked about the difference between unittest and pytest. My talk starts at 30:17, but be sure to listen to all of the talks.
I’d also like to thank my employer, PrecisionLender, for sponsoring my trip and enabling me to speak.
Talks are usually the main part of any conference. PyTexas 2019 was a single-track conference, meaning that everyone saw all of the talks. All talks were memorable for me, but I’ll write a separate post about the talks once all the recordings are posted. Here, I’ll cover other awesome things that happened.
My Recovery Day
Things had been very stressful for me in the first few months of 2019. I came to PyTexas essentially exhausted from life, and I needed a “Self Care Sprint” (as Kojo would say). So, that’s exactly what I did: I flew into Austin on Friday morning and spent the whole afternoon just being a low-key tourist. I ate a Texas-sized lunch at Stubb’s BBQ, viewed the artwork at Mexic-Arte Museum, walked along the Colorado River, and nearly fell asleep in the Central Library after perusing the stacks. That evening, I met up with other speakers at the Spider House for an informal pre-conference get-together. Even though I wasn’t “productive” by any professional definition, I felt thoroughly refreshed and ready for the excitement to come.
Austin has been invaded by electric scooters. They are on every street corner. There must be half a dozen different brands. Even Uber and Lyft have scooters for rent! Instead of hailing ride shares downtown, I just hopped the nearest Lime scooter. They go really fast, and they’re tons of fun!
The First After-Party
Literati Books generously hosted an after-party at Jo’s Coffee after the first day of the conference. I got to spend time with a bunch of cool people from the conference while enjoying sliders and craft beer. Carl even shared some of his jerky with us!
Other Testing Talks
I always get a rise out of testing talks at conferences. Python conferences always have a few but only a few. PyTexas had three. I think Kojo‘s tweets summed up my enthusiasm perfectly:
The Zen of Python Teams
Adrienne delivered one of the best keynote addresses I’ve ever attended. Seriously, go watch it. She talked about how the Zen of Python can be applied not only to code but also to teams. The best part was the “Easter egg” at the end. The Zen of Python famously leaves the 20th line blank so that we can make it for ourselves. Adrienne challenged us to come up with our own 20th point after handing out real Easter eggs to everyone in the audience! Mine? People matter.
I had never eaten at Whataburger before. This trip, that changed. William, Brian, and I hopped on those electric scooters and went to the Whataburger across the river for lunch on day 2. The patty melt was tasty, but the Dr. Pepper milkshake was out of this world! The views from the bridge were gorgeous as well.
The Second After-Party
After the conference ended, William, Aly, and I went to Mort Subite, a cool Belgian beer bar, to celebrate and unwind. Then, we rode electric scooters over to Baton Creole for a late-night dinner with Adrienne. We had some good food and even better discussions. It was the best way to end PyTexas!
PyTexas was the first conference where I felt like I fully belonged from day one. Every previous conference was a bit of a shot in the dark for me because I was still new to the Python community. PyTexas 2019 felt almost like a reunion. I strengthened existing friendships and made new ones: Adrienne, Kojo, Dustin, Ernest, Aly, William, Piper, Andy, Carl, Mason, Michael, Brian, and so many more. I also felt like I made a bigger impact at PyTexas than at other conferences because I genuinely felt like part of the community.
We should never take conferences (or any moments) for granted. Truly wonderful things happened at PyTexas. I felt creative. I felt inspired. I felt challenged by new ideas. I felt the itch to try new things. I left on a post-conference high and, surprisingly, I wasn’t particularly tired. The organizers did a phenomenal job running the conference smoothly and successfully. Seriously, hats off to them – many thanks for a job well done. As attendees, we should be grateful for all the hard work so many people did for the conference, and we should capitalize on what we take away from the conference.
Single-track and multi-track yield two very different conference experiences. PyTexas 2019 was my second single-track conference and my first one for a Python conference. Overall, I think the single-track format worked very well. Putting everyone on the same track in the same room builds a strong sense of camaraderie. It also gives speakers a much more prominent platform. However, multi-track provides more choices for attendees, and it gives more people the opportunity to speak. Both are good. I think it would be cool if future conferences do both: maybe one day for single-track and another day for multi-track.
I’m going to (attempt to) develop a new Python package. For a while, I’ve wanted to implement a particular testing pattern in a Pythonic way. My goal is to develop and release it to PyPI as an open-source package. I never had the time or clarity to do it until now. PyTexas gave me a huge boost, and I hope I can carry my vision through to delivery!
People matter. The Python community is a truly wonderful group. People come for the language and stay for the community – it’s true. PyTexas 2019 has challenged me to be a better person and to help people through software.
I am a Software Engineer in Test (SET). Many people don’t know quite what that means, though. Developers frequently refer to me as a “tester” or “QA,” and a former director once thought I did DevOps. While my work covers these areas, they aren’t the main focus. Let’s clarify what it means to be a SET.
What is a Software Engineer in Test?
A “Software Engineer in Test” (SET) builds solutions to testing problems. Those problems could include slow feedback, flaky tests, costly runs, poor product quality, lack of communication during development, and more. In some circles, the role is called “Software Development Engineer in Test” (SDET).
Frequently, SETs focus on developing test automation solutions for running tests quickly and repeatedly. Test automation is a software product, after all. Just as front-end developers write web pages and back-end developers write microservices, SETs write automated tests. The same practices and coding skills apply. I frequently say that a Software Engineer in Test must have the heart of a developer.
However, a SET is more than just an automation engineer. SETs also look holistically at quality through the software development lifecycle. They build systems for fast feedback, such as Continuous Integration pipelines and reports. They work with developers and product owners to develop good product designs. They provide tools and frameworks to empower others to cover any testing needs. At times, they may also jump in to help a team with manual and exploratory testing.
So they just write test scripts?
No. Never say this to a SET. Test automation involves much more than just “writing test scripts.” A serious testing solution requires serious design and effort. The top-level automation of a test case is usually just a small piece. SETs are responsible for:
Collaborating with developers and product owners
Contributing to planning and design
Reviewing product code
Formulating test scenarios
Developing test automation frameworks
Automating test scenarios using the frameworks
Knowing and using design patterns where appropriate
Setting up dashboards for reporting test results in real time
Teaching others good quality and testing practices
Developing tools to assist manual and exploratory testing
Saying that testing is “just scripting” belittles the role of the SET and underestimates the workload it requires.
How did this role start?
Software “tester” and “QA” roles have existed for decades, but the SET role first became distinct in the 2000s when large-scale test automation became both feasible and necessary. According to Wikipedia, Microsoft coined the title “Software Developer Engineer in Test” (SDET) in 2005, and others like Amazon and Apple quickly adopted it. Google coined the name “Software Engineer in Test” for the same type of role. I personally prefer the SET title over the SDET title simply because it is more concise.
How is it different from “QA” or “testing” roles?
To me, the SET role is distinct from the traditional “QA” or “testing” role. Software testers historically focused on manual testing and thus didn’t need strong programming skills. Their fortes were product domain knowledge, intuition, out-of-the-box thinking, test planning, and test system setup. And these certainly are important, indispensable skills! SETs, however, live in both the development and testing worlds. They use developer skills to provide software solutions for testing problems. Automation is usually much more central to the SET role. Nevertheless, there will always be a need for manual testing because there are some problems a human can catch much more easily than a script (or an AI agent). A traditional tester will be responsible for doing test cases for a team, while a SET builds the solutions to empower other testers and developers to do the testing.
Personally, I avoid using the titles “QA” and “software tester” for myself because they don’t accurately describe all that I do. I also avoid the title “automation engineer” because, again, it is reductionist. I tackle software testing with the heart of a developer, and I set up test automation solutions from the ground up. I’m proud to be a software engineer who specializes in testing.
As a bonus, check out Test and Code episode 47, in which Brian Okken and I discuss what it means to be a Software Engineer in Test (among other topics).