DEV Community


What is a Software Development Engineer in Test Anyway?

Doug Arcuri
Short writings about software engineering and design.
・3 min read

During my time in the industry, I have worked with talented software development engineers in test (SDET's). Also known as software automation engineers, QA engineers, and other associated titles, they practice a discipline of skill sets to assert the quality and affirm the user experience. Here are my top appreciated attributes.

They find issues sooner. Test engineers typically find ways to diminish quality concerns early. Whether it is reviewing requirements, participating in code review, asking engaging questions, they help identify bugs to reduce the cost of fixing defects later. As a result, they catch defective releases well before going out the door, protecting user experiences and company reputation.

Uncover critical insights with the product team. When product requirements are defined, QA engineers find ways to assert the quality of those features and assure it solves the customer needs. They continuously encourage adding metric analytics for insight. In addition, they work closely to the time estimate by leading a testing plan that is concise and thorough.

Partner with software engineers. SDETs pair closely with software engineers to find areas where code coverage can be placed. And apart from adding enough test coverage, they push further with code-generation, setup, and tooling to make engineers effective and continuously deploy with confidence. Finally, they also encourage the team to test constantly.

Actively brings in new test techniques. Whether it be mutation testing, property-based testing, unit, integration, and new mocking approaches, they find ways to use these techniques and frameworks to test comprehensively. They also organize and lead game days, bug bashes, and actively invest in applying methods in chaos engineering. Finally, they actively educate the team to leverage these tools.

Organizes test suites for effectiveness. When unit and integration tests developed, they promote continual improvement, organizing fixtures, stubs, and mocks efficiently. In addition, these tests support new implementations. They add functional and end-to-end tests to assert the intentional functionality of the system. Above all, the tests are logically separated and ordered, making it easy to run the desired tests at any time.

And promote refactoring and automation. For every test suite, test engineers improve the confidence of the product. They empower the software engineers to move forward with refactors. By doing so, their actions promote the effectiveness and investment of each codebase under test. All these tests serve as living documentation and are hermetic in nature.

They discover edge case scenarios. When requirements can be challenging to automate, they quickly find the edge cases through clever exploratory testing. And with these cases, they see a way to cover these routes with record and playback, ultimately improving adopter satisfaction.

Implements advanced testing methodologies continuously. Test engineers are familiar with exotic ways to test each system. These methodologies include load, stress, visual, performance, and behavioral testing. And if they are not aware, they bridge the communications with the team to those that can. This practice leads to better software acceptance outcomes.

Goes farther with contributing directly to the codebase. At times, SDETs actively contribute to the software engineering side of the product. They are fearless by taking on parts of the system and then writing the tests to back up the quality of their contributions.

Are aware that flaky tests discourage testing. They actively find ways for the test suites to run smoothly. And they confirm tests either succeed or fail deterministically. They quickly stomp out test suites that are best flaky. In the end, they continue to harden and improve the test suite, so there is continued trust.

They are well educated in all the iterations of test philosophy. Testing is complex. And SDETs know all of the visual metaphors of test suites. Whether it's honeycombs, pyramids, trophies, hour-glasses, or ice cream cones, what is most important is to build extendable test suites that find issues sooner.

Much more than janitorial, a discipline that must happen. While slogans such as the engineers assert the quality and QA should find nothing encourage test ownership, and the tech companies that post insightful craft techniques in restrooms to share test burden collectively, better outcomes can be achieved with SDET's on the team. They are the humility makers, shape business reality, and execute well in this maturing craft.

Discussion (0)