I know the subject of this blog can cause some confusion, but that it’s the intention of it, perhaps you have never heard about the SDET term or position, so let’s define that first.
The term was originally used by Microsoft and then Google, Over the years, more and more companies are hiring SDETs as it’s a pivotal role in Agile and DevOps. It is a challenging role to fill as technology changes occur
A Software Developer Engineer in Test (SDET) is a technical software tester with a focus on developing automated test scripts. Typically, they are part of an agile team and work alongside developers to help automate Acceptance Criteria in user stories. As well as participating in typical QA activities, they can write anything from automated integration tests, API tests and/or UI automation tests.
In addition, SDETs could help review unit tests which are written by the developers.
You would be able to find a lot of definitions about this term in Seth (Eliot, 2010) which has this definition “The SDET role can be compared with Software Developer Engineers” the key difference is that the SDET responsibility is to ensure the quality of the software and implement testing.
The same article (Eliot, 2010) gave us a better description of this position: “The SDET is also a developer. The SDET must have knowledge of what represents good software design”. Also, he said that SDET’s “usually play a contributory or reviewer role in the creation of designs for production software.” There´s a phrase that I like because has an abstract definition about SDET position that says “SDET is none other than developers, but they do develop only one feature called TEST.” (Velu, 2016).
Velu (2016) explains the responsibilities of an SDET should have. He believes that as an SDET you should be able to create automation test cases and maintainable automation test code to make easier to test the application. Also, the SDET can propose the best way to do it or new frameworks to do the work.
According to Schwantes (2018) describes the reasons why people really quit their jobs, and I think these 3 are really important:
1.- Poor communication with the team.
2.- Failure to listen.
3.- Not Making themselves available.
Grant, Harrington, Gale & Goler (2018) in their article said a phrase that relates to this problem “People don’t quit a job, the saying goes — they quit a boss”, so, basically could be contributing to SDET’s attrition if you don’t have that a fluent and clear of communication. Also (Grant et al.,2013) in the same article mentions “If you want to keep your people it’s time to pay more attention to how you design their work. Most companies design jobs and then slot people into them”.
Here is an example:
The average cost for your company for an employee considering “none billing time, recruiting, time to onboard and ramp-up” is $72,000 USD only in the United States per year. This estimate may vary a bit, but it gives the certainty of how expensive it is to let your employee go.
So according to what we learned, an SDET should be focused on the testing part by developing automation suites that will help in all the software development life cycle. Yes, a SDET is a developer, but s/he should be in balance between developing and testing skills and it doesn´t mean that you can switch this person between QA and Dev when needed without an impact, you should have a deep conversation about it with your SDET first and understand his/her feelings about this kind of changes, otherwise, you may affect your project end results
We know all projects require changes, but first, let’s take in mind all the factors to make a successful long run for all your team and contributors, if you have any questions reach us at Intersys Consulting we can help you to handle it, we have the expertise.