Five Keys to Finding Success as an SDET

Defining skills needed for a role is an interesting challenge; just look at any must-have skills for open Software Development Engineer in Test (SDET) positions as an example. They tend to contain requirements like: “*arbitrary number of years* programming experience in *insert programming language*”, “*arbitrary number of years* writing, maintaining, and executing clear detailed test plans”, and/or “experience using *array of testing and development tools*”.

At best, this is a generalized list of skills that should be obvious you’ll need as an SDET (programming skills, testing skills, interpersonal communication skills, etc). Let’s dive deeper and explore skills that are learned and not as easily put on a one-line required skill job description. The following are five keys I’ve learned that have helped me find success as an SDET at Glassdoor.

Five Keys to Success as an SDET

Drive all layers of the testing pyramid

Image provided by Elias Nogueira, via this article

Learn what to automate, and where to automate it. There are countless articles to read about the test pyramid and how it should be implemented, but in my experience (and also what I’ve read in articles/discussed in workshops) the reverse of the test pyramid is much more common. I’ve firsthand seen this fail for three main reasons.

1. There was not an emphasis on driving unit test coverage on feature code
2. Development and QA were two separate efforts that did not collaborate
3. “Manual Testers” and “Automation Engineers” were two separate positions; manual testers wrote test cases, and automation engineers automated those exact flows, and only those exact flows per direction of management. This would lead to slow, brittle, unreliable tests.

Implementing the test pyramid properly requires much more collaboration between developers and SDETs, and I recommend the SDET drive the effort.

Work with your front end engineers (before development of a feature) to decide what should be automated with a lightweight, component-based framework (like React Testing Library) that will live alongside the feature code and what should be automated end to end (with something like Selenium) in a separate repository. If the front-end developers need some help automating the RTL tests, jump in! Having these two layers will provide you end-to-end tests for regression testing, as well as give the developers some peace of mind having RTL tests that can run quickly against every new build!

Ensure the back end has both unit tests and integration tests. I wouldn’t recommend jumping in to help with the unit tests, leave this to the developer, but surely jump in to help with integration tests if needed. Regardless of who is writing the tests, setup SonarQube for metric tracking. This will provide details around code coverage, security vulnerabilities, tech debt, and more.

Go beyond testing

As an SDET, your team will come to you with a lot of questions. Try to document everything you can in an easily accessible place for all of your team members (I recommend an internal wiki if your company has one of these). If you’ve been asked a question, chances are you’ll be asked that same question again. Keep all of your test plans, bug bash notes/results, and feature breakdowns (I like to break down entire features to explain what they do, happy path walkthroughs of them, and errors that can occur when using the feature) all in one place. Be sure to include links to applicable documentation that others have written as well (tech specs, database schemas, future design enhancements, etc).

Provide metrics to your team. Create dashboards to display quality metrics and bug tracking and create monthly quality reports. Display how many open bugs your team has. If you see Developer A has 4 bugs assigned to her/him, and Developer B doesn’t have any, you can help divvy up that work, or at least provide some insight around it. But also track the wins as well. Did your team just have a great sprint and close 6 bugs? Display it! Did your team catch a security vulnerability before a new feature was shipped? Call that out as well! This can help boost team morale.

Create scripts and/or tools that can help your teammates be more efficient and productive, while at the same time helping you! Is there a manual task that needs to be done every day and always takes 5 minutes? Automate it! Do you need to be able to create test accounts on the fly with different permissions? Automate that as well! If your teammates are coming and asking you for things often, disrupting both their workflow and your own, find a way to automate it.

Be technical

I’ve read and heard about organizations creating automation frameworks that allow manual testers that are not as technical to write automation scripts by minimizing the amount of code that needs to be written. They want to be able to have manual testers be able to automate, so that way manual regression goes down, but they don’t need to hire someone with enough coding knowledge to write test scripts. Show that you can do more than write test scripts! Learn as much on the technical side that you can. Here are some things I’ve learned that have helped with this:

• Structure of the code base (example: controller -> service layer -> repository)
• As bugs are being reported, I see if I can find if it’s a back-end bug or a front-end bug by leveraging Chrome dev tools to dig into console and network errors.
• Navigating stash to find the code where the bug is failing.

If you file a bug, and have details with which environments it’s failing in, with login credentials, easily understandable steps to reproduce, the failure that occurs, and maybe a video or image, your developers will likely be happy. However, if you can give them all of that, PLUS know who to assign it to (FE or BE dev), the line of code where it’s failing, and the error message the code is throwing, they’ll be able to resolve this bug even more quickly. Once you gain more experience and are feeling comfortable, pull the code base and see if you can make the fix yourself!

Think from every angle

Perhaps one of the most unique parts of being an SDET, is the opportunity to think about the product from different angles. I try to put myself in all positions (end-user, product, design, developer, and tester). How is the end-user going to use this feature? If I was going to use this, how would I want it laid out and presented to me (design)? What impacts (positive and negative) is this going to have on the business (product). What technologies will be leveraged to build this (developer and tester) and what is the ramp-up going to be for the team members. As an SDET, try giving meaningful feedback at all levels. Build great relationships with everyone on your team. Help drive product and design decisions. Know the feature inside and out BEFORE it’s even built, that way you can provide developers with a happy path and edge-case scenarios to consider during development.

Learn tradeoffs

Perhaps the most important piece of advice, and something I am always striving to become better at, is to learn how to accept that there are going to be tradeoffs. Things to learn in this area:

• Prioritization: Just because a bug exists doesn’t mean it’s going to get fixed instantly. The reality is bugs are just going to exist, there is no way to get rid of all of them. Learn how to prioritize what bugs to pull in and when. Is it affecting a large portion or all of your customers? Is it impacting your customers from being able to use your software efficiently? Is it impacting revenue? Then this should likely be fixed before the annoying styling issue that is causing a dropdown to look a little wonky.
• Flexibility: Did you just spend the last few days writing out documentation, test cases, and creating data/organizing a bug bash for a new feature, to be told there’s been a company strategic shift, and there will be a delay of this feature? Accept that this can happen. Put your best foot forward and keep moving. You can really bring down the energy around you if you get upset, but you can also be a motivating voice in a time of potential uncertainty.
• Workarounds: We should always strive to deliver a desirable, well-polished experience for the end-user (and for ourselves), but issues will come up. If a customer is blocked by a bug, see if there is a workaround to unblock them while the bug is being fixed. This should not diverge us from the end goal of fixing the bug, but it will keep customers happy if we are able to unblock them quickly. Similarly, if you are blocked internally try to find a workaround. I’ve seen this often with test environments being down or unstable. No matter the issue at hand, the first step should always be finding a way to unblock whoever is being affected, and the second step is to find the long-term implementation/solution for the problem (and document all of the steps taken!).

Conclusion

I hope this article has provided you with some insight into ways to improve testing in your organization. No matter what your title is: SDET, Automation Engineer, Tester, Quality Analyst, I believe you can benefit from implementing the above ideas into your day-to-day role. Good luck, and happy testing!